From alexandru.petrescu@gmail.com Wed Jul 1 02:07:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED35E3A6836 for ; Wed, 1 Jul 2009 02:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 YHxGQbxL5f25 for ; Wed, 1 Jul 2009 02:07:47 -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 0490E28C3E3 for ; Wed, 1 Jul 2009 02:07:46 -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 n6197tcV013377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jul 2009 11:07:55 +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 n6197tZt016827; Wed, 1 Jul 2009 11:07:55 +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 n6197swm013090; Wed, 1 Jul 2009 11:07:54 +0200 Message-ID: <4A4B276A.9050107@gmail.com> Date: Wed, 01 Jul 2009 11:07:54 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Goindi, Manhar" , ROLL WG Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 09:07:48 -0000 Pascal, as I wrote in private, I doubt the necessity of using the term DAG and the associated DAG theory. Picturing a DAG without arrows makes doubtful sense (figure 1). A link between siblings would use bidir arrows, which would make for a 'loop', which we would try to avoid. Besides, what would an arrow between two nodes mean actually: is it that a node can send a packet to another node but not the other way around? Makes little sense to have all edges so unidirectional. Pascal Thubert (pthubert) a écrit : [...] > Q: Can siblings hear each other as it is not evident from Figure 2: > Example DAG? > > R: Figure 1 represents connectivity and you can see siblings hearing > each other. Figure 2 represents the DAG so it does not include the > sibling links. It should be clear whether or not the siblings can be linked together by links and direct routes or not. At some point in the draft this is explicitely forbidden (it says traffic from node a to node b deep in the network must pass through the DAG root) - this is not good. > Sibling links are bidirectional at the graph level though > unidirectional for a given packet. I don't understand. Do you mean that all links in the network (the DAG is the network) are _uni_directional? > We're missing the term to indicate the DAG+sibling_links. We should call it a network. A graph of paths hopefully loop-free, not necessarily guaranteed. But not a DAG. > Gradient is fine when you talk about pointing to the preferred > parent, but this is also a term that was overloaded in the past. What > else? A network. A net. A set of paths. A topology and the associated paths. A conceptual picture stemming from the set of routes present in each node's routing table. I don't understand the word gradient in this context, throughout the document. Is it a derivative of something? A differential of something? Alex From pthubert@cisco.com Wed Jul 1 03:16:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6D13A6F1F for ; Wed, 1 Jul 2009 03:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.908 X-Spam-Level: X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=0.691, 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 jLfrfLzA46Op for ; Wed, 1 Jul 2009 03:16:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3B8503A6F19 for ; Wed, 1 Jul 2009 03:16:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,323,1243814400"; d="scan'208";a="44089108" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Jul 2009 10:16:51 +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 n61AGppj006001; Wed, 1 Jul 2009 12:16: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.14.3) with ESMTP id n61AGpLL002461; Wed, 1 Jul 2009 10:16:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 12:16: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: Wed, 1 Jul 2009 12:16:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B245CB@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A4B276A.9050107@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4 Thread-Index: Acn6K4NJMgjR6M5zR9Kbehefsc6dcwABO5Rw References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com> <4A4B276A.9050107@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Goindi, Manhar" X-OriginalArrivalTime: 01 Jul 2009 10:16:51.0338 (UTC) FILETIME=[0CE5FEA0:01C9FA35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5530; t=1246443411; x=1247307411; 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[Roll]=20Fwd=3A=20I-D=20Action=3Adraft- dt-roll-rpl-00.txt=20Q2..4 |Sender:=20; bh=9tHLVKk3+nqjJe3RL/74cZ91J6azOo2EDJdtNcTFPcQ=; b=ZnfGdrc8anFNQAaLcMX2IIxyzoNdOIEvOLMaXIqhhtA/vbbSz6sDHf1q/1 1PchoO2X2AsS2irKsFaAazhaD1G/Ph96tBGrVU/Zv5zo+DwoMfdo3r/HtHI5 9TofpSOYXU; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 10:16:37 -0000 SGkgQWxleDoNCg0KVGhlIGxpbmtzIHRvIHBhcmVudHMgZm9ybSBhIERBRy4gSWYgeW91IGluY2x1 ZGUgdGhlIHNpYmxpbmcgbGlua3MgaXQgaXMgbm8gbW9yZSBhIERBRy4NCg0KWWV0IHRoZSByZXN1 bHRpbmcgZ3JhcGggaGFzIHNvbWUgcHJvcGVydGllcyBzaW5jZSB0aGVyZSBpcyBubyBvcmllbnRh dGlvbiB0aGF0IGxlYWRzIGRlZXBlcjsgc28gaXQgaXMgbm90IGEgZ2VuZXJhbCBuZXR3b3JrLiBU aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQgd2UgYXJlIGRvaW5nIGFuZCBtb3JlIGNsYXNzaWNh bCByb3V0aW5nIGlzIHRoYXQgd2UgUkVBTExZIHdhbnQgbXVsdGlwYXRoLiBTbyB3ZSBhcmUgcmVh ZHkgdG8gZm9yd2FyZCBub3Qgb25seSBhbG9uZyBhIGNsYXNzaWNhbCBEQUcgYnV0IGFsc28gdmlh IHNpYmxpbmdzLiANCg0KVGhlIGRlY2lzaW9uIHRvIHBhc3MgYSBnaXZlbiBwYWNrZXQgdG8gYSBn aXZlbiBzaWJsaW5nIGlzIHRha2VuIG9uIGEgcGVyIHBhY2tldCBiYXNpcyB3aGVuOg0KLSB0aGUg REFHIGRvZXMgbm90IGhlbHAsIG5vbmUgb2YgdGhlIHBhcmVudHMgaXMgdXNhYmxlIGF0IHRoaXMg dGltZSAoZS5nLiByZXRyaWVzIGZhaWxlZCkNCi0gcGVyIHBhY2tldCBsb29wIGF2b2lkYW5jZSBh bGxvd3MgdGhhdCBzaWJsaW5nIGZvciB0aGF0IHBhY2tldA0KDQpTbyB0aGUgd2hvbGUgcXVlc3Rp b24gaXMgaG93IGRvIHdlIHBlcmZvcm0gcGVyIHBhY2tldCBsb29wIGF2b2lkYW5jZS4gSW4gYSB2 ZXJ5IHJpY2ggd29ybGQgd2UgY291bGQgYWN0dWFsIHVzZSBhIHNvdXJjZSByb3V0ZSBoZWFkZXIg dGhhdCB0cmFjZXMgYWxsIHRoZSBob3BzIGFsb25nIGEgc2libGluZyBwYXRoIGFuZCB0cnkgYWxs IHBvc3NpYmlsaXRpZXMuIEkgZ3Vlc3Mgd2UgY2Fubm90IGFmZm9yZCB0aGF0LiBXZSBjb3VsZCBh bHNvIGJ1aWxkIGEgREFHIGJldHdlZW4gc2libGluZ3MgYnV0IGFnYWluIHRoYXQgd291bGQgcmVk dWNlIG91ciBvcHBvcnR1bml0aWVzLiBXaXRoIHRoZSBjdXJyZW50IGRyYWZ0LCB3ZSByZXNvbHZl IHRoZSBtb3N0IHByb2JhYmxlIGxvb3BzIGFuZCBsZXQgVFRMIGZpbmlzaCB0aGUgam9iLg0KDQpC YXNpY2FsbHkgaWY6DQotIG5vZGVzIHByZWZlciBwYXJlbnRzIG92ZXIgc2libGluZ3MsIHNpYmxp bmcgcGF0aCBzaG91bGQgYmUgcmVhbCBzaG9ydCwgYW5kIG1vc3RseSAxIGhvcC4NCi0gbm9kZXMg ZG8gbm90IGdpdmUgYSBwYWNrZXQgYmFjayB0byBhIHNpYmxpbmcsIG9yIHRoZXJlJ3MgYSB0aWUg YnJlYWsgdGhlcmUsIDEgaG9wIGxvb3BzIHdvdWxkIGJlIGF2b2lkZWQNCi0gVFRMIGlzIGRlY3Jl bWVudGVkIGFnZ3Jlc3NpdmVseSBhbG9uZyBzaWJsaW5nIHBhdGggKExpa2UgbWludXMgTiBpbnN0 ZWFkIG9mIG1pbnVzIDEpLCBsb29wcyBzaG91bGQgbm90IGNvc3QgdG9vIG11Y2gNCg0KVGhlIGxh c3Qgb3B0aW9uIGlzIG5vdCBpbiB0aGUgZHJhZnQgeWV0LiBJdCBpcyBvbiB0aGUgdGFibGUgZm9y IGRpc2N1c3Npb24uIEl0IGlzIGEgd2F5IHRvIGFkYXB0IHRoZSB1cCpkb3duKiB0byBJUHY2IHRo YXQgaGFzIGEgc2luZ2xlIGNvdW50ZXIsIGhvcCBsaW1pdC4gU28gd2Ugd291bGQgYWxsb3cgYW4g b3V0d2FyZCBwYWNrZXQgdG8gbWFrZSB1cCB0byBIb3AgTGltaXQgaG9wcyBhbG9uZyB0aGUgREFH LCBidXQgb25seSB1cCB0byBIb3AgTGltaXQvTiBob3BzIGFsb25nIHNpYmxpbmdzLCBhbmQgZGlz YWxsb3cgZ29pbmcgb3V0d2FyZC4NCg0KTWFrZXMgc2Vuc2U/DQoNClBhc2NhbA0KDQo+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21haWx0bzph bGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPlNlbnQ6IG1lcmNyZWRpIDEganVpbGxldCAy MDA5IDExOjA4DQo+VG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj5DYzogR29pbmRpLCBN YW5oYXI7IEpQIFZhc3NldXIgKGp2YXNzZXVyKTsgUk9MTCBXRw0KPlN1YmplY3Q6IFJlOiBbUm9s bF0gRndkOiBJLUQgQWN0aW9uOmRyYWZ0LWR0LXJvbGwtcnBsLTAwLnR4dCBRMi4uNA0KPg0KPlBh c2NhbCwgYXMgSSB3cm90ZSBpbiBwcml2YXRlLCBJIGRvdWJ0IHRoZSBuZWNlc3NpdHkgb2YgdXNp bmcgdGhlIHRlcm0NCj5EQUcgYW5kIHRoZSBhc3NvY2lhdGVkIERBRyB0aGVvcnkuICBQaWN0dXJp bmcgYSBEQUcgd2l0aG91dCBhcnJvd3MgbWFrZXMNCj5kb3VidGZ1bCBzZW5zZSAoZmlndXJlIDEp LiAgQSBsaW5rIGJldHdlZW4gc2libGluZ3Mgd291bGQgdXNlIGJpZGlyDQo+YXJyb3dzLCB3aGlj aCB3b3VsZCBtYWtlIGZvciBhICdsb29wJywgd2hpY2ggd2Ugd291bGQgdHJ5IHRvIGF2b2lkLg0K Pg0KPkJlc2lkZXMsIHdoYXQgd291bGQgYW4gYXJyb3cgYmV0d2VlbiB0d28gbm9kZXMgbWVhbiBh Y3R1YWxseTogaXMgaXQgdGhhdA0KPmEgbm9kZSBjYW4gc2VuZCBhIHBhY2tldCB0byBhbm90aGVy IG5vZGUgYnV0IG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZD8NCj5NYWtlcyBsaXR0bGUgc2Vuc2Ug dG8gaGF2ZSBhbGwgZWRnZXMgc28gdW5pZGlyZWN0aW9uYWwuDQo+DQo+UGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KSBhIMOpY3JpdCA6DQo+Wy4uLl0NCj4+IFE6IENhbiBzaWJsaW5ncyBoZWFyIGVh Y2ggb3RoZXIgYXMgaXQgaXMgbm90IGV2aWRlbnQgZnJvbSBGaWd1cmUgMjoNCj4+IEV4YW1wbGUg REFHPw0KPj4NCj4+IFI6IEZpZ3VyZSAxIHJlcHJlc2VudHMgY29ubmVjdGl2aXR5IGFuZCB5b3Ug Y2FuIHNlZSBzaWJsaW5ncyBoZWFyaW5nDQo+PiAgZWFjaCBvdGhlci4gRmlndXJlIDIgcmVwcmVz ZW50cyB0aGUgREFHIHNvIGl0IGRvZXMgbm90IGluY2x1ZGUgdGhlDQo+PiBzaWJsaW5nIGxpbmtz Lg0KPg0KPkl0IHNob3VsZCBiZSBjbGVhciB3aGV0aGVyIG9yIG5vdCB0aGUgc2libGluZ3MgY2Fu IGJlIGxpbmtlZCB0b2dldGhlciBieQ0KPmxpbmtzIGFuZCBkaXJlY3Qgcm91dGVzIG9yIG5vdC4g IEF0IHNvbWUgcG9pbnQgIGluIHRoZSBkcmFmdCB0aGlzIGlzDQo+ZXhwbGljaXRlbHkgZm9yYmlk ZGVuIChpdCBzYXlzIHRyYWZmaWMgZnJvbSBub2RlIGEgdG8gbm9kZSBiIGRlZXAgaW4gdGhlDQo+ bmV0d29yayBtdXN0IHBhc3MgdGhyb3VnaCB0aGUgREFHIHJvb3QpIC0gdGhpcyBpcyBub3QgZ29v ZC4NCj4NCj4+IFNpYmxpbmcgbGlua3MgYXJlIGJpZGlyZWN0aW9uYWwgYXQgdGhlIGdyYXBoIGxl dmVsIHRob3VnaA0KPj4gdW5pZGlyZWN0aW9uYWwgZm9yIGEgZ2l2ZW4gcGFja2V0Lg0KPg0KPkkg ZG9uJ3QgdW5kZXJzdGFuZC4gIERvIHlvdSBtZWFuIHRoYXQgYWxsIGxpbmtzIGluIHRoZSBuZXR3 b3JrICh0aGUgREFHDQo+aXMgdGhlIG5ldHdvcmspIGFyZSBfdW5pX2RpcmVjdGlvbmFsPw0KPg0K Pj4gV2UncmUgbWlzc2luZyB0aGUgdGVybSB0byBpbmRpY2F0ZSB0aGUgREFHK3NpYmxpbmdfbGlu a3MuDQo+DQo+V2Ugc2hvdWxkIGNhbGwgaXQgYSBuZXR3b3JrLiAgQSBncmFwaCBvZiBwYXRocyBo b3BlZnVsbHkgbG9vcC1mcmVlLCBub3QNCj5uZWNlc3NhcmlseSBndWFyYW50ZWVkLiAgQnV0IG5v dCBhIERBRy4NCj4NCj4+IEdyYWRpZW50IGlzIGZpbmUgd2hlbiB5b3UgdGFsayBhYm91dCBwb2lu dGluZyB0byB0aGUgcHJlZmVycmVkDQo+PiBwYXJlbnQsIGJ1dCB0aGlzIGlzIGFsc28gYSB0ZXJt IHRoYXQgd2FzIG92ZXJsb2FkZWQgaW4gdGhlIHBhc3QuIFdoYXQNCj4+ICBlbHNlPw0KPg0KPkEg bmV0d29yay4gIEEgbmV0LiAgIEEgc2V0IG9mIHBhdGhzLiAgQSB0b3BvbG9neSBhbmQgdGhlIGFz c29jaWF0ZWQNCj5wYXRocy4gIEEgY29uY2VwdHVhbCBwaWN0dXJlIHN0ZW1taW5nIGZyb20gdGhl IHNldCBvZiByb3V0ZXMgcHJlc2VudCBpbg0KPmVhY2ggbm9kZSdzIHJvdXRpbmcgdGFibGUuDQo+ DQo+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSB3b3JkIGdyYWRpZW50IGluIHRoaXMgY29udGV4dCwg dGhyb3VnaG91dCB0aGUNCj5kb2N1bWVudC4gIElzIGl0IGEgZGVyaXZhdGl2ZSBvZiBzb21ldGhp bmc/ICBBIGRpZmZlcmVudGlhbCBvZiBzb21ldGhpbmc/DQo+DQo+QWxleA0KPg0KDQo= From alexandru.petrescu@gmail.com Wed Jul 1 03:49:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36E53A681E for ; Wed, 1 Jul 2009 03:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 A8gG6iPpr356 for ; Wed, 1 Jul 2009 03:49:45 -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 D34613A67F3 for ; Wed, 1 Jul 2009 03:49:44 -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 n61AlgO2000676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jul 2009 12:47:42 +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 n61Ao0AQ009245; Wed, 1 Jul 2009 12:50:00 +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 n61Anx0a015976; Wed, 1 Jul 2009 12:50:00 +0200 Message-ID: <4A4B3F57.2020901@gmail.com> Date: Wed, 01 Jul 2009 12:49:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com> <4A4B276A.9050107@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC07B245CB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B245CB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Goindi, Manhar" , ROLL WG Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 10:49:46 -0000 Pascal Thubert (pthubert) a écrit : > Hi Alex: > > The links to parents form a DAG. If you include the sibling links it > is no more a DAG. So why talking DAG in the first place? Do you assume there are no links between siblings? > Yet the resulting graph has some properties since there is no > orientation that leads deeper; There should be an orientation that leads deeper too. > so it is not a general network. The difference between what we are > doing and more classical routing is that we REALLY want multipath. Sorry, I don't understand. IF we wanted multipath then we preferred links between siblings and also paths down the DAG, not only up to DAG root. > So we are ready to forward not only along a classical DAG but also > via siblings. Ok this. > The decision to pass a given packet to a given sibling is taken on a > per packet basis when: - the DAG does not help, none of the parents > is usable at this time (e.g. retries failed) - per packet loop > avoidance allows that sibling for that packet Sorry, I don't understand you when you say routing on a per packet basis. All routing is on a per packet basis - it looks at dst, consults routing table and then puts the packet on the right interface with the right dst MAC address. > So the whole question is how do we perform per packet loop avoidance. > In a very rich world we could actual use a source route header that > traces all the hops along a sibling path and try all possibilities. I > guess we cannot afford that. We could also build a DAG between > siblings but again that would reduce our opportunities. I disagree. To build a loop-free network there are much more options than just source route headers and DAGs. I don't understand the choice of DAG. > With the current draft, we resolve the most probable loops and let > TTL finish the job. Inefficient DAG. Unnatural DAG. > Basically if: - nodes prefer parents over siblings, sibling path > should be real short, and mostly 1 hop. - nodes do not give a packet > back to a sibling, or there's a tie break there, 1 hop loops would be > avoided - TTL is decremented aggressively along sibling path (Like > minus N instead of minus 1), loops should not cost too much > > The last option is not in the draft yet. It is on the table for > discussion. It is a way to adapt the up*down* to IPv6 that has a > single counter, hop limit. So we would allow an outward packet to > make up to Hop Limit hops along the DAG, but only up to Hop Limit/N > hops along siblings, and disallow going outward. If by this table you mean the table of negotiation of DT I think the table should be open to much more options of building routing for networks than just DAG and src routing. Alex From richard.kelsey@ember.com Wed Jul 1 05:55:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9FC3A6964 for ; Wed, 1 Jul 2009 05:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ZLjrNradB1KL for ; Wed, 1 Jul 2009 05:55:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3E1D63A69DD for ; Wed, 1 Jul 2009 05:55:41 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 08:53:44 -0400 Date: Wed, 01 Jul 2009 08:54:07 -0400 Message-Id: <8763ecy368.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> (message from Jonathan Hui on Tue, 30 Jun 2009 15:45:25 -0700) From: Richard Kelsey References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> X-OriginalArrivalTime: 01 Jul 2009 12:53:44.0646 (UTC) FILETIME=[F7AACE60:01C9FA4A] Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 12:55:42 -0000 From: Jonathan Hui Date: Tue, 30 Jun 2009 15:45:25 -0700 Jonathan, On Jun 30, 2009, at 3:25 PM, Richard Kelsey wrote: > The issue isn't that the relevent information is more > than a version number, it is that the relevent information > isn't being taken into account. For example, with a > network with a backbone of line-powered nodes and a bunch > of low-power nodes, you would prefer that nodes tend to > choose the line-powered nodes as parents. Having RAs > from low-power nodes suppress RAs from the line-powered > nodes is going to work against this, which in turn means > that you want to take routing contraints into account > when deciding when to send an RA. I think we can successfully support this case. As I mentioned in my previous email, we just have to specify that c is incremented when receiving RAs indicating a similar routing cost to what will be advertised. The problem is that 'similar routing cost' is in the eye of the beholder. How does a node determine that a received RA will be considered similar to its own by other devices? This not a problem in a network where all nodes are running the same stack from the same vendor. For it to work in a network running multiple stacks from multiple vendors there will have to be a shared, well-defined notion of 'cost'. For example, consider the issue of trust. If node A trusts node B but not node C, then C's RA is not a replacement for B's and should not suppress it. How does B learn this? > Also, the CTP paper describes in detail how it can be used to > maintain a routing gradient: > > http://sing.stanford.edu/pubs/sing-09-01.pdf > > It does so by not using Trickle's suppression mechanism, > which is the part of Trickle which worries me. > Trickle-with-suppression and Trickle-without-suppression are > substantially different algorithms. We have and are using Trickle's suppression mechanism successfully in real deployments. We did run into the scenarios you have raised and have dealt with them simply by restricting when to increment c. My other concern with the suppression mechanism is how it behaves in networks with variable density. I have run a few simulations of this. If you have a cluster of, say, 20 nodes that can all hear each other and a few scattered outliers that can hear only one or two nodes in the cluster, it can take a while for the outliers to hear an updated RA. This doesn't happen in the original Trickle, as the outliers get updated as soon as they themselves transmit. With the RA version, hearing an outdated RA does not trigger a transmission. Would it be OK to unicast an RA in such a case? In other words, if node A hears an RA from node B that has an older sequence number, node A could unicast its RA to B while leaving its Trickle timer as-is. In my view, the suppression mechanism can be critical for operation in dense environments - especially when using links where broadcast can be very expensive compared to unicast. I agree that there has to be a way to limit broadcasts. I am not convinced that Trickle is always appropriate, but I admit that I do not have an alternative proposal. Setting k to infinity addresses my concerns. In rpl-00 k is a constant, DEFAULT_DIO_REDUNDANCY_CONSTANT. We could add a DIORedundancyLimit field. > It would bother me at all if RPL became more like the > Collection Tree Protocol in other ways as well :-). We have been working very hard to pull in the good ideas from CTP. We are looking into including data-based loop detection, adaptive beaconing, etc. Note, however, that we are concerned only with routing here - the forwarding aspects of CTP are out-of-scope. The data-based loop detection was what I had in mind. -Richard Kelsey From alexandru.petrescu@gmail.com Wed Jul 1 07:22:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F01428C52F for ; Wed, 1 Jul 2009 07:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 OZzVfoa4rC5y for ; Wed, 1 Jul 2009 07:21:59 -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 9E7EE3A67AE for ; Wed, 1 Jul 2009 07:21:58 -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 n61DqQcn020226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Jul 2009 15:52:26 +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 n61DqQc7025486 for ; Wed, 1 Jul 2009 15:52:26 +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 n61DqPC7014780 for ; Wed, 1 Jul 2009 15:52:26 +0200 Message-ID: <4A4B6A19.20004@gmail.com> Date: Wed, 01 Jul 2009 15:52:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Partial review of draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:22:01 -0000 Dear ROLLers, I've reviewed draft-dt-roll-rpl-00.txt up to section 5.3 "Trickle Timer for RA." It is a 60-pages long document, out of which 50 pages are effective descriptions. It is roughly divided in 3 conceptual parts: the DAG-oriented protocol (supposedly inherited from the Thubert Tree Discovery protocol), the Trickle timer part (probably inherited from Levis Trickle works) and the 3rd part that I haven't read. Reading the document requires concentration and exposes consistency between various parts. Some times it is incosistent. The document is in its infancy (00) and I expect many changes to occur to it later. Because of this I doubt a detail review is of any use right now. The document describes examples at several places, and this is very useful for understanding the intention. However, there are a few questions which can't be answered obviously by reading the draft: -why DAG? -how many interfaces does a node have? -how are the addresses and prefixes configured on the nodes? -and some nits. Title: I find "RPL" to risk clashing with other uses of the same abbreviation at IETF, e.g. Rendez-vous Point Link RFC 5015. This could make the conversation difficult when we will probably try to add an RPL to RPL. I suggest ROLL instead. > Because those requirements are heterogeneous and sometimes > incompatible in nature, the approach is first taken to design a > protocol capable of supporting a core set of functionalities > corresponding to the intersection of the requirements. (Note: it is > intended that as this design evolves optional features may be added > to address some application specific requirements). All "MUST" > application requirements that cannot be satisfied by RPL will be > specifically listed in the Appendix A, accompanied by a > justification. In the current 00 version, this is not the case: there is no stated list of requirements which are satisfied by the protocol 'RPL'. Probably it will come later. If not, we may have a big problem: working without requirements. > Autonomous: Refers to the ability of a routing protocol to > independently function without requiring any external influence or > guidance. Includes self-configuration and self-organization > capabilities. Self-configuration of what? Does each node self-configure an address for itself? How? Does it self-configure a prefix for itself? How? Does it self-configure some routes? How? > DAG: Directed Acyclic Graph- A directed graph having the property > that all edges are oriented in such a way that no cycles exist. In > the RPL context, all edges are contained in paths oriented toward and > terminating at a root node (a DAG root, or sink- typically a LBR). The DAG theory is clear. But what does DAG mean in the context of a network? A link between siblings is obviously bidirectional: this makes for a loop. But it's said no loop. I have very strong doubts about the use of DAG theory in this draft. I will not go as far as to say it is useless, but I'm tempted to. LBR: throughout the document the terms LBR, Sink and DAG Root are used interchangeably: why three terms when one is sufficient? DAG: in theory, a DAG can be made of two separate disconnected acyclic graphs: it's still one DAG. The definitions above don't mention it. Later in the text the terms 'parallel' DAGs are used: are two parallel DAGs a single DAG? Are two parallel DAGs connected? It is not clear. > DAG Sibling: A sibling of a node within a DAG is defined to be any > neighboring node node which is located at the same depth, or rank, > within a DAG. The 'sibling' as I understand it has sense in a tree only. Here we have DAGs. 'Neighbor' is not defined. So, can there be two siblings which are not neighbors? I guess yes, but the definition says no. Depends what a 'neighbor' is. What is a neighbor? > DAG Root: A DAG root is a sink within the DAG graph. All paths in > the DAG terminate at a DAG root, and all DAG edges shared with nodes > adjacent to a DAG root are oriented toward the DAG root. What does 'adjacent' mean? Is it a neighbor? A sibling? > In many use cases, source- sink represents the foremost traffic flow, 'Foremost' or 'inward'? I think it is meant 'inward', by the later definition of 'inward'. > Maintaining default routing towards DAG roots is therefore a primary > functionality for RPL. Well I agree mostly. But I would have liked the primary functionality to be to maintain consistent routes for all destinations within the network, not just a default route to the Internet. > Inward: In the context of RPL, inward refers to the direction from > leaf nodes towards DAG roots, following the orientation of the edges > within the DAG. What is a 'leaf' node? Is it the deepest node? Is it any node except the DAG Roots? > MP2P: Multipoint-to-Point; used to describe a particular traffic > pattern. A common RPL use case involves MP2P flows collecting > information from many nodes in the DAG, flowing inwards towards DAG > roots. Note that a DAG root may not be the ultimate destination of > the information, but it is a common transit node. I agree with this term, MP2P, and with the fact that it is probably the main type of traffic pattern, because it corresponds to the activity of querying a set of sensors. However, I think there may be an issue with saying just what is said above. If I think TCP: the TCP is a three-way handshake. If the query and responses are TCP then the traffic doesn't correspond precisely to a simple MP2P traffic: there are acks from querier to queried nodes which are not MP2P but P2P. I think MP2P as described above is ok only when we talk about the queried data sent by sensors to the querier, and when that traffic is UDP only (or ICMP responses, or similar, but not TCP nor HTTP). > The aim of this section is to describe RPL in the spirit of > [RFC4101]. This is excellent initiative! RFC4101 says at some point that the model should feature a diagram of the major communicating parties and their inter-relationships. I think the Figures 1 and 2 of this drat try to play this role. But these figures don't show messages between entities, just links and too many nodes, maybe. I would have preferred to see entities and messages between them. > Note that in this document, the terms `node' and `LLN router' are > used interchangeably. Why not just one? It would ease reading. > RPL is strictly compliant with layered IPv6 architecture. What does this mean? What is the layered IPv6 architecture? > usually low bandwidth with low packet success rate ^delivery > 3.2.4. Autonomous Operation > > Nodes running RPL are thus able independently and autonomously > discover a network topology and compute and install routes, without > requiring further administrative interaction. I don't understand the 'thus' above? There's no preceding text making one conclude that RPL nodes discover network topology without further administrative interaction. It is not said anywhere how are the addresses and prefixes assigned to nodes in the first place. They must come from somewhere but it's not said where from. What is the starting point? An admin? > As DAGs are organized, RPL will use a Destination Advertisement > mechanism to build up routing state in support of outward P2MP > traffic flows. Traffic directed from one node to another may flow > inward along the DAG until a common parent is reached capable of > directing the traffic along the outward path. Traffic between two siblings being forced through a parent, despite the existence of a straight link is sub-optimal routing, and it is not good. The text says 'may' but it is not capitalized. I am afraid this may become a MUST later, and I oppose it. > RPL constructs one or more base routing topologies, in the form of > DAGs, over gradients rooted at designated nodes. What is a gradient? Also, I assume a topology is a set of physical links. These links can't be put up/down by some protocol but by human intervention. I thought the protocol builds a set of paths over some links which must be up. I think we may have a misunderstanding between what is a 'topology' and a 'path'. We could define it better. > increases path diversity (yes, this is too short citation, but what is 'path diversity'? I think it appears 5 times; is it the 'multipath'?) > As nodes join the DAG they are able advertise the fact by beginning > to multicast the DAG information in Router Advertisements. I agree. This makes me think you have a precise idea about the link layer having multicast features. (RA multicast is link-layer multicast). Is it so that you assume the link-layer has multicast features? I agree if yes. > node may be unfairly unable to become a DAG parent Hmmm... does this mean the node is fairly able to become a DAG parent? (double negation). > When receiving traffic forwarded from a sibling, the traffic should > not be forwarded back to the same sibling in order to avoid a 2-node > loop. Oki. But the node receiving should have a means to know where is the traffic coming from, and the src field is not useful because it's the original source. So the MAC address? What kind of MAC addresses are used? Some links don't have MAC addresses. > By employing this procedure, the LLN is able to set up a path- > constrained DAG, rooted at designated nodes, with other nodes > radiating outward from the DAG root in an orderly fashion. 'outward' is from DAG root to other nodes, ok. But other nodes radiating outward? What do they radiate? Or are they just placed as radiuses around the the DAG root? > MP2P traffic intended for the default destination flows inward along > the DAG towards the root, and transit nodes are able to leverage the > path diversity of the DAG as necessary. Ok, but what are the transit nodes? > the DAG may is not offering a default route. Nit: may is not. > A DAG, or a sub-DAG, may also become isolated because of a network > element failure. What is an 'isolated' DAG? There's no definition in the draft. Another DAG definition from theory shows a DAG can be made of disconnected acyclic graphs. Such a graph could be considered 'isolated'. But is this the meaning in this draft? > maintain parallel DAGs Also, what is a 'parallel' DAG? A topology with the same number of vertices and same edges as the parallel topology? > o A DAGID used to uniquely identify the DAG. Typically the > (potentially compressed) IPv6 address of the DAG root. May be tested > for equality. There are at least two means of compressing IPv6 addresses I've seen in the MANET WG and elsewhere. What is the test for equality? Longest-prefix match? Exact match? How are compressed addresses compared? > [DIO contains]... o Indications for the DAG, e.g. grounded or > floating. But this information could come from other existing fields in the RA, i.e. the default route. Default route is the only distinction between grounded or floating, so why not reusing the default route (a lifetime field) in the existing RA. > In addition to periodic RAs, each LLN node will respond to Router > Solicitation messages according to [RFC4861]. Will each LLN node join the corresponding multicast group? RFC4861 requires it so. So I think it is worth mentioning it joins that group before responding to RS. > marking within the IPv6 header Nit: missing dot at end of phrase. > o Is the neighboring node heard reliably enough How is the test performed to decide whether a neighbor (what is a neighbor?) is heard reliably enough? > are the metrics stable enough How would one test for stable metrics? What is a stable metric? > When the node inserts the first DAG parent into the empty DAG parent > set, it is able to join the DAG. The node will join the DAG at a > depth deeper than that of its deepest DAG parent. This begs the question: what is the deepest DAG parent when the DAG parent set is empty? > 3.3.1.4.1. Example Thanks for the example. This is very good to understand what is all about. > 3.3.3. Destination Advertisement > > As RPL constructs DAGs, nodes are able to learn a set of default > routes in order to send traffic to the sink. How do the nodes learn the default routes? What does a default route look like? Is it ::/0 and a link-local gateway address? Where does it come from? > [DAO contains]... o A lifetime and sequence counter to determine the > freshness of the Destination Advertisement. Is this sequence counter the same as the Sequence Number in the DIO base option pp. 26? > o Reverse Route information to record the reverse route when the > intermediate nodes along the path cannot support storing state for > Hop-By-Hop routing. What is 'hop-by-hop' routing? What is the 'reverse route'? > At this time the node may perform route aggregation if it is able, > thus reducing the overall number of DAOs. I am pretty sure we don't have a common understanding of what route aggregation is and how could it be performed. > 3.3.4. Examples > > Consider the example LLN physical topology in Figure 1. In this > example the links depicted are all usable L2 links. First, I wanted to say thank you for the examples. All examples and figures are paramount for understanding what is meant. And the question: in figure 1 node 32 has 7 links: is this a node with 7 interfaces? > 3.4.2. Loop Avoidance > > The goal of a guaranteed consistent global routing solution for an > LLN may not be practically achieved given the real behavior and > volatility of the underlying metrics. The trade offs to achieve a > stable approximation of global convergence may be too restrictive > with respect to the need of the LLN to react quickly in response to > the lossy environment. Globally the LLN may achieve a weak > convergence, in particular as link changes are able to be handled > locally and result in minimal changes to global topology. > > RPL does not aim to guarantee loop free path selection, or strong > global convergence. RPL includes mechanisms to detect and break > loops, and to try to avoid the creation of loops when undergoing > topology changes. When RPL parameters are properly configured, in > particular with respect to metric reporting and route update > intervals, it should be possible for RPL to achieve a weak global > convergence while still responding and reacting to changes in the LLN > environment. Sorry, this section is a declaration of intention, it is ok, but it is not a mechanism for loop avoidance. > 4.1. Routing Metrics This section does not mention the routing metric most used: the number of IP hops. I think it should. It is the 8bit field named 'metric' in RIPng RTE, and some of the 'Metric' fields in OSPF Database Description (only some). > The key design point is that each node is solely responsible for > setting the vector that it sources in the gradient, which is achieved > by selecting its preferred parent. What is a 'vector' and what is a 'gradient'? > As a result, the gradient is not broken if another node makes its > decisions in as antagonistic fashion, though an end-to-end path might > not fully achieve any of the optimizations that nodes along the way > expect. Sorry? > 5.1. DAG Information Option > > The DAG Information Option carries a number of metrics and other > information that allows a node to discover a DAG, select its DAG > parents, and identify its siblings while employing loop avoidance > strategies. I am happy the protocol has a means to encode different metrics. > BootTimeRandom: A random value computed at boot time and recomputed > in case of a duplication with another node. How is the random value computed? Is it really random? Is there a risk that we assume it random but it may actually be not so random when all sensors perform same algorithm for randomness computing? RFC4086 has some requirements around this. > DAGDelay: 16-bit unsigned integer set by the DAG root indicating the > delay before changing the DAG configuration, in TBD-units. A > default value is TBD. It is expected to be an order of > magnitude smaller than the RA-interval. It is also expected to > be an order of magnitude longer than the typical propagation > delay inside the LLN. DAGDelay expressed in what? Seconds? Mili-seconds? What is an RA-interval? What is an order of magnitude when things are encoded in binary (and not decimal)? Is it still 10 or is it 2^10? If DAGDelay is 2^16 then does this mean the max propagation delay through the LLN is 2^6? Is there such a link layer with such delays? > RA-DIO should be send Nit: sent. > DIOIntervalMin: 24-bit unsigned integer. Used to configure the > trickle timer governing when RA-DIO should be sent within the > DAG. DIOIntervalMin is the minimum configured interval for the > RA-DIO trickle timer expressed in units of 10ms. For example, > a DIOIntervalMin value of 10ms is expressed as 0x000001. This is a field difficult to deal with programattically. I mean there are standard uint8_t, uint16_t, uint32_t, etc. but there's no uint24_t. Programmer needs to shift bits around to manage this field. Why not making it uint32_t? Besides, the max DIOIntervalMin on 24bit tens of milliseconds makes for almost two days. Why not making it longer, like a whole month. A month is what an airplane blackbox seems to last emitting, to not cite recent news. > PathDigest: 32-bit unsigned integer CRC, updated by each LLN Node. > This is the result of a CRC-32c computation on a bit string > obtained by[...] What is CRC? What is CRC-32c and how is it computed? Why not the Internet checksum (used by UDP and ICMP at least) which are standardized at rfc1071 "Computing the Internet Checksum", I think. The details of computing are mentioned at least in the ICMPv6 RFC and it is straightforward guidance for implementation. > DAGID: 128-bit unsigned integer which uniquely identify a DAG. This > value is set by the DAG root. The global IPv6 home address of > the DAG root can be used. The IPv6 home address? In this case the rfc3963 at least should be cited because it talks mobile routers and IPv6 home addresses. > Suboption Type: 8-bit identifier of the type of suboption. When > processing a DIO containing a suboption for which the Suboption > Type value is not recognized by the receiver, the receiver MUST > silently ignore and skip over the suboption, correctly handling > any remaining options in the message. This sounds as we want it to be TBA and request IANA assignment. > 5.1.1.1.4. DAG Metric Container > > The DAG Metric Container suboption may be aligned as necessary to > support its contents. Its format is as follows: > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > | Type = 2 TBA with IANA. > The DAG Metric Container is used to report aggregated path metrics > along the DAG. What does it mean aggregated path metrics? IS it that there are several metrics listed in the container? Or just a sort of "aggregation" of them all? I prefer the former. The ContainerLen field is on 8bits, and expresses number of octets. This makes for a Metric Container of maximum 255 octets. This limits the number of metrics it could hold. If we consider the energy metric for link to be e.g.: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This makes for 12 octets and represents only energy for one link. If we want to send several links then it grows substantially. > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 3 | Length | Prefix Length |Resvd|Prf|Resvd| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Prefix (Variable Length) | > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I think this Destination Prefix is not variable length. It is length 128bits and the dots on the left and right columns should disappear and "(Variable Length)" should disappear too. Alex From jhui@archrock.com Wed Jul 1 08:07:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C3F3A6F63 for ; Wed, 1 Jul 2009 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 3zvIjC3g5oNE for ; Wed, 1 Jul 2009 08:07:10 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id BD2A928C58D for ; Wed, 1 Jul 2009 08:06:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 017F1AF906; Wed, 1 Jul 2009 08:06:37 -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 JBnve9cIPEly; Wed, 1 Jul 2009 08:06:32 -0700 (PDT) Received: from [192.168.7.22] (69-12-164-139.sfo.archrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 27F37AF905; Wed, 1 Jul 2009 08:06:32 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <8763ecy368.fsf@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 v935.3) Date: Wed, 1 Jul 2009 08:06:31 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:07:24 -0000 Hi Richard, On Jul 1, 2009, at 5:54 AM, Richard Kelsey wrote: > From: Jonathan Hui > Date: Tue, 30 Jun 2009 15:45:25 -0700 > > I think we can successfully support this case. As I mentioned in my > previous email, we just have to specify that c is incremented when > receiving RAs indicating a similar routing cost to what will be > advertised. > > The problem is that 'similar routing cost' is in the eye of > the beholder. How does a node determine that a received RA > will be considered similar to its own by other devices? > This not a problem in a network where all nodes are running > the same stack from the same vendor. For it to work in a > network running multiple stacks from multiple vendors there > will have to be a shared, well-defined notion of 'cost'. The larger issue is that we intentionally didn't even try to define the 'cost'. Different networks will use different metric(s) and we cannot possibly dream up all metrics that might be used. The best thing we can do is define what happens in the default case - the case where you just don't know how to process another node's metrics. > For example, consider the issue of trust. If node A trusts > node B but not node C, then C's RA is not a replacement for > B's and should not suppress it. How does B learn this? Is this "trust" from a security view? I guess I was assuming that it will be enough for B and C to determine from their own logic the capabilities and costs each provides. If they are the same, then go ahead and suppress. If they are different (because values are different or the metrics are not understandable) then you should default to no suppression. But if the logic for what capabilities B and C may provide are implemented only on node A, then I agree that's an issue. > We have and are using Trickle's suppression mechanism > successfully in real deployments. We did run into the > scenarios you have raised and have dealt with them simply > by restricting when to increment c. > > My other concern with the suppression mechanism is how it > behaves in networks with variable density. I have run a few > simulations of this. If you have a cluster of, say, 20 > nodes that can all hear each other and a few scattered > outliers that can hear only one or two nodes in the cluster, > it can take a while for the outliers to hear an updated RA. > This doesn't happen in the original Trickle, as the outliers > get updated as soon as they themselves transmit. With the > RA version, hearing an outdated RA does not trigger a > transmission. I'd argue that hearing an inconsistent RA should always trigger a Trickle reset. This may be due to a sequence number change or some other indicators like data-driven loop detection. I prefer the term inconsistent since Trickle resets shouldn't be based on just the sequence number. One useful behavior of Trickle is that the "outliers" won't be suppressed by the other nodes. So once the outliers advertise, then only the nodes that can hear the outliers will reset their Trickle timer. Of course, this assumes that radio range is symmetric - the worse case being if the outliers have a larger radio range. In the end, Trickle does impose a resource-consumption-delay tradeoff - especially if you set the parameters such that it operates conservatively (i.e. k is a small value). > Would it be OK to unicast an RA in such a case? In other > words, if node A hears an RA from node B that has an > older sequence number, node A could unicast its RA to B > while leaving its Trickle timer as-is. We have discussed whether or not it is OK to unicast, but haven't gone into the discussion in-depth. Of course, the challenge is avoiding RA collisions, especially in dense networks. > In my view, the suppression mechanism can be critical for > operation in dense environments - especially when using > links where broadcast can be very expensive compared to > unicast. > > I agree that there has to be a way to limit broadcasts. I > am not convinced that Trickle is always appropriate, but I > admit that I do not have an alternative proposal. Setting > k to infinity addresses my concerns. In rpl-00 k is a > constant, DEFAULT_DIO_REDUNDANCY_CONSTANT. We could add > a DIORedundancyLimit field. Agree. k allows an operator to make a tradeoff, so it probably should be parameter carried in the RA similar to the min/max period for Trickle. We'll look into including this in the next rev. > We have been working very hard to pull in the good ideas from CTP. > We > are looking into including data-based loop detection, adaptive > beaconing, etc. Note, however, that we are concerned only with > routing > here - the forwarding aspects of CTP are out-of-scope. > > The data-based loop detection was what I had in mind. Sure. We have plans to include this already. -- Jonathan Hui From prvs=4263ebebf=mukul@uwm.edu Wed Jul 1 08:28:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED4D3A6F3F for ; Wed, 1 Jul 2009 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.688, 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 SBxB0qvQZdJq for ; Wed, 1 Jul 2009 08:28:23 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id EAE973A6F3A for ; Wed, 1 Jul 2009 08:28:22 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 01 Jul 2009 10:27:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 44402B20008 for ; Wed, 1 Jul 2009 10:27:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSLuPttJQcvj for ; Wed, 1 Jul 2009 10:27:33 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 85197B20013 for ; Wed, 1 Jul 2009 10:27:32 -0500 (CDT) Date: Wed, 1 Jul 2009 10:27:32 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1230040773.17468701246462052420.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] dt-roll-rpl: Gradient X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:41:41 -0000 Quoting from section 4.1 (the last paragraph) "RPL is designed to survive and still operate, though in a somewhat degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector that it sources in the gradient, which is achieved by selecting its preferred parent. As a result, the gradient is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect." I am not sure what does the gradient mean and what does the following line mean "each node is solely responsible for setting the vector that it sources in the gradient, which is achieved by selecting the preferred parent." The draft needs to define gradient. And perhaps give an example of "the gradient is not broken if another node makes its decision in an atagonistic fashion". Thanks Mukul From prvs=4263ebebf=mukul@uwm.edu Wed Jul 1 08:50:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FF63A6A5F for ; Wed, 1 Jul 2009 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.215, 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 aBHFr5zszk08 for ; Wed, 1 Jul 2009 08:50:36 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 43D203A6921 for ; Wed, 1 Jul 2009 08:50:36 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta2.uwm.edu with ESMTP; 01 Jul 2009 10:50:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B9C1EB20004 for ; Wed, 1 Jul 2009 10:50:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jamp-adS9Eym for ; Wed, 1 Jul 2009 10:50:16 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 95375B20002 for ; Wed, 1 Jul 2009 10:50:16 -0500 (CDT) Date: Wed, 1 Jul 2009 10:50:16 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <867015478.17481381246463416498.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1452622866.17477201246462971922.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] dt-roll-rpl: constraint X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:50:37 -0000 Section 4.2 in the draft defines a "constraint" as follows: "A constraint is a link or a node characteristic that must be satisfied by the computed path..." This definition excludes the possibility that a routing constraint may be a function of characteristics of multiple (or all) links/nodes in the path. For example, it seems that it may not be possible to allow the following objective function under the given definition of "constraint". "Find the shortest path (path with lowest cost where the path cost is same as the hop-count) such that the end-to-end reliability of the path is more than 75%." Thanks Mukul From jhui@archrock.com Wed Jul 1 08:52:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585293A68F4 for ; Wed, 1 Jul 2009 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 QXaY8b0En35O for ; Wed, 1 Jul 2009 08:52:04 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 916AE3A67AF for ; Wed, 1 Jul 2009 08:52:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 42286AF8B2; Wed, 1 Jul 2009 08:51: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 5thwCbRDTMBB; Wed, 1 Jul 2009 08:51:48 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 55120AF8A6; Wed, 1 Jul 2009 08:51:48 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <873a9gxvrf.fsf@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 v935.3) Date: Wed, 1 Jul 2009 08:51:47 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> <873a9gxvrf.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:52:05 -0000 Hi Richard, On Jul 1, 2009, at 8:34 AM, Richard Kelsey wrote: > Is this "trust" from a security view? I guess I was assuming that it > will be enough for B and C to determine from their own logic the > capabilities and costs each provides. If they are the same, then go > ahead and suppress. > > "Trust" was just a stand in for any asymmetric link metric. > It could be energy or anything else. > > The problem is not B's and C's cost determination, but > that of A. Even if B and C agree on what their costs are, > in picking a parent A is going to consider its own costs for > forwarding via B and C. Those costs may be quite different > and unknown to B and C. Right. But I don't think that k = infinity has to be the default value. A main effect of Trickle is that k bounds the effective density of RAs for a given time period. If that k-bounded density is forgiving enough, then these corner cases shouldn't be an issue most of the time. Of course, it is probabilistic. > I'd argue that hearing an inconsistent RA should always trigger a > Trickle reset. This may be due to a sequence number change or some > other indicators like data-driven loop detection. I prefer the term > inconsistent since Trickle resets shouldn't be based on just the > sequence number. > > The -00 draft does not include this in the list in section > 5.3.2. In rule 5 of section 5.4 it states: > > Nodes MUST ignore RAs that are received from other routers > located deeper within the same DAG. > > That clearly rules out a Trickle reset when hearing an > out-of-date RA from a child. Yes. That text was basically lifted from one of Pascal's drafts. What we did was take a bunch of mechanisms we thought were useful and tried to bring them together. There certainly is more work to do here in making sure that these mechanisms work together properly. -- Jonathan Hui From richard.kelsey@ember.com Wed Jul 1 08:57:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F65F3A69B7 for ; Wed, 1 Jul 2009 08:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 sEoFlD11Y3K2 for ; Wed, 1 Jul 2009 08:57:18 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B9D0C3A69FD for ; Wed, 1 Jul 2009 08:57:18 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 11:33:48 -0400 Date: Wed, 01 Jul 2009 11:34:12 -0400 Message-Id: <873a9gxvrf.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Wed, 1 Jul 2009 08:06:31 -0700) From: Richard Kelsey References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 01 Jul 2009 15:33:48.0787 (UTC) FILETIME=[542E6C30:01C9FA61] Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:57:31 -0000 Jonathan, From: Jonathan Hui Date: Wed, 1 Jul 2009 08:06:31 -0700 On Jul 1, 2009, at 5:54 AM, Richard Kelsey wrote: > I think we can successfully support this case. As I mentioned in my > previous email, we just have to specify that c is incremented when > receiving RAs indicating a similar routing cost to what will be > advertised. > > The problem is that 'similar routing cost' is in the eye of > the beholder. How does a node determine that a received RA > will be considered similar to its own by other devices? > This not a problem in a network where all nodes are running > the same stack from the same vendor. For it to work in a > network running multiple stacks from multiple vendors there > will have to be a shared, well-defined notion of 'cost'. The larger issue is that we intentionally didn't even try to define the 'cost'. Yes. I think this leads so some significant complications, but that's a topic for a different thread. > For example, consider the issue of trust. If node A trusts > node B but not node C, then C's RA is not a replacement for > B's and should not suppress it. How does B learn this? Is this "trust" from a security view? I guess I was assuming that it will be enough for B and C to determine from their own logic the capabilities and costs each provides. If they are the same, then go ahead and suppress. "Trust" was just a stand in for any asymmetric link metric. It could be energy or anything else. The problem is not B's and C's cost determination, but that of A. Even if B and C agree on what their costs are, in picking a parent A is going to consider its own costs for forwarding via B and C. Those costs may be quite different and unknown to B and C. > My other concern with the suppression mechanism is how it > behaves in networks with variable density. I have run a few > simulations of this. If you have a cluster of, say, 20 > nodes that can all hear each other and a few scattered > outliers that can hear only one or two nodes in the cluster, > it can take a while for the outliers to hear an updated RA. > This doesn't happen in the original Trickle, as the outliers > get updated as soon as they themselves transmit. With the > RA version, hearing an outdated RA does not trigger a > transmission. I'd argue that hearing an inconsistent RA should always trigger a Trickle reset. This may be due to a sequence number change or some other indicators like data-driven loop detection. I prefer the term inconsistent since Trickle resets shouldn't be based on just the sequence number. The -00 draft does not include this in the list in section 5.3.2. In rule 5 of section 5.4 it states: Nodes MUST ignore RAs that are received from other routers located deeper within the same DAG. That clearly rules out a Trickle reset when hearing an out-of-date RA from a child. > We could add a DIORedundancyLimit field. Agree. k allows an operator to make a tradeoff, so it probably should be parameter carried in the RA similar to the min/max period for Trickle. We'll look into including this in the next rev. Great. -Richard Kelsey From richard.kelsey@ember.com Wed Jul 1 13:22:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B2D3A6839 for ; Wed, 1 Jul 2009 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 H4doaaG-9Ad3 for ; Wed, 1 Jul 2009 13:22:29 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D040B3A67C1 for ; Wed, 1 Jul 2009 13:20:15 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 16:20:22 -0400 Date: Wed, 01 Jul 2009 16:20:45 -0400 Message-Id: <87bpo46tpe.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Wed, 1 Jul 2009 08:51:47 -0700) From: Richard Kelsey References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> <873a9gxvrf.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 01 Jul 2009 20:20:22.0349 (UTC) FILETIME=[5C57C7D0:01C9FA89] Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:22:30 -0000 Jonathan, From: Jonathan Hui Date: Wed, 1 Jul 2009 08:51:47 -0700 On Jul 1, 2009, at 8:34 AM, Richard Kelsey wrote: Right. But I don't think that k = infinity has to be the default value. A main effect of Trickle is that k bounds the effective density of RAs for a given time period. If that k-bounded density is forgiving enough, then these corner cases shouldn't be an issue most of the time. Of course, it is probabilistic. The choice of k has to balance bandwidth versus responsiveness. I wouldn't advocate k = infinity is the best everywhere, but it is the best in many cases. > I'd argue that hearing an inconsistent RA should always trigger a > Trickle reset. This may be due to a sequence number change or some > other indicators like data-driven loop detection. I prefer the term > inconsistent since Trickle resets shouldn't be based on just the > sequence number. > > The -00 draft does not include this in the list in section > 5.3.2. In rule 5 of section 5.4 it states: > > Nodes MUST ignore RAs that are received from other routers > located deeper within the same DAG. > > That clearly rules out a Trickle reset when hearing an > out-of-date RA from a child. Yes. That text was basically lifted from one of Pascal's drafts. What we did was take a bunch of mechanisms we thought were useful and tried to bring them together. I think that text is correct, in that you cannot trigger a Trickle reset just because you hear an inconsistent RA. Suppose node A hears an inconsistent RA from node B. There are two cases: - If node B will accept A as a parent, then node A should do a Trickle reset. - If node B will not accept A as a parent, then A should not do a Trickle reset. The problem is that node A has no way of determining which of these two is actually the case. The safe thing to do is to not do a reset. Otherwise A will continue to reset until B gets updated from other devices. On the other hand, if B will accept only A as a parent, perhaps because no other possible parent is in range, and A allows its RAs to be suppressed by other RAs and also ignores B's out-of-date RAs, then B might have to wait a while before getting updated. This is why I think it makes sense to set k to infinity. -Richard Kelsey From jhui@archrock.com Wed Jul 1 14:27:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BB93A6976 for ; Wed, 1 Jul 2009 14:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 bxaF0DuYrzWV for ; Wed, 1 Jul 2009 14:27:20 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A97B53A699F for ; Wed, 1 Jul 2009 14:27:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 84422AF81E; Wed, 1 Jul 2009 14:27:39 -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 W3GnP+HinSvJ; Wed, 1 Jul 2009 14:27:34 -0700 (PDT) Received: from [192.168.7.22] (69-12-164-139.sfo.archrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 97719AF879; Wed, 1 Jul 2009 14:27:34 -0700 (PDT) Message-Id: <88FDAB42-A6D1-4095-AA98-68EDF37078D1@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87bpo46tpe.fsf@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 v935.3) Date: Wed, 1 Jul 2009 14:27:33 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> <873a9gxvrf.fsf@kelsey-ws.hq.ember.com> <87bpo46tpe.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:27:22 -0000 On Jul 1, 2009, at 1:20 PM, Richard Kelsey wrote: > Right. But I don't think that k = infinity has to be the default > value. A main effect of Trickle is that k bounds the effective > density > of RAs for a given time period. If that k-bounded density is > forgiving > enough, then these corner cases shouldn't be an issue most of the > time. Of course, it is probabilistic. > > The choice of k has to balance bandwidth versus > responsiveness. I wouldn't advocate k = infinity is the > best everywhere, but it is the best in many cases. More precisely, the tradeoff between resource (channel and energy) utilization and responsiveness is most acute for nodes that have limited potential routes. When there are a good number of potential routes, responsiveness doesn't suffer much. When there are lots of potential routes, Trickle reduces wasted energy in unnecessary RAs. > Yes. That text was basically lifted from one of Pascal's > drafts. What we did was take a bunch of mechanisms we > thought were useful and tried to bring them together. > > I think that text is correct, in that you cannot trigger > a Trickle reset just because you hear an inconsistent RA. > Suppose node A hears an inconsistent RA from node B. There > are two cases: > > - If node B will accept A as a parent, then node A > should do a Trickle reset. > > - If node B will not accept A as a parent, then A > should not do a Trickle reset. > > The problem is that node A has no way of determining which > of these two is actually the case. The safe thing to do > is to not do a reset. Otherwise A will continue to reset > until B gets updated from other devices. That depends on what you consider "safe". This, again, is a tradeoff between resource consumption and responsiveness. If responsiveness is more important than energy and/or channel channel utilization, then A should do a reset. > On the other hand, if B will accept only A as a parent, > perhaps because no other possible parent is in range, and A > allows its RAs to be suppressed by other RAs and also > ignores B's out-of-date RAs, then B might have to wait a > while before getting updated. If B only has 1 choice for a parent, then there's not much receiver diversity to talk about. And if B's RA does not trigger A to reset, then it will have to wait a while if Trickle's upper-bound is set to something large. > This is why I think it makes sense to set k to infinity. I think we're both right on this issue. It falls in the category of "it depends". That's why I agreed that it makes sense to make k a parameter carried within the protocol. -- Jonathan Hui From prvs=4263ebebf=mukul@uwm.edu Wed Jul 1 15:55:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688AF28C0EF for ; Wed, 1 Jul 2009 15:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 XXyPhy2SHT2J for ; Wed, 1 Jul 2009 15:55:40 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 6562D28C0D8 for ; Wed, 1 Jul 2009 15:55:40 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta2.uwm.edu with ESMTP; 01 Jul 2009 17:55:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 47D09B20002 for ; Wed, 1 Jul 2009 17:55:54 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmwk3ZnYI2HT for ; Wed, 1 Jul 2009 17:55:54 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 21623B20001 for ; Wed, 1 Jul 2009 17:55:54 -0500 (CDT) Date: Wed, 1 Jul 2009 17:55:54 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <721410963.17661851246488080156.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:55:41 -0000 RPL allows a node to have parents with different depths from the root. By choosing deeper neighbors as parents, a node increases its own depth (required to be more than that of any of its parents to avoid loops) and thus makes itself less attractive for selection as a parent. RPL also allows a node to discard its deeper parents to improve its own depth and thus make itself more attactive for selection as a parent. But this is not mandatory. The question is what is the inherent benefit of this flexibility? Why is it that such a DAG may lead to better routes than one based strictly on min hop-distance (i.e. where a node would be required to discard parents when it finds less deeper ones)? Under the RPL approach, the depth of a node is an upper bound on its hop distance from the root. It just tells that a packet forwarded to the node may take anywhere between 1 and the "depth" hops to reach the root (unless the node maintains the "min_hop_distance" from the root as well, in which case a packet forwarded to the node may take any where between "min_hop_distance" and "depth" hops to reach the root). The end result is that a node has very little control over the number of hops a packet, it forwards, takes to reach the root. It seems to me that forcing the depth to be same as the min hop distance would still allow all the benefits of DAGs (loop avoidance, flexible routes in face of topology changes) while assigning a better meaning to the term "depth". Thanks Mukul From pal@cs.stanford.edu Wed Jul 1 16:00:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27BC3A6A25 for ; Wed, 1 Jul 2009 16:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a606z5sm88rz for ; Wed, 1 Jul 2009 16:00:28 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 154453A67AF for ; Wed, 1 Jul 2009 16:00:28 -0700 (PDT) Received: from dnab422234.stanford.edu ([171.66.34.52]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MM8n4-0002Pq-Lm; Wed, 01 Jul 2009 16:00:34 -0700 Message-Id: <2F5F2067-96A5-464A-8817-98C174A4B537@cs.stanford.edu> From: Philip Levis To: Mukul Goyal In-Reply-To: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 16:00:34 -0700 References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:00:28 -0000 On Jul 1, 2009, at 3:55 PM, Mukul Goyal wrote: > Why is it that such a DAG may lead to better routes than one based > strictly on min hop-distance (i.e. where a node would be required to > discard parents when it finds less deeper ones)? There is a tremendous amount of research in wireless which has shown that min hop-distance is not a good metric for wireless networks. DeCouto's paper is probably the best experimental study: http://pdos.csail.mit.edu/~rtm/papers/etx.pdf Any proposal which suggests that routing should be in terms of hop- count is dead in the water. Phil From prvs=4263ebebf=mukul@uwm.edu Wed Jul 1 16:07:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9093A6C75 for ; Wed, 1 Jul 2009 16:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 XAlwP7whwcpB for ; Wed, 1 Jul 2009 16:07:26 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 5E58D3A6C1A for ; Wed, 1 Jul 2009 16:07:26 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 01 Jul 2009 18:07:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id F25D8B20002 for ; Wed, 1 Jul 2009 18:07:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf9GNKbLtcc8 for ; Wed, 1 Jul 2009 18:07:46 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A82D9B20001 for ; Wed, 1 Jul 2009 18:07:46 -0500 (CDT) Date: Wed, 1 Jul 2009 18:07:46 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:07:27 -0000 Let me rephrase: The question is why is it that a DAG where a node can have parents with different depths is inherently better than one where a node can have parents of same depth only (where the depth may or may not be same as the min hop distance from the root)? Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "roll" Sent: Wednesday, July 1, 2009 5:55:54 PM GMT -06:00 US/Canada Central Subject: [Roll] RPL: why not base a DAG on the min hop distance from the root? RPL allows a node to have parents with different depths from the root. By choosing deeper neighbors as parents, a node increases its own depth (required to be more than that of any of its parents to avoid loops) and thus makes itself less attractive for selection as a parent. RPL also allows a node to discard its deeper parents to improve its own depth and thus make itself more attactive for selection as a parent. But this is not mandatory. The question is what is the inherent benefit of this flexibility? Why is it that such a DAG may lead to better routes than one based strictly on min hop-distance (i.e. where a node would be required to discard parents when it finds less deeper ones)? Under the RPL approach, the depth of a node is an upper bound on its hop distance from the root. It just tells that a packet forwarded to the node may take anywhere between 1 and the "depth" hops to reach the root (unless the node maintains the "min_hop_distance" from the root as well, in which case a packet forwarded to the node may take any where between "min_hop_distance" and "depth" hops to reach the root). The end result is that a node has very little control over the number of hops a packet, it forwards, takes to reach the root. It seems to me that forcing the depth to be same as the min hop distance would still allow all the benefits of DAGs (loop avoidance, flexible routes in face of topology changes) while assigning a better meaning to the term "depth". Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Wed Jul 1 16:17:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A853A6C1A for ; Wed, 1 Jul 2009 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiaWfj4jwW71 for ; Wed, 1 Jul 2009 16:17:13 -0700 (PDT) Received: from smtp103-mob.biz.mail.ac4.yahoo.com (smtp103-mob.biz.mail.ac4.yahoo.com [76.13.13.224]) by core3.amsl.com (Postfix) with SMTP id 5C84A3A69AD for ; Wed, 1 Jul 2009 16:13:56 -0700 (PDT) Received: (qmail 42412 invoked from network); 1 Jul 2009 23:14:01 -0000 Received: from unknown (HELO bda1055.bisx.prod.on.blackberry) (d.sturek@67.223.70.32 with xymcookie) by smtp103-mob.biz.mail.ac4.yahoo.com with SMTP; 1 Jul 2009 23:14:01 -0000 X-YMail-OSG: ZNVQU3UVM1l_fA5HizcxLFCMkOU5Ez4xrfR_nzsagNxnZ5QUMemklxKfWCNOpYIbkzpHpfpwomj9Ur694vOzcgJUR9v0e9KqNzdWhqTeLm3R8Rw5zgPYQniYJOBv06wQuPYnD7PsaLQ2RUdKREvZj7z5YvRaxIX5aueUnD3v7_tuKZyH0e.AHp_seGTln1vHkBZtKx4D5sNtmP4AYEoSYIS5Gtw4pUXXRhMUsWbMvU04S71_1e0vGFCzHaqNTr5s6aTjGxNM4QXLU2LitNc4776KEKM7w2Gd1ypvQpcBvQUs2Q-- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 330485463 Message-ID: <330485463-1246490040-cardhu_decombobulator_blackberry.rim.net-1157327261-@bxe1266.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu><2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> Sensitivity: Normal Importance: Normal To: "Mukul Goyal" , roll-bounces@ietf.org, "roll" From: d.sturek@att.net Date: Wed, 1 Jul 2009 23:16:31 +0000 Content-Type: text/plain MIME-Version: 1.0 Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:17:14 -0000 SGkgTXVrdWwsDQoNCkkgdGhpbmsgYSBmZWF0dXJlIHdoZXJlIGEgZGV2aWNlIGNhbiBlbGVjdCBv biBpdHMgb3duIChhYnNlbnQgYW55IHRvcG9sb2dpY2FsIGtub3dsZWRnZSBvZiB0aGUgbmV0d29y aykgdG8gZG93bmdyYWRlIGl0c2VsZiBpbiBkZXB0aCBpcyBxdWVzdGlvbmFibGUuDQoNClBoaWw6 ICBVbmRlciB3aGF0IGNpcmN1bXN0YW5jZXMgY291bGQgeW91IHNlZSBhIGRldmljZSBtYWtpbmcg c3VjaCBhbiBlbGVjdGlvbj8NCg0KRG9uDQpTZW50IHZpYSBCbGFja0JlcnJ5IGZyb20gVC1Nb2Jp bGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11a3VsIEdveWFsIDxtdWt1 bEB1d20uZWR1Pg0KDQpEYXRlOiBXZWQsIDEgSnVsIDIwMDkgMTg6MDc6NDYgDQpUbzogcm9sbDxy b2xsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSb2xsXSBSUEw6IHdoeSBub3QgYmFzZSBhIERB RyBvbiB0aGUgbWluIGhvcCBkaXN0YW5jZSBmcm9tIHRoZQ0KIHJvb3Q/DQoNCg0KTGV0IG1lIHJl cGhyYXNlOg0KDQpUaGUgcXVlc3Rpb24gaXMgd2h5IGlzIGl0IHRoYXQgYSBEQUcgd2hlcmUgYSBu b2RlIGNhbiBoYXZlIHBhcmVudHMgd2l0aCBkaWZmZXJlbnQgZGVwdGhzIGlzIGluaGVyZW50bHkg YmV0dGVyIHRoYW4gb25lIHdoZXJlIGEgbm9kZSBjYW4gaGF2ZSBwYXJlbnRzIG9mIHNhbWUgZGVw dGggb25seSAod2hlcmUgdGhlIGRlcHRoIG1heSBvciBtYXkgbm90IGJlIHNhbWUgYXMgdGhlIG1p biBob3AgZGlzdGFuY2UgZnJvbSB0aGUgcm9vdCk/DQoNClRoYW5rcw0KTXVrdWwNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVk dT4NClRvOiAicm9sbCIgPHJvbGxAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMSwg MjAwOSA1OjU1OjU0IFBNIEdNVCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwNClN1YmplY3Q6IFtS b2xsXSBSUEw6IHdoeSBub3QgYmFzZSBhIERBRyBvbiB0aGUgbWluIGhvcCBkaXN0YW5jZSBmcm9t IHRoZSByb290Pw0KDQpSUEwgYWxsb3dzIGEgbm9kZSB0byBoYXZlIHBhcmVudHMgd2l0aCBkaWZm ZXJlbnQgZGVwdGhzIGZyb20gdGhlIHJvb3QuIEJ5IGNob29zaW5nIGRlZXBlciBuZWlnaGJvcnMg YXMgcGFyZW50cywgYSBub2RlIGluY3JlYXNlcyBpdHMgb3duIGRlcHRoIChyZXF1aXJlZCB0byBi ZSBtb3JlIHRoYW4gdGhhdCBvZiBhbnkgb2YgaXRzIHBhcmVudHMgdG8gYXZvaWQgbG9vcHMpIGFu ZCB0aHVzIG1ha2VzIGl0c2VsZiBsZXNzIGF0dHJhY3RpdmUgZm9yIHNlbGVjdGlvbiBhcyBhIHBh cmVudC4NCg0KUlBMIGFsc28gYWxsb3dzIGEgbm9kZSB0byBkaXNjYXJkIGl0cyBkZWVwZXIgcGFy ZW50cyB0byBpbXByb3ZlIGl0cyBvd24gZGVwdGggYW5kIHRodXMgbWFrZSBpdHNlbGYgbW9yZSBh dHRhY3RpdmUgZm9yIHNlbGVjdGlvbiBhcyBhIHBhcmVudC4gQnV0IHRoaXMgaXMgbm90IG1hbmRh dG9yeS4NCg0KVGhlIHF1ZXN0aW9uIGlzIHdoYXQgaXMgdGhlIGluaGVyZW50IGJlbmVmaXQgb2Yg dGhpcyBmbGV4aWJpbGl0eT8gV2h5IGlzIGl0IHRoYXQgc3VjaCBhIERBRyBtYXkgbGVhZCB0byBi ZXR0ZXIgcm91dGVzIHRoYW4gb25lIGJhc2VkIHN0cmljdGx5IG9uIG1pbiBob3AtZGlzdGFuY2Ug KGkuZS4gd2hlcmUgYSBub2RlIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGRpc2NhcmQgcGFyZW50cyB3 aGVuIGl0IGZpbmRzIGxlc3MgZGVlcGVyIG9uZXMpPw0KDQpVbmRlciB0aGUgUlBMIGFwcHJvYWNo LCB0aGUgZGVwdGggb2YgYSBub2RlIGlzIGFuIHVwcGVyIGJvdW5kIG9uIGl0cyBob3AgZGlzdGFu Y2UgZnJvbSB0aGUgcm9vdC4gSXQganVzdCB0ZWxscyB0aGF0IGEgcGFja2V0IGZvcndhcmRlZCB0 byB0aGUgbm9kZSBtYXkgdGFrZSBhbnl3aGVyZSBiZXR3ZWVuIDEgYW5kIHRoZSAiZGVwdGgiIGhv cHMgdG8gcmVhY2ggdGhlIHJvb3QgKHVubGVzcyB0aGUgbm9kZSBtYWludGFpbnMgdGhlICJtaW5f aG9wX2Rpc3RhbmNlIiBmcm9tIHRoZSByb290IGFzIHdlbGwsIGluIHdoaWNoIGNhc2UgYSBwYWNr ZXQgZm9yd2FyZGVkIHRvIHRoZSBub2RlIG1heSB0YWtlIGFueSB3aGVyZSBiZXR3ZWVuICJtaW5f aG9wX2Rpc3RhbmNlIiBhbmQgImRlcHRoIiBob3BzIHRvIHJlYWNoIHRoZSByb290KS4gVGhlIGVu ZCByZXN1bHQgaXMgdGhhdCBhIG5vZGUgaGFzIHZlcnkgbGl0dGxlIGNvbnRyb2wgb3ZlciB0aGUg bnVtYmVyIG9mIGhvcHMgYSBwYWNrZXQsIGl0IGZvcndhcmRzLCB0YWtlcyB0byByZWFjaCB0aGUg cm9vdC4NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBmb3JjaW5nIHRoZSBkZXB0aCB0byBiZSBzYW1l IGFzIHRoZSBtaW4gaG9wIGRpc3RhbmNlIHdvdWxkIHN0aWxsIGFsbG93IGFsbCB0aGUgYmVuZWZp dHMgb2YgREFHcyAobG9vcCBhdm9pZGFuY2UsIGZsZXhpYmxlIHJvdXRlcyBpbiBmYWNlIG9mIHRv cG9sb2d5IGNoYW5nZXMpIHdoaWxlIGFzc2lnbmluZyBhIGJldHRlciBtZWFuaW5nIHRvIHRoZSB0 ZXJtICJkZXB0aCIuDQoNClRoYW5rcw0KTXVrdWwNCiANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlz dA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y b2xsDQo= From gnawali@gmail.com Wed Jul 1 19:30:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E76C3A69DB for ; Wed, 1 Jul 2009 19:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF+3lcLA7dBT for ; Wed, 1 Jul 2009 19:30:58 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 0D6B73A68D9 for ; Wed, 1 Jul 2009 19:30:57 -0700 (PDT) Received: by yxe12 with SMTP id 12so2154607yxe.29 for ; Wed, 01 Jul 2009 19:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=M7czUR4h8aiFRGL0u9OGCsrWswfNvgzN8O2TmHzM4eM=; b=Adz/oq02wbo58lx6UmzCpL34ejXxYD5/HqsJR4RbDYdzmDfydZOLlnd+sjF0fh3W/n uO4AUCffPVdY9i1BerZn6oZeqC3/RO8pNRSXg/9i7Az5Dqtbz9JxCQdSIjk+Ngx19frB Da+sUsGQ+pK+TMI+0m0ELemJv6cKD7kghx/Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CIFBuvWuh8+LLpJSMq+ih/jxVFxCpg/75KrBb92120hgtvpo6i1c4PE3qVrIKZfjhH tQRGkLfka+gLDl3fLOFVzPzkjCtcPbufy6o4DziHEK3ZVWvCk9PWKqKXsze/LR8cQIZb 0GttjMGFCU3IYmOiYQ/23YkWUFs62qozp8cCo= MIME-Version: 1.0 Sender: gnawali@gmail.com Received: by 10.90.82.17 with SMTP id f17mr8882136agb.17.1246501878356; Wed, 01 Jul 2009 19:31:18 -0700 (PDT) In-Reply-To: <8763ecy368.fsf@kelsey-ws.hq.ember.com> References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> Date: Wed, 1 Jul 2009 19:31:18 -0700 X-Google-Sender-Auth: 7bf0f4219d05e387 Message-ID: From: Omprakash Gnawali To: Richard Kelsey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 02:30:59 -0000 On Wed, Jul 1, 2009 at 5:54 AM, Richard Kelsey wr= ote: ... > > =A0 > =A0 Also, the CTP paper describes in detail how it can be used to > =A0 > =A0 maintain a routing gradient: > =A0 > > =A0 > =A0 http://sing.stanford.edu/pubs/sing-09-01.pdf > =A0 > > =A0 > It does so by not using Trickle's suppression mechanism, > =A0 > which is the part of Trickle which worries me. > =A0 > Trickle-with-suppression and Trickle-without-suppression are > =A0 > substantially different algorithms. > > =A0 We have and are using Trickle's suppression mechanism > =A0 successfully in real deployments. We did run into the > =A0 scenarios you have raised and have dealt with them simply > =A0 by restricting when to increment c. > > My other concern with the suppression mechanism is how it > behaves in networks with variable density. =A0I have run a few > simulations of this. =A0If you have a cluster of, say, 20 > nodes that can all hear each other and a few scattered > outliers that can hear only one or two nodes in the cluster, > it can take a while for the outliers to hear an updated RA. > This doesn't happen in the original Trickle, as the outliers > get updated as soon as they themselves transmit. =A0With the > RA version, hearing an outdated RA does not trigger a > transmission. > > Would it be OK to unicast an RA in such a case? =A0In other > words, if node A hears an RA from node B that has an > older sequence number, node A could unicast its RA to B > while leaving its Trickle timer as-is. > > =A0 In my view, the suppression mechanism can be critical for > =A0 operation in dense environments - especially when using > =A0 links where broadcast can be very expensive compared to > =A0 unicast. > > I agree that there has to be a way to limit broadcasts. =A0I > am not convinced that Trickle is always appropriate, but I > admit that I do not have an alternative proposal. =A0Setting > k to infinity addresses my concerns. =A0In rpl-00 k is a > constant, DEFAULT_DIO_REDUNDANCY_CONSTANT. =A0We could add > a DIORedundancyLimit field. Just one data point from the CTP paper (which does not use suppression) - it has been known to work efficiently even in networks with node degree of up to (214,305) or (114,120). That is pretty dense. - om_p From jhui@archrock.com Wed Jul 1 19:35:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683303A6B1B for ; Wed, 1 Jul 2009 19:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b70ZiiC827xT for ; Wed, 1 Jul 2009 19:35:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id BB1C33A6ACB for ; Wed, 1 Jul 2009 19:35:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 48F28AF879; Wed, 1 Jul 2009 19:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8oLD+Gp-Flk; Wed, 1 Jul 2009 19:35:31 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id 70E06AF81C; Wed, 1 Jul 2009 19:35:31 -0700 (PDT) Message-Id: <3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> From: Jonathan Hui To: Omprakash Gnawali 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 v935.3) Date: Wed, 1 Jul 2009 19:35:29 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 02:35:14 -0000 On Jul 1, 2009, at 7:31 PM, Omprakash Gnawali wrote: > Just one data point from the CTP paper (which does not use > suppression) - it has been known to work efficiently even in networks > with node degree of up to (214,305) or (114,120). That is pretty > dense. Try the same experiment with LPL set to a reasonable duty cycle :) I'm not saying that suppression is necessary in all cases - just necessary in some cases. While we should be link agnostic, we should also be cognizant of link protocols that are likely to be used. -- Jonathan Hui From gnawali@gmail.com Wed Jul 1 19:41:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE3E28C0FE for ; Wed, 1 Jul 2009 19:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDgrSDEUVMZV for ; Wed, 1 Jul 2009 19:41:13 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 65FA93A6B1B for ; Wed, 1 Jul 2009 19:39:07 -0700 (PDT) Received: by yxe12 with SMTP id 12so2160595yxe.29 for ; Wed, 01 Jul 2009 19:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Fiz/eaFJo6UasXJ3Ra3ldxBj5TRmSS/AIdbU05bUZsk=; b=ILDzQ53hpIOCMbD31hJ3WIzdu52JBV3JkdDrLrxbj2+V5l2YP0ub6R/Z3EWXJIi1Uw Tj7KLTAwIG3Fl8wIbAIGQ0WizNeXfxgKzwZIN89GJj7+0Cxk652P4mijI4wrSZMBM8Ws xuAlt+/i9Y59pYuS8m82HTIsANjBGCAfARXfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EgPjNaQpGQZmpu2Xpx1A7nBzB41EIhYtv0AABD77KkZaV4gjqRVLD6IrC6FK9Lie7D c17Y04QjbejIzfvHOH+Y/MZa5o3XfQwePlwZ0CE+V7TlmWyVMLtewVGfr6vzTEvLJg8y ecIzqW76dESFyrZf65+wqTNEZkFAMkJBHSM9U= MIME-Version: 1.0 Sender: gnawali@gmail.com Received: by 10.90.117.17 with SMTP id p17mr8864607agc.83.1246502367747; Wed, 01 Jul 2009 19:39:27 -0700 (PDT) In-Reply-To: <330485463-1246490040-cardhu_decombobulator_blackberry.rim.net-1157327261-@bxe1266.bisx.prod.on.blackberry> References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <330485463-1246490040-cardhu_decombobulator_blackberry.rim.net-1157327261-@bxe1266.bisx.prod.on.blackberry> Date: Wed, 1 Jul 2009 19:39:27 -0700 X-Google-Sender-Auth: 74cb85181c76676d Message-ID: From: Omprakash Gnawali To: d.sturek@att.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 02:41:14 -0000 On Wed, Jul 1, 2009 at 4:16 PM, wrote: > Hi Mukul, > > I think a feature where a device can elect on its own (absent any topolog= ical knowledge of the network) to downgrade itself in depth is questionable= . > > Phil: =A0Under what circumstances could you see a device making such an e= lection? When the selected parent is unreachable, the ability to select a new parent quickly? - om_p From pal@cs.stanford.edu Wed Jul 1 20:01:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25AE83A68F8 for ; Wed, 1 Jul 2009 20:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA2tNgvGFQNU for ; Wed, 1 Jul 2009 20:01:08 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 70C573A68AF for ; Wed, 1 Jul 2009 20:01:08 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MMCYE-0000Ga-NG; Wed, 01 Jul 2009 20:01:30 -0700 In-Reply-To: <3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> <3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 1 Jul 2009 20:01:29 -0700 To: Jonathan Hui X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:01:09 -0000 On Jul 1, 2009, at 7:35 PM, Jonathan Hui wrote: > > On Jul 1, 2009, at 7:31 PM, Omprakash Gnawali wrote: >> Just one data point from the CTP paper (which does not use >> suppression) - it has been known to work efficiently even in networks >> with node degree of up to (214,305) or (114,120). That is pretty >> dense. > > Try the same experiment with LPL set to a reasonable duty cycle :) > > I'm not saying that suppression is necessary in all cases - just > necessary in some cases. While we should be link agnostic, we > should also be cognizant of link protocols that are likely to be used. I agree. I would take the CTP results to say that a network *can* work without suppression, but it's quite clear that doing so is desirable. I'll go out on a limb and say that exactly how the suppression works is something which should not be specified yet: that leaves it open for future work to figure out, just as 793 doesn't specify fast retransmit. Instead, the specification should state the MUSTs of when RAs are sent necessary for correct operation and note that additional RAs MAY be sent. I'd interpret this as MUSTs of when the timer must be reset and when packets MUST NOT increment c. Phil I'd Phil From jhui@archrock.com Wed Jul 1 20:13:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40D83A6CA6 for ; Wed, 1 Jul 2009 20:13:38 -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 FqQIRcUY6BsL for ; Wed, 1 Jul 2009 20:13: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 EB8CC3A6C90 for ; Wed, 1 Jul 2009 20:13:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 58FECAF860; Wed, 1 Jul 2009 20:14:00 -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 oa81Mc5TAFlX; Wed, 1 Jul 2009 20:13:55 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id 54E07AF81E; Wed, 1 Jul 2009 20:13:55 -0700 (PDT) Message-Id: <95145504-4D31-46E7-9F2B-5A6B36DAAA1C@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 20:13:54 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com> <852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu> <877hytqrzg.fsf@kelsey-ws.hq.ember.com> <243111A7-189D-4FF9-8B50-87553D77A233@archrock.com> <8763ecy368.fsf@kelsey-ws.hq.ember.com> <3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:13:38 -0000 On Jul 1, 2009, at 8:01 PM, Philip Levis wrote: >> I'm not saying that suppression is necessary in all cases - just >> necessary in some cases. While we should be link agnostic, we >> should also be cognizant of link protocols that are likely to be >> used. > > I agree. I would take the CTP results to say that a network *can* > work without suppression, but it's quite clear that doing so is > desirable. > > I'll go out on a limb and say that exactly how the suppression works > is something which should not be specified yet: that leaves it open > for future work to figure out, just as 793 doesn't specify fast > retransmit. Instead, the specification should state the MUSTs of > when RAs are sent necessary for correct operation and note that > additional RAs MAY be sent. I'd interpret this as MUSTs of when the > timer must be reset and when packets MUST NOT increment c. Sure. There seems to be a dependency between suppression and the routing metric anyway, so I think we can lump this in with these "logic plugins" that are occasionally referred to on the ML. Only issue is now we have to interoperate with nodes that may never suppress themselves. Since we're talking about variations of Trickle suppression rules, I'd say that we might want nodes to force an advertisement with a relatively long period to avoid starvation when neighboring nodes fail to suppress themselves. It does, however, mean that these slow, unsuppressed advertisements will grow with density. But if the WG agrees to defer the suppression specification, then we can table this discussion for now. -- Jonathan Hui From pal@cs.stanford.edu Wed Jul 1 20:16:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFFB3A696F for ; Wed, 1 Jul 2009 20:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id howi12t1-w9X for ; Wed, 1 Jul 2009 20:16:21 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E0D2528C0FE for ; Wed, 1 Jul 2009 20:13:59 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MMCkg-0000mQ-8R; Wed, 01 Jul 2009 20:14:22 -0700 In-Reply-To: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 1 Jul 2009 20:14:21 -0700 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:16:22 -0000 On Jul 1, 2009, at 4:07 PM, Mukul Goyal wrote: > Let me rephrase: > > The question is why is it that a DAG where a node can have parents > with different depths is inherently better than one where a node > can have parents of same depth only (where the depth may or may not > be same as the min hop distance from the root)? > > Thanks > Mukul The reason Om mentioned is a good one. While a node might prefer a parent at the same hopcount in order to prevent loops (IIRC the ARC stack does this), it should not require one. Given that you are routing in terms of a different metric, this constraint leads to inefficient routes. I'd actually flip this around: almost all working LLN mesh protocols I know of do not enforce this limitation. Why do you think going against this common wisdom is a good idea? It wasn't an arbitrary decision. Phil From jhui@archrock.com Wed Jul 1 20:31:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDDC3A68D8 for ; Wed, 1 Jul 2009 20:31:54 -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 c49YoG8ePBY0 for ; Wed, 1 Jul 2009 20:31:54 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id F1A133A68C5 for ; Wed, 1 Jul 2009 20:31:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 80938AF879; Wed, 1 Jul 2009 20:32:16 -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 hebtG4YgXw66; Wed, 1 Jul 2009 20:32:11 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id A902CAF81E; Wed, 1 Jul 2009 20:32:11 -0700 (PDT) Message-Id: From: Jonathan Hui To: Philip Levis 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 v935.3) Date: Wed, 1 Jul 2009 20:32:10 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:31:54 -0000 On Jul 1, 2009, at 8:14 PM, Philip Levis wrote: >> Let me rephrase: >> >> The question is why is it that a DAG where a node can have parents >> with different depths is inherently better than one where a node >> can have parents of same depth only (where the depth may or may not >> be same as the min hop distance from the root)? >> >> Thanks >> Mukul > > The reason Om mentioned is a good one. While a node might prefer a > parent at the same hopcount in order to prevent loops (IIRC the ARC > stack does this), it should not require one. Given that you are > routing in terms of a different metric, this constraint leads to > inefficient routes. Phil put his finger on an important point. We want to select routes using metrics that are not necessarily based on hop-count for a variety of reasons (e.g. ETX), but hop-count is a way to avoid and detect loops while being agnostic to the metric used. This distinction highlights a subtle difference between the Arch Rock stack and CTP, where the former uses hop-count for data-path loop detection and the latter uses the routing cost itself. With ETX and other metrics, it's not uncommon to have an equal path cost through parents that have different hop counts from the root. -- Jonathan Hui From prvs=4276677de=mukul@uwm.edu Wed Jul 1 20:37:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634333A68C9 for ; Wed, 1 Jul 2009 20:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 j+gHjRfai14S for ; Wed, 1 Jul 2009 20:37:55 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 912123A685D for ; Wed, 1 Jul 2009 20:37:55 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta2.uwm.edu with ESMTP; 01 Jul 2009 22:38:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 7E451B2000E; Wed, 1 Jul 2009 22:38:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGZRYIkBsKtW; Wed, 1 Jul 2009 22:38:04 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 587BDB20002; Wed, 1 Jul 2009 22:38:04 -0500 (CDT) Date: Wed, 1 Jul 2009 22:38:04 -0500 (CDT) From: Mukul Goyal To: Omprakash Gnawali Message-ID: <167394744.17701611246505884258.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1679362086.17701311246505704612.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:45:37 -0000 I don't think that selecting parents with multiple depths provides any fund= amental advantage when a node needs to select a new parent. In both cases (all parents at same depth and parents with multiple depths),= selecting a new parent may require a node to change its depth. Similarly, in both cases, a node may be able to choose a new parent _quickl= y_ from the set of neighbors it already knows without changing its depth. Thanks Mukul =20 ----- Original Message ----- From: "Omprakash Gnawali" To: "d sturek" Cc: "Mukul Goyal" , "roll" Sent: Wednesday, July 1, 2009 9:39:27 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from t= heroot? On Wed, Jul 1, 2009 at 4:16 PM, wrote: > Hi Mukul, > > I think a feature where a device can elect on its own (absent any topolog= ical knowledge of the network) to downgrade itself in depth is questionable= . > > Phil: =C2=A0Under what circumstances could you see a device making such a= n election? When the selected parent is unreachable, the ability to select a new parent quickly? - om_p From pal@cs.stanford.edu Wed Jul 1 21:01:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3593A68C5 for ; Wed, 1 Jul 2009 21:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmE7O-P8o7pV for ; Wed, 1 Jul 2009 21:01:19 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id BEF353A67E1 for ; Wed, 1 Jul 2009 21:01:19 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MMDUQ-0003jB-Ic; Wed, 01 Jul 2009 21:01:38 -0700 In-Reply-To: <167394744.17701611246505884258.JavaMail.root@mail02.pantherlink.uwm.edu> References: <167394744.17701611246505884258.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 1 Jul 2009 21:01:37 -0700 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:01:20 -0000 On Jul 1, 2009, at 8:38 PM, Mukul Goyal wrote: > I don't think that selecting parents with multiple depths provides > any fundamental advantage when a node needs to select a new parent. Well, "think" is a belief. On the other hand, there's experimental evidence and engineering experience to the contrary, that such a constraint is disadvantageous. I'd rather follow hard facts. Phil From prvs=4276677de=mukul@uwm.edu Wed Jul 1 21:10:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365CF3A68C9 for ; Wed, 1 Jul 2009 21:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 F7rubPiLxVbf for ; Wed, 1 Jul 2009 21:10:57 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 3E1A53A689D for ; Wed, 1 Jul 2009 21:10:57 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 01 Jul 2009 23:11:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id CFE80B20007; Wed, 1 Jul 2009 23:11:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogxk9lFWcHsN; Wed, 1 Jul 2009 23:11:17 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 9D452B20002; Wed, 1 Jul 2009 23:11:17 -0500 (CDT) Date: Wed, 1 Jul 2009 23:11:17 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1059950206.17704301246507877537.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <380443858.17703891246507555643.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:10:58 -0000 Phil Experimental/engineering experience is not really "facts". Experimental/engineering experience depends to a large extent on the particular network topology etc. Change in the topology and other related factors can change the experimental results. I am still waiting for a strong argument in favor of parents at multiple depths. I have provided one in favor of same depth parents - it makes the term "depth" meaningful as the number of hops the packet would travel to reach the root. Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "Omprakash Gnawali" , "roll" Sent: Wednesday, July 1, 2009 11:01:37 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 1, 2009, at 8:38 PM, Mukul Goyal wrote: > I don't think that selecting parents with multiple depths provides > any fundamental advantage when a node needs to select a new parent. Well, "think" is a belief. On the other hand, there's experimental evidence and engineering experience to the contrary, that such a constraint is disadvantageous. I'd rather follow hard facts. Phil From jhui@archrock.com Wed Jul 1 21:13:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9163A6812 for ; Wed, 1 Jul 2009 21:13:08 -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 mSMX6JqCnBFC for ; Wed, 1 Jul 2009 21:13:07 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 73F063A67E1 for ; Wed, 1 Jul 2009 21:13:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 04BE8AF81E; Wed, 1 Jul 2009 21:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzxIjFbPmkOF; Wed, 1 Jul 2009 21:13:22 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id 27923AF860; Wed, 1 Jul 2009 21:13:22 -0700 (PDT) Message-Id: From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1059950206.17704301246507877537.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 21:13:21 -0700 References: <1059950206.17704301246507877537.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:13:08 -0000 On Jul 1, 2009, at 9:11 PM, Mukul Goyal wrote: > I am still waiting for a strong argument in favor of parents at > multiple depths. I have provided one in favor of same depth parents > - it makes the term "depth" meaningful as the number of hops the > packet would travel to reach the root. But depth is often not what we really care about... ETX is just one example. -- Jonathan Hui From prvs=4276677de=mukul@uwm.edu Wed Jul 1 21:20:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088863A6BC7 for ; Wed, 1 Jul 2009 21:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 089rK5nWu04j for ; Wed, 1 Jul 2009 21:20:04 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 1C30D3A689D for ; Wed, 1 Jul 2009 21:20:04 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta2.uwm.edu with ESMTP; 01 Jul 2009 23:20:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 49F3EB2000F; Wed, 1 Jul 2009 23:20:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxS0V5xUJlxJ; Wed, 1 Jul 2009 23:20:26 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 22641B2000B; Wed, 1 Jul 2009 23:20:26 -0500 (CDT) Date: Wed, 1 Jul 2009 23:19:21 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1209984168.17704771246508361046.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:20:05 -0000 It is possible that I will be surprised. But I will be really surprised if people dont care about how many hops their packets travel before they reach the root. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "Philip Levis" , "roll" , "Omprakash Gnawali" Sent: Wednesday, July 1, 2009 11:13:21 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 1, 2009, at 9:11 PM, Mukul Goyal wrote: > I am still waiting for a strong argument in favor of parents at > multiple depths. I have provided one in favor of same depth parents > - it makes the term "depth" meaningful as the number of hops the > packet would travel to reach the root. But depth is often not what we really care about... ETX is just one example. -- Jonathan Hui From prvs=4276677de=mukul@uwm.edu Wed Jul 1 21:21:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CB83A689D for ; Wed, 1 Jul 2009 21:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 Bd5RdzeP+bAB for ; Wed, 1 Jul 2009 21:21:53 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 084D13A67E1 for ; Wed, 1 Jul 2009 21:21:52 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 01 Jul 2009 23:22:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 303A9B2000C; Wed, 1 Jul 2009 23:22:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6U8QgvjIPku; Wed, 1 Jul 2009 23:22:15 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 09818B20003; Wed, 1 Jul 2009 23:22:15 -0500 (CDT) Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1537394276.17704851246508389926.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:21:53 -0000 It is possible that I will be surprised. But I will be really surprised if people dont care about how many hops their packets travel before they reach the root. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "Philip Levis" , "roll" , "Omprakash Gnawali" Sent: Wednesday, July 1, 2009 11:13:21 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 1, 2009, at 9:11 PM, Mukul Goyal wrote: > I am still waiting for a strong argument in favor of parents at > multiple depths. I have provided one in favor of same depth parents > - it makes the term "depth" meaningful as the number of hops the > packet would travel to reach the root. But depth is often not what we really care about... ETX is just one example. -- Jonathan Hui From jhui@archrock.com Wed Jul 1 21:27:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752923A6B87 for ; Wed, 1 Jul 2009 21:27:32 -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 oiu64vHtB6lf for ; Wed, 1 Jul 2009 21:27: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 6AD273A67E1 for ; Wed, 1 Jul 2009 21:27:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 07369AF881; Wed, 1 Jul 2009 21:27:54 -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 3kg75zSPe+Vu; Wed, 1 Jul 2009 21:27:49 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id 124D5AF81E; Wed, 1 Jul 2009 21:27:49 -0700 (PDT) Message-Id: <8C40864E-AAC3-48C6-9D73-1AC0B388E93B@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 21:27:48 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll , Omprakash Gnawali Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:27:32 -0000 On Jul 1, 2009, at 9:22 PM, Mukul Goyal wrote: > It is possible that I will be surprised. > > But I will be really surprised if people dont care about how many > hops their packets travel before they reach the root. Hops is often a factor, but I'd argue that hops alone does not lend itself to building robust networking. ETX, for example, reduces to hops when link success rates are 100% for all links. But we know link success rates are never 100%, hence the lossy. On lossy links, the number of transmissions is much more important than the number of hops - it is a much better indicator of end-to-end communication delay, channel utilization, energy consumption, etc. -- Jonathan Hui From Manhar.Goindi@landisgyr.com Wed Jul 1 21:46:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482603A6CE3 for ; Wed, 1 Jul 2009 21:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=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 HlEuQPmDPzPj for ; Wed, 1 Jul 2009 21:46:23 -0700 (PDT) Received: from mail.ap.landisgyr.com (mail.ap.landisgyr.com [61.8.13.202]) by core3.amsl.com (Postfix) with ESMTP id CCCDA3A6C2A for ; Wed, 1 Jul 2009 21:46:22 -0700 (PDT) Received: from mail pickup service by mail.ap.landisgyr.com with Microsoft SMTPSVC; Thu, 2 Jul 2009 14:46:43 +1000 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FAD0.154EF5FD" Date: Thu, 2 Jul 2009 14:46:35 +1000 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B2421F@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1 Thread-Index: Acn4dPg7R69y6SvLTY+gr1em4Xy6YgA2wd9AAAvMFAAAVBX6IA== References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B2421F@xmb-ams-337.emea.cisco.com> From: "Goindi, Manhar" To: "Pascal Thubert \(pthubert\)" , "JP Vasseur \(jvasseur\)" , "ROLL WG" X-OriginalArrivalTime: 02 Jul 2009 04:46:43.0862 (UTC) FILETIME=[1922C360:01C9FAD0] Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:46:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FAD0.154EF5FD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 Thanks for your clarification! =20 I shall await the use case drafts and the enhanced metrics draft to get = more clarity on the manner to short-list preferred parents & siblings. = For instance, there could be a metric for choosing parents and another = metric to choose siblings. =20 I agree that Case 1 & Case 2 are loops and are not desirable. Case 4 is = superior to Case 3 by offering an alternate path for forwarding by way = of siblings. Thanks for the illustration. =20 =20 Thanks & Best Regards, Manhar Goindi From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Tuesday, June 30, 2009 7:20 PM To: Goindi, Manhar; JP Vasseur (jvasseur); ROLL WG Subject: RE: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1 =20 1. How does a node know that DIO it has received from a node should be = taken as a Parent or a Sibling with reference to Example in section = 3.3.1.4.1? I mean how would it decide its own depth. =20 Hi Manhar: =20 The component that makes that resolution is out of scope. That = component, that I call plugin for the lack of a better term, depends on = the metrics which in turn depend on the link type (like RSSI) and the = use case (like battery). Because the plugin depends on the metrics, it = makes more sense to specify reference examples using those metrics in = the current metrics drafts. Other drafts might follow for more specific = use cases, and you might even find RA extensions and plugins that are = completely proprietary.=20 =20 The plugin component is very loosely constrained. It selects an ordered = set of preferred parents and from then generic RPL takes over. RPL will = use for this node a depth that is incremented from the depth of the = deepest parent. The resulting depth enables an abstraction of feasible = successors in the same DAG, some parents (least depth) some siblings = (same depth). Loop avoidance is guaranteed by construction when packets = are passed to parents. It is attempted on a per packet basis when = forwarding via siblings. =20 Note that the plugin might not be use the depth as primary selector for = the choice of the preferred parent. For instance that a node sees 2 = routers, one at depth 1 with a poor signal indicator and one at depth 2 = with a very good signal. The plugin should prefer the second router.=20 =20 The resulting graph might depend a lot on how greedy the plugins are. = If you consider that a node is richer when it has a higher number of = feasible successors, what society are we trying to build? Let me give = you an example. We have a triangle, A, B, C. A is a root and B and C = dynamically appear. Once things settle, you could end up with a = situation like: =20 =20 +--->A<---+ +--->A<---+ +--->A<---+ +--->A<---+ | | | | | | | | | | |+--->---+| | | | | B Manhar Goindi Technical Expert Phone: +91 120 3352149 -------->C B| |C B C B<------->C +---<---+ Case 1 Case 2 Case 3 Case 4 =20 Case 1: B is a scrooge. If it comes up after C it sees A and C and = tries to optimize locally its number of parents. If C comes later, B = detaches from A and reattaches to again get 2 parents. The resulting = depths are A:0, C:1 and B:2 . Drawback: C is always deprived from an = alternate forwarding solution. Greediness is discouraged unless the node = has a very good reason like critical + low battery but draft 00 lacks = any clear cut constraint about that. =20 Case 2: C is also greedy. So when B attaches to C as before, C will = detach from A to reattach to B and C, and we are in a loop till maximum = depth. At which point the looser will attach to A only and we start over = the count to infinity. This is definitively broken. A simple tie break = is to ignore RAs from deeper, and this is MUSTed in section 5.4 at the = end of item 5. So, case 2 is actually impossible with the current spec. =20 Case 3. B & C are both genuinely altruistic, so anxious of the benefit = of others that they wouldn't dare get deeper than they could. So they = end up at depth 1 with only one feasible successor, A. The result is in = fact even worse than case 1 because neither B nor C can benefit from the = other. =20 Case 4. Same as case 3 with a new rule of allowing sibling forwarding. = In that case, B and C are still both depth 1, but they can use one = another as alternate (backup) feasible successors. Because the sibling = hops do not belong to the DAG, they are not loopless by construction and = additional measures must be taken like always prefer a real parent, do = not give a packet back to a sibling, decrement hop limit faster, that = sort of thing. =20 The spec is very open but case 4 might be often desirable but for = specific nodes that really need to be greedier than average. One way of = doing this is to select only ONE preferred parent (then again not = necessarily the shallowest one) and orient its vector in the gradient = towards that guy. If we do that, the depth will really represent the = hops over the preferred and most probable path as opposed to the worst = path within selected parents. =20 My take is that we should SHOULD that behavior. What do you think? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Goindi, Manhar Sent: mardi 30 juin 2009 11:15 To: JP Vasseur (jvasseur); ROLL WG Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt =20 Hi JP, =20 Thanks a lot for sharing this draft as it proved very informative & I = thoroughly enjoyed reading it. =20 I have the following queries: =20 2. How does a node know that DIO it has received from a node should be = taken as a Parent or a Sibling with reference to Example in section = 3.3.1.4.1? I mean how would it decide its own depth. 3. In Section 3.3.4.4 =E2=80=93 why doesn=E2=80=99t node 51 reattach = itself as a child to node 53 instead of making node 52 as its parent? = Is it that node 51 cannot hear node 53 directly so it has to go through = node 52? 4. Can siblings hear each other as it is not evident from Figure 2: = Example DAG? 5. In section 3.3.4.1: Moving Down a DAG =E2=80=93 it is mentioned that = there is little change for a loop and node 56 may reattach to DAG with = parents 43 & 55. How is the formation or non-formation of this loop = detected? What is the mechanism for that? =20 Would someone like to see if there is an answer to them? =20 =20 Thanks & Best Regards, Manhar Goindi =20 Manhar Goindi Technical Expert Landis+Gyr =20 Phone: +91 120 3352149 manhar.goindi@landisgyr.com www.landisgyr.com =20 manage energy better From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur Sent: Monday, June 29, 2009 10:19 AM To: ROLL WG Subject: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt =20 Here you are. =20 Thanks. =20 JP. =20 Begin forwarded message: =20 From: Internet-Drafts@ietf.org Date: June 29, 2009 1:15:01 AM CEDT To: i-d-announce@ietf.org Subject: I-D Action:draft-dt-roll-rpl-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 Title : RPL: Routing Protocol for Low Power and = Lossy Networks Author(s) : T. Winter, R. Team Filename : draft-dt-roll-rpl-00.txt Pages : 60 Date : 2009-06-28 =20 This document specifies the Routing Protocol for Low Power and Lossy Networks (RPL), in accordance with the requirements described in [I-D.ietf-roll-building-routing-reqs], [I-D.ietf-roll-home-routing-reqs], [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dt-roll-rpl-00.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 =EF=81=90 PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. =20 This e-mail (including any attachments) is confidential and may be = legally privileged. If you are not an intended recipient or an = authorized representative of an intended recipient, you are prohibited = from using, copying or distributing the information in this e-mail or = its attachments. If you have received this e-mail in error, please = notify the sender immediately by return e-mail and delete all copies of = this message and any attachments. Thank you. ------_=_NextPart_001_01C9FAD0.154EF5FD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Thanks for your clarification!

 

I shall await the use case drafts and the enhanced = metrics draft to get more clarity on the manner to short-list preferred parents & siblings.  For instance, there could be a metric for choosing = parents and another metric to choose siblings.

 

I agree that Case 1 & Case 2 are loops and are not desirable.  Case 4 is superior to Case 3 by offering an alternate = path for forwarding by way of siblings.  Thanks for the = illustration.

 

 

Thanks & Best Regards,

Manhar Goindi



Manhar = Goindi
Technical Expert
Phone: +91 120 = 3352149

From:= Pascal = Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, June 30, 2009 7:20 PM
To: Goindi, Manhar; JP Vasseur (jvasseur); ROLL WG
Subject: RE: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt = Q1

 

1. How does a node know that DIO it has received = from a node should be taken as a Parent or a Sibling with reference to Example = in section 3.3.1.4.1?  I mean how would it decide its own = depth.

 

Hi Manhar:

 

The component that makes that resolution is out = of scope. That component, that I call plugin for the lack of a better term,  = depends on the metrics which in turn depend on the link type (like RSSI) and the = use case (like battery). Because the plugin depends on the metrics, it makes = more sense to specify reference examples using those metrics in the current = metrics drafts. Other drafts might follow for more specific use cases, and you = might even find RA extensions and plugins that are completely proprietary. =

 

The plugin component is very loosely = constrained. It selects an ordered set of preferred parents and from then generic RPL takes = over. RPL will use for this node a depth that is incremented from the depth of the deepest parent. The resulting depth enables an abstraction of feasible successors in the same DAG, some parents (least depth) some siblings = (same depth). Loop avoidance is guaranteed by construction when packets are = passed to parents. It is attempted on a per packet basis when forwarding via = siblings.

 

Note that the plugin might not be use the depth = as primary selector for the choice of the preferred parent. For instance that a = node sees 2 routers, one at depth 1 with a poor signal indicator and one at depth = 2 with a very good signal. The plugin should prefer the second router. =

 

The resulting graph might depend a lot on how = greedy the plugins are.  If you consider that a node is richer when it has a = higher number of feasible successors, what society are we trying to build? Let = me give you an example. We have a triangle, A, B, C. A is  a root and B and = C dynamically appear. Once things settle, you could end up with a situation = like: 

         =

 +--->A<---+     = ;   +--->A<---+        +--->A<---+      &n= bsp; +--->A<---+

 |       &nb= sp; |        |         |        |         = |        |         |

 |       &nb= sp; |        = |+--->---+|        |         |        |         |

 B-------->C     &n= bsp;  B|       |C       = ; B         C        = B<------->C

        &nbs= p;            +---<---+

   Case 1            = Case 2            = Case 3            = Case 4

 

Case 1: B is a scrooge. If it comes up after C = it sees A  and C and tries to optimize locally its number of parents. If C = comes later, B detaches from A and reattaches to again get 2 parents. The = resulting depths are A:0, C:1 and B:2 . Drawback: C is always deprived from an = alternate forwarding solution. Greediness is discouraged unless the node has a = very good reason like critical + low battery but draft 00 lacks any clear cut = constraint about that.

 

Case 2:  C is also greedy. So when B = attaches to C as before, C will detach from A to reattach to B and C, and we are in a = loop till maximum depth. At which point the looser will attach to A only and = we start over the count to infinity. This is definitively broken. A simple = tie break is to ignore RAs from deeper, and this is MUSTed in section 5.4 at = the end of item 5. So, case 2 is actually impossible with the current = spec.

 

Case 3. B & C are both genuinely altruistic, = so anxious of the benefit of others that they wouldn't dare get deeper than = they could. So they end up at depth 1 with only one feasible successor, A. = The result is in fact even worse than case 1 because neither B nor C can = benefit from the other.

 

Case 4. Same as case 3 with a new rule of = allowing sibling forwarding. In that case, B and C are still both depth 1, but = they can use one another as alternate (backup) feasible successors. Because the = sibling hops do not belong to the DAG, they are not loopless by construction and additional measures must be taken like always prefer a real parent, do = not give a packet back to a sibling, decrement hop limit faster, that sort of = thing.

 

The spec is very open but case 4 might be often = desirable but for specific nodes that really need to be greedier than average. One = way of doing this is to select only ONE preferred parent (then again not = necessarily the shallowest one) and orient its vector in the gradient towards that = guy. If we do that, the depth will really represent the hops over the preferred = and most probable path as opposed to the worst path within selected = parents.

 

My take is that we should SHOULD that behavior. = What do you think?

 

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Goindi, = Manhar

Sent: mardi 30 juin 2009 = 11:15

To: JP Vasseur (jvasseur); ROLL = WG

Subject: Re: [Roll] Fwd: I-D = Action:draft-dt-roll-rpl-00.txt

 

Hi JP,

 

Thanks a lot for sharing this draft as it proved = very informative & I thoroughly enjoyed reading it.

 

I have the following queries:

 

2. How does a node know that DIO it has received = from a node should be taken as a Parent or a Sibling with reference to Example = in section 3.3.1.4.1?  I mean how would it decide its own = depth.

3. In Section 3.3.4.4 – why doesn’t = node 51 reattach itself as a child to node 53 instead of making node 52 as its = parent?  Is it that node 51 cannot hear node 53 directly so it has to go through = node 52?

4. Can siblings hear each other as it is not = evident from Figure 2:  Example DAG?

5. In section 3.3.4.1:  Moving Down a DAG = – it is mentioned that there is little change for a loop and node 56 may = reattach to DAG with parents 43 & 55.  How is the formation or = non-formation of this loop detected?  What is the mechanism for that?

 

Would someone like to see if there is an answer = to them?

 

 

Thanks & Best Regards,

Manhar Goindi

 

Manhar Goindi

Technical Expert

Landis+Gyr       =  

Phone: +91 120 3352149

manhar.goindi@landisgyr.com

www.landisgyr.com

 

manage energy better

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur

Sent: Monday, June 29, 2009 10:19 = AM

To: ROLL WG

Subject: [Roll] Fwd: I-D = Action:draft-dt-roll-rpl-00.txt

 

Here you are.

 

Thanks.

 

JP.

 

Begin forwarded message:

 

From: Internet-Drafts@ietf.org

Date: June 29, 2009 1:15:01 AM = CEDT

To: i-d-announce@ietf.org

Subject: I-D = Action:draft-dt-roll-rpl-00.txt 

Reply-To: = internet-drafts@ietf.org

 

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

 

        &nbs= p;   Title           : RPL: Routing Protocol for Low Power and Lossy Networks

        &nbs= p;   Author(s)       : T. Winter, R. = Team

        &nbs= p;   Filename        : = draft-dt-roll-rpl-00.txt

        &nbs= p;   Pages           : = 60

        &nbs= p;   Date            : 2009-06-28

 

This document specifies the Routing Protocol for = Low Power and Lossy

Networks (RPL), in accordance with the = requirements described in

[I-D.ietf-roll-building-routing-reqs],

[I-D.ietf-roll-home-routing-reqs],

[I-D.ietf-roll-indus-routing-reqs], and = [RFC5548].

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-dt-roll-rp= l-00.txt

 

Internet-Drafts are also available by anonymous = FTP at:

ftp://ftp.ietf.org/internet-drafts/

 

Below is the data which will enable a MIME = compliant mail reader

implementation to automatically retrieve the = ASCII version of the

Internet-Draft.

 

 PLEASE CONSIDER OUR ENVIRONMENT = BEFORE PRINTING THIS EMAIL.

 

This e-mail (including any attachments) is = confidential and may be legally privileged. If you are not an intended recipient or = an authorized representative of an intended recipient, you are prohibited = from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify = the sender immediately by return e-mail and delete all copies of this = message and any attachments. Thank you.

------_=_NextPart_001_01C9FAD0.154EF5FD-- From jvasseur@cisco.com Thu Jul 2 01:39:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15A93A67FA; Thu, 2 Jul 2009 01:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.727 X-Spam-Level: X-Spam-Status: No, score=-9.727 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, 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 vgphnGVdcwu1; Thu, 2 Jul 2009 01:39:17 -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 EF2083A6B0A; Thu, 2 Jul 2009 01:38:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,331,1243814400"; d="scan'208,217";a="44177010" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 08:39:14 +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 n628dE2U019547; Thu, 2 Jul 2009 10:39:14 +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.14.3) with ESMTP id n628dE22003363; Thu, 2 Jul 2009 08:39:14 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); Thu, 2 Jul 2009 10:39:14 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 10:39:13 +0200 Message-Id: <06460014-9658-4A11-89BB-0D7304665CDD@cisco.com> From: JP Vasseur To: ROLL WG , pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-359--301065336 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 11:46:30 +0200 References: <20090620012428.GA12782@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 08:39:13.0495 (UTC) FILETIME=[93C3D670:01C9FAF0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5535; t=1246523954; x=1247387954; 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:=20Fwd=3A=20Section=20Ordering=20in=20RFCs=20(Abst ract=20Placement) |Sender:=20; bh=sqiaXHjaCOceAq/973VlhpDp47AfR5+44jvGVoU7H6E=; b=bNq/8uJZeep+B65erOoAdHIidXn/Wup34yFkNORIvmqI+lyKkCaCLoxK9T sj/pg8KIlxV8Y4CKRgI1aS+6430gS737tyeGZj4az4f0/izivNXvJEsOkdB+ htQenKtK+w; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Fwd: Section Ordering in RFCs (Abstract Placement) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:39:18 -0000 --Apple-Mail-359--301065336 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: RFC Editor > Date: June 20, 2009 3:24:28 AM CEDT > To: ietf-announce@ietf.org, rfc-interest@rfc-editor.org > Cc: IAB , IESG , RFC Editor > > Subject: Section Ordering in RFCs (Abstract Placement) > > Greetings All, > > The recent changes to the copyright for RFCs (RFC 5378), and the > changes that will be required when > draft-iab-streams-headers-boilerplates-08.txt is published, often > result in the abstract not appearing on the front page of the RFC. > We concur with the IETF-list comments that expressed a desire to > keep the abstract on the front page of the RFC. For this reason, the > RFC Editor recommends the following section order as the initial > contents of an RFC. > > RFC header/Author information > RFC Title > Abstract > Status of this Memo > [IESG Note - when required] > Copyright > > The RFC Editor will implement this change as of 1 July 2009. > > We will make requests with the appropriate individuals for the > templates and tools to be updated accordingly. However, we will > reorder the sections manually during the final publication stage until > the updated tools are available. > > Thank you. > > RFC Editor > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-359--301065336 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = RFC Editor <rfc-editor@rfc-editor.org>= ;
Date: June 20, 2009 3:24:28 AM = CEDT
Subject: Section Ordering in RFCs (Abstract = Placement)
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-359--301065336-- From alexandru.petrescu@gmail.com Thu Jul 2 02:13:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB3B3A69D0 for ; Thu, 2 Jul 2009 02:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_11=1, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hul33X5lHNP for ; Thu, 2 Jul 2009 02:13:01 -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 A6E363A6837 for ; Thu, 2 Jul 2009 02:13:00 -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 n629DI4M000745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jul 2009 11:13:18 +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 n629DHrw030773; Thu, 2 Jul 2009 11:13:17 +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 n629DFuo013886; Thu, 2 Jul 2009 11:13:16 +0200 Message-ID: <4A4C7A2B.3020404@gmail.com> Date: Thu, 02 Jul 2009 11:13:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Goindi, Manhar" References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B2421F@xmb-ams-337.emea.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] energy metric for IPv6 links (was: Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:13:03 -0000 About the metrics discussion. As mentioned before, I think and believe an energy metric for IPv6 links can be useful. It is related to energy needed to send an 1280byte IPv6 packet on a certain link hop. I propose 4 encodings: for RA, for RIPng and two for OSPF (one link metric and one multi-link cumulative metric). Energy Metric Option in Router Advertisement: +-----------+ +-----------------+ +--+ +-------+ |Base Header| ...|Extension Headers| |RA| ...|Options| +-----------+ +-----------------+ +--+ +-------+ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Energy Metric Encoded in RIPng RTE: +-----------+ +-----------------+ +---+ +----+ |Base Header| ...|Extension Headers| |UDP| ...|RTEs| +-----------+ +-----------------+ +---+ +----+ +-----------+ +------------++-----------+ +------------++-----------+ |NextHop1RTE| |Address1 RTE||Energy1 RTE| |Address2 RTE||Energy2 RTE| +-----------+ +------------++-----------+ +------------++-----------+ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | route tag (2) | prefix len (1)| Energy Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Energy Metric Encoded in OSPF Opaque LSA +-----------+ +-----------------+ +----------+ +----+ |Base Header| ...|Extension Headers| |OSPFheader| ...|LSAs| +-----------+ +-----------------+ +----------+ +----+ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10, or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Link-local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I also propose encoding the Energy metric for several IPv6 links by expressing the metric in terms of the cost to reach a prefix. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10, or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Link Energy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The related biblio follows: [callaway-lowpower] Callaway, E., "Secure Low-Power Operation of Wireless Sensor Networks", January 2004. [dsr-encoding-energy] Doshi, S., Bhandare, S., and T. Brown, "An On-demand Minimum Energy Routing Protocol for a Wireless Ad Hoc Network", Mobile Computing and Communications Review, Volume 6, pp. 50-66, 2002. [efficiency-centric-communication] Cao, Q., He, T., Fang, L., Abdelzaher, T., Stankovic, J., and S. Son, "Efficiency Centric Communication Model for Wireless Sensor Networks", INFOCOM 2006. 25th IEEE International Conference on Computer Communications. Proceedings pp. 1-12, April 2006. [energy-aware-routing] Shah, R. and J. Rabaey, "Energy Aware Routing for Low Energy Ad Hoc Sensor Networks", Wireless Communications and Networking Conference, 2002. WCNC2002. 2002 IEEE Volume 1, pp. 350-355, March 2002. [energy-conserving] Chang, J-H. and L. Tassiulas, "Energy Conserving Routing in Wireless Ad-hoc Networks", INFOCOM 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, Volume 1, pp 22-31, 2000. [energy-efficient-aodv] Nie, N. and C. Comaniciu, "Energy Efficient AODV Routing in CDMA Ad Hoc Networks Using Beamforming", EURASIP Journal on Wireless Communications and Networking pp. 14-14, 2006. [energy-efficient-communication] Heinzelman, W., Chandrakasan, A., and H. Balakrishnan, "Energy-Efficient Communication Protocol for Wireless Microsensor Networks", Proceedings of the 33rd Hawaii International Conference on System Sciences, HICSS Volume 8, 2000. [energy-efficient-forwarding] Busse, M., Haenselmann, T., and W. Effelsberg, "Energy- Efficient Forwarding Schemes for Wireless Sensor Networks", Proceedings of the 2006 International Symposium on on World of Wireless, Mobile and Multimedia Networks pp. 125-133, 2006. [investigating-energy] Finnie, L. and M. Nilsson, "Investigating the Energy Consumption of a Wireless Network Interface in an Ad Hoc Networking Environment", INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE Volume 3, pp. 1548-1557, 2001. [link-inef-metric] Dhananjay, L., Manjeshwar, A., Herrmann, F., Uysal- Biyikoglu, E., and A. Keshavarzian, "Measurement and Characterization of Link Quality Metrics in Energy Constrained Wireless Sensor Networks", IEEE Global Telecommunications Conference, Globecom 03 Volume 1, pp 446-452, 2003. [minimum-energy-mobile] Rodoplu, V. and T. Meng, "Minimum Energy Mobile Wireless Networks", IEEE Journal on Selected Areas in Communications Volume 17, Number 8, August 1999. [minimum-energy-revisited] Li, L. and J. Halpern, "Minimum-Energy Mobile Wireless Networks Revisited", Communications, 2001. ICC 2001. IEEE International Conference on Volume 1, pp. 278-283, June 2001. [new-routing-metric] Boughanmi, N. and Y-Q. Song, "A New Routing Metric for Satisfying both Energy and Delay Constraints in Wireless Sensor Networks", Journal of Signal Processing Systems Volume 51, Issue 2, pp. 137-143, May 2008. [online-power-aware] Li, Q., Aslam, J., and D. Rus, "Online Power-aware Routing in Wireless Ad-hoc Networks", Proceedings of the 7th annual international conference on Mobile computing and networking pp. 97-107, 2001. [power-aware-routing] Singh, S., Woo, M., and C. Raghavendra, "Power-Aware Routing in Mobile Ad Hoc Networks", Proceedings of the 4th annual ACM/IEEE international conference on Mobile computing and networking pp. 181-190, 1998. [power-control-wireless] Goodman, D. and N. Mandayam, "Power Control for Wireless Data", IEEE Personal Communications , 2000. [routing-and-channel] Scott, K. and N. Bambos, "Routing and Channel Assignment for Low Power Transmission in PCS", Universal Personal Communications, 1996. Record., 1996 5th IEEE International Conference on Volume 2, pp. 498-502, 1996. Alex Goindi, Manhar a écrit : > Hi Pascal, > > > > Thanks for your clarification! > > > > I shall await the use case drafts and the enhanced metrics draft to get > more clarity on the manner to short-list preferred parents & siblings. > For instance, there could be a metric for choosing parents and another > metric to choose siblings. > > > > I agree that Case 1 & Case 2 are loops and are not desirable. Case 4 is > superior to Case 3 by offering an alternate path for forwarding by way > of siblings. Thanks for the illustration. > > > > > > Thanks & Best Regards, > > Manhar Goindi > > > > *Manhar Goindi* > Technical Expert > Phone: +91 120 3352149 > > *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > *Sent:* Tuesday, June 30, 2009 7:20 PM > *To:* Goindi, Manhar; JP Vasseur (jvasseur); ROLL WG > *Subject:* RE: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1 > > > > 1. How does a node know that DIO it has received from a node should be > taken as a Parent or a Sibling with reference to Example in section > 3.3.1.4.1? I mean how would it decide its own depth. > > > > Hi Manhar: > > > > The component that makes that resolution is out of scope. That > component, that I call plugin for the lack of a better term, depends on > the metrics which in turn depend on the link type (like RSSI) and the > use case (like battery). Because the plugin depends on the metrics, it > makes more sense to specify reference examples using those metrics in > the current metrics drafts. Other drafts might follow for more specific > use cases, and you might even find RA extensions and plugins that are > completely proprietary. > > > > The plugin component is very loosely constrained. It selects an ordered > set of preferred parents and from then generic RPL takes over. RPL will > use for this node a depth that is incremented from the depth of the > deepest parent. The resulting depth enables an abstraction of feasible > successors in the same DAG, some parents (least depth) some siblings > (same depth). Loop avoidance is guaranteed by construction when packets > are passed to parents. It is attempted on a per packet basis when > forwarding via siblings. > > > > Note that the plugin might not be use the depth as primary selector for > the choice of the preferred parent. For instance that a node sees 2 > routers, one at depth 1 with a poor signal indicator and one at depth 2 > with a very good signal. The plugin should prefer the second router. > > > > The resulting graph might depend a lot on how greedy the plugins are. > If you consider that a node is richer when it has a higher number of > feasible successors, what society are we trying to build? Let me give > you an example. We have a triangle, A, B, C. A is a root and B and C > dynamically appear. Once things settle, you could end up with a > situation like: > > > > +--->A<---+ +--->A<---+ +--->A<---+ +--->A<---+ > > | | | | | | | | > > | | |+--->---+| | | | | > > B-------->C B| |C B C B<------->C > > +---<---+ > > Case 1 Case 2 Case 3 Case 4 > > > > Case 1: B is a scrooge. If it comes up after C it sees A and C and > tries to optimize locally its number of parents. If C comes later, B > detaches from A and reattaches to again get 2 parents. The resulting > depths are A:0, C:1 and B:2 . Drawback: C is always deprived from an > alternate forwarding solution. Greediness is discouraged unless the node > has a very good reason like critical + low battery but draft 00 lacks > any clear cut constraint about that. > > > > Case 2: C is also greedy. So when B attaches to C as before, C will > detach from A to reattach to B and C, and we are in a loop till maximum > depth. At which point the looser will attach to A only and we start over > the count to infinity. This is definitively broken. A simple tie break > is to ignore RAs from deeper, and this is MUSTed in section 5.4 at the > end of item 5. So, case 2 is actually impossible with the current spec. > > > > Case 3. B & C are both genuinely altruistic, so anxious of the benefit > of others that they wouldn't dare get deeper than they could. So they > end up at depth 1 with only one feasible successor, A. The result is in > fact even worse than case 1 because neither B nor C can benefit from the > other. > > > > Case 4. Same as case 3 with a new rule of allowing sibling forwarding. > In that case, B and C are still both depth 1, but they can use one > another as alternate (backup) feasible successors. Because the sibling > hops do not belong to the DAG, they are not loopless by construction and > additional measures must be taken like always prefer a real parent, do > not give a packet back to a sibling, decrement hop limit faster, that > sort of thing. > > > > The spec is very open but case 4 might be often desirable but for > specific nodes that really need to be greedier than average. One way of > doing this is to select only ONE preferred parent (then again not > necessarily the shallowest one) and orient its vector in the gradient > towards that guy. If we do that, the depth will really represent the > hops over the preferred and most probable path as opposed to the worst > path within selected parents. > > > > My take is that we should SHOULD that behavior. What do you think? > > > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Goindi, Manhar > > Sent: mardi 30 juin 2009 11:15 > > To: JP Vasseur (jvasseur); ROLL WG > > Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt > > > > Hi JP, > > > > Thanks a lot for sharing this draft as it proved very informative & I > thoroughly enjoyed reading it. > > > > I have the following queries: > > > > 2. How does a node know that DIO it has received from a node should be > taken as a Parent or a Sibling with reference to Example in section > 3.3.1.4.1? I mean how would it decide its own depth. > > 3. In Section 3.3.4.4 – why doesn’t node 51 reattach itself as a child > to node 53 instead of making node 52 as its parent? Is it that node 51 > cannot hear node 53 directly so it has to go through node 52? > > 4. Can siblings hear each other as it is not evident from Figure 2: > Example DAG? > > 5. In section 3.3.4.1: Moving Down a DAG – it is mentioned that there > is little change for a loop and node 56 may reattach to DAG with parents > 43 & 55. How is the formation or non-formation of this loop detected? > What is the mechanism for that? > > > > Would someone like to see if there is an answer to them? > > > > > > Thanks & Best Regards, > > Manhar Goindi > > > > Manhar Goindi > > Technical Expert > > Landis+Gyr > > Phone: +91 120 3352149 > > manhar.goindi@landisgyr.com > > www.landisgyr.com > > > > manage energy better > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur > > Sent: Monday, June 29, 2009 10:19 AM > > To: ROLL WG > > Subject: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt > > > > Here you are. > > > > Thanks. > > > > JP. > > > > Begin forwarded message: > > > > From: Internet-Drafts@ietf.org > > Date: June 29, 2009 1:15:01 AM CEDT > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-dt-roll-rpl-00.txt > > Reply-To: internet-drafts@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : RPL: Routing Protocol for Low Power and > Lossy Networks > > Author(s) : T. Winter, R. Team > > Filename : draft-dt-roll-rpl-00.txt > > Pages : 60 > > Date : 2009-06-28 > > > > This document specifies the Routing Protocol for Low Power and Lossy > > Networks (RPL), in accordance with the requirements described in > > [I-D.ietf-roll-building-routing-reqs], > > [I-D.ietf-roll-home-routing-reqs], > > [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-dt-roll-rpl-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > >  PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > > > This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are prohibited > from using, copying or distributing the information in this e-mail or > its attachments. If you have received this e-mail in error, please > notify the sender immediately by return e-mail and delete all copies of > this message and any attachments. Thank you. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 2 02:37:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B7C3A6A9E for ; Thu, 2 Jul 2009 02:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.417 X-Spam-Level: X-Spam-Status: No, score=-9.417 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, J_BACKHAIR_11=1, J_CHICKENPOX_63=0.6, 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 eweZTtzgDcxH for ; Thu, 2 Jul 2009 02:37:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 70C3E3A693E for ; Thu, 2 Jul 2009 02:37:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,332,1243814400"; d="scan'208";a="44186131" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 09:37:50 +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 n629bo3g009136; Thu, 2 Jul 2009 11:37:50 +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.14.3) with ESMTP id n629biYk027253; Thu, 2 Jul 2009 09:37:50 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); Thu, 2 Jul 2009 11:37:49 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 11:37:48 +0200 Message-Id: <5B4B354B-73FD-4B98-B17D-2971AD7E8375@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A4C7A2B.3020404@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 11:37:31 +0200 References: <20090628231501.3A1353A69E4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC07B2421F@xmb-ams-337.emea.cisco.com> <4A4C7A2B.3020404@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 09:37:48.0867 (UTC) FILETIME=[C3170930:01C9FAF8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22441; t=1246527470; x=1247391470; 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=20energy=20metric=20for=20IPv6=20links=20 =20(was=3A=20[Roll]=20Fwd=3A=20I-D=20Action=3Adraft-dt-roll- rpl-00.txt=20Q1) |Sender:=20; bh=RhICav/4yV+Q+HPfc9qApCBKCQzkJGp47Bybz1PmE1Q=; b=tJ1Fv62046hNFThMVFF4F7hQYJsREFvWZyyXonSNqB7lTL4wZa7vVYoyHB J8f2eSF5p2orwpDcFkTWZv4L+jDX5AQt666w0jfTi2xvtvXNkuZP33YBsbJr 3GKoA7WjS4; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Goindi, Manhar" , ROLL WG Subject: Re: [Roll] energy metric for IPv6 links (was: Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:37:33 -0000 Hi Alex, We can certainly continue the discussion on whether we need a link =20 energy metric. For the ID, it will be updated once a routing protocol will have been =20= chosen by the WG. Thanks. JP. On Jul 2, 2009, at 11:13 AM, Alexandru Petrescu wrote: > About the metrics discussion. > > As mentioned before, I think and believe an energy metric for IPv6 =20 > links can be useful. It is related to energy needed to send an =20 > 1280byte IPv6 packet on a certain link hop. > > I propose 4 encodings: for RA, for RIPng and two for OSPF (one link =20= > metric and one multi-link cumulative metric). > > Energy Metric Option in Router Advertisement: > +-----------+ +-----------------+ +--+ +-------+ > |Base Header| ...|Extension Headers| |RA| ...|Options| > +-----------+ +-----------------+ +--+ +-------+ > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Energy Metric Encoded in RIPng RTE: > +-----------+ +-----------------+ +---+ +----+ > |Base Header| ...|Extension Headers| |UDP| ...|RTEs| > +-----------+ +-----------------+ +---+ +----+ > +-----------+ +------------++-----------+ +------------+=20 > +-----------+ > |NextHop1RTE| |Address1 RTE||Energy1 RTE| |Address2 RTE||Energy2 =20 > RTE| > +-----------+ +------------++-----------+ +------------+=20 > +-----------+ > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | route tag (2) | prefix len (1)| Energy Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Energy Metric Encoded in OSPF Opaque LSA > > +-----------+ +-----------------+ +----------+ +----+ > |Base Header| ...|Extension Headers| |OSPFheader| ...|LSAs| > +-----------+ +-----------------+ +----------+ +----+ > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS age | Options | 9, 10, or 11 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opaque Type | Opaque ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Advertising Router | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS checksum | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +- -+ > | | > +- Link-local Interface Address -+ > | | > +- -+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > I also propose encoding the Energy metric for several IPv6 links by > expressing the metric in terms of the cost to reach a prefix. > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS age | Options | 9, 10, or 11 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opaque Type | Opaque ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Advertising Router | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LS checksum | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | # prefixes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PrefixLength | PrefixOptions | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Prefix | > | | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PrefixLength | PrefixOptions | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Prefix | > | | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The related biblio follows: > [callaway-lowpower] > Callaway, E., "Secure Low-Power Operation of Wireless > Sensor Networks", January 2004. > > [dsr-encoding-energy] > Doshi, S., Bhandare, S., and T. Brown, "An On-demand > Minimum Energy Routing Protocol for a Wireless Ad Hoc > Network", Mobile Computing and Communications > Review, Volume 6, pp. 50-66, 2002. > > [efficiency-centric-communication] > Cao, Q., He, T., Fang, L., Abdelzaher, T., Stankovic, J., > and S. Son, "Efficiency Centric Communication Model for > Wireless Sensor Networks", INFOCOM 2006. 25th IEEE > International Conference on Computer Communications. > Proceedings pp. 1-12, April 2006. > > [energy-aware-routing] > Shah, R. and J. Rabaey, "Energy Aware Routing for Low > Energy Ad Hoc Sensor Networks", Wireless Communications > and Networking Conference, 2002. WCNC2002. 2002 > IEEE Volume 1, pp. 350-355, March 2002. > > [energy-conserving] > Chang, J-H. and L. Tassiulas, "Energy Conserving Routing > in Wireless Ad-hoc Networks", INFOCOM 2000. Nineteenth > Annual Joint Conference of the IEEE Computer and > Communications Societies. Proceedings. IEEE, Volume 1, pp > 22-31, 2000. > > [energy-efficient-aodv] > Nie, N. and C. Comaniciu, "Energy Efficient AODV Routing > in CDMA Ad Hoc Networks Using Beamforming", EURASIP > Journal on Wireless Communications and Networking pp. > 14-14, 2006. > > [energy-efficient-communication] > Heinzelman, W., Chandrakasan, A., and H. Balakrishnan, > "Energy-Efficient Communication Protocol for Wireless > Microsensor Networks", Proceedings of the 33rd Hawaii > International Conference on System Sciences, HICSS Volume > 8, 2000. > > [energy-efficient-forwarding] > Busse, M., Haenselmann, T., and W. Effelsberg, "Energy- > Efficient Forwarding Schemes for Wireless Sensor > Networks", Proceedings of the 2006 International =20 > Symposium > on on World of Wireless, Mobile and Multimedia > Networks pp. 125-133, 2006. > > [investigating-energy] > Finnie, L. and M. Nilsson, "Investigating the Energy > Consumption of a Wireless Network Interface in an Ad Hoc > Networking Environment", INFOCOM 2001. Twentieth Annual > Joint Conference of the IEEE Computer and Communications > Societies. Proceedings. IEEE Volume 3, pp. 1548-1557, > 2001. > > [link-inef-metric] > Dhananjay, L., Manjeshwar, A., Herrmann, F., Uysal- > Biyikoglu, E., and A. Keshavarzian, "Measurement and > Characterization of Link Quality Metrics in Energy > Constrained Wireless Sensor Networks", IEEE Global > Telecommunications Conference, Globecom 03 Volume 1, pp > 446-452, 2003. > > [minimum-energy-mobile] > Rodoplu, V. and T. Meng, "Minimum Energy Mobile Wireless > Networks", IEEE Journal on Selected Areas in > Communications Volume 17, Number 8, August 1999. > > [minimum-energy-revisited] > Li, L. and J. Halpern, "Minimum-Energy Mobile Wireless > Networks Revisited", Communications, 2001. ICC 2001. IEEE > International Conference on Volume 1, pp. 278-283, > June 2001. > > [new-routing-metric] > Boughanmi, N. and Y-Q. Song, "A New Routing Metric for > Satisfying both Energy and Delay Constraints in Wireless > Sensor Networks", Journal of Signal Processing > Systems Volume 51, Issue 2, pp. 137-143, May 2008. > > [online-power-aware] > Li, Q., Aslam, J., and D. Rus, "Online Power-aware =20 > Routing > in Wireless Ad-hoc Networks", Proceedings of the 7th > annual international conference on Mobile computing and > networking pp. 97-107, 2001. > > [power-aware-routing] > Singh, S., Woo, M., and C. Raghavendra, "Power-Aware > Routing in Mobile Ad Hoc Networks", Proceedings of the =20= > 4th > annual ACM/IEEE international conference on Mobile > computing and networking pp. 181-190, 1998. > > [power-control-wireless] > Goodman, D. and N. Mandayam, "Power Control for Wireless > Data", IEEE Personal Communications , 2000. > > [routing-and-channel] > Scott, K. and N. Bambos, "Routing and Channel Assignment > for Low Power Transmission in PCS", Universal Personal > Communications, 1996. Record., 1996 5th IEEE =20 > International > Conference on Volume 2, pp. 498-502, 1996. > > Alex > > Goindi, Manhar a =C3=A9crit : >> Hi Pascal, >> Thanks for your clarification! >> I shall await the use case drafts and the enhanced metrics draft to =20= >> get more clarity on the manner to short-list preferred parents & =20 >> siblings. For instance, there could be a metric for choosing =20 >> parents and another metric to choose siblings. >> I agree that Case 1 & Case 2 are loops and are not desirable. Case =20= >> 4 is superior to Case 3 by offering an alternate path for =20 >> forwarding by way of siblings. Thanks for the illustration. >> Thanks & Best Regards, >> Manhar Goindi >> *Manhar Goindi* >> Technical Expert >> Phone: +91 120 3352149 >> *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> *Sent:* Tuesday, June 30, 2009 7:20 PM >> *To:* Goindi, Manhar; JP Vasseur (jvasseur); ROLL WG >> *Subject:* RE: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1 >> 1. How does a node know that DIO it has received from a node should =20= >> be taken as a Parent or a Sibling with reference to Example in =20 >> section 3.3.1.4.1? I mean how would it decide its own depth. >> Hi Manhar: >> The component that makes that resolution is out of scope. That =20 >> component, that I call plugin for the lack of a better term, =20 >> depends on the metrics which in turn depend on the link type (like =20= >> RSSI) and the use case (like battery). Because the plugin depends =20 >> on the metrics, it makes more sense to specify reference examples =20 >> using those metrics in the current metrics drafts. Other drafts =20 >> might follow for more specific use cases, and you might even find =20 >> RA extensions and plugins that are completely proprietary. >> The plugin component is very loosely constrained. It selects an =20 >> ordered set of preferred parents and from then generic RPL takes =20 >> over. RPL will use for this node a depth that is incremented from =20 >> the depth of the deepest parent. The resulting depth enables an =20 >> abstraction of feasible successors in the same DAG, some parents =20 >> (least depth) some siblings (same depth). Loop avoidance is =20 >> guaranteed by construction when packets are passed to parents. It =20 >> is attempted on a per packet basis when forwarding via siblings. >> Note that the plugin might not be use the depth as primary selector =20= >> for the choice of the preferred parent. For instance that a node =20 >> sees 2 routers, one at depth 1 with a poor signal indicator and one =20= >> at depth 2 with a very good signal. The plugin should prefer the =20 >> second router. >> The resulting graph might depend a lot on how greedy the plugins =20 >> are. If you consider that a node is richer when it has a higher =20 >> number of feasible successors, what society are we trying to build? =20= >> Let me give you an example. We have a triangle, A, B, C. A is a =20 >> root and B and C dynamically appear. Once things settle, you could =20= >> end up with a situation like: +--->A<---+ +--->A<---=20= >> + +--->A<---+ +--->A<---+ >> | | | | | | | | >> | | |+--->---+| | | | | >> B-------->C B| |C B C B<------->C >> +---<---+ >> Case 1 Case 2 Case 3 Case 4 >> Case 1: B is a scrooge. If it comes up after C it sees A and C and =20= >> tries to optimize locally its number of parents. If C comes later, =20= >> B detaches from A and reattaches to again get 2 parents. The =20 >> resulting depths are A:0, C:1 and B:2 . Drawback: C is always =20 >> deprived from an alternate forwarding solution. Greediness is =20 >> discouraged unless the node has a very good reason like critical + =20= >> low battery but draft 00 lacks any clear cut constraint about that. >> Case 2: C is also greedy. So when B attaches to C as before, C =20 >> will detach from A to reattach to B and C, and we are in a loop =20 >> till maximum depth. At which point the looser will attach to A only =20= >> and we start over the count to infinity. This is definitively =20 >> broken. A simple tie break is to ignore RAs from deeper, and this =20 >> is MUSTed in section 5.4 at the end of item 5. So, case 2 is =20 >> actually impossible with the current spec. >> Case 3. B & C are both genuinely altruistic, so anxious of the =20 >> benefit of others that they wouldn't dare get deeper than they =20 >> could. So they end up at depth 1 with only one feasible successor, =20= >> A. The result is in fact even worse than case 1 because neither B =20 >> nor C can benefit from the other. >> Case 4. Same as case 3 with a new rule of allowing sibling =20 >> forwarding. In that case, B and C are still both depth 1, but they =20= >> can use one another as alternate (backup) feasible successors. =20 >> Because the sibling hops do not belong to the DAG, they are not =20 >> loopless by construction and additional measures must be taken like =20= >> always prefer a real parent, do not give a packet back to a =20 >> sibling, decrement hop limit faster, that sort of thing. >> The spec is very open but case 4 might be often desirable but for =20 >> specific nodes that really need to be greedier than average. One =20 >> way of doing this is to select only ONE preferred parent (then =20 >> again not necessarily the shallowest one) and orient its vector in =20= >> the gradient towards that guy. If we do that, the depth will really =20= >> represent the hops over the preferred and most probable path as =20 >> opposed to the worst path within selected parents. >> My take is that we should SHOULD that behavior. What do you think? >> Pascal >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of Goindi, Manhar >> Sent: mardi 30 juin 2009 11:15 >> To: JP Vasseur (jvasseur); ROLL WG >> Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt >> Hi JP, >> Thanks a lot for sharing this draft as it proved very informative & =20= >> I thoroughly enjoyed reading it. >> I have the following queries: >> 2. How does a node know that DIO it has received from a node should =20= >> be taken as a Parent or a Sibling with reference to Example in =20 >> section 3.3.1.4.1? I mean how would it decide its own depth. >> 3. In Section 3.3.4.4 =E2=80=93 why doesn=E2=80=99t node 51 reattach = itself as a =20 >> child to node 53 instead of making node 52 as its parent? Is it =20 >> that node 51 cannot hear node 53 directly so it has to go through =20 >> node 52? >> 4. Can siblings hear each other as it is not evident from Figure =20 >> 2: Example DAG? >> 5. In section 3.3.4.1: Moving Down a DAG =E2=80=93 it is mentioned = that =20 >> there is little change for a loop and node 56 may reattach to DAG =20 >> with parents 43 & 55. How is the formation or non-formation of =20 >> this loop detected? What is the mechanism for that? >> Would someone like to see if there is an answer to them? >> Thanks & Best Regards, >> Manhar Goindi >> Manhar Goindi >> Technical Expert >> Landis+Gyr Phone: +91 120 3352149 >> manhar.goindi@landisgyr.com >> www.landisgyr.com >> manage energy better >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of JP Vasseur >> Sent: Monday, June 29, 2009 10:19 AM >> To: ROLL WG >> Subject: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt >> Here you are. >> Thanks. >> JP. >> Begin forwarded message: >> From: Internet-Drafts@ietf.org >> Date: June 29, 2009 1:15:01 AM CEDT >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-dt-roll-rpl-00.txt Reply-To: = internet-drafts@ietf.org >> A New Internet-Draft is available from the on-line Internet-Drafts =20= >> directories. >> Title : RPL: Routing Protocol for Low Power =20 >> and Lossy Networks >> Author(s) : T. Winter, R. Team >> Filename : draft-dt-roll-rpl-00.txt >> Pages : 60 >> Date : 2009-06-28 >> This document specifies the Routing Protocol for Low Power and Lossy >> Networks (RPL), in accordance with the requirements described in >> [I-D.ietf-roll-building-routing-reqs], >> [I-D.ietf-roll-home-routing-reqs], >> [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-dt-roll-rpl-00.txt >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> =EF=81=90 PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. >> This e-mail (including any attachments) is confidential and may be =20= >> legally privileged. If you are not an intended recipient or an =20 >> authorized representative of an intended recipient, you are =20 >> prohibited from using, copying or distributing the information in =20 >> this e-mail or its attachments. If you have received this e-mail in =20= >> error, please notify the sender immediately by return e-mail and =20 >> delete all copies of this message and any attachments. Thank you. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Thu Jul 2 03:42:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2113A68F8 for ; Thu, 2 Jul 2009 03:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7RZMPHy+QJQl for ; Thu, 2 Jul 2009 03:42:18 -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 881663A683A for ; Thu, 2 Jul 2009 03:42:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,332,1243814400"; d="scan'208,217";a="44196039" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 10:42:37 +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 n62Agb96000996 for ; Thu, 2 Jul 2009 12:42:37 +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.14.3) with ESMTP id n62AgbYu023965 for ; Thu, 2 Jul 2009 10:42:37 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); Thu, 2 Jul 2009 12:42:37 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 12:42:36 +0200 Message-Id: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-414--211299820 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 12:42:36 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 10:42:36.0971 (UTC) FILETIME=[D0949FB0:01C9FB01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2514; t=1246531357; x=1247395357; 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:=20Agenda=20and=20Routing=20Protocol=20Selection |Sender:=20; bh=/EGtN3+SoVgnXbybAVpgvOVkoyqyg+GElb0XTriECa8=; b=GgEJpua01QsnALftU6V1TkJ/dxxKLIsfjnmpgMccxSEw4DTjAfJG9PKs7U ZpXh9+SHPwKMTc6XurHTGdttZYMYgZBvP+MUYGMaJm8oknSk5heWjtBklTM6 45ICSQrRCl; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Agenda and Routing Protocol Selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:42:18 -0000 --Apple-Mail-414--211299820 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, Here is the latest agenda: http://www.ietf.org/proceedings/09jul/agenda/roll.txt We have two major topics: 1) Routing Protocol 2) Security With regards to 1), there are as of today two proposals on the table (any other proposal is of course welcome): RPL (DT proposal): draft-dt-roll-rpl draft-iwao-roll-dadr The objective of the next meeting is to select one of them so as to continue to move forward. Indeed, we need to reach to reach that next important milestone also to progress on others IDs such as the metric- ID (this is the reason why the metric ID will not be discussed in this WG meeting). Please read and comments the proposals and be ready for Stockholm. With regards to 2), Rene is getting up to speed and we have a 45mn slot for this item. Thanks. JP. --Apple-Mail-414--211299820 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = WG,


We= have two major topics:
1) Routing Protocol
2) = Security

With regards to 1), there are as of = today two proposals on the table (any other proposal is of course = welcome):
RPL (DT = proposal): draft-dt-roll-rpl
= draft-iwao-roll-dadr

The objective of = the next meeting is to select one of them so as to continue to move = forward. Indeed, we need to reach to reach that next important = milestone also to progress on others IDs such as the metric-ID (this is = the reason why the metric ID will not be discussed in this WG = meeting).

Please read and comments the = proposals and be ready for Stockholm.

With = regards to 2), Rene is getting up to speed and we have a 45mn slot for = this = item.

Thanks.

JP.
<= /body>= --Apple-Mail-414--211299820-- From alexandru.petrescu@gmail.com Thu Jul 2 03:50:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347173A6BF9 for ; Thu, 2 Jul 2009 03:50:54 -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 ekKySopgaT8B for ; Thu, 2 Jul 2009 03:50:53 -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 79FB128C223 for ; Thu, 2 Jul 2009 03:49:07 -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 n62AnPiF029571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jul 2009 12:49:25 +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 n62AnPe9020480; Thu, 2 Jul 2009 12:49:25 +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 n62AnP15012206; Thu, 2 Jul 2009 12:49:25 +0200 Message-ID: <4A4C90B4.1060507@gmail.com> Date: Thu, 02 Jul 2009 12:49:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> In-Reply-To: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Agenda and Routing Protocol Selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:50:54 -0000 JP Vasseur a crit : > Dear WG, > > Here is the latest > agenda: http://www.ietf.org/proceedings/09jul/agenda/roll.txt > > We have two major topics: > 1) Routing Protocol > 2) Security > > With regards to 1), there are as of today two proposals on the table > (any other proposal is of course welcome): > RPL (DT proposal): draft-dt-roll-rpl > draft-iwao-roll-dadr Sorry, please clarify: I can not find draft-iwao-roll-dadr, where is it? But I can find: draft-goyal-roll-dv-00.txt at http://www.ietf.org/internet-drafts/draft-goyal-roll-dv-00.txt and draft-kelsey-roll-lip-00.txt at http://www.ietf.org/internet-drafts/draft-kelsey-roll-lip-00.txt Alex > > *The objective of the next meeting is to select one of them so as to > continue to move forward.* Indeed, we need to reach to reach that next > important milestone also to progress on others IDs such as the metric-ID > (this is the reason why the metric ID will not be discussed in this WG > meeting). > > Please read and comments the proposals and be ready for Stockholm. > > With regards to 2), Rene is getting up to speed and we have a 45mn slot > for this item. > > Thanks. > > JP. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Thu Jul 2 04:35:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68AE128C13D for ; Thu, 2 Jul 2009 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hrBXayyOz0e for ; Thu, 2 Jul 2009 04:35: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 487F83A6D79 for ; Thu, 2 Jul 2009 04:35:44 -0700 (PDT) X-Files: logo.gif, green.gif : 837, 87 X-IronPort-AV: E=Sophos;i="4.42,332,1243814400"; d="gif'147?scan'147,208,217,147";a="44203109" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 11:35:55 +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 n62BZtoO005911 for ; Thu, 2 Jul 2009 13:35:55 +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.14.3) with ESMTP id n62BZtfx013435 for ; Thu, 2 Jul 2009 11:35:55 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 13:35:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01C9FB09.42E69C3C"; type="multipart/alternative" Date: Thu, 2 Jul 2009 13:35:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Thread-Index: Acn7CUJQPBbZhygbShu6+SCqJDi0sQ== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 02 Jul 2009 11:35:55.0462 (UTC) FILETIME=[43079E60:01C9FB09] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14420; t=1246534555; x=1247398555; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdurvy@cisco.com; z=From:=20=22Mathilde=20Durvy=20(mdurvy)=22=20 |Subject:=20Re=3A=20[Roll]=20Fwd=3A=20I-D=20Action=3Adraft- dt-roll-rpl-00.txt |Sender:=20; bh=Q+EnCfldSXEBDVLKfdaAZPOFwhM37SIYP97iBv9SidA=; b=AcE6y6ZYzqhMLwiGHWzHqqLCuu8MFrfu1muSg5BHBdMy8cMHkPAeNuw+ho iMs5gFhoSxAcIs4B6jHHqsVSbWsISPfYrBgcqzl7gd9fZZ9uxJpb7voFavG6 cHvw00vATv; Authentication-Results: ams-dkim-1; header.From=mdurvy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:35:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FB09.42E69C3C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9FB09.42E69C3C" ------_=_NextPart_002_01C9FB09.42E69C3C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 Thanks for this nice draft!=20 A few comments/questions: =20 - 3.3.1.2 shadow cone. In the example given, if node (42) had siblings, = they would also be part of its shadow cone, correct? =20 - Must all nodes in a DAG use the same metric(s) as suggested by = section 3.3.1.4.? This seems to conflict with the last paragraphs of = section 4.1. What do you mean by consistent parent selection? Does it = mean that a node should not join a DAG if it's metric logic does not = agree with the metric logic of other nodes in the DAG? =20 - 3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if = something goes wrong with Node (B) and (E), correct? =20 - 3.3.3.1. " Note that further details of the message and its triggers = are still under investigation, including whether or not the DAO should = be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still = under investigation given that section 5.5.1.1 speaks only of NA? =20 - 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, = PROBE) contained in the neighbor cache table? One way to maintain = routing adjacencies would be to use a relatively low reachable time = which means that the neighbors will be in STALE state rapidly. Once a = neighbor is in this state, any packet for this neighbor will trigger a = NS/NA exchange to confirm reachability. However, the data packet will be = send before the NS is sent... =20 - 5.4 Item 3. I guess you are talking only about a LBR not any LLN = router =20 - 5.4.3.1 " When a new DAG is discovered, the candidate parent that = advertises the new DAG is placed in a held up state for the duration of = a DAG Hop timer". What if the node want to be part of both DAGs (its = original DAG and the new one), I guess this does not apply. =20 Typos: - DAG Sibling definition page 5: neighboring node node - 3.2.4: able to ... discover - 3.3.1.2: I guess you mean 'consider Node (42)' - 3.3.1.2: 'the node rooting the DAG may is not' - 3.3.1.4: lessor -> lesser - 3.3.4.5: Node (51), (41), (42) and (54) - 5.1.1.1.5: "this may be useful in cases where more than one LBR" - 5.2: "candidate neighbor set(, bounded), and" - 5.5.1.1: "RRcount: 8-bit unsigned integer" - 5.5.2.1 "The DelayNA timer has a duration that is DEF_NA_LATENCY = divided by 2 with the DAG depth". Does this mean 2^(DAG depth)? =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01C9FB09.42E69C3C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Thanks = for this nice=20 draft!
A few=20 comments/questions:
 
- = 3.3.1.2 shadow=20 cone. In the example given, if node (42) had siblings, they would also = be part=20 of its shadow cone, correct?
 
- Must all=20 nodes in a DAG use the same metric(s)  as suggested by section = 3.3.1.4.?=20 This seems to conflict with the last paragraphs of section 4.1. What do = you mean=20 by consistent parent selection? Does it mean that a node should not join = a DAG=20 if it's metric logic does not agree with the metric logic of other nodes = in the=20 DAG?
 
- = 3.3.1.4.1. I guess=20 Node (N) may also forward traffic via Node (C) if something goes wrong = with Node=20 (B) and (E), correct?
 
- 3.3.3.1.=20 " Note that further = details of the=20 message and its triggers are still under investigation, including = whether or not=20 the DAO should be a IPv6 = Hop-By-Hop=20 option or a Neighbor Discovery option." = Is it still under = investigation given that section 5.5.1.1 speaks only of=20 NA?
 
- = 3.4.3 Do you use=20 the state (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE) contained in the = neighbor=20 cache table? One way to maintain routing adjacencies would be to use a=20 relatively low reachable time which means that the neighbors will be in = STALE=20 state rapidly. Once a neighbor is in this state, any = packet for=20 this neighbor will trigger a NS/NA exchange to confirm reachability. = However,=20 the data packet will be send before the NS is = sent...
 
- 5.4 = Item 3. I=20 guess you are talking only about a LBR not any LLN = router
 
- = 5.4.3.1 " When a=20 new DAG is discovered, the candidate parent that advertises the new DAG is placed in a held = up state=20 for the duration of a DAG Hop timer".  What if the node want to be = part of=20 both DAGs (its original DAG and the new one), I guess this does not=20 apply.
 
Typos:
- DAG = Sibling=20 definition page 5: neighboring node = node
- = 3.2.4: able=20 to ... discover
- = 3.3.1.2: I guess=20 you mean 'consider Node (42)'
- = 3.3.1.2: 'the node=20 rooting the DAG may is not'
- = 3.3.1.4:=20 lessor -> lesser
- = 3.3.4.5: Node=20 (51), (41), (42) and (54)
- = 5.1.1.1.5: "this=20 may be useful in cases where more than one=20 LBR"
- 5.2: = "candidate=20 neighbor set(, bounded), and"
- = 5.5.1.1: "RRcount:=20 8-bit unsigned integer"
- = 5.5.2.1 "The DelayNA timer has a = duration that=20 is DEF_NA_LATENCY divided by 2 with the DAG depth". Does this mean = 2^(DAG=20 depth)?
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01C9FB09.42E69C3C-- ------_=_NextPart_001_01C9FB09.42E69C3C Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01C9FB09.42E69C3C Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01C9FB09.42E69C3C-- From pthubert@cisco.com Thu Jul 2 05:17:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FCA3A6D6F for ; Thu, 2 Jul 2009 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.944 X-Spam-Level: X-Spam-Status: No, score=-9.944 tagged_above=-999 required=5 tests=[AWL=0.655, 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 46k4T57CFEVt for ; Thu, 2 Jul 2009 05:17:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 85C2A3A6849 for ; Thu, 2 Jul 2009 05:17:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,333,1243814400"; d="scan'208";a="44208399" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 12:17:26 +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 n62CHQAj032108; Thu, 2 Jul 2009 14:17:26 +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.14.3) with ESMTP id n62CHPDG029665; Thu, 2 Jul 2009 12:17:25 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 14:17:25 +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, 2 Jul 2009 14:17:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B9387D@xmb-ams-337.emea.cisco.com> In-Reply-To: <1230040773.17468701246462052420.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] dt-roll-rpl: Gradient Thread-Index: Acn6YoLU8AZPO0x6Szm3CdskWOBsHgAp5W+Q References: <1230040773.17468701246462052420.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 02 Jul 2009 12:17:25.0806 (UTC) FILETIME=[0F63F4E0:01C9FB0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2943; t=1246537046; x=1247401046; 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[Roll]=20dt-roll-rpl=3A=20Gradient |Sender:=20; bh=pjz2IAq2VgugxSIvrEz9zQxGfpLKgoGRtbenK2XyqiQ=; b=HF1+aq2bMAV5Q+AhZIpeGAQVljeiJQ6FYRcvr/AWdDyPUiUXMChpCm5N0q QLgkcEwsGD3IYlc7B66xBkoaDLUoJFLm33mkt2J60l5P477oAdcbdzB/QgTh Jz+sfflznf; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] dt-roll-rpl: Gradient X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:17:06 -0000 Hi Mukul We have changed language and terms a number of times and it appears we're not fully settled: -DAG has the inconvenience to miss the sibling path.=20 -Gradient indicates that you select a preferred parent and orient a vector towards it. But it fails to represent the alternate paths.=20 Yet, Gradient represents a cool abstraction of how I see what the protocol operation should be and I plead guilty for that text. In my favorite mode, the router selects its absolute preferred parent by whatever means (might include depth or not at all) and then selects a depth that SHOULD be the depth of that parent +1. Exceptions would be tolerated if for instance the node is short on battery and wish to artificially avoid children by faking a infinite (or close to) depth. Alt Parents are defined by lesser depth, siblings by same depth. Because the depth might not be primary to select the preferred parent there might be parents at a lesser depth than the preferred one. At the moment, the draft enables to pick alternate parents that are deeper than the most preferred. As a result: - there's no boundary to greediness (remember my drawings about this issue) - the depth represents the worst path as opposed to the preferred path and looses value - similarly, aggregating other metrics from multiple parents might also lose all sense I suppose that additional thinking will help resolve if the text should stay as it stands or if we make it a bit more restrictive as I recommend here.=20 Suggestions / comments appreciated. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal >Sent: mercredi 1 juillet 2009 17:28 >To: roll >Subject: [Roll] dt-roll-rpl: Gradient > >Quoting from section 4.1 (the last paragraph) > >"RPL is designed to survive and still operate, though in a somewhat > degraded fashion, when confronted to such heterogeneity. The key > design point is that each node is solely responsible for setting the > vector that it sources in the gradient, which is achieved by > selecting its preferred parent. As a result, the gradient is not > broken if another node makes its decisions in as antagonistic > fashion, though an end-to-end path might not fully achieve any of the > optimizations that nodes along the way expect." > > >I am not sure what does the gradient mean and what does the following line mean > >"each node is solely responsible for setting the vector that it sources in the gradient, which is achieved by >selecting the preferred parent." > >The draft needs to define gradient. And perhaps give an example of "the gradient is not broken if another node >makes its decision in an atagonistic fashion". > >Thanks >Mukul >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Jul 2 07:32:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC11D28C139 for ; Thu, 2 Jul 2009 07:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 tme7V2hspuiJ for ; Thu, 2 Jul 2009 07:32:42 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 114A728C1AB for ; Thu, 2 Jul 2009 07:32:41 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 10:33:02 -0400 Date: Thu, 02 Jul 2009 10:33:26 -0400 Message-Id: <871vozxih5.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 1 Jul 2009 23:22:14 -0500 (CDT)) From: Richard Kelsey References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 02 Jul 2009 14:33:02.0865 (UTC) FILETIME=[0174A010:01C9FB22] Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:32:42 -0000 Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) From: Mukul Goyal It is possible that I will be surprised. But I will be really surprised if people dont care about how many hops their packets travel before they reach the root. I do not care how many hops packets travel to reach the root. I have worked on two ROLL-style protocols that have seen years of successful commercial use. Neither of them uses hop count in determining routes. Different hops are different enough in their properties that there is little value in a metric that considers them all equal. Hop count may be useful for routing, but it certainly isn't essential. -Richard Kelsey From alexandru.petrescu@gmail.com Thu Jul 2 07:51:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69263A6B0F for ; Thu, 2 Jul 2009 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 6jMQ8hbbdRox for ; Thu, 2 Jul 2009 07:51:53 -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 B5C8A3A680F for ; Thu, 2 Jul 2009 07:51:52 -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 n62EqB3L001531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jul 2009 16:52:11 +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 n62Eq9fV021877; Thu, 2 Jul 2009 16:52: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 n62Eq8nQ022724; Thu, 2 Jul 2009 16:52:08 +0200 Message-ID: <4A4CC997.7000206@gmail.com> Date: Thu, 02 Jul 2009 16:52:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Richard Kelsey References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <871vozxih5.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:51:53 -0000 Richard Kelsey a crit : > Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) > From: Mukul Goyal > > It is possible that I will be surprised. > > But I will be really surprised if people dont care about how many > hops their packets travel before they reach the root. > > I do not care how many hops packets travel to reach the > root. I have worked on two ROLL-style protocols that have > seen years of successful commercial use. Neither of them > uses hop count in determining routes. Different hops are > different enough in their properties that there is little > value in a metric that considers them all equal. > > Hop count may be useful for routing, but it certainly isn't > essential. A metric is what helps a distributed algorithm to build loop-free short paths through a graph, especially make independent nodes to have precisely the same view of that network. This is of paramount importance when the network is large and dynamic, where humans can't possibly understand it. Not using metrics can be useful if the network is small, and mostly static, and a few humans manage it, I agree. I am not sure what is the situation with the ROLL networks, how large are they, and how much connected to the Internet are they. Alex > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Thu Jul 2 07:55:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FA73A6D3A for ; Thu, 2 Jul 2009 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 KSzrTs6+Fd-G for ; Thu, 2 Jul 2009 07:55:56 -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 0085E3A6D82 for ; Thu, 2 Jul 2009 07:54:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,334,1243814400"; d="scan'208";a="44230950" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 14:55:02 +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 n62Et2Dg022244; Thu, 2 Jul 2009 16:55:02 +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.14.3) with ESMTP id n62EswnE000197; Thu, 2 Jul 2009 14:55:02 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); Thu, 2 Jul 2009 16:55:00 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 16:54:59 +0200 Message-Id: <0E0418CE-A487-4220-86AB-EF44A4FA5046@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <871vozxih5.fsf@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 v935.3) Date: Thu, 2 Jul 2009 16:54:58 +0200 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 14:54:59.0467 (UTC) FILETIME=[123625B0:01C9FB25] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1133; t=1246546502; x=1247410502; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=XyyjD3yzQFTeerlRzQ1w62nBRdzwqdIZiffScFwTNKc=; b=KC9WdAePvKZgtqp+OpL10Uc7SoKZT/IXV9PIYcB1k8nH72z0f3LH8RGGRH CkEB7UCNr0HeqMEtcQR8UfxR0Fhh6EGhRoqeGW+wQiBrA6TYbGI4ZRITJju7 2MfZZ9wLld; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:55:57 -0000 On Jul 2, 2009, at 4:33 PM, Richard Kelsey wrote: > > Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) > From: Mukul Goyal > > It is possible that I will be surprised. > > But I will be really surprised if people dont care about how many > hops their packets travel before they reach the root. > > I do not care how many hops packets travel to reach the > root. I have worked on two ROLL-style protocols that have > seen years of successful commercial use. Neither of them > uses hop count in determining routes. Different hops are > different enough in their properties that there is little > value in a metric that considers them all equal. Fully agree. There are cases where indeed this might be of interest (for example when node may add jitter because of queueing delays) but this is not one of many factors. > > Hop count may be useful for routing, but it certainly isn't > essential. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu Jul 2 07:55:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FAA3A6906 for ; Thu, 2 Jul 2009 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 zubwzckivBbg for ; Thu, 2 Jul 2009 07:55:57 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 276373A6A9A for ; Thu, 2 Jul 2009 07:55:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CB78EAF819; Thu, 2 Jul 2009 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8aWMDlmOtAH; Thu, 2 Jul 2009 07:55:21 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 04608AF84A; Thu, 2 Jul 2009 07:55:20 -0700 (PDT) Message-Id: <811F8FD0-523C-464A-A82F-BC1578540FBA@archrock.com> From: Jonathan Hui To: Alexandru Petrescu In-Reply-To: <4A4CC997.7000206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 07:55:18 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <4A4CC997.7000206@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:55:57 -0000 On Jul 2, 2009, at 7:52 AM, Alexandru Petrescu wrote: > Richard Kelsey a =E9crit : >> Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) >> From: Mukul Goyal >> It is possible that I will be surprised. >> But I will be really surprised if people dont care about how many >> hops their packets travel before they reach the root. >> I do not care how many hops packets travel to reach the >> root. I have worked on two ROLL-style protocols that have >> seen years of successful commercial use. Neither of them >> uses hop count in determining routes. Different hops are >> different enough in their properties that there is little >> value in a metric that considers them all equal. >> Hop count may be useful for routing, but it certainly isn't >> essential. > > A metric is what helps a distributed algorithm to build loop-free =20 > short paths through a graph, especially make independent nodes to =20 > have precisely the same view of that network. > > This is of paramount importance when the network is large and =20 > dynamic, where humans can't possibly understand it. > > Not using metrics can be useful if the network is small, and mostly =20= > static, and a few humans manage it, I agree. > > I am not sure what is the situation with the ROLL networks, how =20 > large are they, and how much connected to the Internet are they. Richard wasn't arguing for no metrics at all - just that hop count as =20= a metric wasn't very useful to him. -- Jonathan Hui From jvasseur@cisco.com Thu Jul 2 07:56:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FAC28C110 for ; Thu, 2 Jul 2009 07:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 VlfUs0ZwY3wH for ; Thu, 2 Jul 2009 07:56:04 -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 7FAFE3A680F for ; Thu, 2 Jul 2009 07:55:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,334,1243814400"; d="scan'208";a="44231127" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 14:56:13 +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 n62EuDBd010075; Thu, 2 Jul 2009 16:56:13 +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.14.3) with ESMTP id n62EuDsc000677; Thu, 2 Jul 2009 14:56:13 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 16:56:12 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 16:56:11 +0200 Message-Id: <79DEEB63-6595-42A8-BA4D-C5B220FE8D1F@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A4CC997.7000206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 16:56:10 +0200 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <4A4CC997.7000206@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 14:56:11.0832 (UTC) FILETIME=[3D582B80:01C9FB25] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1805; t=1246546573; x=1247410573; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=Jusb+iGQVXoQPalqlNhYpNqFvJ8i6liPzns6g2l+EM8=; b=sIBj8kqxlQ6ME0vkGG2yrBEEa0w60xnRYB4O4GEeUW80DX6sMTeIR73t4r xyrNpJyqDnM0V6bbiuHCov7xd2sETB8cE+SI7lOKJX1cDdIJqthtdiGVbYXl cP+oqetpzC; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:56:05 -0000 On Jul 2, 2009, at 4:52 PM, Alexandru Petrescu wrote: > Richard Kelsey a =E9crit : >> Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT) >> From: Mukul Goyal >> It is possible that I will be surprised. >> But I will be really surprised if people dont care about how many >> hops their packets travel before they reach the root. >> I do not care how many hops packets travel to reach the >> root. I have worked on two ROLL-style protocols that have >> seen years of successful commercial use. Neither of them >> uses hop count in determining routes. Different hops are >> different enough in their properties that there is little >> value in a metric that considers them all equal. >> Hop count may be useful for routing, but it certainly isn't >> essential. > > A metric is what helps a distributed algorithm to build loop-free =20 > short paths through a graph, especially make independent nodes to =20 > have precisely the same view of that network. > > This is of paramount importance when the network is large and =20 > dynamic, where humans can't possibly understand it. > > Not using metrics can be useful if the network is small, and mostly =20= > static, and a few humans manage it, I agree. > I do not think Richard is suggesting not to use metrics ... > I am not sure what is the situation with the ROLL networks, how =20 > large are they, and how much connected to the Internet are they. > > Alex > > >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Jul 2 08:21:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9333A6E9B for ; Thu, 2 Jul 2009 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 oo6KmIoyOdYZ for ; Thu, 2 Jul 2009 08:21:14 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 105CB28C0DB for ; Thu, 2 Jul 2009 08:21:13 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 11:21:35 -0400 Date: Thu, 02 Jul 2009 11:21:59 -0400 Message-Id: <87zlbnw1ns.fsf@kelsey-ws.hq.ember.com> To: Alexandru Petrescu In-reply-to: <4A4CC997.7000206@gmail.com> (message from Alexandru Petrescu on Thu, 02 Jul 2009 16:52:07 +0200) From: Richard Kelsey References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <4A4CC997.7000206@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Jul 2009 15:21:35.0240 (UTC) FILETIME=[C95DC880:01C9FB28] Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:21:15 -0000 Date: Thu, 02 Jul 2009 16:52:07 +0200 From: Alexandru Petrescu Richard Kelsey a écrit : > > I do not care how many hops packets travel to reach the > root. I have worked on two ROLL-style protocols that have > seen years of successful commercial use. Neither of them > uses hop count in determining routes. Different hops are > different enough in their properties that there is little > value in a metric that considers them all equal. > > Hop count may be useful for routing, but it certainly isn't > essential. A metric is what helps a distributed algorithm to build loop-free short paths through a graph, especially make independent nodes to have precisely the same view of that network. This is of paramount importance when the network is large and dynamic, where humans can't possibly understand it. Not using metrics can be useful if the network is small, and mostly static, and a few humans manage it, I agree. We use metrics, but hop count is not one of them. The networks are up to several thousand nodes in size and have little or no human management. The nodes use 802.15.4 radios and the links are quite dynamic, even for those nodes that have static locations. -Richard Kelsey From alexandru.petrescu@gmail.com Thu Jul 2 08:31:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3938F3A690D for ; Thu, 2 Jul 2009 08:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 AQp8msWPIKie for ; Thu, 2 Jul 2009 08:31:11 -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 A18673A6DAE for ; Thu, 2 Jul 2009 08:31:09 -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 n62FVS1Y005208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jul 2009 17:31: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 n62FVRor030170; Thu, 2 Jul 2009 17:31: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 n62FVRk3011521; Thu, 2 Jul 2009 17:31:27 +0200 Message-ID: <4A4CD2CF.8060004@gmail.com> Date: Thu, 02 Jul 2009 17:31:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Richard Kelsey References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <4A4CC997.7000206@gmail.com> <87zlbnw1ns.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87zlbnw1ns.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:31:12 -0000 Richard Kelsey a écrit : > Date: Thu, 02 Jul 2009 16:52:07 +0200 > From: Alexandru Petrescu > > Richard Kelsey a écrit : > > > > I do not care how many hops packets travel to reach the > > root. I have worked on two ROLL-style protocols that have > > seen years of successful commercial use. Neither of them > > uses hop count in determining routes. Different hops are > > different enough in their properties that there is little > > value in a metric that considers them all equal. > > > > Hop count may be useful for routing, but it certainly isn't > > essential. > > A metric is what helps a distributed algorithm to build loop-free > short paths through a graph, especially make independent nodes to > have precisely the same view of that network. > > This is of paramount importance when the network is large and dynamic, > where humans can't possibly understand it. > > Not using metrics can be useful if the network is small, and mostly > static, and a few humans manage it, I agree. > > We use metrics, but hop count is not one of them. The > networks are up to several thousand nodes in size and have > little or no human management. The nodes use 802.15.4 > radios and the links are quite dynamic, even for those nodes > that have static locations. Hmmm... does it have a notion of universal reachability, like any node must reach any other node at any time? Alex From richard.kelsey@ember.com Thu Jul 2 08:49:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872E528C250 for ; Thu, 2 Jul 2009 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=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 lP9NK7rmR6XM for ; Thu, 2 Jul 2009 08:49:43 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id F21753A6DC1 for ; Thu, 2 Jul 2009 08:49:32 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 11:49:41 -0400 Date: Thu, 02 Jul 2009 11:50:05 -0400 Message-Id: <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Wed, 1 Jul 2009 20:32:10 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 02 Jul 2009 15:49:41.0271 (UTC) FILETIME=[B651B270:01C9FB2C] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:49:44 -0000 From: Jonathan Hui Date: Wed, 1 Jul 2009 20:32:10 -0700 Phil put his finger on an important point. We want to select routes using metrics that are not necessarily based on hop-count for a variety of reasons (e.g. ETX), but hop-count is a way to avoid and detect loops while being agnostic to the metric used. This distinction highlights a subtle difference between the Arch Rock stack and CTP, where the former uses hop-count for data-path loop detection and the latter uses the routing cost itself. That subtle difference can have a large effect. The current DAG discovery strongly prefers a single hop over any alternative path that is three or more hops in length, regardless of any routing contraints. This stems directly from the use of hop count for loop avoidance. To see this, consider a network with four nodes LBR, A, B, and C, where A and B do not share a link and the LBR<->B link is inferior enough that the LBR<->A<->C<->B route is significantly better than the one-hop LBR<->B route. LBR / \ A B \ / C LBR, as the root, sends out an RA at depth 0, heard by both A and B. They in turn send out their RAs at depth 1 and C picks A as a parent, the cost of the LBR<->B link making B an bad choice. C then sends out an RA at depth 2, which is ignored by A and B because C's depth is greater than theirs. The upshot is that B's route to LBR almost always uses the poor-quality LBR<->B link, rather than the preferred route via C and A. The 'almost always' is because you might get lucky and B might not hear the initial RA from the LBR and hear C's RA first. -Richard Kelsey From Rob.Alexander@ember.com Thu Jul 2 08:57:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A783A683F for ; Thu, 2 Jul 2009 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 fp8xpU4GqTv2 for ; Thu, 2 Jul 2009 08:57:48 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6C75128C0EC for ; Thu, 2 Jul 2009 08:57:48 -0700 (PDT) Received: from 192.168.81.21 ([192.168.81.21]) by EMPIRE.hq.ember.com ([192.168.80.108]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Jul 2009 15:58:04 +0000 Received: from ralexander-laptop by empire.hq.ember.com; 02 Jul 2009 11:58:06 -0400 From: Rob Alexander To: JP Vasseur In-Reply-To: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> References: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 02 Jul 2009 11:58:06 -0400 Message-Id: <1246550286.15736.19.camel@ralexander-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: ROLL WG Subject: Re: [Roll] Agenda and Routing Protocol Selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:57:49 -0000 Hi JP, The agenda mentions draft-tsao-roll-security-framework-01, but I was only able to find version 00. Is that the correct one? - Rob On Thu, 2009-07-02 at 12:42 +0200, JP Vasseur wrote: > Dear WG, > > > Here is the latest > agenda: http://www.ietf.org/proceedings/09jul/agenda/roll.txt > > > We have two major topics: > 1) Routing Protocol > 2) Security > > > With regards to 1), there are as of today two proposals on the table > (any other proposal is of course welcome): > RPL (DT proposal): draft-dt-roll-rpl > draft-iwao-roll-dadr > > > The objective of the next meeting is to select one of them so as to > continue to move forward. Indeed, we need to reach to reach that next > important milestone also to progress on others IDs such as the > metric-ID (this is the reason why the metric ID will not be discussed > in this WG meeting). > > > Please read and comments the proposals and be ready for Stockholm. > > > With regards to 2), Rene is getting up to speed and we have a 45mn > slot for this item. > > > Thanks. > > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll *** Robert Alexander Ember, Inc. 47 Farnsworth Street Boston, MA 02210 T: 617-951-1244 F: 617-951-0999 From jvasseur@cisco.com Thu Jul 2 09:01:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818F728C23E for ; Thu, 2 Jul 2009 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.251 X-Spam-Level: X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 a9aHdc6DTxgD for ; Thu, 2 Jul 2009 09:01:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3024228C232 for ; Thu, 2 Jul 2009 09:01:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,335,1243814400"; d="scan'208";a="44239734" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 16:02:08 +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 n62G28f6011471; Thu, 2 Jul 2009 18:02:08 +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.14.3) with ESMTP id n62G28WK024014; Thu, 2 Jul 2009 16:02:08 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); Thu, 2 Jul 2009 18:02:08 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 18:02:06 +0200 Message-Id: <052DB983-766A-43E1-865B-6B6937BEF925@cisco.com> From: JP Vasseur To: Rob Alexander In-Reply-To: <1246550286.15736.19.camel@ralexander-laptop> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 18:02:03 +0200 References: <62E9E57F-F1FC-4318-A178-6434A72C9B2A@cisco.com> <1246550286.15736.19.camel@ralexander-laptop> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 16:02:07.0297 (UTC) FILETIME=[72FC3B10:01C9FB2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1509; t=1246550528; x=1247414528; 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[Roll]=20Agenda=20and=20Routing=20Proto col=20Selection |Sender:=20; bh=b9UXLKblYLn4bSUJMTOfUrm2ZhoinYhe+GvKIZ6PHjA=; b=AI9IutWsjtYobHU0WHDc5NxKyVjLVkHwQrZa35QH55HxkKEoq8xhXcBrdf 3F3vgCe5tr/JkI1gw4k8k3NZ5nhlZvytoXavczHEnjNMQcgfsYNyjYcdgOLO UT2H3bnYwA; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Agenda and Routing Protocol Selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:01:54 -0000 Hi, On Jul 2, 2009, at 5:58 PM, Rob Alexander wrote: > Hi JP, > > The agenda mentions draft-tsao-roll-security-framework-01, but I was > only able to find version 00. Is that the correct one? > -00 is the current one indeed. JP. > - Rob > > > > On Thu, 2009-07-02 at 12:42 +0200, JP Vasseur wrote: >> Dear WG, >> >> >> Here is the latest >> agenda: http://www.ietf.org/proceedings/09jul/agenda/roll.txt >> >> >> We have two major topics: >> 1) Routing Protocol >> 2) Security >> >> >> With regards to 1), there are as of today two proposals on the table >> (any other proposal is of course welcome): >> RPL (DT proposal): draft-dt-roll-rpl >> draft-iwao-roll-dadr >> >> >> The objective of the next meeting is to select one of them so as to >> continue to move forward. Indeed, we need to reach to reach that next >> important milestone also to progress on others IDs such as the >> metric-ID (this is the reason why the metric ID will not be discussed >> in this WG meeting). >> >> >> Please read and comments the proposals and be ready for Stockholm. >> >> >> With regards to 2), Rene is getting up to speed and we have a 45mn >> slot for this item. >> >> >> Thanks. >> >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > *** > > Robert Alexander > Ember, Inc. > 47 Farnsworth Street > Boston, MA 02210 > T: 617-951-1244 > F: 617-951-0999 From jhui@archrock.com Thu Jul 2 09:19:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A313A6B86 for ; Thu, 2 Jul 2009 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=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 vW9Kf8KYhUmX for ; Thu, 2 Jul 2009 09:19:12 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4F3C028C157 for ; Thu, 2 Jul 2009 09:19:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E5B23AF860; Thu, 2 Jul 2009 09:19: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 G4gjwWlQVH4v; Thu, 2 Jul 2009 09:19:29 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 0FD1CAF819; Thu, 2 Jul 2009 09:19:29 -0700 (PDT) Message-Id: <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87y6r7w0cy.fsf@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 v935.3) Date: Thu, 2 Jul 2009 09:19:25 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:19:13 -0000 Hi Richard, On Jul 2, 2009, at 8:50 AM, Richard Kelsey wrote: > From: Jonathan Hui > Date: Wed, 1 Jul 2009 20:32:10 -0700 > > Phil put his finger on an important point. We want to select routes > using metrics that are not necessarily based on hop-count for a > variety of reasons (e.g. ETX), but hop-count is a way to avoid and > detect loops while being agnostic to the metric used. This > distinction > highlights a subtle difference between the Arch Rock stack and CTP, > where the former uses hop-count for data-path loop detection and the > latter uses the routing cost itself. > > That subtle difference can have a large effect. The current > DAG discovery strongly prefers a single hop over any > alternative path that is three or more hops in length, > regardless of any routing contraints. This stems directly > from the use of hop count for loop avoidance. > > To see this, consider a network with four nodes LBR, A, B, > and C, where A and B do not share a link and the LBR<->B > link is inferior enough that the LBR<->A<->C<->B route is > significantly better than the one-hop LBR<->B route. > > LBR > / \ > A B > \ / > C > > LBR, as the root, sends out an RA at depth 0, heard by both > A and B. They in turn send out their RAs at depth 1 and C > picks A as a parent, the cost of the LBR<->B link making B > an bad choice. C then sends out an RA at depth 2, which is > ignored by A and B because C's depth is greater than theirs. > > The upshot is that B's route to LBR almost always uses the > poor-quality LBR<->B link, rather than the preferred route > via C and A. The 'almost always' is because you might get > lucky and B might not hear the initial RA from the LBR and > hear C's RA first. I was referring to data-path loop detection. You are referring to control-path loop avoidance. With the former, the forwarding node attaches what it believes to be the depth of the next hop in each datagram sent. The next hop receives the datagram and checks whether the depth agrees. But to address your specific point - with the example you give, it is unclear what the overall best situation is. From B's point of view, it is better to go through C. But from C's point of view, it may be better to have two feasible successors A and B. If it is acceptable for B to communicate directly with the LBR, then that might be the overall better solution. In the end, I don't think we can feasibly optimize each individual node locally while optimizing the entire routing graph. What is globally optimal is not even well defined... -- Jonathan Hui From Yusuf.Bashir@jci.com Thu Jul 2 09:24:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D9228C1ED; Thu, 2 Jul 2009 09:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 oVx9YZ16fC6E; Thu, 2 Jul 2009 09:24:42 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id 2D4893A6BFE; Thu, 2 Jul 2009 09:23:51 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSkzfF4LlhpOOcl/C0lIFqnV20WIkMBDG@postini.com; Thu, 02 Jul 2009 09:24:14 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009070211244936-3850907 ; Thu, 2 Jul 2009 11:24:49 -0500 In-Reply-To: <871vozxih5.fsf@kelsey-ws.hq.ember.com> References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey MIME-Version: 1.0 X-KeepSent: 11886124:468A050A-862575E7:005530F3; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Yusuf.Bashir@jci.com Message-ID: Date: Thu, 2 Jul 2009 10:48:01 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/02/2009 11:22:13 AM, Serialize complete at 07/02/2009 11:22:13 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 11:24:49 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 11:26:49 AM, Serialize complete at 07/02/2009 11:26:49 AM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:24:43 -0000
Using low data rate 802.15.4 radios in commercial buildings we design our deployments
 to minimize hops and that has been an essential part of the success of our networks. The result of
excessive hops is higher latency and higher probability of collisions which leads to devices timing out and going
offline. This is an essential customer requirement for us.  We also have data showing that when you do over the air downloads,
minimizing hops is key to meeting our timing requirements.

Regards,
Yusuf


From: Richard Kelsey <richard.kelsey@ember.com>
To: Mukul Goyal <mukul@uwm.edu>
Cc: roll@ietf.org, gnawali@usc.edu
Date: 07/02/2009 09:37 AM
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot?




   Date: Wed, 1 Jul 2009 23:22:14 -0500 (CDT)
  From: Mukul Goyal <mukul@uwm.edu>

  It is possible that I will be surprised.

  But I will be really surprised if people dont care about how many
  hops their packets travel before they reach the root.

I do not care how many hops packets travel to reach the
root.  I have worked on two ROLL-style protocols that have
seen years of successful commercial use.  Neither of them
uses hop count in determining routes.  Different hops are
different enough in their properties that there is little
value in a metric that considers them all equal.

Hop count may be useful for routing, but it certainly isn't
essential.
                             -Richard Kelsey
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From jhui@archrock.com Thu Jul 2 09:27:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BFF13A6951; Thu, 2 Jul 2009 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 EFk+KgQAP3+v; Thu, 2 Jul 2009 09:27:21 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8BFB33A677D; Thu, 2 Jul 2009 09:27:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 50869AF860; Thu, 2 Jul 2009 09:27:44 -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 8CjB1ldcZVWj; Thu, 2 Jul 2009 09:27:39 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 5849EAF819; Thu, 2 Jul 2009 09:27:39 -0700 (PDT) Message-Id: <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> From: Jonathan Hui To: Yusuf.Bashir@jci.com 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 v935.3) Date: Thu, 2 Jul 2009 09:27:35 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:27:22 -0000 On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: > > Using low data rate 802.15.4 radios in commercial buildings we > design our deployments > to minimize hops and that has been an essential part of the success > of our networks. The result of > excessive hops is higher latency and higher probability of > collisions which leads to devices timing out and going > offline. This is an essential customer requirement for us. We also > have data showing that when you do over the air downloads, > minimizing hops is key to meeting our timing requirements. But would you agree that minimizing the number of transmissions on a path is a better metric than hops in your case? -- Jonathan Hui From prvs=4276677de=mukul@uwm.edu Thu Jul 2 10:13:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4771B3A6B94; Thu, 2 Jul 2009 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 nnP1H7EvNEZl; Thu, 2 Jul 2009 10:13:32 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 378493A695F; Thu, 2 Jul 2009 10:13:32 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta2.uwm.edu with ESMTP; 02 Jul 2009 12:13:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1C7EAB20018; Thu, 2 Jul 2009 12:13:54 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaJ5dsCdCqIb; Thu, 2 Jul 2009 12:13:53 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 86CA4B20007; Thu, 2 Jul 2009 12:13:53 -0500 (CDT) Date: Thu, 2 Jul 2009 12:13:53 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <638675580.17844541246554833439.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <64035423.17833331246552992010.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf Bashir , gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:13:33 -0000 Jonathan Whether an application uses minimum hop routes or ETX or some other (combination of) metric(s) to determine routes should be left to the application itself. Now lets talk about the shortcomings of ETX as a routing metric. ETX is not a panacea. Number of transmissions allowed by a MAC protocol before it gives up the packet is a configurable parameter in many protocols. I can configure some 802.15.4 nodes to give up a packet after 1 try and some others to give up after 5 tries. So, if path A has ETX 40 and path B has ETX 50, I can't really say that path A is better because it is possible that ETX for path A is low because nodes on path A don't allow as many transmissions per packet as nodes on path B. ETX paper defines ETX as "the predicted number of data transmissions required to send a packet over that link". I am not sure how ETX would be calculated when limits exist on the number of packet transmissions before MAC layer gives it up. But, unless ETX is calculated in a manner to account for such limits, it seems to me that ETX across links are diffficult to compare when these links have different limits on the number of retries. So, as individual hops are incomparable with each other (as some on the list have suggested), it may be that individual ETX values are also incomparable. Moreover, ETX seems to be ignoring the "channel access failures" (borrowing 15.4 terminology). A link may be so bad that very few transmissions take place. Not sure how ETX accounts for channel access failures. A path may have low ETX because of the high channel access failure rates along the links on the path. I think this discussion is not moving in the way I wanted it to be. The original question was why is it better to have parents with multiple depths. It seemed to me that we can have all the flexibility of DAGs while preserving the meaning of the term "depth", which has been lost the way RPL works. I will explain the question in a separate email. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Yusuf Bashir" Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu Sent: Thursday, July 2, 2009 11:27:35 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: > > Using low data rate 802.15.4 radios in commercial buildings we > design our deployments > to minimize hops and that has been an essential part of the success > of our networks. The result of > excessive hops is higher latency and higher probability of > collisions which leads to devices timing out and going > offline. This is an essential customer requirement for us. We also > have data showing that when you do over the air downloads, > minimizing hops is key to meeting our timing requirements. But would you agree that minimizing the number of transmissions on a path is a better metric than hops in your case? -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu Jul 2 10:24:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ECB83A6BC1; Thu, 2 Jul 2009 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 8TqPNtMGFB3D; Thu, 2 Jul 2009 10:24:18 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id BBEB328C1C2; Thu, 2 Jul 2009 10:24:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 66E1BAF879; Thu, 2 Jul 2009 10:24:17 -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 hjVA4C4Xayfg; Thu, 2 Jul 2009 10:24:13 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 1D749AF860; Thu, 2 Jul 2009 10:24:13 -0700 (PDT) Message-Id: From: Jonathan Hui To: Mukul Goyal In-Reply-To: <638675580.17844541246554833439.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 10:24:09 -0700 References: <638675580.17844541246554833439.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf Bashir , gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:24:19 -0000 HI Mulul, On Jul 2, 2009, at 10:13 AM, Mukul Goyal wrote: > Whether an application uses minimum hop routes or ETX or some other > (combination of) metric(s) to determine routes should be left to the > application itself. Yes. ETX is simply an example of a metric that provides more information than hop count yet reduces to hop count with perfect links. > Now lets talk about the shortcomings of ETX as a routing metric. > > ETX is not a panacea. Number of transmissions allowed by a MAC > protocol before it gives up the packet is a configurable parameter > in many protocols. I can configure some 802.15.4 nodes to give up a > packet after 1 try and some others to give up after 5 tries. So, if > path A has ETX 40 and path B has ETX 50, I can't really say that > path A is better because it is possible that ETX for path A is low > because nodes on path A don't allow as many transmissions per packet > as nodes on path B. Ideally, ETX should be the number of actual transmissions at the link layer. > ETX paper defines ETX as "the predicted number of data transmissions > required to send a packet over that link". I am not sure how ETX > would be calculated when limits exist on the number of packet > transmissions before MAC layer gives it up. But, unless ETX is > calculated in a manner to account for such limits, it seems to me > that ETX across links are diffficult to compare when these links > have different limits on the number of retries. So, as individual > hops are incomparable with each other (as some on the list have > suggested), it may be that individual ETX values are also > incomparable. One way to compute the link ETX is (number of transmissions)/(number of acked transmissions). The path ETX is simply the sum of the link ETXs along the path. > Moreover, ETX seems to be ignoring the "channel access > failures" (borrowing 15.4 terminology). A link may be so bad that > very few transmissions take place. Not sure how ETX accounts for > channel access failures. A path may have low ETX because of the high > channel access failure rates along the links on the path. Sure - there are a lot of other things that ETX doesn't provide information about - energy consumed per transmission is another example. But hop count doesn't address those either... > I think this discussion is not moving in the way I wanted it to be. > The original question was why is it better to have parents with > multiple depths. It seemed to me that we can have all the > flexibility of DAGs while preserving the meaning of the term > "depth", which has been lost the way RPL works. I will explain the > question in a separate email. Will wait for your mail. -- Jonathan Hui > > Thanks > Mukul > > ----- Original Message ----- > From: "Jonathan Hui" > To: "Yusuf Bashir" > Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu > Sent: Thursday, July 2, 2009 11:27:35 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Jul 2 10:27:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DBA3A6D5A for ; Thu, 2 Jul 2009 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=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 EqV0BcSvF+Ey for ; Thu, 2 Jul 2009 10:27:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DF8823A68F8 for ; Thu, 2 Jul 2009 10:27:19 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:27:23 -0400 Date: Thu, 02 Jul 2009 13:27:47 -0400 Message-Id: <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> (message from Jonathan Hui on Thu, 2 Jul 2009 09:19:25 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> X-OriginalArrivalTime: 02 Jul 2009 17:27:23.0224 (UTC) FILETIME=[5C50BD80:01C9FB3A] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:27:21 -0000 Jonathan, From: Jonathan Hui Date: Thu, 2 Jul 2009 09:19:25 -0700 On Jul 2, 2009, at 8:50 AM, Richard Kelsey wrote: > To see this, consider a network with four nodes LBR, A, B, > and C, where A and B do not share a link and the LBR<->B > link is inferior enough that the LBR<->A<->C<->B route is > significantly better than the one-hop LBR<->B route. > > LBR > / \ > A B > \ / > C > > LBR, as the root, sends out an RA at depth 0, heard by both > A and B. They in turn send out their RAs at depth 1 and C > picks A as a parent, the cost of the LBR<->B link making B > an bad choice. C then sends out an RA at depth 2, which is > ignored by A and B because C's depth is greater than theirs. > > The upshot is that B's route to LBR almost always uses the > poor-quality LBR<->B link, rather than the preferred route > via C and A. The 'almost always' is because you might get > lucky and B might not hear the initial RA from the LBR and > hear C's RA first. I was referring to data-path loop detection. Yes, sorry, I missed that. But to address your specific point - with the example you give, it is unclear what the overall best situation is. From B's point of view, it is better to go through C. But from C's point of view, it may be better to have two feasible successors A and B. If it is acceptable for B to communicate directly with the LBR, then that might be the overall better solution. In the end, I don't think we can feasibly optimize each individual node locally while optimizing the entire routing graph. What is globally optimal is not even well defined... The problem isn't that hop count doesn't pick the best route, but that it often doesn't even pick a good one. To quote from a posting by Philip Levis: There is a tremendous amount of research in wireless which has shown that min hop-distance is not a good metric for wireless networks. In this and similar situations, RPL lets hop count trump all other routing constraints. This seems like a bad idea. -Richard Kelsey From jhui@archrock.com Thu Jul 2 10:57:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123753A68F8 for ; Thu, 2 Jul 2009 10:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 g4alns5AF-Hr for ; Thu, 2 Jul 2009 10:57:07 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 43A863A67A6 for ; Thu, 2 Jul 2009 10:57:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 85126AF879; Thu, 2 Jul 2009 10:56:15 -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 0pbe+pL0MIsQ; Thu, 2 Jul 2009 10:56:10 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id AA923AF860; Thu, 2 Jul 2009 10:56:10 -0700 (PDT) Message-Id: <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87vdmbvvu4.fsf@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 v935.3) Date: Thu, 2 Jul 2009 10:56:06 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:57:08 -0000 Hi Richard, On Jul 2, 2009, at 10:27 AM, Richard Kelsey wrote: > But to address your specific point - with the example you give, it > is > unclear what the overall best situation is. From B's point of > view, it > is better to go through C. But from C's point of view, it may be > better to have two feasible successors A and B. If it is acceptable > for B to communicate directly with the LBR, then that might be the > overall better solution. In the end, I don't think we can feasibly > optimize each individual node locally while optimizing the entire > routing graph. What is globally optimal is not even well defined... > > The problem isn't that hop count doesn't pick the best > route, but that it often doesn't even pick a good one. To > quote from a posting by Philip Levis: > > There is a tremendous amount of research in wireless which > has shown that min hop-distance is not a good metric for > wireless networks. > > In this and similar situations, RPL lets hop count trump all > other routing constraints. This seems like a bad idea. Yes. I understand the problem and agree with you here - that the loop avoidance mechanism is not based on the actual routing metrics used (whatever they may be). We actually had a lengthy discussion about this within the DT. I'd actually like to see the loop avoidance mechanism be based on the routing metrics themselves rather than the hop count. This works fine as long as the metric we use have a monotonic property such that there is a consistent notion of "deeper" in the gradient. Things get a bit more tricky when dealing with multiple metrics simultaneously. With multiple metrics, nothing changes as long as the comparator function between two metric vectors is a strictly monotonic function. If that strictly monotonic function does not exist (i.e. the metrics are completely orthogonal), then things get a bit more difficult. One possible solution is that we require one or more of the path metrics to be strictly monotonic and the rule becomes: a node cannot go "deeper" in any of the monotonic metrics. This seems a bit over-constrained, so we were discussing whether we can relax this constraint and this is still work in progress. Do you think we are headed in a fruitful direction? What are your thoughts? -- Jonathan Hui From richard.kelsey@ember.com Thu Jul 2 11:46:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FED3A6BD5 for ; Thu, 2 Jul 2009 11:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 uuIh0BMAjgD1 for ; Thu, 2 Jul 2009 11:46:30 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2218A3A6B7C for ; Thu, 2 Jul 2009 11:46:27 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 14:46:48 -0400 Date: Thu, 02 Jul 2009 14:47:12 -0400 Message-Id: <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> (message from Jonathan Hui on Thu, 2 Jul 2009 10:56:06 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> X-OriginalArrivalTime: 02 Jul 2009 18:46:48.0474 (UTC) FILETIME=[74A02FA0:01C9FB45] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:46:31 -0000 Jonathan, From: Jonathan Hui Date: Thu, 2 Jul 2009 10:56:06 -0700 Things get a bit more tricky when dealing with multiple metrics simultaneously. With multiple metrics, nothing changes as long as the comparator function between two metric vectors is a strictly monotonic function. If that strictly monotonic function does not exist (i.e. the metrics are completely orthogonal), then things get a bit more difficult. One possible solution is that we require one or more of the path metrics to be strictly monotonic and the rule becomes: a node cannot go "deeper" in any of the monotonic metrics. This seems a bit over-constrained, so we were discussing whether we can relax this constraint and this is still work in progress. Here is a suggestion: Leave the hop count as is, and add a DAGCost field. The DAGCost field is a fixed-point value, say 16 bits of which 8 bits are the fractional part. The units for the cost field are hops, so a hop with a cost 0x0001 is equivalent to an additional 1/256th of a 'best case' hop and 0x0100 is equivalent to a complete additional 'best case' hop. The actual path cost is (DAGDepth << 8) + DAGCost Loop avoidance and parent selection is done using the path cost. In an outgoing DIO the DAGDepth MUST be larger than the maximum parent DAGDepth and the DAGCost MUST be large enough such that the path cost of the DIO is greater than the maximum parent path cost. Increasing the DAGCost is optional. If no node does so the result is the same as the current algorithm. Nodes are free to include metric containers with additional information. If a node makes use of multiple metrics the additional costs for one hop need not be additive. For example, if a link is both slow and energy intensive, the link cost could be the average of the two, instead of their sum. What do you think? -Richard Kelsey From d.sturek@att.net Thu Jul 2 12:21:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E30E3A6C17 for ; Thu, 2 Jul 2009 12:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECaHL31NL4Ak for ; Thu, 2 Jul 2009 12:21:29 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 3F3E53A6BBB for ; Thu, 2 Jul 2009 12:21:29 -0700 (PDT) Received: from [68.142.200.227] by n10.bullet.mail.mud.yahoo.com with NNFMP; 02 Jul 2009 19:21:47 -0000 Received: from [68.142.201.244] by t8.bullet.mud.yahoo.com with NNFMP; 02 Jul 2009 19:21:47 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 02 Jul 2009 19:21:47 -0000 X-Yahoo-Newman-Id: 506818.14400.bm@omp405.mail.mud.yahoo.com Received: (qmail 79161 invoked from network); 2 Jul 2009 19:21:47 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2009 19:21:46 -0000 X-YMail-OSG: Vn8_wikVM1mS2U5IDEhjZWgnOPSM4uzuLTBv3_2SeF1nESX5UgSZvkGOQqdWJEYCPcY49KSJ73Yv6o2.b1_tE4Rm5ZUiWvqBzMNTlNQK5bfSKKjKwJPmlPMBu5pA2aG1k0EblGfiK1obRG6l2n72eY2dXU4edAIG61rw_nOef_XnSnbLmO1bAMxclGhU4T3NBordRmgtHwAw6RIrQPJxRoQrkvU.kPhWIG06f54VggKs.WiAiTQybOjc7J_xbc.i1TsZNYb0uDBudg0zIfrvWOKHhAQzGv0BHqibFD1z3QsjJN1Z X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Richard Kelsey'" , "'Jonathan Hui'" References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> Date: Thu, 2 Jul 2009 12:21:43 -0700 Message-ID: <015701c9fb4a$555bc8c0$00135a40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7RXrmVSfIwiMiS1WD0evMvMGbGAABCYKA Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:21:30 -0000 Hi Richard, The proposal below seems reasonable. Hopefully, these inputs can be accommodated in the ROLL DT work. Overall, I do think the proposal was good absent the issue around consideration of hops from the DAG root (which I do think some implementations care about). Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey Sent: Thursday, July 02, 2009 11:47 AM To: Jonathan Hui Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? Jonathan, From: Jonathan Hui Date: Thu, 2 Jul 2009 10:56:06 -0700 Things get a bit more tricky when dealing with multiple metrics simultaneously. With multiple metrics, nothing changes as long as the comparator function between two metric vectors is a strictly monotonic function. If that strictly monotonic function does not exist (i.e. the metrics are completely orthogonal), then things get a bit more difficult. One possible solution is that we require one or more of the path metrics to be strictly monotonic and the rule becomes: a node cannot go "deeper" in any of the monotonic metrics. This seems a bit over-constrained, so we were discussing whether we can relax this constraint and this is still work in progress. Here is a suggestion: Leave the hop count as is, and add a DAGCost field. The DAGCost field is a fixed-point value, say 16 bits of which 8 bits are the fractional part. The units for the cost field are hops, so a hop with a cost 0x0001 is equivalent to an additional 1/256th of a 'best case' hop and 0x0100 is equivalent to a complete additional 'best case' hop. The actual path cost is (DAGDepth << 8) + DAGCost Loop avoidance and parent selection is done using the path cost. In an outgoing DIO the DAGDepth MUST be larger than the maximum parent DAGDepth and the DAGCost MUST be large enough such that the path cost of the DIO is greater than the maximum parent path cost. Increasing the DAGCost is optional. If no node does so the result is the same as the current algorithm. Nodes are free to include metric containers with additional information. If a node makes use of multiple metrics the additional costs for one hop need not be additive. For example, if a link is both slow and energy intensive, the link cost could be the average of the two, instead of their sum. What do you think? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Jul 2 12:41:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE7E3A6BF1 for ; Thu, 2 Jul 2009 12:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3-xQB9hdKwe for ; Thu, 2 Jul 2009 12:41:37 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 50B8528C1AC for ; Thu, 2 Jul 2009 12:40:42 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 15:41:03 -0400 Date: Thu, 02 Jul 2009 15:41:28 -0400 Message-Id: <87skhex47r.fsf@kelsey-ws.hq.ember.com> To: Alexandru Petrescu In-reply-to: <4A4CD2CF.8060004@gmail.com> (message from Alexandru Petrescu on Thu, 02 Jul 2009 17:31:27 +0200) From: Richard Kelsey References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <4A4CC997.7000206@gmail.com> <87zlbnw1ns.fsf@kelsey-ws.hq.ember.com> <4A4CD2CF.8060004@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Jul 2009 19:41:03.0678 (UTC) FILETIME=[08E0E5E0:01C9FB4D] Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:41:38 -0000 Date: Thu, 02 Jul 2009 17:31:27 +0200 From: Alexandru Petrescu Richard Kelsey a écrit : > We use metrics, but hop count is not one of them. The > networks are up to several thousand nodes in size and have > little or no human management. The nodes use 802.15.4 > radios and the links are quite dynamic, even for those nodes > that have static locations. Hmmm... does it have a notion of universal reachability, like any node must reach any other node at any time? Yes and no. Any node can reach any other node at any time, as long as only a few nodes actually try to do so. The network has only a small, fixed bandwidth available for arbitrary any-to-any messages. For the relevent applications, traffic is mostly many-to-one or one-to-many, and often there is some degree of locality as well. Why do you ask? -Richard Kelsey From d.sturek@att.net Thu Jul 2 12:51:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0383A6AD2 for ; Thu, 2 Jul 2009 12:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCa0ZwpM+LVE for ; Thu, 2 Jul 2009 12:51:08 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 187613A67AC for ; Thu, 2 Jul 2009 12:51:08 -0700 (PDT) Received: (qmail 3527 invoked from network); 2 Jul 2009 19:51:27 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 2 Jul 2009 19:51:26 -0000 X-YMail-OSG: ZOU9p20VM1l0ynAOSpQGmvSEYxUhx42XeLF6wgE6V1cam4Jv.bYqXkEAPcp3wNbg7hHXc6Qcoi3FRWLkb3ch6BbrMDDp2NBv871fvpaBcKv2dHtNuJefaNDVO9A_aFDv7ACSk_IlbzN5g5SU3G._jWFE7SmPytbG0pIm_vNiUVK6y6FBhACuRjduM8gVUHxfYC7CiS2j1056cXN3JcilEiHm0H6nr6aYr5RfxHQNej68yk12wTAf0HoIH13aLm3S53rfCmVa7PdBKPwAWvgcXm.kT8O6TPsSr0wYM6b6.JCnqLaM X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" , References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> In-Reply-To: <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> Date: Thu, 2 Jul 2009 12:51:22 -0700 Message-ID: <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7Mgi4cQ8LCfZCSOiPHUh1NHDQ1wAHB+KA Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:51:08 -0000 Hi Jonathan, I think the example Yusuf may be referring to involves data link level security where packets are encrypted/decrypted hop by hop (please correct me if I am wrong). In that scenario, it is good to minimize the number of hops (within reason of course). If that involves a few extra re-transmissions then you probably still end up with a more efficient packet delivery from a latency point of view. Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Thursday, July 02, 2009 9:28 AM To: Yusuf.Bashir@jci.com Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: > > Using low data rate 802.15.4 radios in commercial buildings we > design our deployments > to minimize hops and that has been an essential part of the success > of our networks. The result of > excessive hops is higher latency and higher probability of > collisions which leads to devices timing out and going > offline. This is an essential customer requirement for us. We also > have data showing that when you do over the air downloads, > minimizing hops is key to meeting our timing requirements. But would you agree that minimizing the number of transmissions on a path is a better metric than hops in your case? -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 2 13:01:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E823A6D84; Thu, 2 Jul 2009 13:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 ZUlxuQVX3IzJ; Thu, 2 Jul 2009 13:01:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EFA263A6BF1; Thu, 2 Jul 2009 13:01:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,337,1243814400"; d="scan'208";a="44252799" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 20:01:26 +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 n62K1QWV010522; Thu, 2 Jul 2009 22:01:26 +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.14.3) with ESMTP id n62K1QE2005793; Thu, 2 Jul 2009 20:01:26 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 22:01:26 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 22:01:25 +0200 Message-Id: <53800201-E0C1-4136-913A-499E46947E91@cisco.com> From: JP Vasseur To: d.sturek@att.net In-Reply-To: <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 22:01:24 +0200 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 02 Jul 2009 20:01:25.0724 (UTC) FILETIME=[E14651C0:01C9FB4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2051; t=1246564886; x=1247428886; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=09theroot? |Sender:=20; bh=Yu5TJf4H+L4Ul4dYkeQzl0TYPQ0MPMD2H1ZpayOJuGI=; b=UwgIw3pBaQ/eOJi2lxQkx8ml9BINMvZf710UMDckzf+M0KmB1NTp3SCx2d XThxYCnyNQtdKZHM6dUBTnu3lWD8o9K23fEa3ZuS4qqCYr/GEvLahcyjO2/Y 7aopGq9WSN; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:01:06 -0000 Hi Don, I think that we are on the same page here: the number of hops should not be *the* only metric but *could* be a metric. Agree ? Thanks. JP. On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please > correct me > if I am wrong). In that scenario, it is good to minimize the number > of hops > (within reason of course). If that involves a few extra re- > transmissions > then you probably still end up with a more efficient packet delivery > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Jul 2 13:12:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679D228C16A for ; Thu, 2 Jul 2009 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaV2Z47BSEv5 for ; Thu, 2 Jul 2009 13:12:16 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 2146328C146 for ; Thu, 2 Jul 2009 13:12:16 -0700 (PDT) Received: (qmail 2218 invoked from network); 2 Jul 2009 20:05:59 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 2 Jul 2009 20:05:59 -0000 X-YMail-OSG: az9kW8YVM1mZNy779yYTXXgI9nYTzCRzMKPvsRyI4hmG.tCzizlQCCcYQ0F_ud7fLEgpB7aGKun3hHn6EAuwm3H91Hc4dbiuq9xhyv59VPKeUbPcFHKMiXQyw4cl_yyE_hs6dcs9ulmTLGNOzMJTMbCpCg5.VLpVaTKq0QHX1Bs39KDbZEsO28dST4NEmGDE5Ckm3o8PP684hcZlIIQfOUZZB28HA8e1kxDH1KNTyJ_iVaJuPZP2lcfLPSBdItoDDnOptreZQhsOYyFjAyhI9Y5TY6GUeY4lqK9I3qWDb0JSpi4- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> In-Reply-To: <53800201-E0C1-4136-913A-499E46947E91@cisco.com> Date: Thu, 2 Jul 2009 13:05:54 -0700 Message-ID: <018301c9fb50$82558d10$8700a730$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7T+IJbcqvA9DAQme4cCMfjkdTXAAADTBA Content-Language: en-us Cc: roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:12:16 -0000 Hi JP, Absolutely correct. Number of hops is not *the* metric. It just cannot be completely ignored and in some cases (like the data link security example) it does have a direct affect on latency. Don -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, July 02, 2009 1:01 PM To: d.sturek@att.net Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, I think that we are on the same page here: the number of hops should not be *the* only metric but *could* be a metric. Agree ? Thanks. JP. On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please > correct me > if I am wrong). In that scenario, it is good to minimize the number > of hops > (within reason of course). If that involves a few extra re- > transmissions > then you probably still end up with a more efficient packet delivery > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Yusuf.Bashir@jci.com Thu Jul 2 13:21:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8F628C1C0; Thu, 2 Jul 2009 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 RvHN3Q-CLQSz; Thu, 2 Jul 2009 13:21:57 -0700 (PDT) Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by core3.amsl.com (Postfix) with ESMTP id 0EC7028C18C; Thu, 2 Jul 2009 13:21:56 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKSk0W+vhVMOTe89q0T0Im39J+kfX66iz0@postini.com; Thu, 02 Jul 2009 13:22:20 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009070215245015-3880735 ; Thu, 2 Jul 2009 15:24:50 -0500 In-Reply-To: <018301c9fb50$82558d10$8700a730$@sturek@att.net> References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> <018301c9fb50$82558d10$8700a730$@sturek@att.net> To: d.sturek@att.net MIME-Version: 1.0 X-KeepSent: 78F5314A:3729A69D-862575E7:006FA89D; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Yusuf.Bashir@jci.com Message-ID: Date: Thu, 2 Jul 2009 15:22:04 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/02/2009 03:22:15 PM, Serialize complete at 07/02/2009 03:22:15 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 03:24:50 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 03:24:55 PM, Serialize complete at 07/02/2009 03:24:55 PM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@ietf.org, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:21:58 -0000
Hi JP and Don,
You are both correct. The number of hops should be one of the metrics not "the metric".

Regards,
Yusuf



From: "Don Sturek" <d.sturek@att.net>
To: "'JP Vasseur'" <jvasseur@cisco.com>
Cc: roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com
Date: 07/02/2009 03:12 PM
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance        from        theroot?




Hi JP,

Absolutely correct.  Number of hops is not *the* metric.  It just cannot be
completely ignored and in some cases (like the data link security example)
it does have a direct affect on latency.

Don


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, July 02, 2009 1:01 PM
To: d.sturek@att.net
Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org;
roll-bounces@ietf.org; gnawali@usc.edu
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from
theroot?

Hi Don,

I think that we are on the same page here: the number of hops should  
not be *the* only metric but *could* be a metric.

Agree ?

Thanks.

JP.

On Jul 2, 2009, at 9:51 PM, Don Sturek wrote:

> Hi Jonathan,
>
> I think the example Yusuf may be referring to involves data link level
> security where packets are encrypted/decrypted hop by hop (please  
> correct me
> if I am wrong).  In that scenario, it is good to minimize the number  
> of hops
> (within reason of course).  If that involves a few extra re-
> transmissions
> then you probably still end up with a more efficient packet delivery  
> from a
> latency point of view.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of
> Jonathan Hui
> Sent: Thursday, July 02, 2009 9:28 AM
> To: Yusuf.Bashir@jci.com
> Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu
> Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance  
> from
> theroot?
>
>
> On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote:
>>
>> Using low data rate 802.15.4 radios in commercial buildings we
>> design our deployments
>> to minimize hops and that has been an essential part of the success
>> of our networks. The result of
>> excessive hops is higher latency and higher probability of
>> collisions which leads to devices timing out and going
>> offline. This is an essential customer requirement for us.  We also
>> have data showing that when you do over the air downloads,
>> minimizing hops is key to meeting our timing requirements.
>
> But would you agree that minimizing the number of transmissions on a
> path is a better metric than hops in your case?
>
> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From alexandru.petrescu@gmail.com Thu Jul 2 13:36:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DB228C25C; Thu, 2 Jul 2009 13:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 tlINybWL06Ke; Thu, 2 Jul 2009 13:36:02 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 699AF3A6DE9; Thu, 2 Jul 2009 13:35:51 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id A5953D48113; Thu, 2 Jul 2009 22:35:49 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id DACD5D48154; Thu, 2 Jul 2009 22:35:45 +0200 (CEST) Message-ID: <4A4D1A1E.3000804@gmail.com> Date: Thu, 02 Jul 2009 22:35:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> In-Reply-To: <53800201-E0C1-4136-913A-499E46947E91@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090702-0, 02/07/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:36:03 -0000 JP - what is a metric? I consider the depth used by the DAG to be a metric - a hop count metric. When a node joins a DAG below a certain depth, it is using a metric: the number of hops between self and topmost node (LBR, DAG Root). As it stands now, the hopcount is _the_ metric of RPL. Alex JP Vasseur a crit : > Hi Don, > > I think that we are on the same page here: the number of hops should not > be *the* only metric but *could* be a metric. > > Agree ? > > Thanks. > > JP. > > On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > >> Hi Jonathan, >> >> I think the example Yusuf may be referring to involves data link level >> security where packets are encrypted/decrypted hop by hop (please >> correct me >> if I am wrong). In that scenario, it is good to minimize the number >> of hops >> (within reason of course). If that involves a few extra re-transmissions >> then you probably still end up with a more efficient packet delivery >> from a >> latency point of view. >> >> Don >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Jonathan Hui >> Sent: Thursday, July 02, 2009 9:28 AM >> To: Yusuf.Bashir@jci.com >> Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu >> Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from >> theroot? >> >> >> On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >>> >>> Using low data rate 802.15.4 radios in commercial buildings we >>> design our deployments >>> to minimize hops and that has been an essential part of the success >>> of our networks. The result of >>> excessive hops is higher latency and higher probability of >>> collisions which leads to devices timing out and going >>> offline. This is an essential customer requirement for us. We also >>> have data showing that when you do over the air downloads, >>> minimizing hops is key to meeting our timing requirements. >> >> But would you agree that minimizing the number of transmissions on a >> path is a better metric than hops in your case? >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Jerald.P.Martocci@jci.com Thu Jul 2 13:45:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E733A67B1; Thu, 2 Jul 2009 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfLcjALr5fcH; Thu, 2 Jul 2009 13:45:50 -0700 (PDT) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id C12D73A6B6A; Thu, 2 Jul 2009 13:45:00 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKSk0cYW2/eBiW98S/MLxYrBzQA47kpdpg@postini.com; Thu, 02 Jul 2009 13:45:24 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009070215452652-755974 ; Thu, 2 Jul 2009 15:45:26 -0500 In-Reply-To: <018301c9fb50$82558d10$8700a730$@sturek@att.net> MIME-Version: 1.0 To: d.sturek@att.net X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 2 Jul 2009 15:44:59 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/02/2009 03:45:14 PM, Serialize complete at 07/02/2009 03:45:14 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 03:45:26 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/02/2009 03:45:36 PM, Serialize complete at 07/02/2009 03:45:36 PM Content-Type: multipart/alternative; boundary="=_alternative 0071FF8F862575E7_=" Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:45:51 -0000 This is a multipart message in MIME format. --=_alternative 0071FF8F862575E7_= Content-Type: text/plain; charset="US-ASCII" I agree that hops may not be the do all and end all. Maybe overall transmissions (e.g. ETRX) is a better primitive metric. We'll work this out. However, it's also important that nodes can talk directly to other nodes within the LLN for fault tolerance purposes. We don't want to force communication up through the DAG when the destination is in the LLN; especially if the destination is within direct radio range as the source. Moving data up and back down the DAG only makes higher layer nodes more critical to system operation than others. So when some of us talk about reducing hops, it's not only to reduce latency but also to increase redundancy and fault tolerance of the overall LLN. Jerry "Don Sturek" Sent by: roll-bounces@ietf.org 07/02/2009 03:12 PM Please respond to d.sturek@att.net To "'JP Vasseur'" cc roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com Subject Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi JP, Absolutely correct. Number of hops is not *the* metric. It just cannot be completely ignored and in some cases (like the data link security example) it does have a direct affect on latency. Don -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, July 02, 2009 1:01 PM To: d.sturek@att.net Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, I think that we are on the same page here: the number of hops should not be *the* only metric but *could* be a metric. Agree ? Thanks. JP. On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please > correct me > if I am wrong). In that scenario, it is good to minimize the number > of hops > (within reason of course). If that involves a few extra re- > transmissions > then you probably still end up with a more efficient packet delivery > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0071FF8F862575E7_= Content-Type: text/html; charset="US-ASCII"
I agree that hops may not be the do all and end all.  Maybe overall transmissions (e.g. ETRX) is a better primitive metric.  We'll work this out.

However, it's also important that nodes can talk directly to other nodes within the LLN for fault tolerance purposes.  We don't want to force communication up through the DAG when the destination is in the LLN; especially if the destination is within direct radio range as the source.  Moving data up and back down the DAG only makes higher layer nodes more critical to system operation than others.

So when some of us talk about reducing hops, it's not only to reduce latency but also to increase redundancy and fault tolerance of the overall LLN.
Jerry




"Don Sturek" <d.sturek@att.net>
Sent by: roll-bounces@ietf.org

07/02/2009 03:12 PM
Please respond to
d.sturek@att.net
To
"'JP Vasseur'" <jvasseur@cisco.com>
cc
roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com
Subject
Re: [Roll] RPL: why not base a DAG on the min hop distance        from        theroot?





Hi JP,

Absolutely correct.  Number of hops is not *the* metric.  It just cannot be
completely ignored and in some cases (like the data link security example)
it does have a direct affect on latency.

Don


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, July 02, 2009 1:01 PM
To: d.sturek@att.net
Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org;
roll-bounces@ietf.org; gnawali@usc.edu
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from
theroot?

Hi Don,

I think that we are on the same page here: the number of hops should  
not be *the* only metric but *could* be a metric.

Agree ?

Thanks.

JP.

On Jul 2, 2009, at 9:51 PM, Don Sturek wrote:

> Hi Jonathan,
>
> I think the example Yusuf may be referring to involves data link level
> security where packets are encrypted/decrypted hop by hop (please  
> correct me
> if I am wrong).  In that scenario, it is good to minimize the number  
> of hops
> (within reason of course).  If that involves a few extra re-
> transmissions
> then you probably still end up with a more efficient packet delivery  
> from a
> latency point of view.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of
> Jonathan Hui
> Sent: Thursday, July 02, 2009 9:28 AM
> To: Yusuf.Bashir@jci.com
> Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu
> Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance  
> from
> theroot?
>
>
> On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote:
>>
>> Using low data rate 802.15.4 radios in commercial buildings we
>> design our deployments
>> to minimize hops and that has been an essential part of the success
>> of our networks. The result of
>> excessive hops is higher latency and higher probability of
>> collisions which leads to devices timing out and going
>> offline. This is an essential customer requirement for us.  We also
>> have data showing that when you do over the air downloads,
>> minimizing hops is key to meeting our timing requirements.
>
> But would you agree that minimizing the number of transmissions on a
> path is a better metric than hops in your case?
>
> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0071FF8F862575E7_=-- From jhui@archrock.com Thu Jul 2 14:14:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D673A6947 for ; Thu, 2 Jul 2009 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 h99o3atasa2a for ; Thu, 2 Jul 2009 14:14:30 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7732E3A68A2 for ; Thu, 2 Jul 2009 14:14:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AC936AF860; Thu, 2 Jul 2009 14:14:52 -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 8eUBFhLt2Lw9; Thu, 2 Jul 2009 14:14:48 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id D0AC2AF81C; Thu, 2 Jul 2009 14:14:47 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87tz1ux6q7.fsf@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 v935.3) Date: Thu, 2 Jul 2009 14:14:46 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:14:31 -0000 Hi Richard, On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: > Here is a suggestion: > > Leave the hop count as is, and add a DAGCost field. The > DAGCost field is a fixed-point value, say 16 bits of which 8 > bits are the fractional part. The units for the cost field > are hops, so a hop with a cost 0x0001 is equivalent to an > additional 1/256th of a 'best case' hop and 0x0100 is > equivalent to a complete additional 'best case' hop. The > actual path cost is > > (DAGDepth << 8) + DAGCost > > Loop avoidance and parent selection is done using the path > cost. In an outgoing DIO the DAGDepth MUST be larger than > the maximum parent DAGDepth and the DAGCost MUST be large > enough such that the path cost of the DIO is greater than > the maximum parent path cost. This is an interesting approach. It forces each node to aggregate whatever metrics they use into a single DAGCost metric and relate that to the DAGDepth in some way. Does it make sense to add another constraint that DAGCost has to be >= the parent's DAGCost? What I'm thinking about is the possible loss in information across multiple hops. In a completely contrived case, a node could advertise a path cost only 1 greater (by incrementing DAGDepth by 1 and decreasing DAGCost by 255) - then the meaning of a "hop" and relationship between DAGCost and DAGDepth gets lost. Or did you intend it to allow reductions in DAGCost so that they can optionally be summarized into DAGDepth along the way? But for now, the way you defined it, it is equivalent to having a single 16-bit integer that can be increased arbitrarily at every hop. If 0 <= DAGCost < 256, then you must increase by at least 256 - DAGCost. -- Jonathan Hui From jhui@archrock.com Thu Jul 2 14:21:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1EC3A6DD9; Thu, 2 Jul 2009 14:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 spesQ0CKnhOW; Thu, 2 Jul 2009 14:21: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 073203A68A2; Thu, 2 Jul 2009 14:21:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8FB52AF879; Thu, 2 Jul 2009 14:21:42 -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 Gtc60yyPbDZS; Thu, 2 Jul 2009 14:21:38 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 48AE8AF860; Thu, 2 Jul 2009 14:21:38 -0700 (PDT) Message-Id: From: Jonathan Hui To: In-Reply-To: <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 14:21:36 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:21:47 -0000 Agree with you and JP that hop count could be a metric. But lumping the cost of encryption/decryption into hop count doesn't seem like the right approach to me... Just for my information, what is the cost of encryption/decryption? I tend to view retransmissions as fairly costly operations in terms of energy and latency, so it help me to know the relative cost between different operations. -- Jonathan Hui On Jul 2, 2009, at 12:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please > correct me > if I am wrong). In that scenario, it is good to minimize the number > of hops > (within reason of course). If that involves a few extra re- > transmissions > then you probably still end up with a more efficient packet delivery > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu Jul 2 14:29:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532B928C1C6; Thu, 2 Jul 2009 14:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 7ySJCN93kNu9; Thu, 2 Jul 2009 14:29:26 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 3D5633A6B7C; Thu, 2 Jul 2009 14:28:43 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E22DDD4814D; Thu, 2 Jul 2009 23:29:00 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 1BC75D48179; Thu, 2 Jul 2009 23:28:57 +0200 (CEST) Message-ID: <4A4D2695.3030800@gmail.com> Date: Thu, 02 Jul 2009 23:28:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090702-0, 02/07/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:29:27 -0000 Jerald.P.Martocci@jci.com a crit : > > I agree that hops may not be the do all and end all. Maybe overall > transmissions (e.g. ETRX) is a better primitive metric. We'll work this > out. > > However, it's also important that nodes can talk directly to other nodes > within the LLN for fault tolerance purposes. We don't want to force > communication up through the DAG when the destination is in the LLN; > especially if the destination is within direct radio range as the > source. Moving data up and back down the DAG only makes higher layer > nodes more critical to system operation than others. I fully agree it's also important nodes to talk directly to each other, not necessarily up through the LBR (sink, DAG root). Alex > > So when some of us talk about reducing hops, it's not only to reduce > latency but also to increase redundancy and fault tolerance of the > overall LLN. > > Jerry > > > > > *"Don Sturek" * > Sent by: roll-bounces@ietf.org > > 07/02/2009 03:12 PM > Please respond to > d.sturek@att.net > > > > To > "'JP Vasseur'" > cc > roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, > Yusuf.Bashir@jci.com > Subject > Re: [Roll] RPL: why not base a DAG on the min hop distance from > theroot? > > > > > > > > > Hi JP, > > Absolutely correct. Number of hops is not *the* metric. It just cannot be > completely ignored and in some cases (like the data link security example) > it does have a direct affect on latency. > > Don > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, July 02, 2009 1:01 PM > To: d.sturek@att.net > Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org; > roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from > theroot? > > Hi Don, > > I think that we are on the same page here: the number of hops should > not be *the* only metric but *could* be a metric. > > Agree ? > > Thanks. > > JP. > > On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > > > Hi Jonathan, > > > > I think the example Yusuf may be referring to involves data link level > > security where packets are encrypted/decrypted hop by hop (please > > correct me > > if I am wrong). In that scenario, it is good to minimize the number > > of hops > > (within reason of course). If that involves a few extra re- > > transmissions > > then you probably still end up with a more efficient packet delivery > > from a > > latency point of view. > > > > Don > > > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of > > Jonathan Hui > > Sent: Thursday, July 02, 2009 9:28 AM > > To: Yusuf.Bashir@jci.com > > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > > from > > theroot? > > > > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: > >> > >> Using low data rate 802.15.4 radios in commercial buildings we > >> design our deployments > >> to minimize hops and that has been an essential part of the success > >> of our networks. The result of > >> excessive hops is higher latency and higher probability of > >> collisions which leads to devices timing out and going > >> offline. This is an essential customer requirement for us. We also > >> have data showing that when you do over the air downloads, > >> minimizing hops is key to meeting our timing requirements. > > > > But would you agree that minimizing the number of transmissions on a > > path is a better metric than hops in your case? > > > > -- > > Jonathan Hui > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Jul 2 14:44:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009AF3A6BAB for ; Thu, 2 Jul 2009 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fXojfSW0cui for ; Thu, 2 Jul 2009 14:44:18 -0700 (PDT) Received: from smtp101.sbc.mail.gq1.yahoo.com (smtp101.sbc.mail.gq1.yahoo.com [67.195.15.60]) by core3.amsl.com (Postfix) with SMTP id ECE433A6951 for ; Thu, 2 Jul 2009 14:43:48 -0700 (PDT) Received: (qmail 34172 invoked from network); 2 Jul 2009 21:37:32 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 2 Jul 2009 21:37:31 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: k9WgFsgVM1nMJV6XHxgQReL_UG5nBJ3qbQ6Kisxdmgo59MfmpVlht9x5TwG8Za85VwxtJv7gEEnFzaP5SSQJljj9n46OEdSXXTmCjbCVSQXCa.sD9HHmDdpf9xq67v9bTpwYModqEfewUPbWUmBEPlEz6ZwKcrjWnw_uEqhzoOvbwwU1PJVSsyje6F_39Z3CsHEoLFsADb8RAHJ7l4zmD.YV4MImsqvEW5YeuVuy.SsVFICyE8zyKvTin64PwLaw0_dditXUcFJU9Ggl475AEgmrO8eAk0BESSp_uusNXTNcm08- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> In-Reply-To: Date: Thu, 2 Jul 2009 14:37:27 -0700 Message-ID: <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7WxiYivlGEE0sTpKQrxbdCgkWKgAAKKlg Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:44:19 -0000 Hi Jonathan, I did not mean to lump encryption/decryption with the hop count discussion for routing metrics, only cite it as an example where hop count matters. Clearly the encryption/decryption cited in the example is a layer 2 issue. For our application, when we use data link security and encrypt/decrypt per hop, we use AES-128 encryption/decryption for each neighbor transmission (this was using IEEE 802.15.4-2003 with data link security applied above the MAC). I think if you turn on IEEE 802.15.4-2006 MAC security you get the same hop by hop encryption/decryption (maybe someone can correct me if I am wrong on this). I believe the encrypt/decrypt operation per hop is on the order of 10s of milliseconds (which is why this makes hop count relevant). As noted in several places, hop count is not the only consideration as a routing metric. I just wanted to point out (and I think others with experience using data link security like this as well) that hop count does matter in some routing situations. Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Thursday, July 02, 2009 2:22 PM To: d.sturek@att.net Cc: Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Agree with you and JP that hop count could be a metric. But lumping the cost of encryption/decryption into hop count doesn't seem like the right approach to me... Just for my information, what is the cost of encryption/decryption? I tend to view retransmissions as fairly costly operations in terms of energy and latency, so it help me to know the relative cost between different operations. -- Jonathan Hui On Jul 2, 2009, at 12:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please > correct me > if I am wrong). In that scenario, it is good to minimize the number > of hops > (within reason of course). If that involves a few extra re- > transmissions > then you probably still end up with a more efficient packet delivery > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jhui@archrock.com Thu Jul 2 14:44:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C089B3A67B1; Thu, 2 Jul 2009 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 EJ0x+k4xF5ne; Thu, 2 Jul 2009 14:44: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 C91703A6B6C; Thu, 2 Jul 2009 14:44:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AE8C0AF882; Thu, 2 Jul 2009 14:44:39 -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 ZwYEiXhA4F8Z; Thu, 2 Jul 2009 14:44:35 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id C346BAF860; Thu, 2 Jul 2009 14:44:34 -0700 (PDT) Message-Id: From: Jonathan Hui To: In-Reply-To: <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 14:44:33 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:44:19 -0000 Hi Don, On Jul 2, 2009, at 2:37 PM, Don Sturek wrote: > For our application, when we use data link security and encrypt/ > decrypt per > hop, we use AES-128 encryption/decryption for each neighbor > transmission > (this was using IEEE 802.15.4-2003 with data link security applied > above the > MAC). I think if you turn on IEEE 802.15.4-2006 MAC security you > get the > same hop by hop encryption/decryption (maybe someone can correct me > if I am > wrong on this). I believe the encrypt/decrypt operation per hop is > on the > order of 10s of milliseconds (which is why this makes hop count > relevant). Is this assuming a software implementation of security? 10s of milliseconds is quite a lot. Utilizing hardware encryption engines built into many 802.15.4 radios/SoCs we typically achieve encryption/ decryption times better than a few hundred microseconds. Or is there something else I am missing? > As noted in several places, hop count is not the only consideration > as a > routing metric. I just wanted to point out (and I think others with > experience using data link security like this as well) that hop > count does > matter in some routing situations. Agree. -- Jonathan Hui From d.sturek@att.net Thu Jul 2 14:49:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E013A6B62 for ; Thu, 2 Jul 2009 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QIyNNXL0vmR for ; Thu, 2 Jul 2009 14:49:49 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id C23733A6915 for ; Thu, 2 Jul 2009 14:49:49 -0700 (PDT) Received: (qmail 10042 invoked from network); 2 Jul 2009 21:50:09 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2009 21:50:09 -0000 X-YMail-OSG: byU45VoVM1lwpqfz2keKwNFYKxVkukpMf9qqqGIwmyOhC7.vxo5fG0RBUer5tpvun5BhxGyKswrLCp3QE89T7D_1OJgkd1yHAKuhcseiQotvivS69HHHeg9so5ujVs5nqawwHnTPKf8AjuO52VckcuM6JR53MVgMeNb.DJIAcQyKp.EQk5JoO7RsvJaC7MroZ7mFjvtIT.CEQjP5pPUkQv2o_enUWYWGyWwz5tZbL8jDiMPejv8jxkYz2QEbnaGI4ob_1I4CK1hkPMRO1h5ZY479HmPe5djiGBre38WTsKkgXCc- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> In-Reply-To: Date: Thu, 2 Jul 2009 14:50:06 -0700 Message-ID: <01b401c9fb5f$1022f0c0$3068d240$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7Xk1ZnRzc+I52R0KOkY/TbkttaQAAHxBA Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:49:50 -0000 Hi Jonathan, We actually saw such long latencies (10s of milliseconds) even for AES-128 engines built in hardware. It was actually quite surprising. We even measured with multiple vendors just to see if we might be dealing with an implementation issue. Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Thursday, July 02, 2009 2:45 PM To: d.sturek@att.net Cc: Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, On Jul 2, 2009, at 2:37 PM, Don Sturek wrote: > For our application, when we use data link security and encrypt/ > decrypt per > hop, we use AES-128 encryption/decryption for each neighbor > transmission > (this was using IEEE 802.15.4-2003 with data link security applied > above the > MAC). I think if you turn on IEEE 802.15.4-2006 MAC security you > get the > same hop by hop encryption/decryption (maybe someone can correct me > if I am > wrong on this). I believe the encrypt/decrypt operation per hop is > on the > order of 10s of milliseconds (which is why this makes hop count > relevant). Is this assuming a software implementation of security? 10s of milliseconds is quite a lot. Utilizing hardware encryption engines built into many 802.15.4 radios/SoCs we typically achieve encryption/ decryption times better than a few hundred microseconds. Or is there something else I am missing? > As noted in several places, hop count is not the only consideration > as a > routing metric. I just wanted to point out (and I think others with > experience using data link security like this as well) that hop > count does > matter in some routing situations. Agree. -- Jonathan Hui From jhui@archrock.com Thu Jul 2 14:55:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800933A6A8C; Thu, 2 Jul 2009 14:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 whV0BFP30eaE; Thu, 2 Jul 2009 14:55:52 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 700823A68ED; Thu, 2 Jul 2009 14:54:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8A7E8AF879; Thu, 2 Jul 2009 14:55:22 -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 XVn4odwBcOT0; Thu, 2 Jul 2009 14:55:17 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id A6824AF860; Thu, 2 Jul 2009 14:55:17 -0700 (PDT) Message-Id: <1D6AFA74-DD95-4B28-BD8F-A5A136ECD6F4@archrock.com> From: Jonathan Hui To: In-Reply-To: <01b401c9fb5f$1022f0c0$3068d240$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 14:55:16 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> <01b401c9fb5f$1022f0c0$3068d240$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:55:53 -0000 On Jul 2, 2009, at 2:50 PM, Don Sturek wrote: > We actually saw such long latencies (10s of milliseconds) even for > AES-128 > engines built in hardware. It was actually quite surprising. We even > measured with multiple vendors just to see if we might be dealing > with an > implementation issue. That's certainly interesting to me. Care to share which ones? :-) The CC2420 datasheet claims 222us with I(a) = 50, I(m) = 69, and I(MIC) = 8. Even if you took the worst-case values for each, you wouldn't get anywhere near 10s of milliseconds. Our implementation does not show any discrepancy with the quoted timing numbers. -- Jonathan Hui From d.sturek@att.net Thu Jul 2 14:56:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9103F3A69F3 for ; Thu, 2 Jul 2009 14:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSCV08DvFlrn for ; Thu, 2 Jul 2009 14:56:24 -0700 (PDT) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 989813A68ED for ; Thu, 2 Jul 2009 14:56:24 -0700 (PDT) Received: from [68.142.194.244] by n15.bullet.mail.mud.yahoo.com with NNFMP; 02 Jul 2009 21:56:46 -0000 Received: from [68.142.201.64] by t2.bullet.mud.yahoo.com with NNFMP; 02 Jul 2009 21:56:45 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 02 Jul 2009 21:56:45 -0000 X-Yahoo-Newman-Id: 932345.9028.bm@omp416.mail.mud.yahoo.com Received: (qmail 28658 invoked from network); 2 Jul 2009 21:56:45 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2009 21:56:45 -0000 X-YMail-OSG: q25w4bMVM1k8YfXJlSxAEYnimMSoGM7uq082I268Ivq1yW64j8n0mBjRLZ_5smCuyFewfKkl7W7Ea15x35NM90SlIIoLik8aanfg.XmyWukKzNOi7QhBgMzmDadU3z9PhQpihJiX.tKkGDFTPl9_kY8fDIfGz9Me0c4PqlTuoHGOwuLzQ1ZYllVf_K6jw3JAeoTxRe52LCx4VT7yZWKeC2FBVTzmzipNh9Nc6E2qW3yeO1P6N1II4A5anRjztXGJ48RfGU6REN_E4E1uwcLnYiPLCaAZFOwpzexArlrYRp8wIws- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> In-Reply-To: Date: Thu, 2 Jul 2009 14:56:41 -0700 Message-ID: <01b701c9fb5f$fbfe9440$f3fbbcc0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7Xk1ZnRzc+I52R0KOkY/TbkttaQAAHxBAAAAmMKA= Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:56:25 -0000 By the way, for the numbers I was citing, here was the processing: 1) Receive message from your neighbor, decrypt (AES-128 with 32 bit MIC) 2) Perform network layer processing on the packet, determine next neighbor to send it to 3) Encrypt message for transmission to next neighbor (AES-128 with 32 bit MIC). In our case, there was a need in performing the above processing at each hop (including validating the MIC from your upstream neighbor and creating a new MIC for your downstream neighbor). Don -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, July 02, 2009 2:50 PM To: 'Jonathan Hui' Cc: 'Yusuf.Bashir@jci.com'; 'roll@ietf.org'; 'roll-bounces@ietf.org'; 'gnawali@usc.edu' Subject: RE: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Jonathan, We actually saw such long latencies (10s of milliseconds) even for AES-128 engines built in hardware. It was actually quite surprising. We even measured with multiple vendors just to see if we might be dealing with an implementation issue. Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Thursday, July 02, 2009 2:45 PM To: d.sturek@att.net Cc: Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, On Jul 2, 2009, at 2:37 PM, Don Sturek wrote: > For our application, when we use data link security and encrypt/ > decrypt per > hop, we use AES-128 encryption/decryption for each neighbor > transmission > (this was using IEEE 802.15.4-2003 with data link security applied > above the > MAC). I think if you turn on IEEE 802.15.4-2006 MAC security you > get the > same hop by hop encryption/decryption (maybe someone can correct me > if I am > wrong on this). I believe the encrypt/decrypt operation per hop is > on the > order of 10s of milliseconds (which is why this makes hop count > relevant). Is this assuming a software implementation of security? 10s of milliseconds is quite a lot. Utilizing hardware encryption engines built into many 802.15.4 radios/SoCs we typically achieve encryption/ decryption times better than a few hundred microseconds. Or is there something else I am missing? > As noted in several places, hop count is not the only consideration > as a > routing metric. I just wanted to point out (and I think others with > experience using data link security like this as well) that hop > count does > matter in some routing situations. Agree. -- Jonathan Hui From jhui@archrock.com Thu Jul 2 15:03:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B093D3A68CD; Thu, 2 Jul 2009 15:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Shoeia46Pztf; Thu, 2 Jul 2009 15:03:39 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E6CD93A68AE; Thu, 2 Jul 2009 15:03:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F03A4AF860; Thu, 2 Jul 2009 15:04:02 -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 g6nLuuhAcb5s; Thu, 2 Jul 2009 15:03:58 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 1CABCAF81C; Thu, 2 Jul 2009 15:03:58 -0700 (PDT) Message-Id: From: Jonathan Hui To: In-Reply-To: <01b701c9fb5f$fbfe9440$f3fbbcc0$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 15:03:54 -0700 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> <01b701c9fb5f$fbfe9440$f3fbbcc0$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:03:40 -0000 Hi Don, On Jul 2, 2009, at 2:56 PM, Don Sturek wrote: > By the way, for the numbers I was citing, here was the processing: > 1) Receive message from your neighbor, decrypt (AES-128 with 32 bit > MIC) > 2) Perform network layer processing on the packet, determine next > neighbor > to send it to > 3) Encrypt message for transmission to next neighbor (AES-128 with > 32 bit > MIC). > > In our case, there was a need in performing the above processing at > each hop > (including validating the MIC from your upstream neighbor and > creating a new > MIC for your downstream neighbor). Have you profiled the relative cost of 1, 2, and 3? From my experience, I'd guess the vast majority of your time is spent in 2. If that is the case, then minimizing hops doesn't do much if you want to allow for next-hop lookups for each (re)transmission. There seems to be consensus within this working group that allowing next-hop lookups when performing retransmissions (at least a subset of them) is a useful thing. -- Jonathan Hui From prvs=4276677de=mukul@uwm.edu Thu Jul 2 15:11:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2723D3A6951 for ; Thu, 2 Jul 2009 15:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 jKHXIe9TpP22 for ; Thu, 2 Jul 2009 15:11:00 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 25B5D3A68CD for ; Thu, 2 Jul 2009 15:11:00 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 02 Jul 2009 17:11:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id AC2FDB20012; Thu, 2 Jul 2009 17:11:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umvPl0zjvV-R; Thu, 2 Jul 2009 17:11:22 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 3D318B2000D; Thu, 2 Jul 2009 17:11:22 -0500 (CDT) Date: Thu, 2 Jul 2009 17:11:22 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <635956747.17975961246572682130.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:11:01 -0000 Richard Could you please explain your suggestion. It seems like you would want the actual routing metrics to be used in loop avoidance and are proposing mapping the routing metrics to a DAGCost variable (in units of hops). The sum of DAGCost and DAGDepth will be used to select parents as well as to avoid loops. Is this understanding correct? Why not do away with DAGDepth totally? It is sort of meaningless any way. Just have DAGCost that is a function of routing metrics and is used for parent selection as well as loop avoidance. All the nodes would have to enforce the same mapping function between the routing metrics and the DAGCost. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: "Jonathan Hui" Cc: roll@ietf.org Sent: Thursday, July 2, 2009 1:47:12 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? Jonathan, From: Jonathan Hui Date: Thu, 2 Jul 2009 10:56:06 -0700 Things get a bit more tricky when dealing with multiple metrics simultaneously. With multiple metrics, nothing changes as long as the comparator function between two metric vectors is a strictly monotonic function. If that strictly monotonic function does not exist (i.e. the metrics are completely orthogonal), then things get a bit more difficult. One possible solution is that we require one or more of the path metrics to be strictly monotonic and the rule becomes: a node cannot go "deeper" in any of the monotonic metrics. This seems a bit over-constrained, so we were discussing whether we can relax this constraint and this is still work in progress. Here is a suggestion: Leave the hop count as is, and add a DAGCost field. The DAGCost field is a fixed-point value, say 16 bits of which 8 bits are the fractional part. The units for the cost field are hops, so a hop with a cost 0x0001 is equivalent to an additional 1/256th of a 'best case' hop and 0x0100 is equivalent to a complete additional 'best case' hop. The actual path cost is (DAGDepth << 8) + DAGCost Loop avoidance and parent selection is done using the path cost. In an outgoing DIO the DAGDepth MUST be larger than the maximum parent DAGDepth and the DAGCost MUST be large enough such that the path cost of the DIO is greater than the maximum parent path cost. Increasing the DAGCost is optional. If no node does so the result is the same as the current algorithm. Nodes are free to include metric containers with additional information. If a node makes use of multiple metrics the additional costs for one hop need not be additive. For example, if a link is both slow and energy intensive, the link cost could be the average of the two, instead of their sum. What do you think? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Jul 2 15:18:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DAE3A6B29 for ; Thu, 2 Jul 2009 15:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jDqq90Kbflq for ; Thu, 2 Jul 2009 15:18:13 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 0CF1D3A6B0E for ; Thu, 2 Jul 2009 15:18:13 -0700 (PDT) Received: (qmail 53851 invoked from network); 2 Jul 2009 22:11:56 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.226.148.222 with login) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2009 22:11:56 -0000 X-YMail-OSG: .l0g6GUVM1khYStk44STcDHYh.ffS68XYjSp.Tf_P6syH.RSzr_aCw4RF.xsGZnHbgGWWq24K8tJU395J0rLbRNpWJL0befdLcyCI1.ENvkcwb184WtLkjWRZk1VOvurg_vObOlj9YmgQVt8wre05xBdfoKkz3rYToKYnn8idQlXSWsCjvMEG9qlkQrn3AVHZLtam6_SYNneOjbYv9O52V7TyzIfBmMTQdRWJw6Nayv9GGAIUJgGu4u0dDZYCwJ9XgDo1.YcQ2Ve7bBl.kvlogXqqW20ToZnagOEzfBNNTMuaU0- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <01a801c9fb5d$4c4720f0$e4d562d0$@sturek@att.net> <01b701c9fb5f$fbfe9440$f3fbbcc0$@sturek@att.net> In-Reply-To: Date: Thu, 2 Jul 2009 15:11:52 -0700 Message-ID: <01c401c9fb62$1aefcde0$50cf69a0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acn7YQMmBLA4KuERTIGua7x5Yi64HgAAKB/Q Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:18:13 -0000 Hi Jonathan, For the next generation Smart Metering application it would be nice to use some network layer security which can be deployed over IEEE 802.15.4-2006 and allowed us to turn off data link layer security. I think the hop count issue may go away if we had such a solution (back to your original DT assumptions then.....) Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Thursday, July 02, 2009 3:04 PM To: d.sturek@att.net Cc: Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, On Jul 2, 2009, at 2:56 PM, Don Sturek wrote: > By the way, for the numbers I was citing, here was the processing: > 1) Receive message from your neighbor, decrypt (AES-128 with 32 bit > MIC) > 2) Perform network layer processing on the packet, determine next > neighbor > to send it to > 3) Encrypt message for transmission to next neighbor (AES-128 with > 32 bit > MIC). > > In our case, there was a need in performing the above processing at > each hop > (including validating the MIC from your upstream neighbor and > creating a new > MIC for your downstream neighbor). Have you profiled the relative cost of 1, 2, and 3? From my experience, I'd guess the vast majority of your time is spent in 2. If that is the case, then minimizing hops doesn't do much if you want to allow for next-hop lookups for each (re)transmission. There seems to be consensus within this working group that allowing next-hop lookups when performing retransmissions (at least a subset of them) is a useful thing. -- Jonathan Hui From pal@cs.stanford.edu Thu Jul 2 15:24:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDCC3A6B0E; Thu, 2 Jul 2009 15:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw+ezeKNaaWy; Thu, 2 Jul 2009 15:24:12 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C54923A6B0F; Thu, 2 Jul 2009 15:23:46 -0700 (PDT) Received: from dnab404671.stanford.edu ([171.64.70.113]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MMUhM-00015S-U2; Thu, 02 Jul 2009 15:24:09 -0700 Message-Id: <1B6B3B6C-056B-4538-9DAB-BAC301E929B2@cs.stanford.edu> From: Philip Levis To: Mukul Goyal In-Reply-To: <638675580.17844541246554833439.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 15:24:08 -0700 References: <638675580.17844541246554833439.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Cc: roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf Bashir Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:24:12 -0000 On Jul 2, 2009, at 10:13 AM, Mukul Goyal wrote: > Jonathan > > Whether an application uses minimum hop routes or ETX or some other > (combination of) metric(s) to determine routes should be left to the > application itself. > > Now lets talk about the shortcomings of ETX as a routing metric. > > ETX is not a panacea. Number of transmissions allowed by a MAC > protocol before it gives up the packet is a configurable parameter > in many protocols. I can configure some 802.15.4 nodes to give up a > packet after 1 try and some others to give up after 5 tries. So, if > path A has ETX 40 and path B has ETX 50, I can't really say that > path A is better because it is possible that ETX for path A is low > because nodes on path A don't allow as many transmissions per packet > as nodes on path B. > > ETX paper defines ETX as "the predicted number of data transmissions > required to send a packet over that link". I am not sure how ETX > would be calculated when limits exist on the number of packet > transmissions before MAC layer gives it up. But, unless ETX is > calculated in a manner to account for such limits, it seems to me > that ETX across links are diffficult to compare when these links > have different limits on the number of retries. So, as individual > hops are incomparable with each other (as some on the list have > suggested), it may be that individual ETX values are also > incomparable. > > Moreover, ETX seems to be ignoring the "channel access > failures" (borrowing 15.4 terminology). A link may be so bad that > very few transmissions take place. Not sure how ETX accounts for > channel access failures. A path may have low ETX because of the high > channel access failure rates along the links on the path. > > I think this discussion is not moving in the way I wanted it to be. > The original question was why is it better to have parents with > multiple depths. It seemed to me that we can have all the > flexibility of DAGs while preserving the meaning of the term > "depth", which has been lost the way RPL works. I will explain the > question in a separate email. All of these things are true -- ETX is not a panacea. There are other metrics which address some problems but not others. For example, one could measure latency and use that as a metric (taking into consideration channel access failures), but this doesn't tell you how much spectrum space-time a path might take. Nor does ETX address the situation when a radio has multiple bitrates. The tradeoffs between metrics are why there's such a discussion around them. Different applications might have different needs, and so use different metrics. That being said, a simple, concrete case where you want to be able to send to nodes at different hopcounts is this routing table at the edge of a sparse network: Dest | Hops | Cost ------------------- A | 4 | 5.6 (active route) B | 5 | 6.3 Now let us suppose the link to node A dies. The options are: 1) Send to node B 2) Drop all packets I'd prefer 1) over 2). Note that if the link to node A is bursty, it might come and go fairly quickly. Phil From prvs=4276677de=mukul@uwm.edu Thu Jul 2 15:24:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2F23A6951; Thu, 2 Jul 2009 15:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 VIWBJP18-b6R; Thu, 2 Jul 2009 15:24:50 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id D7D243A6B0E; Thu, 2 Jul 2009 15:24:49 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 02 Jul 2009 17:25:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 94F3EB20005; Thu, 2 Jul 2009 17:25:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g70U4QFoiQxv; Thu, 2 Jul 2009 17:25:12 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 555DDB20002; Thu, 2 Jul 2009 17:25:12 -0500 (CDT) Date: Thu, 2 Jul 2009 17:25:12 -0500 (CDT) From: Mukul Goyal To: Jerald P Martocci Message-ID: <835311851.17978441246573512245.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf Bashir , gnawali@usc.edu Subject: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:24:51 -0000 Jerry has raised a very important question. RPL supports only tree-based ro= uting. Do we need a _plugin_ to support P2P routing? Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "d sturek" Cc: roll@ietf.org, roll-bounces@ietf.org, "Yusuf Bashir" , gnawali@usc.edu Sent: Thursday, July 2, 2009 3:44:59 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance=09from= =09theroot? I agree that hops may not be the do all and end all. =C2=A0Maybe overall tr= ansmissions (e.g. ETRX) is a better primitive metric. =C2=A0We'll work this= out.=20 However, it's also important that nodes can talk directly to other nodes wi= thin the LLN for fault tolerance purposes. =C2=A0We don't want to force com= munication up through the DAG when the destination is in the LLN; especiall= y if the destination is within direct radio range as the source. =C2=A0Movi= ng data up and back down the DAG only makes higher layer nodes more critica= l to system operation than others.=20 So when some of us talk about reducing hops, it's not only to reduce latenc= y but also to increase redundancy and fault tolerance of the overall LLN.= =20 Jerry=20 "Don Sturek" =20 Sent by: roll-bounces@ietf.org=20 07/02/2009 03:12 PM=20 Please respond to=20 d.sturek@att.net=20 =09 To =09"'JP Vasseur'" =20 cc =09roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@j= ci.com=20 Subject =09Re: [Roll] RPL: why not base a DAG on the min hop distance =C2= =A0 =C2=A0 =C2=A0 =C2=A0from =C2=A0 =C2=A0 =C2=A0 =C2=A0theroot?=20 =09 Hi JP,=20 Absolutely correct. =C2=A0Number of hops is not *the* metric. =C2=A0It just= cannot be=20 completely ignored and in some cases (like the data link security example)= =20 it does have a direct affect on latency.=20 Don=20 -----Original Message-----=20 From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, July 02, 2009 1:01 PM=20 To: d.sturek@att.net=20 Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org;=20 roll-bounces@ietf.org; gnawali@usc.edu=20 Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from=20 theroot?=20 Hi Don,=20 I think that we are on the same page here: the number of hops should =C2=A0= =20 not be *the* only metric but *could* be a metric.=20 Agree ?=20 Thanks.=20 JP.=20 On Jul 2, 2009, at 9:51 PM, Don Sturek wrote:=20 > Hi Jonathan,=20 >=20 > I think the example Yusuf may be referring to involves data link level=20 > security where packets are encrypted/decrypted hop by hop (please =C2=A0= =20 > correct me=20 > if I am wrong). =C2=A0In that scenario, it is good to minimize the number= =C2=A0=20 > of hops=20 > (within reason of course). =C2=A0If that involves a few extra re-=20 > transmissions=20 > then you probably still end up with a more efficient packet delivery =C2= =A0=20 > from a=20 > latency point of view.=20 >=20 > Don=20 >=20 >=20 > -----Original Message-----=20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =C2= =A0=20 > Of=20 > Jonathan Hui=20 > Sent: Thursday, July 02, 2009 9:28 AM=20 > To: Yusuf.Bashir@jci.com=20 > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu=20 > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance =C2= =A0=20 > from=20 > theroot?=20 >=20 >=20 > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote:=20 >>=20 >> Using low data rate 802.15.4 radios in commercial buildings we=20 >> design our deployments=20 >> to minimize hops and that has been an essential part of the success=20 >> of our networks. The result of=20 >> excessive hops is higher latency and higher probability of=20 >> collisions which leads to devices timing out and going=20 >> offline. This is an essential customer requirement for us. =C2=A0We also= =20 >> have data showing that when you do over the air downloads,=20 >> minimizing hops is key to meeting our timing requirements.=20 >=20 > But would you agree that minimizing the number of transmissions on a=20 > path is a better metric than hops in your case?=20 >=20 > --=20 > Jonathan Hui=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4276677de=mukul@uwm.edu Thu Jul 2 15:32:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D483A6AB2 for ; Thu, 2 Jul 2009 15:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 rQuJ3WBocKga for ; Thu, 2 Jul 2009 15:32:04 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 3EB853A6B0F for ; Thu, 2 Jul 2009 15:32:04 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 02 Jul 2009 17:32:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id F215FB20005; Thu, 2 Jul 2009 17:32:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXnAC3EBAgs5; Thu, 2 Jul 2009 17:32:26 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id BD016B20002; Thu, 2 Jul 2009 17:32:26 -0500 (CDT) Date: Thu, 2 Jul 2009 17:32:26 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1953250816.17979501246573946718.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1B6B3B6C-056B-4538-9DAB-BAC301E929B2@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:32:05 -0000 Thanks Phil. Your example does make sense. Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "Jonathan Hui" , roll@ietf.org, roll-bounces@ietf.org, "Yusuf Bashir" , gnawali@usc.edu Sent: Thursday, July 2, 2009 5:24:08 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? On Jul 2, 2009, at 10:13 AM, Mukul Goyal wrote: > Jonathan > > Whether an application uses minimum hop routes or ETX or some other > (combination of) metric(s) to determine routes should be left to the > application itself. > > Now lets talk about the shortcomings of ETX as a routing metric. > > ETX is not a panacea. Number of transmissions allowed by a MAC > protocol before it gives up the packet is a configurable parameter > in many protocols. I can configure some 802.15.4 nodes to give up a > packet after 1 try and some others to give up after 5 tries. So, if > path A has ETX 40 and path B has ETX 50, I can't really say that > path A is better because it is possible that ETX for path A is low > because nodes on path A don't allow as many transmissions per packet > as nodes on path B. > > ETX paper defines ETX as "the predicted number of data transmissions > required to send a packet over that link". I am not sure how ETX > would be calculated when limits exist on the number of packet > transmissions before MAC layer gives it up. But, unless ETX is > calculated in a manner to account for such limits, it seems to me > that ETX across links are diffficult to compare when these links > have different limits on the number of retries. So, as individual > hops are incomparable with each other (as some on the list have > suggested), it may be that individual ETX values are also > incomparable. > > Moreover, ETX seems to be ignoring the "channel access > failures" (borrowing 15.4 terminology). A link may be so bad that > very few transmissions take place. Not sure how ETX accounts for > channel access failures. A path may have low ETX because of the high > channel access failure rates along the links on the path. > > I think this discussion is not moving in the way I wanted it to be. > The original question was why is it better to have parents with > multiple depths. It seemed to me that we can have all the > flexibility of DAGs while preserving the meaning of the term > "depth", which has been lost the way RPL works. I will explain the > question in a separate email. All of these things are true -- ETX is not a panacea. There are other metrics which address some problems but not others. For example, one could measure latency and use that as a metric (taking into consideration channel access failures), but this doesn't tell you how much spectrum space-time a path might take. Nor does ETX address the situation when a radio has multiple bitrates. The tradeoffs between metrics are why there's such a discussion around them. Different applications might have different needs, and so use different metrics. That being said, a simple, concrete case where you want to be able to send to nodes at different hopcounts is this routing table at the edge of a sparse network: Dest | Hops | Cost ------------------- A | 4 | 5.6 (active route) B | 5 | 6.3 Now let us suppose the link to node A dies. The options are: 1) Send to node B 2) Drop all packets I'd prefer 1) over 2). Note that if the link to node A is bursty, it might come and go fairly quickly. Phil From richard.kelsey@ember.com Thu Jul 2 15:42:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C193A6B0F for ; Thu, 2 Jul 2009 15:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 t8rjlDPNnRf8 for ; Thu, 2 Jul 2009 15:42:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 825B43A6AB2 for ; Thu, 2 Jul 2009 15:42:41 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 18:43:02 -0400 Date: Thu, 02 Jul 2009 18:43:27 -0400 Message-Id: <87ws6qvh80.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Thu, 2 Jul 2009 14:14:46 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 02 Jul 2009 22:43:02.0693 (UTC) FILETIME=[751E5D50:01C9FB66] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:42:42 -0000 From: Jonathan Hui Date: Thu, 2 Jul 2009 14:14:46 -0700 Jonathan, On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: > Here is a suggestion: > > Leave the hop count as is, and add a DAGCost field. The > DAGCost field is a fixed-point value, say 16 bits of which 8 > bits are the fractional part. The units for the cost field > are hops, so a hop with a cost 0x0001 is equivalent to an > additional 1/256th of a 'best case' hop and 0x0100 is > equivalent to a complete additional 'best case' hop. The > actual path cost is > > (DAGDepth << 8) + DAGCost > > Loop avoidance and parent selection is done using the path > cost. In an outgoing DIO the DAGDepth MUST be larger than > the maximum parent DAGDepth and the DAGCost MUST be large > enough such that the path cost of the DIO is greater than > the maximum parent path cost. This is an interesting approach. It forces each node to aggregate whatever metrics they use into a single DAGCost metric and relate that to the DAGDepth in some way. Does it make sense to add another constraint that DAGCost has to be >= the parent's DAGCost? With a single parent this would be the way to go. I am unsure how to handle multiple parents if there is a large variance in the split between DAGDepth and DAGCost. What if there are two parents, one with a DAGDepth of 1 and a DAGCost of 3 and the other with a DAGDepth of 3 and a DAGCost of 1? The child's DAGDepth has to be 4 and the DAGCost must be at least 1, but should it be higher? A related problem raised by the current draft is what should be done if there are multiple parents with different metric containers. How should the metric values from different parents be combined? What I'm thinking about is the possible loss in information across multiple hops. In a completely contrived case, a node could advertise a path cost only 1 greater (by incrementing DAGDepth by 1 and decreasing DAGCost by 255) - then the meaning of a "hop" and relationship between DAGCost and DAGDepth gets lost. Or did you intend it to allow reductions in DAGCost so that they can optionally be summarized into DAGDepth along the way? My intent was the outgoing DAGCost should be no smaller than the incoming one. But can you take the DAGDepth from one parent and the DAGCost from another? -Richard Kelsey From richard.kelsey@ember.com Thu Jul 2 16:11:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A5F3A6C13 for ; Thu, 2 Jul 2009 16:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 PH+sWsbXJ6sq for ; Thu, 2 Jul 2009 16:11:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id C47993A6B60 for ; Thu, 2 Jul 2009 16:08:55 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 19:09:16 -0400 Date: Thu, 02 Jul 2009 19:09:41 -0400 Message-Id: <87vdmavg0a.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <635956747.17975961246572682130.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Thu, 2 Jul 2009 17:11:22 -0500 (CDT)) From: Richard Kelsey References: <635956747.17975961246572682130.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 02 Jul 2009 23:09:16.0818 (UTC) FILETIME=[1F5EC720:01C9FB6A] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 23:11:28 -0000 Mukul, Date: Thu, 2 Jul 2009 17:11:22 -0500 (CDT) From: Mukul Goyal Could you please explain your suggestion. It seems like you would want the actual routing metrics to be used in loop avoidance and are proposing mapping the routing metrics to a DAGCost variable (in units of hops). The sum of DAGCost and DAGDepth will be used to select parents as well as to avoid loops. Is this understanding correct? Yes. Why not do away with DAGDepth totally? I kept it to be conservative. From this thread it is clear that DAGDepth is seen to be valuable by some members of the group. DAGDepth may have other uses besides DAG formation. -Richard Kelsey From jhui@archrock.com Thu Jul 2 16:27:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928533A6BCF for ; Thu, 2 Jul 2009 16:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 wWRaPDjf6o01 for ; Thu, 2 Jul 2009 16:27:34 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 744FC3A6B7C for ; Thu, 2 Jul 2009 16:27:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 71B34AF81C; Thu, 2 Jul 2009 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma-jff+3aQIL; Thu, 2 Jul 2009 16:27:52 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 98C5BAF879; Thu, 2 Jul 2009 16:27:52 -0700 (PDT) Message-Id: <68A5221C-4E83-4A5E-96A4-7C25CA541071@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87ws6qvh80.fsf@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 v935.3) Date: Thu, 2 Jul 2009 16:27:51 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <87ws6qvh80.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 23:27:36 -0000 Hi Richard, It seems that your proposal is a special case of my original proposal to deal with the full vector of metrics in use. In your case, the vector has 2 elements (hop count, DAG cost) and both are monotonic. Some of the issues you identified with advertising DAGdepth and DAGcost are also present in mine. Specifically, can a node mix and match metric values from different parents? One difference, however, is that you no longer have an ill-defined notion of DAGcost since the metrics are carried through individually. This leads me back to thinking about the vector-based approach. The nice thing with the vector-based approach is that it's completely valid to include or exclude hop count. You also don't have to decide how some combination of metric A, B, C relates to hop count. As for dealing nodes understanding only certain metrics: In one view, the set of metrics should be originated by the destination (i.e. root). Nodes advertising the cost can either (i) decide to drop the metric from the vector or (ii) pass the metric along, possibly incrementing by some value. Both are useful in different situations, I think. If we went with this approach, it would also be useful to define a base set of metrics (hop count should be one). I still haven't come up with a better solution to the loop-avoidance mechanism in the vector-based approach other than the fairly constrained one I provided earlier... -- Jonathan Hui On Jul 2, 2009, at 3:43 PM, Richard Kelsey wrote: > From: Jonathan Hui > Date: Thu, 2 Jul 2009 14:14:46 -0700 > > Jonathan, > > On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: >> Here is a suggestion: >> >> Leave the hop count as is, and add a DAGCost field. The >> DAGCost field is a fixed-point value, say 16 bits of which 8 >> bits are the fractional part. The units for the cost field >> are hops, so a hop with a cost 0x0001 is equivalent to an >> additional 1/256th of a 'best case' hop and 0x0100 is >> equivalent to a complete additional 'best case' hop. The >> actual path cost is >> >> (DAGDepth << 8) + DAGCost >> >> Loop avoidance and parent selection is done using the path >> cost. In an outgoing DIO the DAGDepth MUST be larger than >> the maximum parent DAGDepth and the DAGCost MUST be large >> enough such that the path cost of the DIO is greater than >> the maximum parent path cost. > > This is an interesting approach. It forces each node to aggregate > whatever metrics they use into a single DAGCost metric and relate > that > to the DAGDepth in some way. Does it make sense to add another > constraint that DAGCost has to be >= the parent's DAGCost? > > With a single parent this would be the way to go. I am > unsure how to handle multiple parents if there is a large > variance in the split between DAGDepth and DAGCost. What if > there are two parents, one with a DAGDepth of 1 and a > DAGCost of 3 and the other with a DAGDepth of 3 and a > DAGCost of 1? The child's DAGDepth has to be 4 and the > DAGCost must be at least 1, but should it be higher? > > A related problem raised by the current draft is what should > be done if there are multiple parents with different metric > containers. How should the metric values from different > parents be combined? > > What I'm thinking about is the possible loss in > information across multiple hops. In a completely > contrived case, a node could advertise a path cost only 1 > greater (by incrementing DAGDepth by 1 and decreasing > DAGCost by 255) - then the meaning of a "hop" and > relationship between DAGCost and DAGDepth gets lost. Or > did you intend it to allow reductions in DAGCost so that > they can optionally be summarized into DAGDepth along the > way? > > My intent was the outgoing DAGCost should be no smaller > than the incoming one. But can you take the DAGDepth from > one parent and the DAGCost from another? > > -Richard Kelsey From pal@cs.stanford.edu Thu Jul 2 17:56:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833AA3A6ACC for ; Thu, 2 Jul 2009 17:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8OUQI3Wgqdl for ; Thu, 2 Jul 2009 17:56:20 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A421B3A6C76 for ; Thu, 2 Jul 2009 17:54:54 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MMX3d-0007d2-72; Thu, 02 Jul 2009 17:55:17 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <87tz1ux6q7.fsf@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 v935.3) Date: Thu, 2 Jul 2009 16:31:48 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 00:56:21 -0000 On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: > Jonathan, > > From: Jonathan Hui > Date: Thu, 2 Jul 2009 10:56:06 -0700 > > Things get a bit more tricky when dealing with multiple metrics > simultaneously. With multiple metrics, nothing changes as long as > the > comparator function between two metric vectors is a strictly > monotonic > function. If that strictly monotonic function does not exist (i.e. > the > metrics are completely orthogonal), then things get a bit more > difficult. One possible solution is that we require one or more of > the > path metrics to be strictly monotonic and the rule becomes: a node > cannot go "deeper" in any of the monotonic metrics. This seems a bit > over-constrained, so we were discussing whether we can relax this > constraint and this is still work in progress. > > Here is a suggestion: > > Leave the hop count as is, and add a DAGCost field. The > DAGCost field is a fixed-point value, say 16 bits of which 8 > bits are the fractional part. The units for the cost field > are hops, so a hop with a cost 0x0001 is equivalent to an > additional 1/256th of a 'best case' hop and 0x0100 is > equivalent to a complete additional 'best case' hop. The > actual path cost is > > (DAGDepth << 8) + DAGCost > > Loop avoidance and parent selection is done using the path > cost. In an outgoing DIO the DAGDepth MUST be larger than > the maximum parent DAGDepth and the DAGCost MUST be large > enough such that the path cost of the DIO is greater than > the maximum parent path cost. > > Increasing the DAGCost is optional. If no node does so the > result is the same as the current algorithm. Nodes are free > to include metric containers with additional information. > > If a node makes use of multiple metrics the additional costs > for one hop need not be additive. For example, if a link is > both slow and energy intensive, the link cost could be > the average of the two, instead of their sum. > > What do you think? Richard, This seems like a totally reasonable metric to use, but I'd be wary of saying it's *the* metric to use. Some implementations are going to want to consider hopcount, others won't. It's just another metric. Rather than hardwire hopcount based assumptions into the protocol design, we should put it on equal footing as other metrics. Correspondingly, the protocol should have general, metric-independent mechanisms for detecting and avoiding loops. Jonathan's concerns about integrating metrics into a single cost is well-founded: it's fraught with all kinds of problematic edge cases which you have to hack around. Advertising the vector is a much safer, more flexible, and less likely to run into broken assumptions which have to be later worked around. As a concrete example, one reason why CTP uses a 16-bit encoding of ETX was a need for precision to at least tenths of an ETX as well as the ability to support > 25 hops (the maximum with 8 bits). Our concrete use case for the second requirement was the network deployed along the length of the Golden Gate Bridge, which was ~40 hops long. Phil From richard.kelsey@ember.com Thu Jul 2 18:44:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5293A6C53 for ; Thu, 2 Jul 2009 18:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 HuH4YkwELnSV for ; Thu, 2 Jul 2009 18:44:45 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 593483A6C69 for ; Thu, 2 Jul 2009 18:44:40 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 21:45:01 -0400 Date: Thu, 02 Jul 2009 21:45:27 -0400 Message-Id: <87tz1uv8so.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Thu, 2 Jul 2009 16:31:48 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 03 Jul 2009 01:45:01.0990 (UTC) FILETIME=[E186DC60:01C9FB7F] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 01:44:46 -0000 Phil, From: Philip Levis Date: Thu, 2 Jul 2009 16:31:48 -0700 On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: > Leave the hop count as is, and add a DAGCost field. The > DAGCost field is a fixed-point value, say 16 bits of which 8 > bits are the fractional part. The units for the cost field > are hops, so a hop with a cost 0x0001 is equivalent to an > additional 1/256th of a 'best case' hop and 0x0100 is > equivalent to a complete additional 'best case' hop. The > actual path cost is > > (DAGDepth << 8) + DAGCost > > Loop avoidance and parent selection is done using the path > cost. In an outgoing DIO the DAGDepth MUST be larger than > the maximum parent DAGDepth and the DAGCost MUST be large > enough such that the path cost of the DIO is greater than > the maximum parent path cost. This seems like a totally reasonable metric to use, but I'd be wary of saying it's *the* metric to use. Some implementations are going to want to consider hopcount, others won't. It's just another metric. I am proposing it, or something like it, as the default metric. The current draft uses hop count both as the default metric and to override other metrics in some cases. This does not seem like a good idea. Replacing hop count with a finer-grained cost avoids the need to override other metrics. Rather than hardwire hopcount based assumptions into the protocol design, we should put it on equal footing as other metrics. Correspondingly, the protocol should have general, metric-independent mechanisms for detecting and avoiding loops. Are there such mechanisms? In order to avoid creating a loop you have to remove or ignore some edges in the graph. Picking which edges to remove would seem to require a metric of some kind. Jonathan's concerns about integrating metrics into a single cost is well-founded: it's fraught with all kinds of problematic edge cases which you have to hack around. I don't understand. Using a single metric, regardless of how it is defined, is straightforward. What are the problematic edge cases? Using a single metric clearly doesn't optimize other metrics, but in the general case you have to use something. For homogeneous networks, where all of the nodes implement and make use of the same set of metrics, then that is the set of metrics you want to use. For such a network the choice of parents will be based on information in the metric containers. The only additional requirement is that the choice be reflected in the DAGCost values. For heterogeneous networks, there is little point in passing around a vector of metrics if different nodes implement and optimize different sets of them. Even if they all implement the same metrics, nothing is optimized if some nodes pick parents based on latency, others use reliability, and still others use energy. For any notion of optimality all nodes have to be using more-or-less the same optimization function. As a concrete example, one reason why CTP uses a 16-bit encoding of ETX was a need for precision to at least tenths of an ETX as well as the ability to support > 25 hops (the maximum with 8 bits). Our concrete use case for the second requirement was the network deployed along the length of the Golden Gate Bridge, which was ~40 hops long. Yes, more bits are likely to be needed than the 16 I mentioned. -Richard Kelsey From pthubert@cisco.com Thu Jul 2 23:24:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06403A68AB; Thu, 2 Jul 2009 23:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.676 X-Spam-Level: X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, 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 DTW32hxioLJm; Thu, 2 Jul 2009 23:24:42 -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 AA26B3A6AAE; Thu, 2 Jul 2009 23:24:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,338,1243814400"; d="scan'208,217";a="44267197" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 06:24:39 +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 n636OdHY008034; Fri, 3 Jul 2009 08:24:39 +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.14.3) with ESMTP id n636Odng014072; Fri, 3 Jul 2009 06:24:39 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 Jul 2009 08:24:39 +0200 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_01C9FBA6.F17D4585" Date: Fri, 3 Jul 2009 08:24:32 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93A63@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hopdistance from theroot? Thread-Index: Acn7UtGbTIv54JoTSwOnSfEGDuW1IAAT51pQ References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com><017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com><018301c9fb50$82558d10$8700a730$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , , , "Alexandru Petrescu" , X-OriginalArrivalTime: 03 Jul 2009 06:24:39.0633 (UTC) FILETIME=[F1C80410:01C9FBA6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25808; t=1246602279; x=1247466279; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hopdistance=09from=09theroot? |Sender:=20; bh=YLI+AX5rKDmuTtKJlKpLyWWsihH6NoPnvzDcE2WxmZ8=; b=eLgMHviC6TBtJQV+vk74h1O5Ic42+7AEvKQ66JXDRheEF5aSSC52X6TP7F ZT7w6jqvL9VnovVqBZbvrU46LV2WEuAoi6AvgdJUuOs4RqX2R+LtKC2Jr7GP IHUb6SC+n3; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hopdistance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 06:24:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FBA6.F17D4585 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 Actually the draft recognizes that there are tons of metrics and then algorithms to sort out those metrics. =20 The draft also recognizes that the perfect one-fit-it-all scalar metric for all is an illusion amongst a number of other illusions, I'm sure I'll have ample chances to come back to those. =20 The net result is that RPL extracts the metrics and their handling in a specific component that selects a (set of) preferred parent(s). That component will vary. From use case to use case. From device generation to the next. =20 The draft focuses on the generic operations that happen after the preferred parent(s?) is selected. The draft then proposes a number of simple laws to organize the society of machines with different and somewhat conflicting objective.=20 =20 The 'depth' metric is the lingua franca that the draft requires to enable comparison between nodes and establish a graph with the required properties of loop avoidance and stability (we're doing a routing protocol) while optimizing the desired property multiple feasible successors for all (that's one of the LLN specific things). =20 That 'depth' must have a number of properties. It MUST be: - Scalar for simple comparison - Strictly monotonous to orient the parent links and sort out siblings - Universal thus very abstract - Coarse grained to enable multiple parents and siblings - Constrained in range to count rapidly to infinity if that can happen in the protocol =20 So it DOES NOT have to be a simple increment by one. Expected Transmission Count is certainly a better approximation of what's needed in a radio mesh and is widely used there. The only trouble with pure ETX is that is makes a lot less sense in wired environment. =20 My sense is that we should abstract something that could be implemented by ETX - or something else - by the node to characterize its hop to parent. That value would be a scalar link rate, like 1, best can do for that type of link, to 8 for the worst acceptable for that type of link. This abstraction fits the MUSTs of the depth and can be derived from an ETX. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yusuf.Bashir@jci.com Sent: jeudi 2 juillet 2009 22:22 To: d.sturek@att.net Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hopdistance from theroot? =20 Hi JP and Don,=20 You are both correct. The number of hops should be one of the metrics not "the metric".=20 Regards,=20 Yusuf=20 From:=20 "Don Sturek" =20 To:=20 "'JP Vasseur'" =20 Cc:=20 roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com=20 Date:=20 07/02/2009 03:12 PM=20 Subject:=20 Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? =20 ________________________________ Hi JP, Absolutely correct. Number of hops is not *the* metric. It just cannot be completely ignored and in some cases (like the data link security example) it does have a direct affect on latency. Don -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com ]=20 Sent: Thursday, July 02, 2009 1:01 PM To: d.sturek@att.net Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, I think that we are on the same page here: the number of hops should =20 not be *the* only metric but *could* be a metric. Agree ? Thanks. JP. On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please =20 > correct me > if I am wrong). In that scenario, it is good to minimize the number =20 > of hops > (within reason of course). If that involves a few extra re-=20 > transmissions > then you probably still end up with a more efficient packet delivery =20 > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org ] On Behalf =20 > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance =20 > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll =20 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01C9FBA6.F17D4585 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

Actually the draft recognizes that there are tons of = metrics and then algorithms to sort out those metrics.

 

The draft also recognizes that the perfect one-fit-it-all = scalar metric for all is an illusion amongst a number of other illusions, = I’m sure I’ll have ample chances to come back to = those.

 

The net result is that RPL extracts the metrics and their = handling in a specific component that selects a (set of) preferred =  parent(s). That component will vary. From use case to use case. From device generation = to the next.

 

The draft focuses on the generic operations that happen = after the preferred parent(s?) is selected. The draft then proposes a number = of simple laws to organize the society of machines with different and = somewhat conflicting objective.

 

The ‘depth’ metric is the lingua franca that = the draft requires to enable comparison between nodes and establish a graph with = the required properties of loop avoidance and stability (we’re doing a routing protocol) while optimizing the desired property multiple = feasible successors for all (that’s one of the LLN specific = things).

 

That ‘depth’ must have a number of = properties. It MUST be:

-          Scalar for simple comparison

-          Strictly monotonous to orient the parent links and sort = out siblings

-          Universal thus very abstract

-          Coarse grained to enable multiple parents and = siblings

-          Constrained in range to count rapidly to infinity if that = can happen in the protocol

 

So it DOES NOT have to be a simple increment by one. = Expected Transmission Count is certainly a better approximation of what’s needed in a = radio mesh and is widely used there. The only trouble with pure ETX is that is = makes a lot less sense in wired environment.

 

My sense is that we should abstract something that could = be implemented by ETX – or something else – by the node to characterize its hop to parent. That value would be a scalar link rate, = like 1, best can do for that type of link, to 8 for the worst acceptable for = that type of link. This abstraction fits the MUSTs of the depth and can be derived = from an ETX.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Yusuf.Bashir@jci.com
Sent: jeudi 2 juillet 2009 22:22
To: d.sturek@att.net
Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu
Subject: Re: [Roll] RPL: why not base a DAG on the min = hopdistance from theroot?

 


Hi JP = and Don,
You = are both correct. The number of hops should be one of the metrics not "the metric".

Regards,
Yusuf =


From:

"Don Sturek" <d.sturek@att.net>

To:

"'JP Vasseur'" <jvasseur@cisco.com>

Cc:

roll@ietf.org,= gnawali@usc.edu, roll-bounces@ietf.org, Yusuf.Bashir@jci.com =

Date:

07/02/2009 03:12 PM

Subject:

Re: [Roll] RPL: why not base a DAG on the min hop distance     =    from        theroot?

 




Hi JP,

Absolutely correct.  Number of hops is not *the* metric. =  It just cannot be
completely ignored and in some cases (like the data link security = example)
it does have a direct affect on latency.

Don


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com<= span style=3D'font-size:10.0pt'>]
Sent: Thursday, July 02, 2009 1:01 PM
To: d.sturek@att.net
Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org;
roll-bounces@ietf.org; gnawali@usc.edu
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance = from
theroot?

Hi Don,

I think that we are on the same page here: the number of hops should =  
not be *the* only metric but *could* be a metric.

Agree ?

Thanks.

JP.

On Jul 2, 2009, at 9:51 PM, Don Sturek wrote:

> Hi Jonathan,
>
> I think the example Yusuf may be referring to involves data = link level
> security where packets are encrypted/decrypted hop by hop = (please  
> correct me
> if I am wrong).  In that scenario, it is good to minimize = the number  
> of hops
> (within reason of course).  If that involves a few extra = re-
> transmissions
> then you probably still end up with a more efficient packet = delivery  
> from a
> latency point of view.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of
> Jonathan Hui
> Sent: Thursday, July 02, 2009 9:28 AM
> To: Yusuf.Bashir@jci.com
> Cc: roll@ietf.org; roll-bounces@ietf.org; = gnawali@usc.edu
> Subject: Re: [Roll] RPL: why not base a DAG on the min hop = distance  
> from
> theroot?
>
>
> On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com = wrote:
>>
>> Using low data rate 802.15.4 radios in commercial buildings = we
>> design our deployments
>> to minimize hops and that has been an essential part of the success
>> of our networks. The result of
>> excessive hops is higher latency and higher probability = of
>> collisions which leads to devices timing out and = going
>> offline. This is an essential customer requirement for us.  We also
>> have data showing that when you do over the air = downloads,
>> minimizing hops is key to meeting our timing = requirements.
>
> But would you agree that minimizing the number of transmissions = on a
> path is a better metric than hops in your case?
>
> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01C9FBA6.F17D4585-- From jvasseur@cisco.com Thu Jul 2 23:55:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49803A6A62; Thu, 2 Jul 2009 23:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 49j5hPa6aAXr; Thu, 2 Jul 2009 23:55:49 -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 F0CCC3A6A49; Thu, 2 Jul 2009 23:55:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,339,1243814400"; d="scan'208";a="44269444" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 06:56:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n636uAov002562; Fri, 3 Jul 2009 08:56:10 +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.14.3) with ESMTP id n636uAjF020736; Fri, 3 Jul 2009 06:56:10 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); Fri, 3 Jul 2009 08:56:10 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 08:56:10 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A4D1A1E.3000804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 3 Jul 2009 08:56:08 +0200 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> <4A4D1A1E.3000804@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Jul 2009 06:56:10.0177 (UTC) FILETIME=[58A22310:01C9FBAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2881; t=1246604170; x=1247468170; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=09from=09theroot? |Sender:=20; bh=7rNOirvXyDTMdAu60pEqsOQjwMeUSliLZycWHmdBlm0=; b=MQMA0cenigl8+Jpey9kkDk+hR+iJiIeReiLS+RI0UJYtTKNm6KV6ypO6LH 70BSiUtBzCNH3QsoG1UFeW6mtbnIV8Y4oIFJxIZfxRR2OT8yZlhdO1zbBgCk ORET/S/xk9; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 06:55:50 -0000 On Jul 2, 2009, at 10:35 PM, Alexandru Petrescu wrote: > JP - what is a metric? > > I consider the depth used by the DAG to be a metric - a hop count =20 > metric. When a node joins a DAG below a certain depth, it is using =20= > a metric: the number of hops between self and topmost node (LBR, DAG =20= > Root). > > As it stands now, the hopcount is _the_ metric of RPL. You can use another metric than the hop count, which is then used to =20 avoid loops. Cheers. JP. > > Alex > > JP Vasseur a =E9crit : >> Hi Don, >> I think that we are on the same page here: the number of hops =20 >> should not be *the* only metric but *could* be a metric. >> Agree ? >> Thanks. >> JP. >> On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: >>> Hi Jonathan, >>> >>> I think the example Yusuf may be referring to involves data link =20 >>> level >>> security where packets are encrypted/decrypted hop by hop (please =20= >>> correct me >>> if I am wrong). In that scenario, it is good to minimize the =20 >>> number of hops >>> (within reason of course). If that involves a few extra re-=20 >>> transmissions >>> then you probably still end up with a more efficient packet =20 >>> delivery from a >>> latency point of view. >>> >>> Don >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >>> Behalf Of >>> Jonathan Hui >>> Sent: Thursday, July 02, 2009 9:28 AM >>> To: Yusuf.Bashir@jci.com >>> Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu >>> Subject: Re: [Roll] RPL: why not base a DAG on the min hop =20 >>> distance from >>> theroot? >>> >>> >>> On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >>>> >>>> Using low data rate 802.15.4 radios in commercial buildings we >>>> design our deployments >>>> to minimize hops and that has been an essential part of the success >>>> of our networks. The result of >>>> excessive hops is higher latency and higher probability of >>>> collisions which leads to devices timing out and going >>>> offline. This is an essential customer requirement for us. We also >>>> have data showing that when you do over the air downloads, >>>> minimizing hops is key to meeting our timing requirements. >>> >>> But would you agree that minimizing the number of transmissions on a >>> path is a better metric than hops in your case? >>> >>> --=20 >>> Jonathan Hui >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Thu Jul 2 23:56:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB0F3A6807 for ; Thu, 2 Jul 2009 23:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.782 X-Spam-Level: X-Spam-Status: No, score=-8.782 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ4gHl6f6rm5 for ; Thu, 2 Jul 2009 23:56:33 -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 719443A6A62 for ; Thu, 2 Jul 2009 23:56:31 -0700 (PDT) X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-AV: E=Sophos;i="4.42,339,1243814400"; d="gif'147?scan'147,208,217,147";a="44269502" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 06:56:53 +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 n636ur19002732 for ; Fri, 3 Jul 2009 08:56:53 +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.14.3) with ESMTP id n636urH6020886 for ; Fri, 3 Jul 2009 06:56:53 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 08:56:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9FBAB.720557F1" Date: Fri, 3 Jul 2009 08:56:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93A89@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Thread-Index: Acn7CUJQPBbZhygbShu6+SCqJDi0sQAnbtTg References: From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , X-OriginalArrivalTime: 03 Jul 2009 06:56:52.0954 (UTC) FILETIME=[722163A0:01C9FBAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=34775; t=1246604213; x=1247468213; 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[Roll]=20Fwd=3A=20I-D=20Action=3Adraft- dt-roll-rpl-00.txt |Sender:=20; bh=I7V6+INrkqvSmPWWuKOa7+R/XCrdk5vW7QrRfmyQ698=; b=HRA0hwfiQ8j4zj8ohGLCvnNB4kKbwKnk9t8Rh9fzbz0EYD9ljbf807iRNd 6UthIw59frvDNaZ+CCreAUW/+noSZx7dN7QqWRtoy7qR4hn2GXNbscqUTWk3 bWkyKJs2PF; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 06:56:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FBAB.720557F1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9FBAB.720557F1" ------_=_NextPart_002_01C9FBAB.720557F1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut Mathilde, =20 How are things in ROLLe? =20 Q if node (42) had siblings, they would also be part of its shadow cone, = correct? Correct. I think we ended up with the definition of shadow cone vs. = subdag with the notion that the subdag is still a DAG so it does not = encompass sibling paths whereas the shadow cone as pure dark AND grey = zones, the grey parts being siblings.=20 http://www.nasaimages.org/luna/servlet/detail/NVA2~4~4~4868~105394:Shadow= -Cone-of-a-Total-Solar-Eclips =20 Q - Must all nodes in a DAG use the same metric(s) as suggested by = section 3.3.1.4.? This seems to conflict with the last paragraphs of = section 4.1. What do you mean by consistent parent selection? Does it = mean that a node should not join a DAG if it's metric logic does not = agree with the metric logic of other nodes in the DAG? =20 Please see my text posted on this list a few minutes ago. The Langua = Franca 'depth' metric can be used to preferred parent selection but this = does not have to be. The degenerated case where that metric is the only = thing used for the parent selection takes us back to a lot closer to = classical DV. With the current draft, nodes may have completely = independent metric logics. This is debated. If we could make broad = families, then nodes might prefer to join a DAG that belongs to the same = family, in particular share optimization objectives. =20 Q 3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if = something goes wrong with Node (B) and (E), correct? =20 Correct. C is a sibling.=20 =20 Q 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, = PROBE) contained in the neighbor cache table? One way to maintain = routing adjacencies would be to use a relatively low reachable time = which means that the neighbors will be in STALE state rapidly. Once a = neighbor is in this state, any packet for this neighbor will trigger a = NS/NA exchange to confirm reachability. However, the data packet will be = send before the NS is sent... =20 We are binding our protocol on ND. Could be bound on other neighboring = protocols, though ND seems a good fit on the occasion, in particular for = it reactive properties in particular for NUD. So we should not use = directly the ND state but be aware of changes in their properties. We = are interested in triggers for neighbors going reachable and then = removed. We are not interested in going stale, delay or probe though we = should probably hint an implementation to reduce the delay time to zero. = We should specify a little better the binding so further down the road, = other bindings can be achieved. =20 Q - 3.3.3.1. " Note that further details of the message and its triggers = are still under investigation, including whether or not the DAO should = be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still = under investigation given that section 5.5.1.1 speaks only of NA? =20 The whole draft is under investigation anyway J NA makes sense so it is = the proposal on the table. NA represents better the relationship that a = node has with the router that it is attached to than RA does. So we = build the routing structure propagating information in RAs outwards and = then paint the graph propagating information in NAs inwards along that = routing structure. =20 Q - 5.4 Item 3. I guess you are talking only about a LBR not any LLN = router =20 Maybe we lack some string language but any router doing our stuff should = use RA-DIO. The absence of it is a signal of a legacy router that we = assume as a wired power-savvy router. =20 Q - 5.4.3.1 " When a new DAG is discovered, the candidate parent that = advertises the new DAG is placed in a held up state for the duration of = a DAG Hop timer". What if the node want to be part of both DAGs (its = original DAG and the new one), I guess this does not apply. =20 It does apply; The main goal is for all nodes that would wish to do the = same thing to do it orderly. When A attaches to the new tree, it offers = a new opportunity for others to do so to. The hop timer lets nodes that = join higher in the new tree to do it first, so nodes joining deeper can = see the final set of opportunities before they can jump in turn. =20 Bonne journ=E9e J =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: jeudi 2 juillet 2009 13:36 To: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt =20 Hi All, =20 Thanks for this nice draft!=20 A few comments/questions: =20 - 3.3.1.2 shadow cone. In the example given, if node (42) had siblings, = they would also be part of its shadow cone, correct? =20 - Must all nodes in a DAG use the same metric(s) as suggested by = section 3.3.1.4.? This seems to conflict with the last paragraphs of = section 4.1. What do you mean by consistent parent selection? Does it = mean that a node should not join a DAG if it's metric logic does not = agree with the metric logic of other nodes in the DAG? =20 - 3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if = something goes wrong with Node (B) and (E), correct? =20 - 3.3.3.1. " Note that further details of the message and its triggers = are still under investigation, including whether or not the DAO should = be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still = under investigation given that section 5.5.1.1 speaks only of NA? =20 - 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, = PROBE) contained in the neighbor cache table? One way to maintain = routing adjacencies would be to use a relatively low reachable time = which means that the neighbors will be in STALE state rapidly. Once a = neighbor is in this state, any packet for this neighbor will trigger a = NS/NA exchange to confirm reachability. However, the data packet will be = send before the NS is sent... =20 - 5.4 Item 3. I guess you are talking only about a LBR not any LLN = router =20 - 5.4.3.1 " When a new DAG is discovered, the candidate parent that = advertises the new DAG is placed in a held up state for the duration of = a DAG Hop timer". What if the node want to be part of both DAGs (its = original DAG and the new one), I guess this does not apply. =20 Typos: - DAG Sibling definition page 5: neighboring node node - 3.2.4: able to ... discover - 3.3.1.2: I guess you mean 'consider Node (42)' - 3.3.1.2: 'the node rooting the DAG may is not' - 3.3.1.4: lessor -> lesser - 3.3.4.5: Node (51), (41), (42) and (54) - 5.1.1.1.5: "this may be useful in cases where more than one LBR" - 5.2: "candidate neighbor set(, bounded), and" - 5.5.1.1: "RRcount: 8-bit unsigned integer" - 5.5.2.1 "The DelayNA timer has a duration that is DEF_NA_LATENCY = divided by 2 with the DAG depth". Does this mean 2^(DAG depth)? =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 ------_=_NextPart_002_01C9FBAB.720557F1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut Mathilde,

 

How are things in ROLLe?

 

Q if node (42) had siblings, they would also be part of its shadow cone, = correct?

Correct. I think we ended up with the definition of = shadow cone vs. subdag with the notion that the subdag is still a DAG so it does not encompass sibling paths whereas the shadow cone as pure dark AND grey = zones, the grey parts being siblings.

http://www.nasaimages.org/luna/ser= vlet/detail/NVA2~4~4~4868~105394:Shadow-Cone-of-a-Total-Solar-Eclips<= o:p>

 

Q - Must all nodes in a DAG use the same metric(s)  as suggested by section 3.3.1.4.? This seems to conflict with the last paragraphs of section = 4.1. What do you mean by consistent parent selection? Does it mean that a node = should not join a DAG if it's metric logic does not agree with the metric logic of = other nodes in the DAG?

 

Please see my text posted on this list a few minutes ago. = The Langua Franca ‘depth’ metric can be used to preferred parent = selection but this does not have to be. The degenerated case where that metric is the = only thing used for the parent selection takes us back to a lot closer to = classical DV. With the current draft, nodes may have completely independent metric logics. This is debated. If we could make broad families, then nodes = might prefer to join a DAG that belongs to the same family, in particular = share optimization objectives.

 

Q =A03.3.1.4.1.= I guess Node (N) may also forward traffic via Node (C) if something goes = wrong with Node (B) and (E), correct?

 

Correct. C is a sibling.

 

Q 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE) = contained in the neighbor cache table? One way to maintain routing adjacencies would = be to use a relatively low reachable time which means that the neighbors will = be in STALE state rapidly. Once a neighbor is in this state, any packet for this neighbor will trigger a NS/NA exchange to confirm reachability. However, the data packet will be send before the NS is = sent...

 

We are binding our protocol on ND. Could be bound on = other neighboring protocols, though ND seems a good fit on the occasion, in particular for it reactive properties in particular for NUD. So we = should not use directly the ND state but be aware of changes in their properties. = We are interested in triggers for neighbors going reachable and then removed. = We are not interested in going stale, delay or probe though we should probably = hint an implementation to reduce the delay time to zero. We should specify a = little better the binding so further down the road, other bindings can be = achieved.

 

Q - 3.3.3.= 1. " Note that further details of the message and its triggers = are still under investigation, including whether or not the DAO should be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still = under investigation given that section 5.5.1.1 speaks only of = NA?

 

The whole draft is under investigation anyway = J NA makes sense so it is the proposal on the table. NA represents better the = relationship that a node has with the router that it is attached to than RA does. So = we build the routing structure propagating information in RAs outwards and = then paint the graph propagating information in NAs inwards along that = routing structure.

 

Q - 5.4 Item 3. I guess you are talking only about a LBR not any LLN = router

 

Maybe we lack some string language but any router doing = our stuff should use RA-DIO. The absence of it is a signal of a legacy router that = we assume as a wired power-savvy router.

 

Q - 5.4.3.1 " When a new DAG is discovered, the candidate parent that advertises the new DAG is placed in a held up state for the duration of = a DAG Hop timer".  What if the node want to be part of both DAGs (its = original DAG and the new one), I guess this does not apply.

 

It does apply; The main goal is for all nodes that would = wish to do the same thing to do it orderly. When A attaches to the new tree, it = offers a new opportunity for others to do so to. The hop timer lets nodes that = join higher in the new tree to do it first, so nodes joining deeper can see = the final set of opportunities before they can jump in = turn.

 

Bonne journ=E9e J

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: jeudi 2 juillet 2009 13:36
To: roll@ietf.org
Subject: Re: [Roll] Fwd: I-D = Action:draft-dt-roll-rpl-00.txt

 

Hi All,

 

Thanks for this nice draft!

A few comments/questions:

 

- 3.3.1.2 shadow cone. In the example given, if node (42) had siblings, = they would also be part of its shadow cone, correct?

 

- Must all nodes in a DAG use the same metric(s)  as suggested by section 3.3.1.4.? This seems to conflict with the last paragraphs of section = 4.1. What do you mean by consistent parent selection? Does it mean that a node = should not join a DAG if it's metric logic does not agree with the metric logic of = other nodes in the DAG?

 

- 3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if = something goes wrong with Node (B) and (E), correct?

 

- 3.3.3.= 1. " Note that further details of the message and its triggers = are still under investigation, including whether or not the DAO should be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still = under investigation given that section 5.5.1.1 speaks only of = NA?

 

- 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE) contained in the neighbor cache table? One way to maintain routing = adjacencies would be to use a relatively low reachable time which means that the = neighbors will be in STALE state rapidly. Once a neighbor is in this = state, any packet for this neighbor will trigger a NS/NA exchange to confirm reachability. However, the data packet will be send before the NS is = sent...

 

- 5.4 Item 3. I guess you are talking only about a LBR not any LLN = router

 

- 5.4.3.1 " When a new DAG is discovered, the candidate parent that advertises the new DAG is placed in a held up state for the duration of = a DAG Hop timer".  What if the node want to be part of both DAGs (its = original DAG and the new one), I guess this does not apply.

 

Typos:=

- DAG Sibling definition page 5: neighboring node node

- 3.2.4: able to ... discover

- 3.3.1.2: I guess you mean 'consider Node (42)'

- 3.3.1.2: 'the node rooting the DAG may is not'

- 3.3.1.4: lessor -> lesser

- 3.3.4.5: Node (51), (41), (42) and (54)

- 5.1.1.1.5: "this may be useful in cases where more than = one = LBR"

- 5.2: "candidate neighbor set(, bounded), = and"

- 5.5.1.1: "RRcount: 8-bit unsigned integer"

- 5.5.2.1 "The DelayNA = timer has a duration that is DEF_NA_LATENCY divided by 2 with the DAG = depth". Does this = mean 2^(DAG depth)?

Durvy = Mathilde=
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

= Cisco Systems International S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page

 

 

3D"ThinkThink before you print.

This e-mail may contain = confidential and privileged material for the sole use of the intended recipient. = Any review, use, distribution or disclosure by others is strictly = prohibited. If you are not the intended recipient (or authorized to receive for = the recipient), please contact the sender by reply e-mail and delete all = copies of this message.


 

------_=_NextPart_002_01C9FBAB.720557F1-- ------_=_NextPart_001_01C9FBAB.720557F1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01C9FBAB.720557F1 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01C9FBAB.720557F1-- From pthubert@cisco.com Fri Jul 3 00:35:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A7E3A68D6 for ; Fri, 3 Jul 2009 00:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.665 X-Spam-Level: X-Spam-Status: No, score=-8.665 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=1, J_CHICKENPOX_61=0.6, 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 tHv24qDp7wQX for ; Fri, 3 Jul 2009 00:35:22 -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 1C7A73A6801 for ; Fri, 3 Jul 2009 00:35:20 -0700 (PDT) X-Files: None : None X-IronPort-AV: E=Sophos;i="4.42,339,1243814400"; d="txt'?scan'208";a="44273581" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 07:35:43 +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 n637ZhMB025875; Fri, 3 Jul 2009 09:35:43 +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.14.3) with ESMTP id n637ZhhS002222; Fri, 3 Jul 2009 07:35:43 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 Jul 2009 09:35:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9FBB0.DE967422" Date: Fri, 3 Jul 2009 09:35:36 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93AAB@xmb-ams-337.emea.cisco.com> In-Reply-To: <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance fromthe root? Thread-Index: Acn7LMnAdbHed4OBTtmkRlzp5hFTuwAf58zw References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Jonathan Hui" X-OriginalArrivalTime: 03 Jul 2009 07:35:42.0986 (UTC) FILETIME=[DEF00EA0:01C9FBB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16726; t=1246606543; x=1247470543; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20fromthe=09root? |Sender:=20; bh=gPtW2Azlglc+xL77FveFoZjdaXY8pH5lEni6yY2qJYI=; b=h8MFbBhbcwFnnB5P+8eURYJgzxOypEslZdBmnrcyjqk+3+KP4xKI6lcTUS 5lr3B3j9GjkPWTYw4wc5oFZGfKNULeuHIIRmfPoo/FPb9IpI5vQuJqJfb8cx Tg9HWW7IYL; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance fromthe root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 07:35:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FBB0.DE967422 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard: Please consider my proposal (attached). It appears that B could rate its link to MBR poor so give is a 'depth' of say, 6 in a scale of 8. So if C to A and A to LBR are both perfect links (rated 1) C will be depth 2, and will not attach to B. When B see C coming, it will attach to C (no wait) and drop LBR. Can you adapt that generic scheme to your own case in a satisfactory manner? I need to explain a lot deeper why we do the things we do. A routing protocol in general aims are a high degree of loop avoidance AND stability. Instabilities result from feedback loops. For instance at a point in ARPANET, the routing metrics would derive from usage, so usage could change the routing which is turn changes the usage, and this would create a feedback loop. In a similar fashion, a node movement might generate another node movement and we could be in a loop. To avoid such an instability problem, the draft creates an event horizon. Whatever happens behind you, don't look. So you're only impacted by movements at a lesser depth, which makes sense in a DV anyway. So there cannot be a feedback loop. There's probably a better way to prevent instabilities, but this one has the merits to 1) exist and 2) be dead simple. I take advantage of this mail to discuss another illusion. There is no perfect DAG. In your example: > LBR > / \ > A B > \ / > C Maybe it's BAD for B to be attached to LBR but it's beneficial for C since that gives it an alternate. So optimizing one thing is detrimental for another thing (le bonheur des uns...).=20 So what the draft does is enable to do something which is satisfactory though imperfect for all. Consider the event horizon thing. This law does not prevent in your example B from detaching and then reattach to C. It only prevents this from happening because of C's messages that MUST be ignored if coming from deeper. So if for other reasons (link to B no more good enough, battery depletion, whatever) B detaches from LBR, then B can later listen to all RAs from that tree and reattach where it prefers. And another illusion of a predictable behavior. The characteristics of the network, including the metrics, are unpredictable. What we really want is that every node gets an acceptable result most of the time. There are many ways in which that can be arranged and we do not look for the illusory perfect DAG one so we could reach any of a large number of acceptable solutions. And another illusion, of the perfection of existing IGPs. The IGPs we're used to operate on a perfect world (one metric, stable links). Yet they would serve us badly. The shortest path perfection yield to highly used avenues and many unused alternate links. The shortcomings must be addressed manually by a new form of art called traffic engineering. All bad for us: avenues would deplete our batteries on the best path to rapidly, and manual interventions are antagonistic to one of our main goals, autonomicity. With the slowly reforming imperfect structures that we are building, we expect the paths to change overtime between an acceptable state to another, and we expect to dissolve the avenue effect. The multiple forwarding solutions that the DAG propose further enables forthcoming additions to automate some degree of autonomic traffic engineering, though haw is can be achieve is out of scope for this doc. Sorry for all the words... Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: jeudi 2 juillet 2009 17:50 >To: Jonathan Hui >Cc: roll@ietf.org >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance fromthe root? > > From: Jonathan Hui > Date: Wed, 1 Jul 2009 20:32:10 -0700 > > Phil put his finger on an important point. We want to select routes > using metrics that are not necessarily based on hop-count for a > variety of reasons (e.g. ETX), but hop-count is a way to avoid and > detect loops while being agnostic to the metric used. This distinction > highlights a subtle difference between the Arch Rock stack and CTP, > where the former uses hop-count for data-path loop detection and the > latter uses the routing cost itself. > >That subtle difference can have a large effect. The current >DAG discovery strongly prefers a single hop over any >alternative path that is three or more hops in length, >regardless of any routing contraints. This stems directly >from the use of hop count for loop avoidance. > >To see this, consider a network with four nodes LBR, A, B, >and C, where A and B do not share a link and the LBR<->B >link is inferior enough that the LBR<->A<->C<->B route is >significantly better than the one-hop LBR<->B route. > > LBR > / \ > A B > \ / > C > >LBR, as the root, sends out an RA at depth 0, heard by both >A and B. They in turn send out their RAs at depth 1 and C >picks A as a parent, the cost of the LBR<->B link making B >an bad choice. C then sends out an RA at depth 2, which is >ignored by A and B because C's depth is greater than theirs. > >The upshot is that B's route to LBR almost always uses the >poor-quality LBR<->B link, rather than the preferred route >via C and A. The 'almost always' is because you might get >lucky and B might not hear the initial RA from the LBR and >hear C's RA first. > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C9FBB0.DE967422 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xmb-ams-337.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 08:25:23 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C9FBA7.0BA14B80" Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 08:25:23 +0200 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 23:25:21 -0700 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2009 06:25:20 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n636PKpf008949; Thu, 2 Jul 2009 23:25:20 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n636P8X9025577; Fri, 3 Jul 2009 06:25:20 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 03 Jul 2009 06:25:20 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653CF28C15D; Thu, 2 Jul 2009 23:24:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06403A68AB; Thu, 2 Jul 2009 23:24:49 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTW32hxioLJm; Thu, 2 Jul 2009 23:24:42 -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 AA26B3A6AAE; Thu, 2 Jul 2009 23:24:17 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 06:24:39 +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 n636OdHY008034; Fri, 3 Jul 2009 08:24:39 +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.14.3) with ESMTP id n636Odng014072; Fri, 3 Jul 2009 06:24:39 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 Jul 2009 08:24:39 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] RPL: why not base a DAG on the minhopdistance from theroot? Date: Fri, 3 Jul 2009 08:24:32 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93A63@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the minhopdistance from theroot? Thread-Index: Acn7UtGbTIv54JoTSwOnSfEGDuW1IAAT51pQ References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com><017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com><018301c9fb50$82558d10$8700a730$@sturek@att.net> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Pascal Thubert (pthubert)" Sender: To: , , , "Alexandru Petrescu" , Cc: , This is a multi-part message in MIME format. ------_=_NextPart_002_01C9FBA7.0BA14B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 Actually the draft recognizes that there are tons of metrics and then = algorithms to sort out those metrics. =20 The draft also recognizes that the perfect one-fit-it-all scalar metric = for all is an illusion amongst a number of other illusions, I'm sure = I'll have ample chances to come back to those. =20 The net result is that RPL extracts the metrics and their handling in a = specific component that selects a (set of) preferred parent(s). That = component will vary. From use case to use case. From device generation = to the next. =20 The draft focuses on the generic operations that happen after the = preferred parent(s?) is selected. The draft then proposes a number of = simple laws to organize the society of machines with different and = somewhat conflicting objective.=20 =20 The 'depth' metric is the lingua franca that the draft requires to = enable comparison between nodes and establish a graph with the required = properties of loop avoidance and stability (we're doing a routing = protocol) while optimizing the desired property multiple feasible = successors for all (that's one of the LLN specific things). =20 That 'depth' must have a number of properties. It MUST be: - Scalar for simple comparison - Strictly monotonous to orient the parent links and sort out = siblings - Universal thus very abstract - Coarse grained to enable multiple parents and siblings - Constrained in range to count rapidly to infinity if that can = happen in the protocol =20 So it DOES NOT have to be a simple increment by one. Expected = Transmission Count is certainly a better approximation of what's needed = in a radio mesh and is widely used there. The only trouble with pure ETX = is that is makes a lot less sense in wired environment. =20 My sense is that we should abstract something that could be implemented = by ETX - or something else - by the node to characterize its hop to = parent. That value would be a scalar link rate, like 1, best can do for = that type of link, to 8 for the worst acceptable for that type of link. = This abstraction fits the MUSTs of the depth and can be derived from an = ETX. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Yusuf.Bashir@jci.com Sent: jeudi 2 juillet 2009 22:22 To: d.sturek@att.net Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hopdistance from = theroot? =20 Hi JP and Don,=20 You are both correct. The number of hops should be one of the metrics = not "the metric".=20 Regards,=20 Yusuf=20 From:=20 "Don Sturek" =20 To:=20 "'JP Vasseur'" =20 Cc:=20 roll@ietf.org, gnawali@usc.edu, roll-bounces@ietf.org, = Yusuf.Bashir@jci.com=20 Date:=20 07/02/2009 03:12 PM=20 Subject:=20 Re: [Roll] RPL: why not base a DAG on the min hop distance from = theroot? =20 _____ =20 Hi JP, Absolutely correct. Number of hops is not *the* metric. It just cannot = be completely ignored and in some cases (like the data link security = example) it does have a direct affect on latency. Don -----Original Message----- From: JP Vasseur [ = mailto:jvasseur@cisco.com]=20 Sent: Thursday, July 02, 2009 1:01 PM To: d.sturek@att.net Cc: 'Jonathan Hui'; Yusuf.Bashir@jci.com; roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Hi Don, I think that we are on the same page here: the number of hops should =20 not be *the* only metric but *could* be a metric. Agree ? Thanks. JP. On Jul 2, 2009, at 9:51 PM, Don Sturek wrote: > Hi Jonathan, > > I think the example Yusuf may be referring to involves data link level > security where packets are encrypted/decrypted hop by hop (please =20 > correct me > if I am wrong). In that scenario, it is good to minimize the number =20 > of hops > (within reason of course). If that involves a few extra re-=20 > transmissions > then you probably still end up with a more efficient packet delivery =20 > from a > latency point of view. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [ = mailto:roll-bounces@ietf.org] On Behalf =20 > Of > Jonathan Hui > Sent: Thursday, July 02, 2009 9:28 AM > To: Yusuf.Bashir@jci.com > Cc: roll@ietf.org; roll-bounces@ietf.org; gnawali@usc.edu > Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance =20 > from > theroot? > > > On Jul 2, 2009, at 8:48 AM, Yusuf.Bashir@jci.com wrote: >> >> Using low data rate 802.15.4 radios in commercial buildings we >> design our deployments >> to minimize hops and that has been an essential part of the success >> of our networks. The result of >> excessive hops is higher latency and higher probability of >> collisions which leads to devices timing out and going >> offline. This is an essential customer requirement for us. We also >> have data showing that when you do over the air downloads, >> minimizing hops is key to meeting our timing requirements. > > But would you agree that minimizing the number of transmissions on a > path is a better metric than hops in your case? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > = https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > = https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org = https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_002_01C9FBA7.0BA14B80 Content-Type: text/plain; name="ATT9312747.txt" Content-Transfer-Encoding: base64 Content-Description: ATT9312747.txt Content-Disposition: inline; filename="ATT9312747.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== ------_=_NextPart_002_01C9FBA7.0BA14B80-- ------_=_NextPart_001_01C9FBB0.DE967422-- From alexandru.petrescu@gmail.com Fri Jul 3 01:50:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7518F3A68FD; Fri, 3 Jul 2009 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 mBxJ0W-4VynF; Fri, 3 Jul 2009 01:50:01 -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 6D7E73A699A; Fri, 3 Jul 2009 01:50:00 -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 n638lsJI031404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2009 10:47:54 +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 n638oBK0026488; Fri, 3 Jul 2009 10:50:12 +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 n638oBpl014071; Fri, 3 Jul 2009 10:50:11 +0200 Message-ID: <4A4DC642.1050503@gmail.com> Date: Fri, 03 Jul 2009 10:50:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> <4A4D1A1E.3000804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Yusuf.Bashir@jci.com, gnawali@usc.edu, roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:50:02 -0000 JP Vasseur a crit : > > On Jul 2, 2009, at 10:35 PM, Alexandru Petrescu wrote: > >> JP - what is a metric? >> >> I consider the depth used by the DAG to be a metric - a hop count >> metric. When a node joins a DAG below a certain depth, it is using >> a metric: the number of hops between self and topmost node (LBR, >> DAG Root). >> >> As it stands now, the hopcount is _the_ metric of RPL. > > You can use another metric than the hop count, which is then used to > avoid loops. Hmm... I can't see a loop in terms of an energy metric, so I can't see how an energy metric solely would help avoid building loops. A loop-free path with a finite number of hops could be a loop path in terms of energy needed, if one of the links requires a huge amount of energy to send the packet (larger than the max bit encoded value). 20 nJ 2^20 J 0-----------0---------0 It is obvious what a loop means in terms of hop count, but unclear what a loop means in terms of other metrics, and even less clear in terms of a combination of metrics. Alex From jvasseur@cisco.com Fri Jul 3 01:51:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E053D3A68FD; Fri, 3 Jul 2009 01:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 hEXfoVRc1qwB; Fri, 3 Jul 2009 01:51:49 -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 6CDD53A67B3; Fri, 3 Jul 2009 01:51:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,340,1243814400"; d="scan'208";a="44282825" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 08:52:10 +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 n638qAcJ016959; Fri, 3 Jul 2009 10:52:10 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n638qAeU026958; Fri, 3 Jul 2009 08:52:10 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 10:52:10 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 10:52:09 +0200 Message-Id: <05C7D661-CAAA-44CC-82AD-D70C48385760@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A4DC642.1050503@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 3 Jul 2009 10:52:06 +0200 References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> <4A4D1A1E.3000804@gmail.com> <4A4DC642.1050503@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Jul 2009 08:52:09.0585 (UTC) FILETIME=[8CC38610:01C9FBBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1277; t=1246611130; x=1247475130; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=09from=09theroot? |Sender:=20; bh=+DfxcZtw1Mrnxg5l8TQt5JLzRiQ+uHWG7DUn3Cyw6c0=; b=a10Iqw1v46jnQYck9x9b0zRxCHM1W9m2ee2bUlca2TMlbCICSdruCDZAjW Za1ihutvvyTEyPCpBe2o2TQOk/bOJ/ijJRm5DWlpSoGJUpdbC4N+pY0OWOGO 0CMmJvAuT1; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, roll-bounces@ietf.org, Yusuf.Bashir@jci.com, gnawali@usc.edu Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:51:50 -0000 the concept of loop is not related to the metric used to compute the =20 path JP. On Jul 3, 2009, at 10:50 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Jul 2, 2009, at 10:35 PM, Alexandru Petrescu wrote: >>> JP - what is a metric? >>> I consider the depth used by the DAG to be a metric - a hop count =20= >>> metric. When a node joins a DAG below a certain depth, it is using >>> a metric: the number of hops between self and topmost node (LBR, >>> DAG Root). >>> As it stands now, the hopcount is _the_ metric of RPL. >> You can use another metric than the hop count, which is then used to >> avoid loops. > > Hmm... I can't see a loop in terms of an energy metric, so I can't see > how an energy metric solely would help avoid building loops. > > A loop-free path with a finite number of hops could be a loop path in > terms of energy needed, if one of the links requires a huge amount of > energy to send the packet (larger than the max bit encoded value). > > 20 nJ 2^20 J > 0-----------0---------0 > > It is obvious what a loop means in terms of hop count, but unclear =20 > what > a loop means in terms of other metrics, and even less clear in terms =20= > of > a combination of metrics. > > Alex > > From alexandru.petrescu@gmail.com Fri Jul 3 01:54:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E313A6C6C; Fri, 3 Jul 2009 01:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 F2BwYVjsfvcr; Fri, 3 Jul 2009 01:54:29 -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 63B033A6C99; Fri, 3 Jul 2009 01:54:29 -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 n638slID028683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2009 10:54:47 +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 n638slIi027666; Fri, 3 Jul 2009 10:54:47 +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 n638sk4c015630; Fri, 3 Jul 2009 10:54:46 +0200 Message-ID: <4A4DC756.7090106@gmail.com> Date: Fri, 03 Jul 2009 10:54:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com><017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com><018301c9fb50$82558d10$8700a730$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07B93A63@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93A63@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Yusuf.Bashir@jci.com, gnawali@usc.edu, roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hopdistance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:54:30 -0000 Pascal Thubert (pthubert) a crit : > Hi: > > > > Actually the draft recognizes that there are tons of metrics and then > algorithms to sort out those metrics. In the section where it lists other metrics it doesn't list the hopcount metric, which is the most widely used. > 4.1. Routing Metrics > > Routing metrics are used by the routing protocol to compute the > shortest path according to one of more defined metrics. IGPs such as > IS-IS ([RFC5120]) and OSPF ([RFC4915]) compute the shortest path > according to a Link State Data Base (LSDB) using link metrics > configured by the network administrator. Such metrics can represent > the link bandwidth (in which case the metric is usually inversely > proportional to the bandwidth), delay, etc. Note that in some cases > the metric is a polynomial function of several metrics defining > different link characteristics. The resulting shortest path cost is > equal to the sum (or multiplication) of the link metrics along the > path: such metrics are said to be additive or multiplicative metrics. > Some routing protocols support more than one metric: in the vast > majority of the cases, one metric is used per (sub)topology. Less > often, a second metric may be used as a tie breaker in the presence > of ECMP (Equal Cost Multiple Paths). The optimization of multiple > metrics is known as an NP complete problem and is sometimes supported > by some centralized path computation engine. This paragraph should say which is the most used metric. That is from RIP, OSPF and BGP. That is a metric which is hop count, or number of IP hops. This should be cited. > Such metrics can represent the link bandwidth (in which case the > metric is usually inversely proportional to the bandwidth), delay, > etc. I.e. in the above paragraph, the hop count could be mentioned explicitely. Alex From alexandru.petrescu@gmail.com Fri Jul 3 01:56:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F7B3A68FD for ; Fri, 3 Jul 2009 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 JxUEX9-a-7bZ for ; Fri, 3 Jul 2009 01:56:47 -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 1ED393A6C5A for ; Fri, 3 Jul 2009 01:56:46 -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 n638v1VL031203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2009 10:57:01 +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 n638v1PK028275; Fri, 3 Jul 2009 10:57:01 +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 n638v0pp016463; Fri, 3 Jul 2009 10:57:01 +0200 Message-ID: <4A4DC7DC.7070100@gmail.com> Date: Fri, 03 Jul 2009 10:57:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Philip Levis References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:56:48 -0000 Philip Levis a crit : > > On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: > >> Jonathan, >> >> From: Jonathan Hui >> Date: Thu, 2 Jul 2009 10:56:06 -0700 >> >> Things get a bit more tricky when dealing with multiple metrics >> simultaneously. With multiple metrics, nothing changes as long as the >> comparator function between two metric vectors is a strictly monotonic >> function. If that strictly monotonic function does not exist (i.e. the >> metrics are completely orthogonal), then things get a bit more >> difficult. One possible solution is that we require one or more of the >> path metrics to be strictly monotonic and the rule becomes: a node >> cannot go "deeper" in any of the monotonic metrics. This seems a bit >> over-constrained, so we were discussing whether we can relax this >> constraint and this is still work in progress. >> >> Here is a suggestion: >> >> Leave the hop count as is, and add a DAGCost field. The >> DAGCost field is a fixed-point value, say 16 bits of which 8 >> bits are the fractional part. The units for the cost field >> are hops, so a hop with a cost 0x0001 is equivalent to an >> additional 1/256th of a 'best case' hop and 0x0100 is >> equivalent to a complete additional 'best case' hop. The >> actual path cost is >> >> (DAGDepth << 8) + DAGCost >> >> Loop avoidance and parent selection is done using the path >> cost. In an outgoing DIO the DAGDepth MUST be larger than >> the maximum parent DAGDepth and the DAGCost MUST be large >> enough such that the path cost of the DIO is greater than >> the maximum parent path cost. >> >> Increasing the DAGCost is optional. If no node does so the >> result is the same as the current algorithm. Nodes are free >> to include metric containers with additional information. >> >> If a node makes use of multiple metrics the additional costs >> for one hop need not be additive. For example, if a link is >> both slow and energy intensive, the link cost could be >> the average of the two, instead of their sum. >> >> What do you think? > > Richard, > > This seems like a totally reasonable metric to use, but I'd be wary of > saying it's *the* metric to use. Some implementations are going to want > to consider hopcount, others won't. It's just another metric. Rather > than hardwire hopcount based assumptions into the protocol design, we > should put it on equal footing as other metrics. Correspondingly, the > protocol should have general, metric-independent mechanisms for > detecting and avoiding loops. Phil, what does 'loop' mean when metrics other than hopcount are used? What does a loop look like when e.g. ETX is used as metric? Alex From alexandru.petrescu@gmail.com Fri Jul 3 02:06:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC26228C133; Fri, 3 Jul 2009 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 yMIOr5jPnwmy; Fri, 3 Jul 2009 02:06:33 -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 1120F3A6A86; Fri, 3 Jul 2009 02:06:23 -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 n6396gDS009327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2009 11:06:42 +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 n6396gE6031017; Fri, 3 Jul 2009 11:06:42 +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 n6396f6P020265; Fri, 3 Jul 2009 11:06:42 +0200 Message-ID: <4A4DCA21.3050708@gmail.com> Date: Fri, 03 Jul 2009 11:06:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <636808739.17704991246508534857.JavaMail.root@mail02.pantherlink.uwm.edu> <871vozxih5.fsf@kelsey-ws.hq.ember.com> <743BDEE5-FEC1-4724-B9CD-9244E959183F@archrock.com> <017501c9fb4e$7a7f6540$6f7e2fc0$@sturek@att.net> <53800201-E0C1-4136-913A-499E46947E91@cisco.com> <4A4D1A1E.3000804@gmail.com> <4A4DC642.1050503@gmail.com> <05C7D661-CAAA-44CC-82AD-D70C48385760@cisco.com> In-Reply-To: <05C7D661-CAAA-44CC-82AD-D70C48385760@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Yusuf.Bashir@jci.com, gnawali@usc.edu, roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:06:33 -0000 JP Vasseur a crit : > the concept of loop is not related to the metric used to compute the path The concept of loop is even less related to the effects of link loss ratio, asymmetry in the loss ratios between the two directions of each link, and interference among the successive links of a path (aka ETX). I am wondering which metric other than hopcount could help build loop-free trees and paths spanning a graph... Alex From jvasseur@cisco.com Fri Jul 3 04:04:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC193A6CB8 for ; Fri, 3 Jul 2009 04:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 WoLdZH9QiUQ8 for ; Fri, 3 Jul 2009 04:04:47 -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 138983A6BB1 for ; Fri, 3 Jul 2009 04:04:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,341,1243814400"; d="scan'208";a="44301218" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 11:05:08 +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 n63B58tg029906; Fri, 3 Jul 2009 13:05:08 +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.14.3) with ESMTP id n63B58iE016147; Fri, 3 Jul 2009 11:05:08 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); Fri, 3 Jul 2009 13:05:08 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 13:05:06 +0200 Message-Id: <6453014F-F0FE-457F-83C5-C99C5064CD99@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A4DC7DC.7070100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 3 Jul 2009 13:05:02 +0200 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Jul 2009 11:05:07.0106 (UTC) FILETIME=[1FBCA020:01C9FBCE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3560; t=1246619108; x=1247483108; 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:=20Clarifications=20about=20DT's=20proposal |Sender:=20; bh=+iEFiVimG28mpFS/e7R2Yak65PRSnUmyWCV5j+Digy8=; b=FrKwx/oLpPmS1F++Rg6zJ9tTfJAoO4BCaMIMQyP5rdV626cwCW/Kil02MY WYu+a+EJydIGIbS+MDKsRUfuWZWCEPg3tVVyvD3w2uu6LFTXJzU5Dr6OvHHo undS0Fq78M; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: [Roll] Clarifications about DT's proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 11:04:48 -0000 Alex and all, There is clearly a confusion between the use of hop count (depth) to =20 avoid loops, the use of the metric to choose a parent (regardless of =20 the depth by the way), rules to re-attach to a potential deeper =20 parents offering a best path metric, ... What I suggested to the DT (stay tune for a few hours) is to show =20 these rules using simple examples to make sure that every is on the =20 same page. Hope that this will help. JP. On Jul 3, 2009, at 10:57 AM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: >>> Jonathan, >>> >>> From: Jonathan Hui >>> Date: Thu, 2 Jul 2009 10:56:06 -0700 >>> >>> Things get a bit more tricky when dealing with multiple metrics >>> simultaneously. With multiple metrics, nothing changes as long as =20= >>> the >>> comparator function between two metric vectors is a strictly =20 >>> monotonic >>> function. If that strictly monotonic function does not exist =20 >>> (i.e. the >>> metrics are completely orthogonal), then things get a bit more >>> difficult. One possible solution is that we require one or more =20 >>> of the >>> path metrics to be strictly monotonic and the rule becomes: a node >>> cannot go "deeper" in any of the monotonic metrics. This seems a =20= >>> bit >>> over-constrained, so we were discussing whether we can relax this >>> constraint and this is still work in progress. >>> >>> Here is a suggestion: >>> >>> Leave the hop count as is, and add a DAGCost field. The >>> DAGCost field is a fixed-point value, say 16 bits of which 8 >>> bits are the fractional part. The units for the cost field >>> are hops, so a hop with a cost 0x0001 is equivalent to an >>> additional 1/256th of a 'best case' hop and 0x0100 is >>> equivalent to a complete additional 'best case' hop. The >>> actual path cost is >>> >>> (DAGDepth << 8) + DAGCost >>> >>> Loop avoidance and parent selection is done using the path >>> cost. In an outgoing DIO the DAGDepth MUST be larger than >>> the maximum parent DAGDepth and the DAGCost MUST be large >>> enough such that the path cost of the DIO is greater than >>> the maximum parent path cost. >>> >>> Increasing the DAGCost is optional. If no node does so the >>> result is the same as the current algorithm. Nodes are free >>> to include metric containers with additional information. >>> >>> If a node makes use of multiple metrics the additional costs >>> for one hop need not be additive. For example, if a link is >>> both slow and energy intensive, the link cost could be >>> the average of the two, instead of their sum. >>> >>> What do you think? >> Richard, >> This seems like a totally reasonable metric to use, but I'd be wary =20= >> of saying it's *the* metric to use. Some implementations are going =20= >> to want to consider hopcount, others won't. It's just another =20 >> metric. Rather than hardwire hopcount based assumptions into the =20 >> protocol design, we should put it on equal footing as other =20 >> metrics. Correspondingly, the protocol should have general, metric-=20= >> independent mechanisms for detecting and avoiding loops. > > Phil, what does 'loop' mean when metrics other than hopcount are =20 > used? What does a loop look like when e.g. ETX is used as metric? > > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 3 05:06:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DCF28C28D for ; Fri, 3 Jul 2009 05:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 EE0VRJtpTZ1z for ; Fri, 3 Jul 2009 05:06:26 -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 0156A28C288 for ; Fri, 3 Jul 2009 05:06:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,341,1243814400"; d="scan'208";a="44308583" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 12:06:48 +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 n63C6mbj016321; Fri, 3 Jul 2009 14:06:48 +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.14.3) with ESMTP id n63C6m87007128; Fri, 3 Jul 2009 12:06:48 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 14:06:48 +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 Jul 2009 14:06:47 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93C69@xmb-ams-337.emea.cisco.com> In-Reply-To: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn6nyBJ+yNQoKE8T9SgXtunq0YWcwBNRXOA References: <721410963.17661851246488080156.JavaMail.root@mail02.pantherlink.uwm.edu> <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 03 Jul 2009 12:06:48.0200 (UTC) FILETIME=[BDC2C080:01C9FBD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2173; t=1246622808; x=1247486808; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=m4P8Id+iFsetc8uVkyii03XUidj+4Fawl7SVy0NFc48=; b=M5wGCC8Sn0ykm2rKrkViTck5ij9PEFoPLUGGokOsZ2b6FalCWnxRnV7kMo wf1WwaMNwCY8d4u5AvUyM9i/v/Yw3momPU570nTJ7vP+IKUIsJNOEWDFkh3B DmmaV6iQa2; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 12:06:27 -0000 Agreed.=20 The idea on the table would be to select a preferred parent (that might not be least depth because depth might not be the foremost argument in parent selection) and then constrain all other parents to be not_deeper. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal >Sent: jeudi 2 juillet 2009 00:56 >To: roll >Subject: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > >RPL allows a node to have parents with different depths from the root. By choosing deeper neighbors as >parents, a node increases its own depth (required to be more than that of any of its parents to avoid loops) >and thus makes itself less attractive for selection as a parent. > >RPL also allows a node to discard its deeper parents to improve its own depth and thus make itself more >attactive for selection as a parent. But this is not mandatory. > >The question is what is the inherent benefit of this flexibility? Why is it that such a DAG may lead to better >routes than one based strictly on min hop-distance (i.e. where a node would be required to discard parents >when it finds less deeper ones)? > >Under the RPL approach, the depth of a node is an upper bound on its hop distance from the root. It just tells >that a packet forwarded to the node may take anywhere between 1 and the "depth" hops to reach the root (unless >the node maintains the "min_hop_distance" from the root as well, in which case a packet forwarded to the node >may take any where between "min_hop_distance" and "depth" hops to reach the root). The end result is that a >node has very little control over the number of hops a packet, it forwards, takes to reach the root. > >It seems to me that forcing the depth to be same as the min hop distance would still allow all the benefits of >DAGs (loop avoidance, flexible routes in face of topology changes) while assigning a better meaning to the >term "depth". > >Thanks >Mukul > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 3 05:06:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8ED3A6E54 for ; Fri, 3 Jul 2009 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.963 X-Spam-Level: X-Spam-Status: No, score=-9.963 tagged_above=-999 required=5 tests=[AWL=0.636, 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 YFY1-iho2oHy for ; Fri, 3 Jul 2009 05:06:28 -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 965E728C288 for ; Fri, 3 Jul 2009 05:06:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,341,1243814400"; d="scan'208";a="44308592" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 12:06:51 +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 n63C6oiS004298; Fri, 3 Jul 2009 14:06:50 +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.14.3) with ESMTP id n63C6oNT007149; Fri, 3 Jul 2009 12:06:50 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 Jul 2009 14:06:50 +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 Jul 2009 14:06:50 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93C6B@xmb-ams-337.emea.cisco.com> In-Reply-To: <2F5F2067-96A5-464A-8817-98C174A4B537@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn6n80Rujxfk2v2Qj277IIzkb24awBNKRyw References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> <2F5F2067-96A5-464A-8817-98C174A4B537@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Mukul Goyal" X-OriginalArrivalTime: 03 Jul 2009 12:06:50.0739 (UTC) FILETIME=[BF462C30:01C9FBD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1817; t=1246622811; x=1247486811; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=c40QvVneRSpPrHBmFwYG4Pjn3CW+qg1PUybUb+XgZR8=; b=V73z9TW3u5BnaZvI0UfI4Ql0bqZMYKBM324qSDd6BTh2itsM0iqAwGzBGv LM55hMDU0mAgWdoDaCHJfwS+ujZN7kQf6oOkkrXLhVqJ8V8x1jP787vA/Xue EceItXyU41; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 12:06:28 -0000 Hi Phil: What we call depth here does not have to represent a hop count. It should be incremented by a number that represents an abstraction of the cost to the parent and that cannot be null.=20 What that langua franca metric is really is and by what it is incremented not settled yet. The proposal on the table is to give a range for the per hop increment. The range could be variable per interface type, and it would be something like 1 to 8. We could decide that on radio networks we normalize ETX within the acceptable range and rescale that to 1 .. 8, that way ETX would be the depth increment.=20 On other interface types, that could be something else. Including the fact that you have a battery that you use to get over that interface and that's going down. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis >Sent: jeudi 2 juillet 2009 01:01 >To: Mukul Goyal >Cc: roll >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > > >On Jul 1, 2009, at 3:55 PM, Mukul Goyal wrote: > >> Why is it that such a DAG may lead to better routes than one based >> strictly on min hop-distance (i.e. where a node would be required to >> discard parents when it finds less deeper ones)? > >There is a tremendous amount of research in wireless which has shown >that min hop-distance is not a good metric for wireless networks. >DeCouto's paper is probably the best experimental study: > >http://pdos.csail.mit.edu/~rtm/papers/etx.pdf > >Any proposal which suggests that routing should be in terms of hop- >count is dead in the water. > >Phil >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 3 06:34:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC0F3A657C for ; Fri, 3 Jul 2009 06:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.989 X-Spam-Level: X-Spam-Status: No, score=-9.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 kdPXWwNrd+Mb for ; Fri, 3 Jul 2009 06:34:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 37EF03A684E for ; Fri, 3 Jul 2009 06:33:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,342,1243814400"; d="scan'208";a="44316164" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 13:34:20 +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 n63DYKr6012113; Fri, 3 Jul 2009 15:34:20 +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.14.3) with ESMTP id n63DYKcw009663; Fri, 3 Jul 2009 13:34:20 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 15:34:20 +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 Jul 2009 15:34:15 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93CCE@xmb-ams-337.emea.cisco.com> In-Reply-To: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from the root? Thread-Index: Acn6oMQyT+X6KnSnTFuwWupmn27rFgBQe34Q References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 03 Jul 2009 13:34:20.0111 (UTC) FILETIME=[F824C5F0:01C9FBE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3004; t=1246628060; x=1247492060; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20the=20root? |Sender:=20; bh=6Tsmz4+2tGNmnKW/Qp9T7pVLE89UDtd8nc8m2YEBJjY=; b=XIV6bUwLzmZJO8HX2lNS1cWdNz+hUqhp3fu4QxwZNjXO2lWe4sus5X0YWR BymhFVBF3ANYpMXIrkWdtpTjNh1l8NEjmfA45MG4qqprzeGg6YsaDxTa9rSX v7SHmEfPuQ; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:34:13 -0000 Hi Mukul: The only case I see is when the parent that has the least depth also has poor properties in terms of the metrics that are used for parent selection. In that case, the preferred parent will be deeper than the shallowest parent. In general - and in spirit, I'm like you, I do not see the point of having parents that are deeper than the preferred parent. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal >Sent: jeudi 2 juillet 2009 01:08 >To: roll >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? > >Let me rephrase: > >The question is why is it that a DAG where a node can have parents with different depths is inherently better >than one where a node can have parents of same depth only (where the depth may or may not be same as the min >hop distance from the root)? > >Thanks >Mukul > >----- Original Message ----- >From: "Mukul Goyal" >To: "roll" >Sent: Wednesday, July 1, 2009 5:55:54 PM GMT -06:00 US/Canada Central >Subject: [Roll] RPL: why not base a DAG on the min hop distance from the root? > >RPL allows a node to have parents with different depths from the root. By choosing deeper neighbors as >parents, a node increases its own depth (required to be more than that of any of its parents to avoid loops) >and thus makes itself less attractive for selection as a parent. > >RPL also allows a node to discard its deeper parents to improve its own depth and thus make itself more >attactive for selection as a parent. But this is not mandatory. > >The question is what is the inherent benefit of this flexibility? Why is it that such a DAG may lead to better >routes than one based strictly on min hop-distance (i.e. where a node would be required to discard parents >when it finds less deeper ones)? > >Under the RPL approach, the depth of a node is an upper bound on its hop distance from the root. It just tells >that a packet forwarded to the node may take anywhere between 1 and the "depth" hops to reach the root (unless >the node maintains the "min_hop_distance" from the root as well, in which case a packet forwarded to the node >may take any where between "min_hop_distance" and "depth" hops to reach the root). The end result is that a >node has very little control over the number of hops a packet, it forwards, takes to reach the root. > >It seems to me that forcing the depth to be same as the min hop distance would still allow all the benefits of >DAGs (loop avoidance, flexible routes in face of topology changes) while assigning a better meaning to the >term "depth". > >Thanks >Mukul > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 3 06:50:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03D73A6E52 for ; Fri, 3 Jul 2009 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=0.587, 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 apKVYBmXUPf0 for ; Fri, 3 Jul 2009 06:50:56 -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 534193A6914 for ; Fri, 3 Jul 2009 06:50:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,342,1243814400"; d="scan'208";a="44318243" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 13:51:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n63DpILI005324; Fri, 3 Jul 2009 15:51: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.14.3) with ESMTP id n63DpIfs015288; Fri, 3 Jul 2009 13:51:18 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 15:51:18 +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 Jul 2009 15:51:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> In-Reply-To: <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle in draft-dt-roll-rpl-00.txt Thread-Index: Acn6wXK+KJ+VuHFlRs2K9QhsT+kb6ABI23Xg References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Jonathan Hui" X-OriginalArrivalTime: 03 Jul 2009 13:51:18.0480 (UTC) FILETIME=[57238D00:01C9FBE5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2317; t=1246629078; x=1247493078; 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[Roll]=20Trickle=20in=20draft-dt-roll-r pl-00.txt |Sender:=20; bh=45mIl+3Z+H0jnd7k1ZyMrbaYLI5Pma9TEf6Q007uw9Q=; b=ad5q5eJ2C9+nhEUBdesVSQk2mwhqPFVsO/M1xAOcJaVtHTITHlsvj+TUtP JWXStMIz8B9jIaEV5pE2m4l8vSaA4tC8VQJZ9ysbqLGs1Nm9pB/G81H3kFAx x5yEPlgVil; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:50:57 -0000 Hi Phil: I think I asked you that same question in Dublin but now we have a context. What I'd really like to suppress is the behavior of a router being a router, as opposed to suppressing some RAs from every routers. Like if I have many of other routers around I could yield and suppress RAs totally. The idea being that some nodes act as routers for some time and then they stop because they think they've done enough. Neighbors node discovering a lesser density take over and now act as routers. Could you adapt your trickle thinking to get there? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis >Sent: jeudi 2 juillet 2009 05:01 >To: Jonathan Hui >Cc: roll@ietf.org; Omprakash Gnawali >Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt > > >On Jul 1, 2009, at 7:35 PM, Jonathan Hui wrote: > >> >> On Jul 1, 2009, at 7:31 PM, Omprakash Gnawali wrote: >>> Just one data point from the CTP paper (which does not use >>> suppression) - it has been known to work efficiently even in networks >>> with node degree of up to (214,305) or (114,120). That is pretty >>> dense. >> >> Try the same experiment with LPL set to a reasonable duty cycle :) >> >> I'm not saying that suppression is necessary in all cases - just >> necessary in some cases. While we should be link agnostic, we >> should also be cognizant of link protocols that are likely to be used. > >I agree. I would take the CTP results to say that a network *can* >work without suppression, but it's quite clear that doing so is >desirable. > >I'll go out on a limb and say that exactly how the suppression works >is something which should not be specified yet: that leaves it open >for future work to figure out, just as 793 doesn't specify fast >retransmit. Instead, the specification should state the MUSTs of when >RAs are sent necessary for correct operation and note that additional >RAs MAY be sent. I'd interpret this as MUSTs of when the timer must >be reset and when packets MUST NOT increment c. > >Phil > > > > > > > > > > > > > > > > > > > I'd > >Phil >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Yusuf.Bashir@jci.com Fri Jul 3 06:53:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2303A6CE9; Fri, 3 Jul 2009 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 e6E3bJTVojVX; Fri, 3 Jul 2009 06:53:26 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 09FB53A688D; Fri, 3 Jul 2009 06:53:25 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSk4NawY6CQYDmTjhts0YrhfEXQfxjMcm@postini.com; Fri, 03 Jul 2009 06:53:50 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009070308535597-818936 ; Fri, 3 Jul 2009 08:53:55 -0500 In-Reply-To: References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> To: Philip Levis MIME-Version: 1.0 X-KeepSent: B81AE744:E9907A82-862575E8:004BBBB7; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Yusuf.Bashir@jci.com Message-ID: Date: Fri, 3 Jul 2009 08:53:32 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/03/2009 08:53:40 AM, Serialize complete at 07/03/2009 08:53:40 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/03/2009 08:53:55 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/03/2009 08:54:04 AM, Serialize complete at 07/03/2009 08:54:04 AM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:53:27 -0000
 Phil,
Your Golden Gate Bridge example is very interesting.Did you have to alternate channels as you hopped to maintain
 a certain throughput level with the 40 hops or did the application not care?


Regards,
Yusuf
 


From: Philip Levis <pal@cs.stanford.edu>
To: Richard Kelsey <richard.kelsey@ember.com>
Cc: roll@ietf.org
Date: 07/02/2009 07:57 PM
Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the        root?





On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote:

> Jonathan,
>
>   From: Jonathan Hui <jhui@archrock.com>
>   Date: Thu, 2 Jul 2009 10:56:06 -0700
>
>   Things get a bit more tricky when dealing with multiple metrics
>   simultaneously. With multiple metrics, nothing changes as long as  
> the
>   comparator function between two metric vectors is a strictly  
> monotonic
>   function. If that strictly monotonic function does not exist (i.e.  
> the
>   metrics are completely orthogonal), then things get a bit more
>   difficult. One possible solution is that we require one or more of  
> the
>   path metrics to be strictly monotonic and the rule becomes: a node
>   cannot go "deeper" in any of the monotonic metrics. This seems a bit
>   over-constrained, so we were discussing whether we can relax this
>   constraint and this is still work in progress.
>
> Here is a suggestion:
>
> Leave the hop count as is, and add a DAGCost field.  The
> DAGCost field is a fixed-point value, say 16 bits of which 8
> bits are the fractional part.  The units for the cost field
> are hops, so a hop with a cost 0x0001 is equivalent to an
> additional 1/256th of a 'best case' hop and 0x0100 is
> equivalent to a complete additional 'best case' hop.  The
> actual path cost is
>
>    (DAGDepth << 8) + DAGCost
>
> Loop avoidance and parent selection is done using the path
> cost.  In an outgoing DIO the DAGDepth MUST be larger than
> the maximum parent DAGDepth and the DAGCost MUST be large
> enough such that the path cost of the DIO is greater than
> the maximum parent path cost.
>
> Increasing the DAGCost is optional.  If no node does so the
> result is the same as the current algorithm.  Nodes are free
> to include metric containers with additional information.
>
> If a node makes use of multiple metrics the additional costs
> for one hop need not be additive.  For example, if a link is
> both slow and energy intensive, the link cost could be
> the average of the two, instead of their sum.
>
> What do you think?

Richard,

This seems like a totally reasonable metric to use, but I'd be wary of  
saying it's *the* metric to use. Some implementations are going to  
want to consider hopcount, others won't. It's just another metric.  
Rather than hardwire hopcount based assumptions into the protocol  
design, we should put it on equal footing as other metrics.  
Correspondingly, the protocol should have general, metric-independent  
mechanisms for detecting and avoiding loops.

Jonathan's concerns about integrating metrics into a single cost is  
well-founded: it's fraught with all kinds of problematic edge cases  
which you have to hack around. Advertising the vector is a much safer,  
more flexible, and less likely to run into broken assumptions which  
have to be later worked around.

As a concrete example, one reason why CTP uses a 16-bit encoding of  
ETX was a need for precision to at least tenths of an ETX as well as  
the ability to support > 25 hops (the maximum with 8 bits). Our  
concrete use case for the second requirement was the network deployed  
along the length of the Golden Gate Bridge, which was ~40 hops long.

Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From richard.kelsey@ember.com Fri Jul 3 08:40:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DBD3A6C44 for ; Fri, 3 Jul 2009 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 mt2-+TeYXtF4 for ; Fri, 3 Jul 2009 08:40:55 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B32933A6A8F for ; Fri, 3 Jul 2009 08:40:55 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 11:41:16 -0400 Date: Fri, 03 Jul 2009 11:41:42 -0400 Message-Id: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 03 Jul 2009 15:41:16.0271 (UTC) FILETIME=[B3BA8FF0:01C9FBF4] Subject: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:40:56 -0000 ROLL has a very aggressive schedule. The argument was that we could make rapid progress by building on existing protocols that are already in use. That doesn't seem to be what we are doing. In particular, there are a number of mechanisms in draft-dt-roll-rpl-00 which I do not believe have seen widespread use. Some of them have been discussed on the mailing list. The nature of those discussions indicates that those features are neither well understood or in common use. I am not saying that we shouldn't use any or all of these, or even necessarily singling out these particular features. My point is we should strongly limit the amount of algorithm development that we undertake. This is a time for refining, not inventing. - using separate metrics for loop avoidance and for parent selection - allowing a node to have multiple parents (using a DAG instead of a tree) - using Trickle to suppress DAG (or tree) discovery messages - routing messages via siblings - the Destination Advertisement mechanism I am certainly not aware of everything in IP or in the sensor network space. If any of these are widely used, I suggest that we make sure we are not modifying them in significant ways. There are a lot of ROLL-style networks out there today. If the routing algorithms they use are good enough, and I believe that they are, then weshould use the same mechanisms. If they are not good enough, then we will have to back off on the schedule. -Richard Kelsey From pthubert@cisco.com Fri Jul 3 08:42:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A41C3A6A8F for ; Fri, 3 Jul 2009 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.034 X-Spam-Level: X-Spam-Status: No, score=-9.034 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=1, 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 hROFGUCvX04v for ; Fri, 3 Jul 2009 08:42:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9021B3A679F for ; Fri, 3 Jul 2009 08:42:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,342,1243814400"; d="scan'208";a="44330775" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 15:42:45 +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 n63Fgj5a005074; Fri, 3 Jul 2009 17:42:45 +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.14.3) with ESMTP id n63Fgj51019213; Fri, 3 Jul 2009 15:42:45 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 17:42:45 +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 Jul 2009 17:42:40 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> In-Reply-To: <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn7Om2pmJgrRv5zTC+iOvieGprWNwAuchpA References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Jonathan Hui" X-OriginalArrivalTime: 03 Jul 2009 15:42:45.0687 (UTC) FILETIME=[E9065C70:01C9FBF4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3552; t=1246635765; x=1247499765; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=Q8TqQNVd0vsiFetp1iN3OFX+WKQNaisYu4HwpMnws1k=; b=rlytcWE1bdAm9H0VFZFo49L2fYvAdxHsKmtU+7odkIAi7npJy4IUBs2s9N gUa+8Wh5V8uXlqEvXAKA2U+VjGLlOhL2ROJdkXDj3oTuWiOI69Ih5zeyOATF 7PTah9uOMr; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:42:25 -0000 >In this and similar situations, RPL lets hop count trump all >other routing constraints. This seems like a bad idea. That would. But RPL only used the depth once the parents are selected, by means that do not have to include the depth at all. Because the draft says that this part (the plugin) is out of scope than it appears that the depth is THE metric. No. The depth is a tool for loop avoidance and stability. It comes after the parent selection happened. All the metrics that you currently use are welcome. I tend to agree that 1-increment per link whatever the link is not panacea either. Hopefully we'll end up converging on that. From Mukul's comments on ETX I find that there should be a way to translate the link poor behavior relative to expected as a good reason to fake a worse depth - be a bit more greedy. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: jeudi 2 juillet 2009 19:28 >To: Jonathan Hui >Cc: roll@ietf.org >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > >Jonathan, > > From: Jonathan Hui > Date: Thu, 2 Jul 2009 09:19:25 -0700 > > On Jul 2, 2009, at 8:50 AM, Richard Kelsey wrote: > > > To see this, consider a network with four nodes LBR, A, B, > > and C, where A and B do not share a link and the LBR<->B > > link is inferior enough that the LBR<->A<->C<->B route is > > significantly better than the one-hop LBR<->B route. > > > > LBR > > / \ > > A B > > \ / > > C > > > > LBR, as the root, sends out an RA at depth 0, heard by both > > A and B. They in turn send out their RAs at depth 1 and C > > picks A as a parent, the cost of the LBR<->B link making B > > an bad choice. C then sends out an RA at depth 2, which is > > ignored by A and B because C's depth is greater than theirs. > > > > The upshot is that B's route to LBR almost always uses the > > poor-quality LBR<->B link, rather than the preferred route > > via C and A. The 'almost always' is because you might get > > lucky and B might not hear the initial RA from the LBR and > > hear C's RA first. > > > I was referring to data-path loop detection. > >Yes, sorry, I missed that. > > But to address your specific point - with the example you give, it is > unclear what the overall best situation is. From B's point of view, it > is better to go through C. But from C's point of view, it may be > better to have two feasible successors A and B. If it is acceptable > for B to communicate directly with the LBR, then that might be the > overall better solution. In the end, I don't think we can feasibly > optimize each individual node locally while optimizing the entire > routing graph. What is globally optimal is not even well defined... > >The problem isn't that hop count doesn't pick the best >route, but that it often doesn't even pick a good one. To >quote from a posting by Philip Levis: > > There is a tremendous amount of research in wireless which > has shown that min hop-distance is not a good metric for > wireless networks. > >In this and similar situations, RPL lets hop count trump all >other routing constraints. This seems like a bad idea. > > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Jul 3 09:16:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAAC3A6F4B for ; Fri, 3 Jul 2009 09:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.318 X-Spam-Level: X-Spam-Status: No, score=-10.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 YFDNGM+X8alZ for ; Fri, 3 Jul 2009 09:16:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9F8203A688D for ; Fri, 3 Jul 2009 09:16:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,343,1243814400"; d="scan'208";a="44333121" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 16:16:40 +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 n63GGem0012159; Fri, 3 Jul 2009 18:16:40 +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.14.3) with ESMTP id n63GGehJ026349; Fri, 3 Jul 2009 16:16:40 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); Fri, 3 Jul 2009 18:16:39 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 18:16:39 +0200 Message-Id: <933B5FEE-55D9-4574-A82D-D603FCBE4C0E@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87eisxyds9.fsf@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 v935.3) Date: Fri, 3 Jul 2009 18:16:38 +0200 References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Jul 2009 16:16:39.0176 (UTC) FILETIME=[A5142880:01C9FBF9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2941; t=1246637800; x=1247501800; 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[Roll]=20ROLL=20and=20new=20technology |Sender:=20; bh=fnLjPU1QoRmcoCEe3k+iry+NgU2EFGu7CvxefIUfqjg=; b=dnIYSS8cPWd8zxyhNxFPhf1iU1qD4CmwXH7l5kzi682okjSNUvlyMvIX+n wSqscSKTFshvqDlZ6kabjA+cfZfz5X6ag3ocQLeAeSOlu5obye1yVl9HzaPO dg7BhdBe6+; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:16:58 -0000 Hi Richard, Few observations in line. On Jul 3, 2009, at 5:41 PM, Richard Kelsey wrote: > ROLL has a very aggressive schedule. The argument was that > we could make rapid progress by building on existing > protocols that are already in use. This was not the argument. The reason for this aggressive schedule is the urgent need to have a routing solution for LLN. As spelled out in our charter, we could either extend an existing protocol or define a new one, or any mix of the two. > That doesn't seem to be > what we are doing. In particular, there are a number of > mechanisms in draft-dt-roll-rpl-00 which I do not believe > have seen widespread use. Some of them have been discussed > on the mailing list. The nature of those discussions > indicates that those features are neither well understood or > in common use. I do agree with you that some of the proposed features need clarifications and require further discussion and agreement. Bear in mind that we have 3 candidates among which the DT draft that was posted in its first revision a few days ago. > > I am not saying that we shouldn't use any or all of these, > or even necessarily singling out these particular features. > My point is we should strongly limit the amount of algorithm > development that we undertake. This is a time for refining, > not inventing. > > - using separate metrics for loop avoidance and for parent > selection > > - allowing a node to have multiple parents (using a DAG > instead of a tree) > > - using Trickle to suppress DAG (or tree) discovery > messages > > - routing messages via siblings > > - the Destination Advertisement mechanism > > I am certainly not aware of everything in IP or in the > sensor network space. If any of these are widely used, I > suggest that we make sure we are not modifying them in > significant ways. > > There are a lot of ROLL-style networks out there today. If > the routing algorithms they use are good enough, and I > believe that they are, then weshould use the same > mechanisms. If they are not good enough, then we will have > to back off on the schedule. This is why we have a WG: to discuss and agree on what the solution should look like. I am agreeing with you here on the fact that there is no need to re- invent the wheel if something exists that works and satisfies our requirements. On the other hand, there is no need to prevent ourselves from inventing something new. We need to find the right trade-off. If you have a solution that you think works, please propose it and it will be discussed in the WG of course. Thanks again for your excellent contribution to the WG by the way. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From quentin.lampin@orange-ftgroup.com Fri Jul 3 09:33:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CFA3A6F5F for ; Fri, 3 Jul 2009 09:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.989 X-Spam-Level: ** X-Spam-Status: No, score=2.989 tagged_above=-999 required=5 tests=[AWL=3.780, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXU71G93UL7P for ; Fri, 3 Jul 2009 09:33:20 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 5944F3A6F60 for ; Fri, 3 Jul 2009 09:33:19 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 18:33:41 +0200 Received: from [10.194.4.252] ([10.194.4.252]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 18:33:41 +0200 Message-ID: <4A4E32E3.90804@orange-ftgroup.com> Date: Fri, 03 Jul 2009 18:33:39 +0200 From: quentin.lampin@orange-ftgroup.com User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2009 16:33:41.0306 (UTC) FILETIME=[0650D1A0:01C9FBFC] Subject: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:33:21 -0000 Hi everyone,

RPL specifies that a node can subscribe to more than one DAG.
Is it the intention to allow nodes to forward packets received from one DAG to another one?
If so, is there any mechanism that we could think of to prevent cross-DAGS loops?
If a packet arrives at a node which knows that the root is no longer reachable, forwarding accross DAGs might be useful...


Thanks for your comments,

Quentin Lampin

From dominique.barthel@orange-ftgroup.com Fri Jul 3 09:42:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C68A28C2C5 for ; Fri, 3 Jul 2009 09:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 HqhEmW9o3PuN for ; Fri, 3 Jul 2009 09:41:59 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 6CFAA28C2A6 for ; Fri, 3 Jul 2009 09:41:59 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 18:42:21 +0200 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_01C9FBFD.1AF3B5B6" Date: Fri, 3 Jul 2009 18:39:31 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF371391@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPL] multiple roots in a DAG Thread-Index: Acn7/Nb7Fgb7KDlvRKeFZdNIzid3Aw== From: To: X-OriginalArrivalTime: 03 Jul 2009 16:42:21.0327 (UTC) FILETIME=[3C45B9F0:01C9FBFD] Subject: [Roll] [RPL] multiple roots in a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:42:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FBFD.1AF3B5B6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello all, Many thanks to the Design Team for having released the RPL draft, providing us with material to ponder upon. Among others, we have a question about the use of multiple roots in a DAG. If I understand the draft correctly, multiple roots shall send "identical" DIOs with synchronized sequence numbers. Therefore, nodes will only know of one root (because they discard DIOs with same or lower seqnum). Most nodes will likely hear from only one root anyway, since intermediate nodes only propagate *one* DIO per DAGID. This results in a watershed effect. The routing algorithm at a node can therefore only chose among parents that lead to the same root in that DAG. Was there any consideration given to nodes knowing about several roots? Or is the use of multiple DAGs recommended instead : this would go counter the advocated intention of using multiple DAGs for serving competing constraints (3.3.1.2)...=20 Best regards, Dominique ------_=_NextPart_001_01C9FBFD.1AF3B5B6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [RPL] multiple roots in a DAG

Hello all,

Many thanks to the Design Team for = having released the RPL draft, providing us with material to ponder = upon.
Among others, we have a question about = the use of multiple roots in a DAG.

If I understand the draft correctly, = multiple roots shall send "identical" DIOs with synchronized = sequence numbers.
Therefore, nodes will only know of one = root (because they discard DIOs with same or lower seqnum).
Most nodes will likely hear from only = one root anyway, since intermediate nodes only propagate *one* DIO per = DAGID.
This results in a watershed = effect.
The routing algorithm at a node can = therefore only chose among parents that lead to the same root in that = DAG.
Was there any consideration given to = nodes knowing about several roots? Or is the use of multiple DAGs = recommended instead : this would go counter the advocated intention of = using multiple DAGs for serving competing constraints (3.3.1.2)... =

Best regards,

Dominique

------_=_NextPart_001_01C9FBFD.1AF3B5B6-- From richard.kelsey@ember.com Fri Jul 3 10:23:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3521928C2E9 for ; Fri, 3 Jul 2009 10:23:33 -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.926, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=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 jODbsd4ToPZo for ; Fri, 3 Jul 2009 10:23:32 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4C1A93A6A11 for ; Fri, 3 Jul 2009 10:23:32 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 13:23:54 -0400 Date: Fri, 03 Jul 2009 13:24:20 -0400 Message-Id: <87d48hy917.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 03 Jul 2009 17:23:54.0912 (UTC) FILETIME=[0A909A00:01C9FC03] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 17:23:33 -0000 Date: Fri, 3 Jul 2009 17:42:40 +0200 From: "Pascal Thubert (pthubert)" >In this and similar situations, RPL lets hop count trump all >other routing constraints. This seems like a bad idea. That would. But RPL only used the depth once the parents are selected, by means that do not have to include the depth at all. Because the draft says that this part (the plugin) is out of scope than it appears that the depth is THE metric. No. The depth is a tool for loop avoidance and stability. It comes after the parent selection happened. All the metrics that you currently use are welcome. As I understand the draft, in the situation I described, RPL always (except if messages go unheard) picks the shorter route over the longer one. It doesn't matter what other metrics are in use. Here is the example again. If I have misunderstood how RPL works, please show me where this example is incorrect. Cconsider a network with four nodes LBR, A, B, and C, where A and B do not share a link and, according to the routing metric in use, the LBR<->B link is inferior enough that the LBR<->A<->C<->B route is significantly better than the one-hop LBR<->B route. LBR / \ A B \ / C 1) LBR, as the root, sends out an RA at depth 0, heard by both A and B. 2) A and B choose LBR as their parent, having heard no other other RAs. The order in which A and B choose a parent does not affect the outcome. 3) A and B send out their RAs at depth 1, in either order. 4) C picks A as a parent because the cost of the LBR<->B link makes B an bad choice. 5) C then sends out an RA at depth 2, which is ignored by B because C's depth is greater than B's. B's route to LBR is the poor-quality LBR<->B link, rather than the preferred route via C and A. The routing metric only affects C's choice of parent. It has no effect on B's choice. -Richard Kelsey From prvs=42940cc68=mukul@uwm.edu Sat Jul 4 00:20:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D6D3A68CC for ; Sat, 4 Jul 2009 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 VgwiUKYlnAOm for ; Sat, 4 Jul 2009 00:20:21 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id D66893A68C0 for ; Sat, 4 Jul 2009 00:20:20 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 04 Jul 2009 02:19:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 33D50B2000D for ; Sat, 4 Jul 2009 02:19:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh7M3XmAAckx for ; Sat, 4 Jul 2009 02:19:12 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0A9FDB2000C for ; Sat, 4 Jul 2009 02:19:12 -0500 (CDT) Date: Sat, 4 Jul 2009 02:19:12 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <271540263.18171481246691951958.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <569831629.18171441246691823396.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] fundamental (?) choice between convergence to "best" routes and (transient) loop avoidance in DV routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 07:27:44 -0000 Here is some food for thought: Its my conjecture that in DV routing, there is a fundamental choice to be made: either you can have ultimate convergence to best routes or you can avoid transient loops but you can not have both. Consider the following scenario: R / \ A-B | | C-D All links are bidirectional and link costs in both directions are same. All link costs are 1 except link B-R has cost 50 and A-B has cost 5. Case 1: --------- Suppose there is no attempt to avoid loops. Clearly, the routes to R from different nodes would be as follows: A: A->R C: C->A->R D: D->C->A->R B: B->D->C->A->R And the costs advertised by different nodes to R would be as follows: A: 1 C: 2 D: 3 B: 4 Suddenly, the cost of link A-R becomes 100. We have a classic "count to infinity" problem at hand. In the absence of any "poison reverse" solution, routing loops exist until B realizes that its best route to R is B->R. Other nodes also realize that they should go through B to reach R. In this case, we were able to converge to best routes but had to bear transient routing loops. Case 2: ---------------- Suppose we have loop avoidance in place in the form of an invariant DAG based on depths derived from initial link costs. The DAG is: B->D->C->A->R Since the DAG is invariant and a node can not choose a deeper node as parent, we are doomed to use the original suboptimal paths after the cost of link A-R changes from 1 to 100. In this case, we were able to avoid loops at the cost of being stuck with bad routes. Case 3: ------------------ Suppose we allow the DAG to change. When link A-R increases in cost from 1 to 100, A advertises a new depth and basically triggers a sequence of events similar to case 1. As in case 1, we converge to the best routes (and to a new DAG) after a transient during which the routing loops exist. It is my conjecture that the routing loops may not be avoidable no matter how the "costs" are mapped to the DAG "depths". From pthubert@cisco.com Sat Jul 4 05:48:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687533A6B9D for ; Sat, 4 Jul 2009 05:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.018 X-Spam-Level: X-Spam-Status: No, score=-8.018 tagged_above=-999 required=5 tests=[AWL=-1.419, 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 Z3uiqRcMwu0B for ; Sat, 4 Jul 2009 05:48:25 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 01F4F3A6B09 for ; Sat, 4 Jul 2009 05:48:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,347,1243814400"; d="scan'208";a="84543049" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2009 12:48:48 +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 n64Cmje0019343; Sat, 4 Jul 2009 14:48:45 +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.14.3) with ESMTP id n64Cmjg5007524; Sat, 4 Jul 2009 12:48:45 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); Sat, 4 Jul 2009 14:48:45 +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: Sat, 4 Jul 2009 14:48:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> In-Reply-To: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL and new technology Thread-Index: Acn79LlM3lus9uJXQPan5ANCI60yoAAqcf9g References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , X-OriginalArrivalTime: 04 Jul 2009 12:48:45.0454 (UTC) FILETIME=[C492FAE0:01C9FCA5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7962; t=1246711725; x=1247575725; 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[Roll]=20ROLL=20and=20new=20technology |Sender:=20; bh=7K4FL5jP2BtGbex5dA+8QyPcImEoa1H9V7U1gLYC7XE=; b=AVMm7WD7zOnO1zEODOVdw6oN7veRQ63/SnO23oUVzohYlQ5BZswQWhegaE Bf99BsK7H/b7NgbwWrLJspOcAJ/m1gdL0TC2PEjDHKSQmmWib5+u9lzCmb6x NaQt/uiH8a; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 12:48:26 -0000 Hi Richard: There is a wide consensus even in implementations to go for a Distance Vector approach. - Good thing, DV properties are very well know. We know RIP and its limitations, and we know that even in a clean wired space it would not fit the scale that we are considering. - Good thing, DV technology has evolved since then, and the techniques employed in IGRP and EIGRP have been widely deployed and verified over the last decade. I cannot argue on the specific implementation that you know best.=20 All I can say is that it is: 1) *inacceptable* to be content with the basic RIP mechanisms (INFINITY is 16 there for a reason or 2) 2) *useful* to learn from more modern DV protocols (route poisoning,=20 3) *necessary* to adapt to the LLN constraints and requirement=20 >what we are doing. In particular, there are a number of >mechanisms in draft-dt-roll-rpl-00 which I do not believe >have seen widespread use. Some of them have been discussed As you might have experienced yourself if you tried it and as the protocol designers well warned, RIP is generally recognized as wholly inadequate for large and complex networks (slow and costly due to count to infinity).=20 Since RIP, a number of DV improvements have been integrated in IGPs: - Source tracing (too costly for us in terms of states) - Composite metrics (IGRP, we're doing our on as part of the metrics work; trick is whether one fits it all forever and consequences if not) - Path holddown (early IGRP)=20 - Route poisoning (Later IGRP, improves Path holddown)=20 - Distributed Update ALgorithm (DUAL, in EIGRP) the diffusion algorithm prefers to create a temporary black hole than a loop, and saves on control to resolve the routing issue. You'll realize that RPL inherits from those with a few tweaks to support adhoc & mobility: - In particular, RPL benefits from the properties that were demonstrated by Garcia-Luna-Aceves for DUAL like you can safeluy move towards the root but cannot move down. - Yet RPL does not require reliable multicast for diffusion like EIGRP does, the trade off is that it is not always loopless unless the sequence is used.=20 The main tweaks are - The way a node is frozen (being frozen in RPL =3D=3D pertaining to a new DAG id of the node that found the breakage)=20 - and unfrozen (tree hop timer + seq as opposed to EIGRP query / reply) - The DAG hop timer to merge back DAGs (saves additional control messages, to do things orderly as opposed to swiftly) In the distributed update algorithm a router that discovers that it will get deeper becomes 'active'. It locks its routing table and diffuses the information. RPL does that by leaving the DAG and belonging to the self rooted DAG of the parent that discovers the breakage. The diffusion happens recursively: a child that has a solution to stay in the main DAG stays "passive" by remaining in the main DAG but losing that parent. A child that cannot freezes by following its parent in the detached DAG. > - using separate metrics for loop avoidance and for parent selection A node makes its own decision to select one or a number of other nodes as parents. That decision is ruled by the node's specific logic I call plugin for the lack of a better term. This comes from the fact that a L3 protocol works on abstractions that must be valid on multiple types of links and environments. We can't expect a single metric to express what we need to express to make a parent selection in ROLL. So we just took it off, this much is out of scope and will be instantiated per need. So you can have your own plugin that does exactly what your implementation does today to select a best parent. At that point you'll have to interact with nodes from different vendors and different generations, so you need to sort out a common metric to be avoid loops and guarantee stability. Separating the 2 actually gives you a lot more latitude in parent selection than enforcing any specific (set of) metric and logic. =20 > - allowing a node to have multiple parents (using a DAG instead of a tree) It is pretty clear from the requirements, though, that any spec that does not allow forwarding across multiple parents *is out*. Note that the fundamentals draft allowed that too. Now you can use RPL to build a tree if you limit to a single parent, so the protocol enables that as a degenerated case, like it allows the depth metric to be the parent selection metric as another degenerated case. > - routing messages via siblings That does not represent an uncontrolled risk. It mostly a way to improve on traditional DAG thinking to get more fwd solution, then again a MUST for LLNs. We note that having multiple parents and siblings enables the routing part that built the graph to let some latitude to the component that selects the next hop for a given packet. That feature is *heavily required* in LLNs because the link conditions can change a lot faster than the graph construction can cope with. > - the Destination Advertisement mechanism Yet another low risk technique because this mechanism does not draw the graph, it merely colors it. And it is triggered only for destination that need it so it is optional in a given deployment though required in implementations.=20 There are only 2 ways to do that simply, either sync db (ala OSPF) or repeat over and over (ala RIP). For the sake of simplicity and because of the mobility that's inherent to LLNs, the draft picked the latter. And yes, there are implementations of this that have been operated in multiple environments, radio and wired. On the Moon I'm unsure but maybe soon :) What I see here is a set of adaptations of rather well known techniques in the DV family plus a set of adaptations to meet LLN requirements. Pretty much what ROLL is chartered to do. There's still a lot of tuning to do but the main lines seem properly defined... Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: vendredi 3 juillet 2009 17:42 >To: roll@ietf.org >Subject: [Roll] ROLL and new technology > >ROLL has a very aggressive schedule. The argument was that >we could make rapid progress by building on existing >protocols that are already in use. That doesn't seem to be >what we are doing. In particular, there are a number of >mechanisms in draft-dt-roll-rpl-00 which I do not believe >have seen widespread use. Some of them have been discussed >on the mailing list. The nature of those discussions >indicates that those features are neither well understood or >in common use. > >I am not saying that we shouldn't use any or all of these, >or even necessarily singling out these particular features. >My point is we should strongly limit the amount of algorithm >development that we undertake. This is a time for refining, >not inventing. > > - using separate metrics for loop avoidance and for parent > selection > > - allowing a node to have multiple parents (using a DAG > instead of a tree) > > - using Trickle to suppress DAG (or tree) discovery > messages > > - routing messages via siblings > > - the Destination Advertisement mechanism > >I am certainly not aware of everything in IP or in the >sensor network space. If any of these are widely used, I >suggest that we make sure we are not modifying them in >significant ways. > >There are a lot of ROLL-style networks out there today. If >the routing algorithms they use are good enough, and I >believe that they are, then weshould use the same >mechanisms. If they are not good enough, then we will have >to back off on the schedule. > > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sat Jul 4 06:04:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B485D28C1F0 for ; Sat, 4 Jul 2009 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.969 X-Spam-Level: X-Spam-Status: No, score=-7.969 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiElbkyBKFpn for ; Sat, 4 Jul 2009 06:04:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9E2A028C1DA for ; Sat, 4 Jul 2009 06:04:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,347,1243814400"; d="scan'208,217";a="84543687" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2009 13:04:40 +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 n64D4e0l021075; Sat, 4 Jul 2009 15:04:40 +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.14.3) with ESMTP id n64D4ejw008821; Sat, 4 Jul 2009 13:04:40 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); Sat, 4 Jul 2009 15:04:40 +0200 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_01C9FCA7.FD823763" Date: Sat, 4 Jul 2009 15:04:32 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A4E32E3.90804@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL]About Nodes subscribing to multiple DAGs Thread-Index: Acn7/Ato2HPYsNlETwaBRUEKX3FJfgAqttog References: <4A4E32E3.90804@orange-ftgroup.com> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 04 Jul 2009 13:04:40.0399 (UTC) FILETIME=[FDC405F0:01C9FCA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7292; t=1246712680; x=1247576680; 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[Roll]=20[RPL]About=20Nodes=20subscribi ng=20to=20multiple=20DAGs |Sender:=20; bh=m5+UTiAPK6SaRMbwKPknrbeZ+w+6IsOnRu/mYWSKLuQ=; b=NjY9kh0HoJWDCWND2yqo6vnqu1HXB4ZfW7zMel4xDFgkAdP4gYdm/PHVA7 CDNdRYtkPNxSFWqmCGsbRSFaXKI37NU3n/MSd5HKuvGwspQsaqjgZxr0q8LT LHB/DWLqNI; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 13:04:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FCA7.FD823763 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Salut Quentin: =20 If DAGs expose different prefixes then the longest match rule applies all the way to follow the graph that advertise that longest match prefix. You can use that to implement a power utility gateway that would get specific traffic but not default. =20 If DAGs expose a same prefix (default) then packets must be tagged (colored) to indicate which one of the topologies they are supposed to follow, otherwise loops will occur (your point I guess). =20 Finally, it is always possible to leave a topology to a strictly lower one, if you have structured your set of topologies as a tree. Like a default spanning topology would be the lowest (root) topology, and constrained control topologies would be the highest (leaves). =20 Will you be in Stockholm? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of quentin.lampin@orange-ftgroup.com Sent: vendredi 3 juillet 2009 18:34 To: roll@ietf.org Subject: [Roll] [RPL]About Nodes subscribing to multiple DAGs =20 Hi everyone, RPL specifies that a node can subscribe to more than one DAG. Is it the intention to allow nodes to forward packets received from one DAG to another one? If so, is there any mechanism that we could think of to prevent cross-DAGS loops? If a packet arrives at a node which knows that the root is no longer reachable, forwarding accross DAGs might be useful... Thanks for your comments, Quentin Lampin =20 ------_=_NextPart_001_01C9FCA7.FD823763 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Salut Quentin:

 

If DAGs expose different prefixes then the longest match = rule applies all the way to follow the graph that advertise that longest = match prefix. You can use that to implement a power utility gateway that would = get specific traffic but not default.

 

If DAGs expose a same prefix (default) then packets must = be tagged (colored) to indicate which one of the topologies they are = supposed to follow, otherwise loops will occur (your point I = guess).

 

Finally, it is always possible to leave a topology to a = strictly lower one, if you have structured your set of topologies as a tree. Like = a default spanning topology would be the lowest (root) topology, and = constrained control topologies would be the highest (leaves).

 

Will you be in Stockholm?

 

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = quentin.lampin@orange-ftgroup.com
Sent: vendredi 3 juillet 2009 18:34
To: roll@ietf.org
Subject: [Roll] [RPL]About Nodes subscribing to multiple = DAGs

 

Hi everyone,

RPL specifies that a node can subscribe to more than one DAG.
Is it the intention to allow nodes to forward packets received from one = DAG to another one?
If so, is there any mechanism that we could think of to prevent = cross-DAGS loops?
If a packet arrives at a node which knows that the root is no longer = reachable, forwarding accross DAGs might be useful...


Thanks for your comments,

Quentin Lampin

 

------_=_NextPart_001_01C9FCA7.FD823763-- From alexandru.petrescu@gmail.com Sat Jul 4 06:14:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6C928C1AC for ; Sat, 4 Jul 2009 06:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 zHTLrimV9aKo for ; Sat, 4 Jul 2009 06:14:24 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 772563A684B for ; Sat, 4 Jul 2009 06:14:22 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E77DBD480CF; Sat, 4 Jul 2009 15:14:42 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 753F0D480CD; Sat, 4 Jul 2009 15:14:39 +0200 (CEST) Message-ID: <4A4F55B9.1010608@gmail.com> Date: Sat, 04 Jul 2009 15:14:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090703-0, 03/07/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 13:14:26 -0000 Pascal Thubert (pthubert) a crit : > Hi Richard: > > There is a wide consensus even in implementations to go for a Distance > Vector approach. IMHO Distance-Vector protocols (a node sends to its immediate neighbors the distance it knows from everybody else, and Bellman-Ford path computation) are better when there are a few (if not one) backbone links and the distances are small, RIP less than 15. However, in the example picture in the graph we can't see such structure of the network: there are many edges, no priviledged backbone. At the same time, sensors are probably having a single interface, and thus pertain to a potential backbone picture: all sensors are connected to one or a few such backbones. But the graph in the RPL draft shows a sensor with many more interfaces. If we knew how many interfaces does a ROLL node have, and what is the structure of the network - a little more than just an arbitrary graph, then we could make decisions on the type of protocol - distance-vector, link-state, vector-path, and more combinations. With a totally arbitrary network of links like a random graph it's difficult to say that Distance Vector protocols are recommended. Alex > > - Good thing, DV properties are very well know. We know RIP and its > limitations, and we know that even in a clean wired space it would not > fit the scale that we are considering. > > - Good thing, DV technology has evolved since then, and the techniques > employed in IGRP and EIGRP have been widely deployed and verified over > the last decade. > > I cannot argue on the specific implementation that you know best. > All I can say is that it is: > > 1) *inacceptable* to be content with the basic RIP mechanisms (INFINITY > is 16 there for a reason or 2) > 2) *useful* to learn from more modern DV protocols (route poisoning, > 3) *necessary* to adapt to the LLN constraints and requirement > > >> what we are doing. In particular, there are a number of >> mechanisms in draft-dt-roll-rpl-00 which I do not believe >> have seen widespread use. Some of them have been discussed > > As you might have experienced yourself if you tried it and as the > protocol designers well warned, RIP is generally recognized as wholly > inadequate for large and complex networks (slow and costly due to count > to infinity). > > Since RIP, a number of DV improvements have been integrated in IGPs: > - Source tracing (too costly for us in terms of states) > - Composite metrics (IGRP, we're doing our on as part of the > metrics work; trick is whether one fits it all forever and consequences > if not) > - Path holddown (early IGRP) > - Route poisoning (Later IGRP, improves Path holddown) > - Distributed Update ALgorithm (DUAL, in EIGRP) the diffusion > algorithm prefers to create a temporary black hole than a loop, and > saves on control to resolve the routing issue. > > You'll realize that RPL inherits from those with a few tweaks to support > adhoc & mobility: > - In particular, RPL benefits from the properties that were > demonstrated by Garcia-Luna-Aceves for DUAL like you can safeluy move > towards the root but cannot move down. > - Yet RPL does not require reliable multicast for diffusion like > EIGRP does, the trade off is that it is not always loopless unless the > sequence is used. > > The main tweaks are > - The way a node is frozen (being frozen in RPL == pertaining to a > new DAG id of the node that found the breakage) > - and unfrozen (tree hop timer + seq as opposed to EIGRP query / > reply) > - The DAG hop timer to merge back DAGs (saves additional control > messages, to do things orderly as opposed to swiftly) > > In the distributed update algorithm a router that discovers that it will > get deeper becomes 'active'. It locks its routing table and diffuses the > information. RPL does that by leaving the DAG and belonging to the self > rooted DAG of the parent that discovers the breakage. The diffusion > happens recursively: a child that has a solution to stay in the main DAG > stays "passive" by remaining in the main DAG but losing that parent. A > child that cannot freezes by following its parent in the detached DAG. > >> - using separate metrics for loop avoidance and for parent selection > > A node makes its own decision to select one or a number of other nodes > as parents. That decision is ruled by the node's specific logic I call > plugin for the lack of a better term. This comes from the fact that a L3 > protocol works on abstractions that must be valid on multiple types of > links and environments. We can't expect a single metric to express what > we need to express to make a parent selection in ROLL. So we just took > it off, this much is out of scope and will be instantiated per need. So > you can have your own plugin that does exactly what your implementation > does today to select a best parent. > > At that point you'll have to interact with nodes from different vendors > and different generations, so you need to sort out a common metric to be > avoid loops and guarantee stability. Separating the 2 actually gives you > a lot more latitude in parent selection than enforcing any specific (set > of) metric and logic. > > >> - allowing a node to have multiple parents (using a DAG instead of a > tree) > > It is pretty clear from the requirements, though, that any spec that > does not allow forwarding across multiple parents *is out*. Note that > the fundamentals draft allowed that too. Now you can use RPL to build a > tree if you limit to a single parent, so the protocol enables that as a > degenerated case, like it allows the depth metric to be the parent > selection metric as another degenerated case. > > >> - routing messages via siblings > > That does not represent an uncontrolled risk. It mostly a way to improve > on traditional DAG thinking to get more fwd solution, then again a MUST > for LLNs. We note that having multiple parents and siblings enables the > routing part that built the graph to let some latitude to the component > that selects the next hop for a given packet. That feature is *heavily > required* in LLNs because the link conditions can change a lot faster > than the graph construction can cope with. > >> - the Destination Advertisement mechanism > > Yet another low risk technique because this mechanism does not draw the > graph, it merely colors it. And it is triggered only for destination > that need it so it is optional in a given deployment though required in > implementations. > > There are only 2 ways to do that simply, either sync db (ala OSPF) or > repeat over and over (ala RIP). For the sake of simplicity and because > of the mobility that's inherent to LLNs, the draft picked the latter. > And yes, there are implementations of this that have been operated in > multiple environments, radio and wired. On the Moon I'm unsure but maybe > soon :) > > What I see here is a set of adaptations of rather well known techniques > in the DV family plus a set of adaptations to meet LLN requirements. > Pretty much what ROLL is chartered to do. There's still a lot of tuning > to do but the main lines seem properly defined... > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey >> Sent: vendredi 3 juillet 2009 17:42 >> To: roll@ietf.org >> Subject: [Roll] ROLL and new technology >> >> ROLL has a very aggressive schedule. The argument was that >> we could make rapid progress by building on existing >> protocols that are already in use. That doesn't seem to be >> what we are doing. In particular, there are a number of >> mechanisms in draft-dt-roll-rpl-00 which I do not believe >> have seen widespread use. Some of them have been discussed >> on the mailing list. The nature of those discussions >> indicates that those features are neither well understood or >> in common use. >> >> I am not saying that we shouldn't use any or all of these, >> or even necessarily singling out these particular features. >> My point is we should strongly limit the amount of algorithm >> development that we undertake. This is a time for refining, >> not inventing. >> >> - using separate metrics for loop avoidance and for parent >> selection >> >> - allowing a node to have multiple parents (using a DAG >> instead of a tree) >> >> - using Trickle to suppress DAG (or tree) discovery >> messages >> >> - routing messages via siblings >> >> - the Destination Advertisement mechanism >> >> I am certainly not aware of everything in IP or in the >> sensor network space. If any of these are widely used, I >> suggest that we make sure we are not modifying them in >> significant ways. >> >> There are a lot of ROLL-style networks out there today. If >> the routing algorithms they use are good enough, and I >> believe that they are, then weshould use the same >> mechanisms. If they are not good enough, then we will have >> to back off on the schedule. >> >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Sat Jul 4 06:23:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C681A3A6C10 for ; Sat, 4 Jul 2009 06:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.923 X-Spam-Level: X-Spam-Status: No, score=-9.923 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6H4pummDj82S for ; Sat, 4 Jul 2009 06:23:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D925A3A6BC3 for ; Sat, 4 Jul 2009 06:23:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,347,1243814400"; d="scan'208,217";a="44364043" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2009 13:23:49 +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 n64DNnoF014074; Sat, 4 Jul 2009 15:23:49 +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.14.3) with ESMTP id n64DNnIE010268; Sat, 4 Jul 2009 13:23:49 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Jul 2009 15:23:49 +0200 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_01C9FCAA.AA53890C" Date: Sat, 4 Jul 2009 15:23:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93DCC@xmb-ams-337.emea.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF371391@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL] multiple roots in a DAG Thread-Index: Acn7/Nb7Fgb7KDlvRKeFZdNIzid3AwAqy9uQ References: <8E09C72DBC577D489F13A71228C0B7BF371391@ftrdmel0.rd.francetelecom.fr> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 04 Jul 2009 13:23:49.0363 (UTC) FILETIME=[AA9A0430:01C9FCAA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9658; t=1246713829; x=1247577829; 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[Roll]=20[RPL]=20multiple=20roots=20in= 20a=20DAG |Sender:=20; bh=+TZIEQLeDkV1W65Q+l0noT8U/io1LFusmpOUGuEOcak=; b=rxNIqJodev9U4SR6Ax7GC/HdPSH+RHpMYPKsnnCygo7tJCZ+XGrBd2fJb2 I2eyZ29X6TWPOLPd5c3jl2jjpFp7w76qPtN+CSRzhqk9lzRXUbExIvPtnlby b2xP80IsxL; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] [RPL] multiple roots in a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 13:23:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FCAA.AA53890C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Salut Dominique=20 =20 If I understand the draft correctly, multiple roots shall send "identical" DIOs with synchronized sequence numbers.=20 Therefore, nodes will only know of one root (because they discard DIOs with same or lower seqnum).=20 Most nodes will likely hear from only one root anyway, since intermediate nodes only propagate *one* DIO per DAGID.=20 This results in a watershed effect.=20 Exactly. Only nodes on the ridges might hear of 2 roots. The interesting part is that the ridges define themselves by the choice of nodes on the ridges.=20 =20 Having multiple DAGs with as many DAGIDs is what we expect in general (divide and conquer) so that problem is isolated within its drainage basin. For instance, the loss of a sink only impacts nodes in that basin that have to migrate to the nearest next one. =20 I understand that you're really talking about, though, is multiple sinks for a same DAGID, what I'd call a delta in a watershed analogy. =20 The only use case for a delta that I have in mind for this is a 6LoWPAN backbone. What's required there is, as you indicate, a sync of the "roots" so that they used consistent sequence numbers and DAGIDs. This can be seen as a single root (the backbone itself ) of a single DAG and the multiple secondary roots advertise depth 1 in that same DAG. What I'd do there is use one of the root to source the protocol over the backbone. I think we had good text on that in the fundamentals draft, maybe we should integrate some of that in RPL. =20 The routing algorithm at a node can therefore only chose among parents that lead to the same root in that DAG.=20 Was there any consideration given to nodes knowing about several roots? Or is the use of multiple DAGs recommended instead : this would go counter the advocated intention of using multiple DAGs for serving competing constraints (3.3.1.2)...=20 There's really one DAG per DAGID. A delta is still one DAG with the first hop in a backbone. I see multiple DAGs as multiple routing topologies. Whether that's needed is a use case thing, but we allow it. That multiplies the cost of control though. Not recommended for every simple destination but useful for a few well chosen ones like gateways. Cheers, Pascal Best regards,=20 Dominique=20 ------_=_NextPart_001_01C9FCAA.AA53890C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [RPL] multiple roots in a DAG

Salut Dominique

 

If I understand the draft correctly, multiple roots shall send "identical" DIOs with synchronized sequence numbers. =
Therefore, nodes will only know of one root (because they discard DIOs with same or = lower seqnum).
Most = nodes will likely hear from only one root anyway, since intermediate nodes only = propagate *one* DIO per DAGID.
This = results in a watershed effect.

Exactly. Only nodes on the ridges might hear of 2 roots. = The interesting part is that the ridges define themselves by the choice of = nodes on the ridges.

 

Having multiple DAGs with as many DAGIDs is what we = expect in general (divide and conquer) so that problem is isolated within its = drainage basin. For instance, the loss of a sink only impacts nodes in that basin = that have to migrate to the nearest next one.

 

I understand that you’re really talking about, = though, is multiple sinks for a same DAGID, what I’d call a delta in a = watershed analogy.

 

The only use case for a delta that I have in mind for = this is a 6LoWPAN backbone. What’s required there is, as you indicate, a sync of the = “roots” so that they used consistent sequence numbers and DAGIDs. This can be = seen as a single root (the backbone itself ) of a single DAG and the multiple = secondary roots advertise depth 1 in that same DAG. What I’d do there is use one = of the root to source the protocol over the backbone. I think we had good text = on that in the fundamentals draft, maybe we should integrate some of that in = RPL.

 


The = routing algorithm at a node can therefore only chose among parents that lead to = the same root in that DAG.
Was = there any consideration given to nodes knowing about several roots? Or is the use = of multiple DAGs recommended instead : this would go counter the advocated intention of using multiple DAGs for serving competing constraints = (3.3.1.2)...

There’s really one DAG per DAGID. A delta is still one DAG with the first hop in = a backbone. I see multiple DAGs as multiple routing topologies. Whether = that’s needed is a use case thing, but we allow it. That multiplies the cost of control though. Not recommended for every simple destination but useful = for a few well chosen ones like gateways.

Cheers,

Pascal

Best = regards,

Dominique

------_=_NextPart_001_01C9FCAA.AA53890C-- From pthubert@cisco.com Sat Jul 4 11:34:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E38F3A67F7 for ; Sat, 4 Jul 2009 11:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.946 X-Spam-Level: X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[AWL=0.653, 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 VnbDj-qbj2Gx for ; Sat, 4 Jul 2009 11:34:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00A1E3A6996 for ; Sat, 4 Jul 2009 11:33:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,349,1243814400"; d="scan'208";a="44368452" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2009 18:34:20 +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 n64IYKDX024390; Sat, 4 Jul 2009 20:34:20 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n64IYK9R004287; Sat, 4 Jul 2009 18:34:20 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Jul 2009 20:34:19 +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: Sat, 4 Jul 2009 20:34:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn7WiopqxiU6gF2Q3C/nooSHAcPOABdzw9Q References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 04 Jul 2009 18:34:19.0864 (UTC) FILETIME=[0B3EDD80:01C9FCD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4509; t=1246732460; x=1247596460; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=B8CNfACG/6MZNjKReqeEE65lojK57CUdaiZy0DxNbS4=; b=C+fIcv2YALbChKN+gHxtnQGzJJP1VVHl5hYE3qCFBW3HTjszuVXWXwYxjS 3S8ZEWXg1ediJJc0IzOz8MxxxtcpRx5fOYl0C8iBD9fDf9LkxPMUAm5t8Oh0 K4iLWxZ3fK; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 18:34:13 -0000 We are certainly converging. I do like the concept though maybe I'd have used less bits. That's because I expect a given mesh to be formed of analogous links.=20 If so, it is possible to define a unit that represents a normalized good hop. In my mind that was 1. It makes sense with ETX in mind that a radio hop that in average will take one retry could a cost of 2. So it certainly makes sense to do depth +=3D 2 for that hop. But to malke that generic to links where the problem is not retries the result for a link type must be normalized like 1 to 8, whatever the maximum retries is on that link. Now if there is a chance that a hop costs a lot less than 1, then it makes sense to echo Richard and say that the normalize increment for the link under expected behavior is say 256, but so we can allow both multiples and fractions of the normalized hop cost.=20 What I strongly doubt is whether the high order octet can still meaningfully be the real hop count.=20 Say what? I don't really mind. That's not required for the ROLL algorithm to operate. What's needed is a reliable sense of inwards so we can pass packets towards there and ignore whatever route changes happens in your back. If we want a hop count we can still have one in the metrics and it will be used wherever useful. If the high order octet is not the hop count, then what Richard is proposing is pretty much analogous to what I just proposed before I read that mail (gargl, sorry Richard). We have a unit, and a hop costs a number of units. The way to compute that is specific to the case like the plugin is. For a link type, there could be is a range of what an acceptable hop can cost.=20 Now do we need 2 octets? Could be useful, but remember, IF we count to infinity, then we'll pay for the extra. Also, how do we define parents vs siblings? If that's only the high order bit then that's fine. Otherwise, being too fine grained will reduce the chances to have siblings.=20 Today the protocol does not count to infinity. That's like a path holddown, because we block RADIOs for parents going deeper. I'm not sure whether we should retain that. Following parents that go deeper immediately treats a loop if RAs are not lost. To be discussed... What do you think? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: jeudi 2 juillet 2009 23:15 >To: Richard Kelsey >Cc: roll@ietf.org >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > > >Hi Richard, > >On Jul 2, 2009, at 11:47 AM, Richard Kelsey wrote: >> Here is a suggestion: >> >> Leave the hop count as is, and add a DAGCost field. The >> DAGCost field is a fixed-point value, say 16 bits of which 8 >> bits are the fractional part. The units for the cost field >> are hops, so a hop with a cost 0x0001 is equivalent to an >> additional 1/256th of a 'best case' hop and 0x0100 is >> equivalent to a complete additional 'best case' hop. The >> actual path cost is >> >> (DAGDepth << 8) + DAGCost >> >> Loop avoidance and parent selection is done using the path >> cost. In an outgoing DIO the DAGDepth MUST be larger than >> the maximum parent DAGDepth and the DAGCost MUST be large >> enough such that the path cost of the DIO is greater than >> the maximum parent path cost. > >This is an interesting approach. It forces each node to aggregate >whatever metrics they use into a single DAGCost metric and relate that >to the DAGDepth in some way. Does it make sense to add another >constraint that DAGCost has to be >=3D the parent's DAGCost? What I'm >thinking about is the possible loss in information across multiple >hops. In a completely contrived case, a node could advertise a path >cost only 1 greater (by incrementing DAGDepth by 1 and decreasing >DAGCost by 255) - then the meaning of a "hop" and relationship between >DAGCost and DAGDepth gets lost. Or did you intend it to allow >reductions in DAGCost so that they can optionally be summarized into >DAGDepth along the way? > >But for now, the way you defined it, it is equivalent to having a >single 16-bit integer that can be increased arbitrarily at every hop. >If 0 <=3D DAGCost < 256, then you must increase by at least 256 - DAGCost. > >-- >Jonathan Hui > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Sun Jul 5 15:16:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4355E28C15F for ; Sun, 5 Jul 2009 15:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, MANGLED_SHOP=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtbeH8SB7z7P for ; Sun, 5 Jul 2009 15:16:24 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5419728C12C for ; Sun, 5 Jul 2009 15:16:24 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 18:16:49 -0400 Date: Sun, 05 Jul 2009 18:17:17 -0400 Message-Id: <87ocryepw2.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 05 Jul 2009 22:16:49.0928 (UTC) FILETIME=[4AEAB880:01C9FDBE] Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 22:16:25 -0000 Date: Sat, 4 Jul 2009 14:48:12 +0200 From: "Pascal Thubert (pthubert)" There is a wide consensus even in implementations to go for a Distance Vector approach. I completely agree. - Good thing, DV properties are very well know. We know RIP and its limitations, and we know that even in a clean wired space it would not fit the scale that we are considering. The only core algorithmic difference between RIP and RPL is how loop detection is done. Everyone, including myself, agrees that RIP's counting-to-infinity won't work. Many people agree that RPL's hop count won't work either. - Good thing, DV technology has evolved since then, and the techniques employed in IGRP and EIGRP have been widely deployed and verified over the last decade. I cannot argue on the specific implementation that you know best. All I can say is that it is: 1) *inacceptable* to be content with the basic RIP mechanisms (INFINITY is 16 there for a reason or 2) I have never proposed using RIP's loop detection mechanism for ROLL. It is obvious that it won't work. My draft-kelsey-roll-lip-00 uses (or was intended to use, the draft explicitly does not specify a complete routing protocol) the data traffic path validation of the Collection Tree Protocol (CTP). The draft was a result of my noticing that CTP and RIP have nearly identical routing control frames, modulo the sizes of the fields. CTP appears to be simple, dynamic, and robust, which for me are the main requirements of a ROLL protocol. (The other main idea in the draft, using CTP/RIP in the context of MPLS, made it easy to add CTP's path-cost field to data messages and also allowed source routes to be added and removed when a packet crosses in and out of a ROLL subnet. The subnet-local source routes can then be used for outward routing within the tree.) 2) *useful* to learn from more modern DV protocols (route poisoning, 3) *necessary* to adapt to the LLN constraints and requirement Absolutely. My main concern with RPL is that it fails to adapt to LLN constraints and requirements. But we disagree on this. [much interesting discussion of individual features removed] What I see here is a set of adaptations of rather well known techniques in the DV family plus a set of adaptations to meet LLN requirements. Pretty much what ROLL is chartered to do. There's still a lot of tuning to do but the main lines seem properly defined... And here too we disagree. To me the discussions on this list (does hop count trump other metrics, how does having multiple metrics interact with having multiple parents, for example) are evidence of this. My main concern is that RPL is significantly more complex than the existing WSN routing protocols that I have used or am familiar with. More complex protocols take longer to develop than simpler ones, and tend to be less robust. -Richard Kelsey From wintert@acm.org Sun Jul 5 15:51:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFDA3A6ACA for ; Sun, 5 Jul 2009 15:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLz-RY12Dac6 for ; Sun, 5 Jul 2009 15:51:46 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id 6E76F3A691D for ; Sun, 5 Jul 2009 15:51:46 -0700 (PDT) Received: (qmail 21222 invoked from network); 5 Jul 2009 22:52:09 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 05 Jul 2009 15:52:09 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: RgQnzikVM1kQ5mf5LD.58xkRljO29mv876gq2fp4ydy1IGDjVfdHtR4Mk9_p4spY7k_TawzY2SKxrb0YKxQ_b.GEwUNL8dEFxMnoIjlkOGMA9bILzvc_Jjs6V29hRowT5VJC4m29IGxNNXe_z4pF8M9Ic5BLW_X6f0oFS70FgYlPQOBgodref.kKKRkn2yoHoEt2UQpRw.xc6TJ7WZ7o_KxAUIooEJT_xTUQQcogO7rO4yPEF1M6n90BPbyMxq2jYKepriU3qGRmvhvJeU1QQGTILm_gFpnLhhtgE_r0J7aTca1h0yA_Vr1_OdJSOwsozrAgug-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A512E97.1030000@acm.org> Date: Sun, 05 Jul 2009 18:52:07 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 22:51:47 -0000 WG, Thanks to everyone for their feedback and comments to the RPL draft so far. There are some good threads here that will definitely help us to improve the RPL design- and there is no doubt more work to be done. I would like to make some clarifications that may be useful in discussing some of the common concerns so far: 1) Why a DAG? A dominant traffic flow in the requirements drafts is MP2P, flowing from the sensors inwards towards a sink, typically an LBR. The design approach taken was to handle this case, use it to restrict the routing problem, and then try to build support for P2MP, P2P, and other cases on top of it. A tree provides the simplest structure for supporting the MP2P flows, but a tree has many single points of failure along the edges from children to parents. A DAG, allowing each node to select and maintain multiple successors in order to forward traffic inwards toward the root, offers the advantage of ready-to-use options. An implementation may then select from the successors as necessary, possibly in response to a temporary failure to forward to one parent, or a load balancing algorithm, or a short-term fluctuation in a link metric that leads the forwarding engine to prefer one next hop over the other. 2) What about other flows? The DAG, and the orientation of the edges in the DAG, is used in routing the MP2P traffic towards the DAG root. The structure of the DAG is then used to restrict the complexity of the P2MP routing problem on the nodes. The Destination Advertisement mechanism lets a node set up routes in support of outward traffic flows, from the DAG root towards the leaf nodes in the LLN. The Destination Advertisement mechanism distributes routing state inwards along the DAG, allowing nodes to learn routing state in support of the sub-DAGs below them. Nodes who are unable to learn routing state pass the Destination Advertisements inward, building up source routing information along the way so that they may be traversed again on the outward flow. The exact implementation of source routing in support of this mechanism is not something that has been addressed by RPL as yet. Further, arbitrary P2P traffic can be supported by the DAG as is by sending traffic inwards along the DAG until a parent is encountered, who has stored routing state and is common to the source and destination of the traffic, who is able to direct the traffic towards the destination. RPL does not discuss any mechanisms to install more optimal P2P routes, but nor does it preclude them, once the fundamentals have been addressed we can have a look at such mechanism to more efficiently route `across' the DAG. 3) Metrics RPL allows for each node to select its set of DAG parents according to its own set of constraints, utilizing whatever subset of metrics it requires to do so. The exact considerations and weighting can be implementation specific. A key design point, one that may need to be further constrained, is that under RPL each node does not assume that other nodes are acting cooperatively, or even that they are using or understand the same set of metrics. One node could be optimizing for latency, another node could be optimizing for ETX, and a third could be optimizing for minimum energy. This design point informs some of the loop avoidance rules, such as the use of depth as a `common language'. Once a node as selected its DAG parents, according to whatever metrics and constraints it chooses, then it has effectively taken up a position in the DAG. It now has a best-case path to the DAG root, through its best parent, and a worst-case path to the DAG root, through its worst parent. Now, as a *consequence* of selecting parents according to its metrics, the node has taken on a depth within the DAG. 4) Loop avoidance The DAG, and the nodes position within the DAG, are used in support of some loop avoidance rules. RPL always allows a node to move inwards along the DAG, towards the root. Moving inwards along the DAG has little chance of creating a loop; the node has only improved its position. Such a move would be based on receiving and processing DIOs with superior metrics from a node of a lesser depth in the DAG. RPL does not allow a node to move outwards along the DAG, increasing its depth. Such a move is possible, but would require the node to leave the DAG, wait for a DAG Hop timer to elapse, and then re-attach at the lower point. RPL would not allow this movement unless the DAG parents of the node have failed, requiring the node to detach and re-attach to the DAG. In general, RPL is taking a conservative approach. For a node N, any node M such that depth(M)>depth(N) MAY be in the sub-DAG of node N. Suppose that node N thought it could improve its metrics through node M. By detaching first, and waiting to observe node M to see that node M remains attached to the DAG, node N may then determine that node M is not part of its own sub-DAG and may safely re-attach at the lower point. BUT if node N is wrong, then an instability has been created for no gain. For this reason, in its current specification, RPL does not allow a node N to process and DIO from node M and detach from the DAG based on information in the DIO from node M. NOTE that this is in part a consequence of the design consideration that not all nodes may be using the same metrics and making the same optimizations. For example, if all nodes in the network were minimizing ETX, then node N may be mostly certain that any node M advertising a superior ETX is NOT in its own sub-DAG. A further complication may come if node N and node M are trying to make optimizations which are antagonistic to each other. For example, if node N where to try to move under node M, it could create a chain of events whereby node M tried to reverse its position with respect to node M, and a chain reaction of instability could result. A simple example of such a case would be where both nodes M and N have a common neighbor and parent P, and nodes M and N subsequently each try to increase the size of their parent set to be 2. (This case has been more thoroughly explained by Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" sent 30 June 2009.) RPL has nodes advertise a depth deeper than that of their deepest DAG parent. Consider an example where node X has parents of depth {2, 7}, and node Y chooses X as a parent. Suppose that nodes then advertise their `best' depth, i.e. node X advertises a depth of 3. Then node Y will advertise a depth of 4. Then suppose node Z adds node Y as a parent, and advertises a depth of 5. Now, Z can actually come to be a successor of node X's depth 7 parent. The result could be Z->Y->X->(cost 7 parent)->(...)->Z and then there is a loop. By advertising a depth deeper that of its deepest parent, a node advertises its worst case scenario, and in the worst case scenario a loop can be avoided. RPL does not require that the DAG is invariant, rather that the movement of the node with respect to the DAG is coordinated in such a way so as to avoid loops. The thought is, whatever the topology, uncoordinated movement in LLNs may increase overhead and churn and require more reliance on expensive mechanisms such as count-to-infinity. The use of depth (~ hop count) in RPL is not meant to trump other metrics, but once a node has taken up a position in the DAG by using its metrics the node acquires a depth, which then restricts the further options that the node has in order to avoid loops. Regards, -Tim From wintert@acm.org Sun Jul 5 16:15:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039C33A67A6 for ; Sun, 5 Jul 2009 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.598 X-Spam-Level: X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_31=1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UjNNxAnj3IV for ; Sun, 5 Jul 2009 16:15:01 -0700 (PDT) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id E44283A67F7 for ; Sun, 5 Jul 2009 16:15:00 -0700 (PDT) Received: (qmail 71590 invoked from network); 5 Jul 2009 23:15:18 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 05 Jul 2009 16:15:17 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: N.LBdy8VM1mAJqpxWTMoOLKnQzSkTwA2uZHomtJ2hg1C4725HhXDgx.fzrpX5KLwxnSQ.faR7bz0ffuCjAvPI4l.9JTSyE9XWIYYJOqcY.dGTfzZ15kswBF7k7_9ieTlWhtwNXHtpeEbyo7cLlpqP3s3ZZmcQsnvwzQgSBgqAJM6J.6KWzboMH5zh5WrXZ2YAohhdRAjzW50Z8tjOveuw.2gWpuCZoQgYJdMIyYJJ9M0YtPFYTh2zp3qSJNqRsL9fJfNpxVJOgf03Tq46pJFQtsUK3i4EIzROrK.zqsWGNmHse29E_0ByIaI42xCX5BOEO6tWJZWu2SQxZRyQDyXrO6YrLExE5a8TYxm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A513404.1000905@acm.org> Date: Sun, 05 Jul 2009 19:15:16 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Richard Kelsey , ROLL WG References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> <87d48hy917.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87d48hy917.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 23:15:02 -0000 Hi Richard, Thanks for all of your feedback so far. Your example and understanding of RPL is correct. In my view, it stems in part from the fact that the loop avoidance mechanism does not trust that other nodes are cooperative, e.g. trying to make the same optimizations and taking into consideration the same metrics. This is a design consideration in the current specification of RPL, e.g. to support LLNs with nodes that may have different optimization goals and may use different metrics, not all of which may be understood by all nodes. In your example, it leads to a functional LLN, but a suboptimal LLN (which is the problem). For illustration, if LBR<->B becomes so bad as to not use the link, then: 6) B will leave the LLN (and start its own floating DAG) 7) B may then, after a hold-up period, hear the DIO of C and attach at depth 3. Now, the real problem you are pointing out comes when LBR<->B is bad, but not bad enough to cause B to leave the LLN. RPLs loop avoidance mechanism causes node B to behave in a manner that may be too conservative in this cases. One possible approach is to negotiate/limit the use of the metrics in the LLN and how they are optimized- maybe by defining `sets' of metrics and goals for LLNs? Alternately, to tag certain metrics and their exclusive use as `safe', e.g. because they are known to monotonically increase globally, therefore if a node has a smaller value it is known to not be in your sub-DAG (similar to Jonathan's discussion). For example, if in an LLN all nodes act to minimize ETX, then node B may safely make a move to attach to node C based on investigation of ETX- if node C has a lesser ETX than node B in this case, then by induction node C cannot be in the sub-DAG of node B and there is no chance of a loop. Such constraints on the use of metrics would have to be done in an interoperable manner- and only in the cases were by design it can be sure that they are globally cooperative, such as `all nodes min ETX', is it safe. Regards, -Tim Richard Kelsey wrote: > Date: Fri, 3 Jul 2009 17:42:40 +0200 > From: "Pascal Thubert (pthubert)" > > >In this and similar situations, RPL lets hop count trump all > >other routing constraints. This seems like a bad idea. > > That would. But RPL only used the depth once the parents > are selected, by means that do not have to include the > depth at all. Because the draft says that this part (the > plugin) is out of scope than it appears that the depth is > THE metric. No. The depth is a tool for loop avoidance > and stability. It comes after the parent selection > happened. All the metrics that you currently use are > welcome. > > As I understand the draft, in the situation I described, > RPL always (except if messages go unheard) picks the > shorter route over the longer one. It doesn't matter > what other metrics are in use. > > Here is the example again. If I have misunderstood how > RPL works, please show me where this example is incorrect. > > Cconsider a network with four nodes LBR, A, B, and C, where > A and B do not share a link and, according to the routing > metric in use, the LBR<->B link is inferior enough that the > LBR<->A<->C<->B route is significantly better than the > one-hop LBR<->B route. > > LBR > / \ > A B > \ / > C > > 1) LBR, as the root, sends out an RA at depth 0, heard by both > A and B. > 2) A and B choose LBR as their parent, having heard no other > other RAs. The order in which A and B choose a parent > does not affect the outcome. > 3) A and B send out their RAs at depth 1, in either order. > 4) C picks A as a parent because the cost of the LBR<->B > link makes B an bad choice. > 5) C then sends out an RA at depth 2, which is ignored by B > because C's depth is greater than B's. > > B's route to LBR is the poor-quality LBR<->B link, rather > than the preferred route via C and A. The routing metric > only affects C's choice of parent. It has no effect on B's > choice. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From richard.kelsey@ember.com Sun Jul 5 18:57:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C7D3A6AD6 for ; Sun, 5 Jul 2009 18:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, J_BACKHAIR_31=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 ULXDm9ufvJNl for ; Sun, 5 Jul 2009 18:57:23 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 68E243A6876 for ; Sun, 5 Jul 2009 18:57:23 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 21:57:49 -0400 Date: Sun, 05 Jul 2009 21:58:18 -0400 Message-Id: <877hymd139.fsf@kelsey-ws.hq.ember.com> To: Tim Winter In-reply-to: <4A513404.1000905@acm.org> (message from Tim Winter on Sun, 05 Jul 2009 19:15:16 -0400) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> <87d48hy917.fsf@kelsey-ws.hq.ember.com> <4A513404.1000905@acm.org> X-OriginalArrivalTime: 06 Jul 2009 01:57:49.0224 (UTC) FILETIME=[2A12BA80:01C9FDDD] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 01:57:24 -0000 Tim, Date: Sun, 05 Jul 2009 19:15:16 -0400 From: Tim Winter Thanks for all of your feedback so far. No problem. I get paid to do this. :-) In your example, it leads to a functional LLN, but a suboptimal LLN (which is the problem). Suboptimal in itself is OK, but hop count has been shown to be unusably bad in many cases. For illustration, if LBR<->B becomes so bad as to not use the link, then: 6) B will leave the LLN (and start its own floating DAG) 7) B may then, after a hold-up period, hear the DIO of C and attach at depth 3. What is the purpose of the hold-up period? Is it enough to hear a DIO from C with a later sequence number? Or is the hold-up period typically less than the period between RAs? -Richard Kelsey From richard.kelsey@ember.com Sun Jul 5 19:15:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFD43A691F for ; Sun, 5 Jul 2009 19:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 qxHFMVj84kxp for ; Sun, 5 Jul 2009 19:15:24 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 47D673A6876 for ; Sun, 5 Jul 2009 19:15:24 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 22:15:50 -0400 Date: Sun, 05 Jul 2009 22:16:19 -0400 Message-Id: <8763e6d098.fsf@kelsey-ws.hq.ember.com> To: Tim Winter In-reply-to: <4A512E97.1030000@acm.org> (message from Tim Winter on Sun, 05 Jul 2009 18:52:07 -0400) From: Richard Kelsey References: <4A512E97.1030000@acm.org> X-OriginalArrivalTime: 06 Jul 2009 02:15:50.0506 (UTC) FILETIME=[AE9144A0:01C9FDDF] Cc: roll@ietf.org Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 02:15:25 -0000 Date: Sun, 05 Jul 2009 18:52:07 -0400 From: Tim Winter 2) What about other flows? [...] Nodes who are unable to learn routing state pass the Destination Advertisements inward, building up source routing information along the way so that they may be traversed again on the outward flow. The exact implementation of source routing in support of this mechanism is not something that has been addressed by RPL as yet. In general, is adding an IP source route to a forwarded packet allowed? Could a root add a source route to an incoming packet before forwarding it down the DAG? 3) Metrics A key design point, one that may need to be further constrained, is that under RPL each node does not assume that other nodes are acting cooperatively, or even that they are using or understand the same set of metrics. One node could be optimizing for latency, another node could be optimizing for ETX, and a third could be optimizing for minimum energy. This doesn't seem very useful to me. To the extent that these three are independent, you could easily end up with routes that were bad at all of them. Why is this a key design point? Also, it seems to me that this interacts poorly with having a DAG. With a tree a node receives a single value for each metric from its parent. With a DAG, one parent may have a a low latency but high energy cost while another parent has high latency and low energy cost. What metric values should the child advertise? Given the dubious benefits of having different nodes optimize different metrics, and the bad interaction with having multiple parents, I really don't understand the emphasis on this feature. -Richard Kelsey From richard.kelsey@ember.com Sun Jul 5 19:25:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0C53A6985 for ; Sun, 5 Jul 2009 19:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 PKyDaFvxlEYj for ; Sun, 5 Jul 2009 19:25:39 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B9AA73A6895 for ; Sun, 5 Jul 2009 19:25:39 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 22:26:05 -0400 Date: Sun, 05 Jul 2009 22:26:34 -0400 Message-Id: <874otqczs5.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 06 Jul 2009 02:26:05.0974 (UTC) FILETIME=[1D6A3B60:01C9FDE1] Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 02:25:41 -0000 Pascal, Date: Fri, 3 Jul 2009 15:51:11 +0200 From: "Pascal Thubert (pthubert)" What I'd really like to suppress is the behavior of a router being a router, as opposed to suppressing some RAs from every routers. Like if I have many of other routers around I could yield and suppress RAs totally. The idea being that some nodes act as routers for some time and then they stop because they think they've done enough. Neighbors node discovering a lesser density take over and now act as routers. The problematic situation for this is when there is a dense clique of nodes and two other nodes, one just out of range of the clique and the other half way inbetween: o o o o o o o <--- 3/4 hop ---> o <--- 3/4 hop ---> o o o o To keep the network connected you want to avoid having the node in the middle, which has all those neighbors over on the left, from deciding not to be a router. -Richard Kelsey From prvs=43190c0b0=mukul@uwm.edu Sun Jul 5 20:12:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30703A6AD4 for ; Sun, 5 Jul 2009 20:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 m2w5OyP8a69J for ; Sun, 5 Jul 2009 20:12:53 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 0B33B3A6951 for ; Sun, 5 Jul 2009 20:12:52 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 05 Jul 2009 22:13:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D8B82C085A0; Sun, 5 Jul 2009 22:13:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgmxH0TYf9+5; Sun, 5 Jul 2009 22:13:17 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5AB01C085A3; Sun, 5 Jul 2009 22:13:17 -0500 (CDT) Date: Sun, 5 Jul 2009 22:13:17 -0500 (CDT) From: Mukul Goyal To: Tim Winter Message-ID: <811770612.58961246849997271.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4A512E97.1030000@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 03:15:21 -0000 Tim Thanks for this explanation. I think most of this email should become part of RPL draft. I would like to convey the discomfort that many of us feel because RPL does not yet support a good P2P routing solution. Tree based P2P routing is not acceptable in many cases. We need to give this problem a high priority. Thanks Mukul ----- Original Message ----- From: "Tim Winter" To: "ROLL WG" Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central Subject: [Roll] Some clarifications on RPL WG, Thanks to everyone for their feedback and comments to the RPL draft so far. There are some good threads here that will definitely help us to improve the RPL design- and there is no doubt more work to be done. I would like to make some clarifications that may be useful in discussing some of the common concerns so far: 1) Why a DAG? A dominant traffic flow in the requirements drafts is MP2P, flowing from the sensors inwards towards a sink, typically an LBR. The design approach taken was to handle this case, use it to restrict the routing problem, and then try to build support for P2MP, P2P, and other cases on top of it. A tree provides the simplest structure for supporting the MP2P flows, but a tree has many single points of failure along the edges from children to parents. A DAG, allowing each node to select and maintain multiple successors in order to forward traffic inwards toward the root, offers the advantage of ready-to-use options. An implementation may then select from the successors as necessary, possibly in response to a temporary failure to forward to one parent, or a load balancing algorithm, or a short-term fluctuation in a link metric that leads the forwarding engine to prefer one next hop over the other. 2) What about other flows? The DAG, and the orientation of the edges in the DAG, is used in routing the MP2P traffic towards the DAG root. The structure of the DAG is then used to restrict the complexity of the P2MP routing problem on the nodes. The Destination Advertisement mechanism lets a node set up routes in support of outward traffic flows, from the DAG root towards the leaf nodes in the LLN. The Destination Advertisement mechanism distributes routing state inwards along the DAG, allowing nodes to learn routing state in support of the sub-DAGs below them. Nodes who are unable to learn routing state pass the Destination Advertisements inward, building up source routing information along the way so that they may be traversed again on the outward flow. The exact implementation of source routing in support of this mechanism is not something that has been addressed by RPL as yet. Further, arbitrary P2P traffic can be supported by the DAG as is by sending traffic inwards along the DAG until a parent is encountered, who has stored routing state and is common to the source and destination of the traffic, who is able to direct the traffic towards the destination. RPL does not discuss any mechanisms to install more optimal P2P routes, but nor does it preclude them, once the fundamentals have been addressed we can have a look at such mechanism to more efficiently route `across' the DAG. 3) Metrics RPL allows for each node to select its set of DAG parents according to its own set of constraints, utilizing whatever subset of metrics it requires to do so. The exact considerations and weighting can be implementation specific. A key design point, one that may need to be further constrained, is that under RPL each node does not assume that other nodes are acting cooperatively, or even that they are using or understand the same set of metrics. One node could be optimizing for latency, another node could be optimizing for ETX, and a third could be optimizing for minimum energy. This design point informs some of the loop avoidance rules, such as the use of depth as a `common language'. Once a node as selected its DAG parents, according to whatever metrics and constraints it chooses, then it has effectively taken up a position in the DAG. It now has a best-case path to the DAG root, through its best parent, and a worst-case path to the DAG root, through its worst parent. Now, as a *consequence* of selecting parents according to its metrics, the node has taken on a depth within the DAG. 4) Loop avoidance The DAG, and the nodes position within the DAG, are used in support of some loop avoidance rules. RPL always allows a node to move inwards along the DAG, towards the root. Moving inwards along the DAG has little chance of creating a loop; the node has only improved its position. Such a move would be based on receiving and processing DIOs with superior metrics from a node of a lesser depth in the DAG. RPL does not allow a node to move outwards along the DAG, increasing its depth. Such a move is possible, but would require the node to leave the DAG, wait for a DAG Hop timer to elapse, and then re-attach at the lower point. RPL would not allow this movement unless the DAG parents of the node have failed, requiring the node to detach and re-attach to the DAG. In general, RPL is taking a conservative approach. For a node N, any node M such that depth(M)>depth(N) MAY be in the sub-DAG of node N. Suppose that node N thought it could improve its metrics through node M. By detaching first, and waiting to observe node M to see that node M remains attached to the DAG, node N may then determine that node M is not part of its own sub-DAG and may safely re-attach at the lower point. BUT if node N is wrong, then an instability has been created for no gain. For this reason, in its current specification, RPL does not allow a node N to process and DIO from node M and detach from the DAG based on information in the DIO from node M. NOTE that this is in part a consequence of the design consideration that not all nodes may be using the same metrics and making the same optimizations. For example, if all nodes in the network were minimizing ETX, then node N may be mostly certain that any node M advertising a superior ETX is NOT in its own sub-DAG. A further complication may come if node N and node M are trying to make optimizations which are antagonistic to each other. For example, if node N where to try to move under node M, it could create a chain of events whereby node M tried to reverse its position with respect to node M, and a chain reaction of instability could result. A simple example of such a case would be where both nodes M and N have a common neighbor and parent P, and nodes M and N subsequently each try to increase the size of their parent set to be 2. (This case has been more thoroughly explained by Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" sent 30 June 2009.) RPL has nodes advertise a depth deeper than that of their deepest DAG parent. Consider an example where node X has parents of depth {2, 7}, and node Y chooses X as a parent. Suppose that nodes then advertise their `best' depth, i.e. node X advertises a depth of 3. Then node Y will advertise a depth of 4. Then suppose node Z adds node Y as a parent, and advertises a depth of 5. Now, Z can actually come to be a successor of node X's depth 7 parent. The result could be Z->Y->X->(cost 7 parent)->(...)->Z and then there is a loop. By advertising a depth deeper that of its deepest parent, a node advertises its worst case scenario, and in the worst case scenario a loop can be avoided. RPL does not require that the DAG is invariant, rather that the movement of the node with respect to the DAG is coordinated in such a way so as to avoid loops. The thought is, whatever the topology, uncoordinated movement in LLNs may increase overhead and churn and require more reliance on expensive mechanisms such as count-to-infinity. The use of depth (~ hop count) in RPL is not meant to trump other metrics, but once a node has taken up a position in the DAG by using its metrics the node acquires a depth, which then restricts the further options that the node has in order to avoid loops. Regards, -Tim _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jul 6 01:24:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72F028C1DE for ; Mon, 6 Jul 2009 01:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.816 X-Spam-Level: X-Spam-Status: No, score=-8.816 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, MANGLED_SHOP=2.3, 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 uSOugqfvHnS4 for ; Mon, 6 Jul 2009 01:24: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 45CDD28C1DD for ; Mon, 6 Jul 2009 01:24:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,355,1243814400"; d="scan'208";a="44416963" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2009 08:23:41 +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 n668NfL9022692; Mon, 6 Jul 2009 10:23:41 +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.14.3) with ESMTP id n668NfF7004627; Mon, 6 Jul 2009 08:23:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 10:23:41 +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: Mon, 6 Jul 2009 10:23:36 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93F0C@xmb-ams-337.emea.cisco.com> In-Reply-To: <87ocryepw2.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL and new technology Thread-Index: Acn9vkzJZJkfL0PeT3S+pfZIwdPabwAUSZOg References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> <87ocryepw2.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 06 Jul 2009 08:23:41.0260 (UTC) FILETIME=[11C310C0:01C9FE13] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5917; t=1246868621; x=1247732621; 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[Roll]=20ROLL=20and=20new=20technology |Sender:=20; bh=UdOZYYhEOso+RuFhpeuUWwnG84qSqjCnTNyNWk5DDoQ=; b=P3W7HJAuOPGpzIKNm77ryMM38LzLUiwZW2JQbXl1zQYvBVIi9/YSmHnMEx 5giFqbsbUojkZ0BDZpXKhGNI2UO7w7HWiMNcHe6be3AKH/TpaQ/3X/eicu8i HAw/XRYodL; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:24:08 -0000 Hi Richard: RPL definitively tries to endorse the good ideas in CTP. There are 2 main ones, the forwarding time path validation and trickle. We spent most of our time on the trickle piece, and that's not finished as you saw on the list. The path validation is on the shelf, ready to be included depending on the exact properties of the RPL protocol as some final decisions are made. > - Good thing, DV technology has evolved since then, and the techniques > employed in IGRP and EIGRP have been widely deployed and verified over > the last decade. > > I cannot argue on the specific implementation that you know best. This is not about implementation. This is about widely deployed protocols (IGRP, EIGRP) that brought and validated improvements on DV that we need to understand and figure how we can reuse. It's very clear to me that the IETF has enough experience on RIP to know that it fails to pass our requirements (scalability, cost and time of convergence) without such improvements.=20 So the question for RPL was really how can we simply adapt those proven ideas. What you're doing there with CPL, we also did with modern DV IGPs. Before you reject our work, you need to understand those principles, how they work and then you can figure out whether RPL inherits properly those proven properties. My point here is that we are going L3. We need to learn from both sides, IETF and WSN engineering, and make sense to the cross-breeding. You can't just reject the experience form the other side because you're not familiar with it. Same goes for the metric. Going L3 means that you can't use your traditional radio metric(s) as-is. You need to abstract and generalize. We are talking here about an abstraction that can be instantiated on many sorts of radios, powerline, infrared/laser, sat, you name it. Same goes for interoperation and expected deployments. We are not talking about a topical setup based on an homogeneous proprietary implementation by one brand. We are talking about interoperation across brands and generations of device. I think I understand your point on risks exploring terra incognita. I'd argue that the terra is less incognita as you might think if you include the DV experience that I already mentioned in this thread (path holddown, route poisoning, DUAL). I'd turn the question into whether you can use the RPL model to do exactly what you want to do, or what it would take, like allowing to increment the depth by more than one for instance. Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: lundi 6 juillet 2009 00:17 >To: Pascal Thubert (pthubert) >Cc: roll@ietf.org >Subject: Re: [Roll] ROLL and new technology > > Date: Sat, 4 Jul 2009 14:48:12 +0200 > From: "Pascal Thubert (pthubert)" > > There is a wide consensus even in implementations to go for a Distance > Vector approach. > >I completely agree. > > - Good thing, DV properties are very well know. We know RIP and its > limitations, and we know that even in a clean wired space it would not > fit the scale that we are considering. > >The only core algorithmic difference between RIP and RPL is >how loop detection is done. Everyone, including myself, >agrees that RIP's counting-to-infinity won't work. Many >people agree that RPL's hop count won't work either. > > - Good thing, DV technology has evolved since then, and the techniques > employed in IGRP and EIGRP have been widely deployed and verified over > the last decade. > > I cannot argue on the specific implementation that you know best. > All I can say is that it is: > > 1) *inacceptable* to be content with the basic RIP mechanisms (INFINITY > is 16 there for a reason or 2) > >I have never proposed using RIP's loop detection mechanism >for ROLL. It is obvious that it won't work. > >My draft-kelsey-roll-lip-00 uses (or was intended to use, >the draft explicitly does not specify a complete routing >protocol) the data traffic path validation of the Collection >Tree Protocol (CTP). The draft was a result of my noticing >that CTP and RIP have nearly identical routing control >frames, modulo the sizes of the fields. CTP appears to be >simple, dynamic, and robust, which for me are the main >requirements of a ROLL protocol. > >(The other main idea in the draft, using CTP/RIP in the >context of MPLS, made it easy to add CTP's path-cost field >to data messages and also allowed source routes to be added >and removed when a packet crosses in and out of a ROLL >subnet. The subnet-local source routes can then be used for >outward routing within the tree.) > > 2) *useful* to learn from more modern DV protocols (route poisoning, > 3) *necessary* to adapt to the LLN constraints and requirement > >Absolutely. My main concern with RPL is that it fails to >adapt to LLN constraints and requirements. But we disagree >on this. > > [much interesting discussion of individual features > removed] > > What I see here is a set of adaptations of rather well > known techniques in the DV family plus a set of > adaptations to meet LLN requirements. Pretty much what > ROLL is chartered to do. There's still a lot of tuning to > do but the main lines seem properly defined... > >And here too we disagree. To me the discussions on this >list (does hop count trump other metrics, how does having >multiple metrics interact with having multiple parents, for >example) are evidence of this. > >My main concern is that RPL is significantly more complex >than the existing WSN routing protocols that I have used or >am familiar with. More complex protocols take longer to >develop than simpler ones, and tend to be less robust. > > -Richard Kelsey From jvasseur@cisco.com Mon Jul 6 01:35:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38FEA28C1DF for ; Mon, 6 Jul 2009 01:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 GpQTD9y7wDg1 for ; Mon, 6 Jul 2009 01:35:32 -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 8375A28C1CB for ; Mon, 6 Jul 2009 01:35:31 -0700 (PDT) X-Files: None : None X-IronPort-AV: E=Sophos;i="4.42,355,1243814400"; d="scan'208,217";a="44418511" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2009 08:33:59 +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 n668XxhW003588 for ; Mon, 6 Jul 2009 10:33:59 +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.14.3) with ESMTP id n668Xxh0008760 for ; Mon, 6 Jul 2009 08:33:59 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 10:33:58 +0200 Received: from [10.113.78.28] ([10.61.91.158]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 10:33:58 +0200 Message-Id: <141805D8-CBC0-4FDE-9CCD-07E24AE7E246@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-26-126579588 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 10:33:55 +0200 References: <20090706024501.423A73A6A3F@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 06 Jul 2009 08:33:58.0608 (UTC) FILETIME=[81BAE500:01C9FE14] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8829; t=1246869239; x=1247733239; 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:=20Fwd=3A=20I-D=20Action=3Adraft-iwao-roll-dadr-00 .txt=20 |Sender:=20; bh=GiShsyZ2Fs507GvP0xg4D07CkffXq68ah+VFZXO/21U=; b=hA5+VfX0HgIZR+nu88DtSFP9bhUZuGUwfzfB7lwCH9z3fu1rdkzctO0ZQo Xplxzp9A4UsBwr6ym9MhSpIabrsl5rvs0tmKc+ULzsB/Qe2FJxJIuzOtT/6a RfGuvNs5Jb; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:35:33 -0000 --Apple-Mail-26-126579588 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit At the agenda of the ROLL WG meeting. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 6, 2009 4:45:01 AM CEDT > To: i-d-announce@ietf.org > Subject: I-D Action:draft-iwao-roll-dadr-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Distributed Autonomous Depth-first Routing > Protocol in LLN > Author(s) : T. Iwao > Filename : draft-iwao-roll-dadr-00.txt > Pages : 24 > Date : 2009-07-05 > > This document is a proposal of the distributed autonomous depth-first > > routing (DADR) protocol which is quite different from conventional > > algorithms such as AODV and OLSR. It proposes a traversable algorithm > > which can determine a direct path between the global source and the > > global destination in a low power and lossy network (LLN). We propose > > the DADR algorithm whose characteristics work well in LLNs with more > > than 10^4 nodes. This algorithm selects a direct path between the > > global source and the global destination based on a routing-cost- > > function which identifies path-candidates with good communication > > quality between each pair of nodes on the path. This protocol does > > not need to configure the equipment such as setting IP addresses, and > > thisresults in saving cost and time in deploying, establishing and > > operating a large scale network. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Iwao, et al. > > > Expires January 2, 2010 > > > > > [page 2] > > > > > > > > > > Internet-Draft > > > > DADR Protocol > > > > > > > July 2009 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-26-126579588 Content-Type: multipart/mixed; boundary=Apple-Mail-27-126579588 --Apple-Mail-27-126579588 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable At the agenda of the ROLL WG = meeting.

Begin forwarded message:

Date: July 6, 2009 4:45:01 AM = CEDT
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-iwao-roll-dadr-00.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : = Distributed Autonomous Depth-first Routing Protocol in LLN
Author(s) =       : T. Iwao
Filename =        : = draft-iwao-roll-dadr-00.txt
Pages =           : = 24
= Date =            : = 2009-07-05

This document is a proposal of the distributed = autonomous depth-first

 routing (DADR) protocol which is = quite different from conventional

 algorithms such as AODV = and OLSR. It proposes a traversable algorithm

 which can = determine a direct path between the global source and the

=  global destination in a low power and lossy network (LLN). We = propose

 the DADR algorithm whose characteristics work = well in LLNs with more

 than 10^4 nodes. This algorithm = selects a direct path between the

 global source and the = global destination based on a routing-cost-

 function which = identifies path-candidates with good communication

=  quality between each pair of nodes on the path. This protocol does =

 not need to configure the equipment such as setting IP = addresses, and

 thisresults in saving cost and time in = deploying, establishing and

 operating a large scale = network. =


























 Iwao, et al.


=  Expires January 2, 2010




 [page 2] =









=  Internet-Draft



 DADR = Protocol






July 2009

A URL for this = Internet-Draft is:
h= ttp://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt

= Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-27-126579588 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-07-05193631.I-D@ietf.org>

--Apple-Mail-27-126579588 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-27-126579588-- --Apple-Mail-26-126579588-- From pthubert@cisco.com Mon Jul 6 03:25:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBBC3A6C0D for ; Mon, 6 Jul 2009 03:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 fvporEK-HjOO for ; Mon, 6 Jul 2009 03:25:29 -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 7020D3A6BB9 for ; Mon, 6 Jul 2009 03:25:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,355,1243814400"; d="scan'208";a="44436883" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2009 10:25:31 +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 n66APV0l005780; Mon, 6 Jul 2009 12:25:31 +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.14.3) with ESMTP id n66APVAE026889; Mon, 6 Jul 2009 10:25:31 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 12:25:31 +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: Mon, 6 Jul 2009 12:25:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B93FF8@xmb-ams-337.emea.cisco.com> In-Reply-To: <874otqczs5.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle in draft-dt-roll-rpl-00.txt Thread-Index: Acn94R8KyFFjnfN0T42UCX62okPQpwAQc2iA References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com><1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> <874otqczs5.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Philip Levis" X-OriginalArrivalTime: 06 Jul 2009 10:25:31.0059 (UTC) FILETIME=[16BDE030:01C9FE24] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2808; t=1246875931; x=1247739931; 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[Roll]=20Trickle=20in=20draft-dt-roll-r pl-00.txt |Sender:=20; bh=+MUdCSnVeGMX56Ls9/wXyjmp01qh5yjwSPUzHy6yt9E=; b=uZ649VJyVXJ+/4Y1CAiPxYpNs8EQjSSA3OOBUqS7Cm1Z+pLcLIY1hQGQVw H2XuqSe2QMp1VAkuPfNfc8XKIr78TQVC1d8H1zjYoeP5hoLlFQV2TtE6Oosf JdP/2U9w/j; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, gnawali@usc.edu Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:25:31 -0000 Hi Richard: > Like if I have many of other routers around I could yield and suppress > RAs totally. The idea being that some nodes act as routers for some time > and then they stop because they think they've done enough. Neighbors > node discovering a lesser density take over and now act as routers. > >The problematic situation for this is when there is a dense >clique of nodes and two other nodes, one just out of range >of the clique and the other half way inbetween: > > o o o > o o o o <--- 3/4 hop ---> o <--- 3/4 hop ---> o > o o o > >To keep the network connected you want to avoid having the >node in the middle, which has all those neighbors over on >the left, from deciding not to be a router. That's correct. Same for trickle in the current draft.=20 RPL enables a node to detach and form its own tree. The result is that children migrate. A goal is that a subdag that is drawn with a detaching parent is minimal to NULL. If it is NULL, then the node can safely abort it's router function. For a while. So we can cope with this issue. First we have to decide if we want this feature or not. I'd argue that trickling on the RA interval has some unwanted effect, part of that making parent disappearance hard to detect at L3 (think about how MIPv6 uses RA interval). Trickling on the role might be a better idea, at least in some cases. And it does NOT have to be one OR the other. :) Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: lundi 6 juillet 2009 04:27 >To: Pascal Thubert (pthubert) >Cc: pal@cs.stanford.edu; jhui@archrock.com; roll@ietf.org; gnawali@usc.edu >Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt > >Pascal, > > Date: Fri, 3 Jul 2009 15:51:11 +0200 > From: "Pascal Thubert (pthubert)" > > What I'd really like to suppress is the behavior of a router being a > router, as opposed to suppressing some RAs from every routers. > > Like if I have many of other routers around I could yield and suppress > RAs totally. The idea being that some nodes act as routers for some time > and then they stop because they think they've done enough. Neighbors > node discovering a lesser density take over and now act as routers. > >The problematic situation for this is when there is a dense >clique of nodes and two other nodes, one just out of range >of the clique and the other half way inbetween: > > o o o > o o o o <--- 3/4 hop ---> o <--- 3/4 hop ---> o > o o o > >To keep the network connected you want to avoid having the >node in the middle, which has all those neighbors over on >the left, from deciding not to be a router. > > -Richard Kelsey From cabo@tzi.org Mon Jul 6 03:56:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D533A6CFC; Mon, 6 Jul 2009 03:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 qooXJfghdby2; Mon, 6 Jul 2009 03:56:01 -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 876373A6CFB; Mon, 6 Jul 2009 03:56:00 -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.3/8.14.3) with ESMTP id n66AuGi6002910; Mon, 6 Jul 2009 12:56:16 +0200 (CEST) Received: from [192.168.217.107] (p5489FE35.dip.t-dialin.net [84.137.254.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AA4BBB42E; Mon, 6 Jul 2009 12:56:15 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan@ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 12:56:14 +0200 X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG Subject: [Roll] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:56:02 -0000 The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. At IETF75, we will hold a Bar BOF to scope out possible IETF work and maybe form an opinion on which part should be done in which IETF area. Tentative information is at http://u.nu/6jfh = http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp (and you are welcome to contribute to this Wiki page). -> Please tell us whether the envisaged date and time of ->Tue 18:30<- will work for you! A first version of a problem statement (where the above paragraph was stolen from) is at: http://tools.ietf.org/id/6lowapp (draft-bormann-6lowpan-6lowapp-problem-00.txt) I will start planning an agenda for the Bar BOF soon, so if you have something to say that would help in this conversation, please tell me (with an estimated amount of time). Gruesse, Carsten From richard.kelsey@ember.com Mon Jul 6 05:04:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B003A69F1 for ; Mon, 6 Jul 2009 05:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 NlqRtHpFbBRO for ; Mon, 6 Jul 2009 05:04:18 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4BF7328C279 for ; Mon, 6 Jul 2009 05:03:56 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 08:03:51 -0400 Date: Mon, 06 Jul 2009 08:04:20 -0400 Message-Id: <87r5wuvwzf.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B93F0C@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> <87ocryepw2.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93F0C@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 06 Jul 2009 12:03:51.0506 (UTC) FILETIME=[D3AEA320:01C9FE31] Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:04:19 -0000 Hi Pascal, Date: Mon, 6 Jul 2009 10:23:36 +0200 From: "Pascal Thubert (pthubert)" > I cannot argue on the specific implementation that you know best. This is not about implementation. [...] You wrote that line, not I. My point here is that we are going L3. We need to learn from both sides, IETF and WSN engineering, and make sense to the cross-breeding. You can't just reject the experience form the other side because you're not familiar with it. Many of the things in RPL have been tried before in the WSN community. I am unhappy with them precisely because they are familiar. I know the problems that are going to arise because I have already seen them happen. I am not rejecting the ideas in RPL. I have been pointing out flaws that need to be fixed and arguing that given the tight schedule we need to stick to what is already in use rather than inventing something new. -Richard Kelsey From richard.kelsey@ember.com Mon Jul 6 06:36:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C60D28C2E2 for ; Mon, 6 Jul 2009 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 BeC6uyACbVU6 for ; Mon, 6 Jul 2009 06:36:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 446DF28C1D5 for ; Mon, 6 Jul 2009 06:36:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 09:33:26 -0400 Date: Mon, 06 Jul 2009 09:33:55 -0400 Message-Id: <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 06 Jul 2009 13:33:26.0537 (UTC) FILETIME=[57734790:01C9FE3E] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:36:09 -0000 Date: Sat, 4 Jul 2009 20:34:14 +0200 From: "Pascal Thubert (pthubert)" We are certainly converging. Yes. Progress! I do like the concept though maybe I'd have used less bits. That's because I expect a given mesh to be formed of analogous links. I suggest that we get the algorithms figured out and then deal with the exact sizes of the fields. If so, it is possible to define a unit that represents a normalized good hop. In my mind that was 1. It makes sense with ETX in mind that a radio hop that in average will take one retry could a cost of 2. A link that requires one retry on average is a pretty bad link. I would expect that most reliable links would require less than that, hence the need for rational costs. What I strongly doubt is whether the high order octet can still meaningfully be the real hop count. Yes, I agree. Now do we need 2 octets? Could be useful, but remember, IF we count to infinity, then we'll pay for the extra. We definitely do not want to count to infinity. I believe that using the DIO sequence number avoids the need to count to infinity. Also, how do we define parents vs siblings? If that's only the high order bit then that's fine. Otherwise, being too fine grained will reduce the chances to have siblings. If the minimum hop cost is k, then any two nodes whose costs differ by less than k are siblings, in the sense that neither is a parent or ancestor of the other. This has the effect of making the sibling relationship nontransitive. A parent and child can both be siblings of the same node. Some terminology (which I just made up): If a node has DAGcost c and the minimum hop cost is k, then: - neighbors with costs in the interval (c, c-k) are "inward siblings". - neighbors with costs in the interval (c+k, c] are "outward siblings" Note that if k = 1 there are no inward siblings and the outward siblings all have the same cost as the node itself, as we have now. Routing via inward siblings will not create a loop. Converting an inward sibling into a parent will also not create a loop, assuming that the new parent has not moved simultaneously. Routing via outward siblings may create a loop. Converting an outward sibling into a parent will not create a loop once the ex-sibling/new-parent has been informed of the change, again assuming no simultaneous moves. -Richard Kelsey From pthubert@cisco.com Mon Jul 6 09:18:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF3228C331 for ; Mon, 6 Jul 2009 09:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=0.630, 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 uXnYRhopytZM for ; Mon, 6 Jul 2009 09:18:15 -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 4A7EC28C271 for ; Mon, 6 Jul 2009 09:18:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,357,1243814400"; d="scan'208";a="44476584" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2009 16:14:15 +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 n66GEF31027721; Mon, 6 Jul 2009 18:14:15 +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.14.3) with ESMTP id n66GEF2o008377; Mon, 6 Jul 2009 16:14:15 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 18:14:15 +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: Mon, 6 Jul 2009 18:14:10 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> In-Reply-To: <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn+PmlJgqbhAGqtT1WpUjkyZllvxwACLPZg References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 06 Jul 2009 16:14:15.0610 (UTC) FILETIME=[CEBEF9A0:01C9FE54] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5212; t=1246896855; x=1247760855; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=3OJVpRorKKVm78k6TKOUtr7XvqJW5MoAb1VsNXW0oaQ=; b=fHQCrs+6SMjHIkojYaiRqTPAcHV+386aBmfQxHrTbX69fEXq79IGk8r34Q UKyjCGnPcolSHU2Uf4t7iPpdFnUP/9qUILLSzbewVW96Daot4T0tHdn7GdUN 8qAEkAy8eb; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:18:17 -0000 Hi Richard. (Some sort of) simultaneous moves are already prevented in the spec by the boot time random.=20 That's a tie breaker for nodes that would simultaneously attach to one another. So when a router sends an RA and receives another one within a short window of time, it will be able to use that only if the random based tie breaker allows so - so one will and not the other. Note that the highest order octet of that tie breaker can be administered if you want to control how the network forms in a floating environment. Yet re-parenting to siblings is discouraged because of additional complexities associated - like you said, collision, but mostly cases where your sibling goes deeper by attaching to another sibling, but you don't know because you missed its RA, and then what you think is inwards but is outwards, and then you end up in a loop. So basically RPL does not let a router augment its depth and I understand that your idea of attaching to an inwards sibling would do that.=20 >From that standpoint, I fail to see that k>1 yields a huge benefit for the cost of the extra complexity. I still can see value of your decimal approach as long as being more precise does not cause us to be less stable. As I understand that the idea was to use the integer part for loop avoidance and still enable to advertise subincrements that could add up along the way and represent the path cost more honestly. There's a danger of ending up with numbers like 1.99 and still advertise 1 or the undesired case where a hop that you would rate .10 causes you to go from 1 to 2 because the integer part is the depth and must be incremented. There's also the danger of going from 1.99 to 2.01 which would cause the node to detach and reattach, require some hysteresis etc... brrrrr. Now we could pick a unit that's still quite coarse but yet a half or a 4th a normalized hop cost, and let a hop cost up to 8 or 16 of that unit. That seems to enable abstracting what we want to achieve here with things like ETX. So we would let one hop increment the depth by up to eight and still enable 32 hops across. Or up to 16 and enable at least 16 hops across, generally more. I thought that this is really where you wanted to get. Did I miss something? Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: lundi 6 juillet 2009 15:34 >To: Pascal Thubert (pthubert) >Cc: jhui@archrock.com; roll@ietf.org >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > > Date: Sat, 4 Jul 2009 20:34:14 +0200 > From: "Pascal Thubert (pthubert)" > > We are certainly converging. > >Yes. Progress! > > I do like the concept though maybe I'd have used less > bits. That's because I expect a given mesh to be formed > of analogous links. > >I suggest that we get the algorithms figured out and then >deal with the exact sizes of the fields. > > If so, it is possible to define a unit that represents a > normalized good hop. In my mind that was 1. It makes > sense with ETX in mind that a radio hop that in average > will take one retry could a cost of 2. > >A link that requires one retry on average is a pretty bad >link. I would expect that most reliable links would require >less than that, hence the need for rational costs. > > What I strongly doubt is whether the high order octet can still > meaningfully be the real hop count. > >Yes, I agree. > > Now do we need 2 octets? Could be useful, but remember, > IF we count to infinity, then we'll pay for the extra. > >We definitely do not want to count to infinity. I believe >that using the DIO sequence number avoids the need to count >to infinity. > > Also, how do we define parents vs siblings? If that's > only the high order bit then that's fine. Otherwise, > being too fine grained will reduce the chances to have > siblings. > >If the minimum hop cost is k, then any two nodes whose costs >differ by less than k are siblings, in the sense that >neither is a parent or ancestor of the other. This has the >effect of making the sibling relationship nontransitive. A >parent and child can both be siblings of the same node. > >Some terminology (which I just made up): > If a node has DAGcost c and the minimum hop cost is k, > then: > > - neighbors with costs in the interval (c, c-k) are > "inward siblings". > > - neighbors with costs in the interval (c+k, c] are > "outward siblings" > >Note that if k =3D 1 there are no inward siblings and the >outward siblings all have the same cost as the node itself, >as we have now. > >Routing via inward siblings will not create a loop. >Converting an inward sibling into a parent will also >not create a loop, assuming that the new parent has >not moved simultaneously. > >Routing via outward siblings may create a loop. >Converting an outward sibling into a parent will not >create a loop once the ex-sibling/new-parent has >been informed of the change, again assuming no >simultaneous moves. > -Richard Kelsey > > > From pal@cs.stanford.edu Mon Jul 6 09:56:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5084A3A6D3F for ; Mon, 6 Jul 2009 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy3rH1koviq0 for ; Mon, 6 Jul 2009 09:56:36 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 909F83A6D37 for ; Mon, 6 Jul 2009 09:56:36 -0700 (PDT) Received: from dnab42203f.stanford.edu ([171.66.32.63]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MNrUN-0004F8-1T; Mon, 06 Jul 2009 09:56:24 -0700 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@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 v935.3) Date: Mon, 6 Jul 2009 09:56:22 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:56:37 -0000 On Jul 3, 2009, at 6:51 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > I think I asked you that same question in Dublin but now we have a > context. > > What I'd really like to suppress is the behavior of a router being a > router, as opposed to suppressing some RAs from every routers. > > Like if I have many of other routers around I could yield and suppress > RAs totally. The idea being that some nodes act as routers for some > time > and then they stop because they think they've done enough. Neighbors > node discovering a lesser density take over and now act as routers. > > Could you adapt your trickle thinking to get there? Can you be more precise? Is it that you want a router to more aggressively suppress others, or is it that you want a router to decide it should suppress itself more? Two questions. The first is: where is the decision is made? Is it: 1) Node A decides node B should stop being a router, or 2) Node B decides it should stop being a router? 1) has problematic security implications. The second is whether node B (who thinks it's done enough) should suppress its RAs even if there are no other nodes around it sending RAs. I.e., what happens when every node thinks it's done enough? The simplest way to get (reasonably) deterministic suppression through priorities is by having different interval lengths. If node A has an interval of length T and node B has an interval of length 2T, node A will always transmit in node B's quiet period and suppress it. But this assumes k=1. Ultimately, Trickle is a randomized algorithm, and there are always chances of packet drops. So without entertaining the possibility of disconnection, B will send *some* RAs, albeit perhaps far fewer than A. Phil From pal@cs.stanford.edu Mon Jul 6 10:02:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF8928C3BC for ; Mon, 6 Jul 2009 10:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EabEtyAdgTab for ; Mon, 6 Jul 2009 10:02:23 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 005663A6D3A for ; Mon, 6 Jul 2009 10:02:20 -0700 (PDT) Received: from dnab42203f.stanford.edu ([171.66.32.63]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MNrHv-0003hX-6b; Mon, 06 Jul 2009 09:43:31 -0700 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93C6B@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 v935.3) Date: Mon, 6 Jul 2009 09:17:21 -0700 References: <1994889821.17664401246488954024.JavaMail.root@mail02.pantherlink.uwm.edu> <2F5F2067-96A5-464A-8817-98C174A4B537@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93C6B@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: roll Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:02:23 -0000 On Jul 3, 2009, at 5:06 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > What we call depth here does not have to represent a hop count. It > should be incremented by a number that represents an abstraction of > the > cost to the parent and that cannot be null. I didn't say it did -- I was responding to Mukul's suggestion that routes should be constrained by hopcount. Phil From pal@cs.stanford.edu Mon Jul 6 10:05:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5888E3A67DF for ; Mon, 6 Jul 2009 10:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vzQdz59pePj for ; Mon, 6 Jul 2009 10:05:12 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 81EB53A682D for ; Mon, 6 Jul 2009 10:05:12 -0700 (PDT) Received: from dnab42203f.stanford.edu ([171.66.32.63]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MNrHu-0003hX-OS; Mon, 06 Jul 2009 09:43:30 -0700 Message-Id: From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4A4DC7DC.7070100@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 09:16:31 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:05:13 -0000 On Jul 3, 2009, at 1:57 AM, Alexandru Petrescu wrote: >> Richard, >> This seems like a totally reasonable metric to use, but I'd be wary >> of saying it's *the* metric to use. Some implementations are going >> to want to consider hopcount, others won't. It's just another >> metric. Rather than hardwire hopcount based assumptions into the >> protocol design, we should put it on equal footing as other >> metrics. Correspondingly, the protocol should have general, metric- >> independent mechanisms for detecting and avoiding loops. > > Phil, what does 'loop' mean when metrics other than hopcount are > used? What does a loop look like when e.g. ETX is used as metric? If there's a loop in an ETX graph, then ETX does not monotonically decrease along the route. This goes back to Jonathan's comment on metric vectors. Phil From richard.kelsey@ember.com Mon Jul 6 10:31:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811943A6924 for ; Mon, 6 Jul 2009 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CtfJ19SqCaNx for ; Mon, 6 Jul 2009 10:31:29 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6F6F73A6D2B for ; Mon, 6 Jul 2009 10:31:29 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 13:30:30 -0400 Date: Mon, 06 Jul 2009 13:31:00 -0400 Message-Id: <87k52lwwff.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 06 Jul 2009 17:30:30.0896 (UTC) FILETIME=[75D43700:01C9FE5F] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:31:30 -0000 Hi Pascal, Date: Mon, 6 Jul 2009 18:14:10 +0200 From: "Pascal Thubert (pthubert)" [discussion of reparenting to siblings] From that standpoint, I fail to see that k>1 yields a huge benefit for the cost of the extra complexity. It's a side issue and not particularly important, so we needn't go into it. We can leave that siblings are nodes with the same cost to the root. I still can see value of your decimal approach as long as being more precise does not cause us to be less stable. As I understand that the idea was to use the integer part for loop avoidance and still enable to advertise subincrements that could add up along the way and represent the path cost more honestly. Not quite. The idea is to use a route cost for loop avoidance. The route cost has a fractional part, but the entire value is used for loop avoidance, including the fraction. Whether or not the low bits of the cost are considered a fraction is a matter of terminology. The outcome is exactly the same if you have an integer cost and require that each hop have a cost of at least k, for some constant k. To get a useful amount of precision, k should be at least 8 or 16. I don't think that going higher than that is particularly useful. -Richard Kelsey From richard.kelsey@ember.com Mon Jul 6 11:17:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14BD3A69D5 for ; Mon, 6 Jul 2009 11:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 bXlfvU8EjbI8 for ; Mon, 6 Jul 2009 11:17:31 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id F0D563A67DF for ; Mon, 6 Jul 2009 11:17:30 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 14:14:59 -0400 Date: Mon, 06 Jul 2009 14:15:29 -0400 Message-Id: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 06 Jul 2009 18:14:59.0693 (UTC) FILETIME=[AC8E51D0:01C9FE65] Subject: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:17:32 -0000 I do not understand the need for the collision avoidance mechanism. The draft says: 5.4.3.3. Collision A race condition occurs if 2 nodes send Router Advertisement - DAG Information Option at the same time and wish to join each other. This might happen between nodes at a same depth, or nodes which act as DAG root of their own DAGs. [...] Section 5.2 states that candidate neighbors at the same depth cannot be considered as candidate parents. If two nodes at the same depth transmit DIOs at the same time there are no new candidate parents and however much they may wish to join each other, such moves are prohibited. Joining to another node at the same level requires leaving the DAG, waiting for the DAG sequence number to change, and then rejoining. Two devices cannot collide while doing this because they cannot advertise the new sequence number without first rejoining to someone that already has it. Am I missing something? -Richard Kelsey From jhui@archrock.com Mon Jul 6 12:53:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD643A6983 for ; Mon, 6 Jul 2009 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 qdbmxfeG5UhZ for ; Mon, 6 Jul 2009 12:53:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AAE473A688F for ; Mon, 6 Jul 2009 12:53:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4A532AF884; Mon, 6 Jul 2009 12:51:55 -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 vbDpUsGS2PpI; Mon, 6 Jul 2009 12:51:50 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 543BFAF881; Mon, 6 Jul 2009 12:51:50 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87k52lwwff.fsf@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 v935.3) Date: Mon, 6 Jul 2009 12:51:49 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:53:14 -0000 Hi Richard, On Jul 6, 2009, at 10:31 AM, Richard Kelsey wrote: > From that standpoint, I fail to see that k>1 yields a huge benefit > for > the cost of the extra complexity. > > It's a side issue and not particularly important, so > we needn't go into it. We can leave that siblings > are nodes with the same cost to the root. If I understand properly, the fundamental difference in philosophy between Pascal's approach and yours is the orthogonal reasons behind coarse vs. fine in the route cost precision. Pascal wants to encourage a undirected sibling edges using lower precision. You want to allow greater information in the route cost by making it have greater precision. Both are fruitful, but are unfortunately at odds. Making k>1 means that a packet can actually make backwards progress, so I'm not sure that's exactly what we want. I personally favor your original approach with k = 1. It does move us closer to a true DAG, but I think robustness will still be good in networks that aren't dangerously sparse. > I still can see value of your decimal approach as long as being more > precise does not cause us to be less stable. As I understand that > the > idea was to use the integer part for loop avoidance and still > enable to > advertise subincrements that could add up along the way and > represent > the path cost more honestly. > > Not quite. The idea is to use a route cost for loop > avoidance. The route cost has a fractional part, but the > entire value is used for loop avoidance, including the > fraction. > > Whether or not the low bits of the cost are considered a > fraction is a matter of terminology. The outcome is exactly > the same if you have an integer cost and require that each > hop have a cost of at least k, for some constant k. To get > a useful amount of precision, k should be at least 8 or 16. > I don't think that going higher than that is particularly > useful. Agree. Things make much more sense now if we say that it is a single route cost and each hop must increment by at least X (8 or 16). I also think 8 or 16 is sufficient. Now that we've gone down a path where ETX can be embedded in the loop detection information, one open question I'm still grappling with is why define a route cost for loop detection separate from the actual routing metrics used? In most cases, I would expect a single route cost metric will be used. In cases when multiple metrics are used, they will often be combined into a single number using some polynomial. Are there cases where multiple metrics are used without any combination? If so, why not simply designate one of those metrics to be used for loop detection? Isn't the real issue here that the loop detection metrics were disjoint from the desired routing metrics? -- Jonathan Hui From jhui@archrock.com Mon Jul 6 14:14:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745083A6C48 for ; Mon, 6 Jul 2009 14:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 7OD0sQLg7Gz0 for ; Mon, 6 Jul 2009 14:14:18 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B2CA43A68AC for ; Mon, 6 Jul 2009 14:14:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 91C76AF8A0; Mon, 6 Jul 2009 14:13:41 -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 WXEL6EySoIHp; Mon, 6 Jul 2009 14:13:36 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id E9E46AF881; Mon, 6 Jul 2009 14:13:34 -0700 (PDT) Message-Id: <9E928DEC-443C-4CCA-B812-A20694768083@archrock.com> From: Jonathan Hui To: Philip Levis 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 v935.3) Date: Mon, 6 Jul 2009 14:13:33 -0700 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:14:19 -0000 On Jul 6, 2009, at 9:56 AM, Philip Levis wrote: > Ultimately, Trickle is a randomized algorithm, and there are always > chances of packet drops. So without entertaining the possibility of > disconnection, B will send *some* RAs, albeit perhaps far fewer than > A. Exactly. The goal of Trickle isn't to actively enable or disable routers. It simply reduces the transmission rate of RAs a particular node sends. Every router is still a router. It is a tradeoff between resource consumption and latency. Channel capacity is one such resource so it makes sense for any node that has many neighbors to reduce the number of RA transmissions because the finite channel capacity is shared with all of its neighbors. If the resource constraints on transmitting RAs is lax, then suppression probably does more harm than good from a latency perspective. I'm not convinced that a more complex topology maintenance scheme is the right way to go either. There's been a bunch of work in developing such mechanisms in the sensornet space, but their effectiveness in real-world environments is often hindered by the very things we worry about - dynamic radio connectivity, message loss, limited energy, etc. -- Jonathan Hui From wintert@acm.org Mon Jul 6 15:14:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825523A6870 for ; Mon, 6 Jul 2009 15:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_BACKHAIR_31=1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQoxniaxa69f for ; Mon, 6 Jul 2009 15:14:14 -0700 (PDT) Received: from smtp105.prem.mail.ac4.yahoo.com (smtp105.prem.mail.ac4.yahoo.com [76.13.13.44]) by core3.amsl.com (Postfix) with SMTP id 0506E28C328 for ; Mon, 6 Jul 2009 15:14:04 -0700 (PDT) Received: (qmail 1751 invoked from network); 6 Jul 2009 22:13:15 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp105.prem.mail.ac4.yahoo.com with SMTP; 06 Jul 2009 15:13:15 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: IchkSJwVM1kgPB0AF_hAksVSyE_Yf8Eo0BQO8y1EuCc7EKTheaBjgJNmNPb59eyycOxP1X6CKynle2G_lnNQAfUbrRMrsSnMTmOFQZ956P32_ZKW04EhJ4B8UepJ.btJ9hOaRiJzB7YzdTiAzkMJDbjjNm0b99aqhdcn1AK5kXIIa_rV4kr8pC3Rqeu3aSqKF8Lo6oO6OY6Db4_1DLHB4k9COHoOwlIOHiIIauKAYQkSeth.JxgoPhq8ZU_T4X870VlmClwl82NRQlPCwRx6kGxsCPuwTHOipf4XLaUo6kA1t7NMwyq5CfWm8MkGOQSMiq_Zfg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5276F6.4040802@acm.org> Date: Mon, 06 Jul 2009 18:13:10 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93D62@xmb-ams-337.emea.cisco.com> <87d48hy917.fsf@kelsey-ws.hq.ember.com> <4A513404.1000905@acm.org> <877hymd139.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <877hymd139.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:14:15 -0000 Hi Richard, Richard Kelsey wrote: > > For illustration, if LBR<->B becomes so bad as to not use > the link, then: > > 6) B will leave the LLN (and start its own floating DAG) > 7) B may then, after a hold-up period, hear the DIO of C > and attach at depth 3. > > What is the purpose of the hold-up period? Is it enough to > hear a DIO from C with a later sequence number? Or is the > hold-up period typically less than the period between RAs? > > -Richard Kelsey > Yes, it would be sufficient to hear a DIO from C with a later sequence number - then node B would be certain that node C was not in its sub-DAG. Meanwhile, the hold-up timer in this case allows some time for the fact that node B has detached and formed its own floating DAG to diffuse, in the form of RA-DIOs into node Bs sub-DAG. If node B had a sub-DAG, and if node C happened to be part of it, then by the time the hold-up has finished then node C should realize, and advertise in its RA-DIOs, that it is now part of the floating sub-DAG. Node B would subsequently see that Node C is deeper in its own sub-DAG and not attach to node C, avoiding a loop. In an alternate example, node C is able to remain part of the grounded DAG and node B may proceed to attach. In a more complicated example, node B's sub-DAG may have several options to attach back to the grounded DAG. In these cases the hold-up timer may have a variable duration such that nodes who can get a better position into the grounded DAG will move first, and the rest of the nodes can subsequently follow. -Tim From richard.kelsey@ember.com Mon Jul 6 15:46:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400F43A6DB1 for ; Mon, 6 Jul 2009 15:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 dEz9c6lR+ZpC for ; Mon, 6 Jul 2009 15:46:03 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id C2ED03A6D11 for ; Mon, 6 Jul 2009 15:46:01 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 18:45:23 -0400 Date: Mon, 06 Jul 2009 18:45:53 -0400 Message-Id: <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Mon, 6 Jul 2009 12:51:49 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 06 Jul 2009 22:45:23.0615 (UTC) FILETIME=[72C45AF0:01C9FE8B] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:46:04 -0000 Hi Jonathan, From: Jonathan Hui Date: Mon, 6 Jul 2009 12:51:49 -0700 On Jul 6, 2009, at 10:31 AM, Richard Kelsey wrote: > From that standpoint, I fail to see that k>1 yields a huge benefit > for the cost of the extra complexity. > > It's a side issue and not particularly important, so > we needn't go into it. We can leave that siblings > are nodes with the same cost to the root. If I understand properly, the fundamental difference in philosophy between Pascal's approach and yours is the orthogonal reasons behind coarse vs. fine in the route cost precision. Pascal wants to encourage a undirected sibling edges using lower precision. You want to allow greater information in the route cost by making it have greater precision. Both are fruitful, but are unfortunately at odds. With hop count neighbors are either: parents (lower hop count) siblings (same hop count) ignored (higher hp count) With a more precise metric, where the optimal link has cost k, neighbors can be divided into four categories: parents (cost less by k or more) inward siblings (cost less by k-1 or less) siblings (same cost) ignored (higher cost) In either case, forwarding via siblings or 'ignored' can send a message around a loop. Forwarding via parents or inward siblings cannot. Using a more precise metric produces fewer siblings, with the remainder being either 'ignored' or inward siblings. category. The net effect is to increase the number of neighbors that can be used to forward messages without creating into a loop, while decreasing the number that might create a loop. I don't have any idea which is likely to work better in practice. Making k>1 means that a packet can actually make backwards progress, so I'm not sure that's exactly what we want. I personally favor your original approach with k = 1. It does move us closer to a true DAG, but I think robustness will still be good in networks that aren't dangerously sparse. I am not sure what 'k' means here. Now that we've gone down a path where ETX can be embedded in the loop detection information, one open question I'm still grappling with is why define a route cost for loop detection separate from the actual routing metrics used? One advantage of having multiple metrics is that it indicates the actual properties of the route. It might make a difference whether it was a low-latency or low-energy route. This works well only if there are not multiple parents (a tree, not a DAG), so that picking a parent also picks a path. I suppose that a root could create two separate DAGs with different metrics. For time-critical messages you use the low latency DAG, for ordinary messages you use the low energy one, even though they go to the same root. Keeping track of two DAGs would be costly. In most cases, I would expect a single route cost metric will be used. In cases when multiple metrics are used, they will often be combined into a single number using some polynomial. Are there cases where multiple metrics are used without any combination? If so, why not simply designate one of those metrics to be used for loop detection? If you do that, the loop detection metric will trump the other ones in some cases. Isn't the real issue here that the loop detection metrics were disjoint from the desired routing metrics? Yes. A related issue is that for lossy links I think any metric works better if the second best link cost is not twice the best. With hop count you have no choice. -Richard Kelsey From wintert@acm.org Mon Jul 6 15:46:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A5D28C41A for ; Mon, 6 Jul 2009 15:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKZd1UKyuiN for ; Mon, 6 Jul 2009 15:46:37 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id 5699F28C2F7 for ; Mon, 6 Jul 2009 15:46:37 -0700 (PDT) Received: (qmail 57992 invoked from network); 6 Jul 2009 22:46:06 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 06 Jul 2009 15:46:06 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: bVMfRXQVM1lZU.qCvyxfrwTlpybjDjfeOWfVqZV8mr9SpAqmtBt8MFIPNhuIp8h__u7MEUxpVUJ5Jl1hTXPxaerKJao_blBJfZCRBe_9TRoZIPppBGW9ZiV3Fco2REEQqCgrww3twPF3SEiShMrYi.8pwRSPx.qvzbHyfrhafLM6jpERH8L5Tiz5pJTzwqV2iN2XZ78kUpbpkkYfrdpxvBAsJT_HGtW.SeTV4rZVdr.oJneh5Kc5PNddu2t7Yk_k_NGPQmm1waTey7PyKUsUJYlv8SkwfEhsarsUV7z5rg9U3eZDFBB1wL2xBdiIzjyv5eAHi5u8R9PiibQU5F6aVxLrxhuMWDK5T42L X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A527EAA.4060603@acm.org> Date: Mon, 06 Jul 2009 18:46:02 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:46:38 -0000 Hi Richard, Richard Kelsey wrote: > Date: Sun, 05 Jul 2009 18:52:07 -0400 > From: Tim Winter > > 2) What about other flows? > [...] Nodes who are unable to learn > routing state pass the Destination Advertisements inward, building up > source routing information along the way so that they may be traversed > again on the outward flow. The exact implementation of source routing in > support of this mechanism is not something that has been addressed by RPL > as yet. > > In general, is adding an IP source route to a forwarded > packet allowed? Could a root add a source route to an > incoming packet before forwarding it down the DAG? It seems that such action on the part of the DAG root would make this mechanism work much better, e.g. adding the proper source routing information to the packet as it traverses the root and not requiring the source of the packet to know of LLN routing internals. But the details, and the proper mechanisms in light of IPv6 architecture, would have to be worked out. There would certainly be some security considerations, etc. as well. > > 3) Metrics > A key design point, one that may need to be further constrained, is > that under RPL each node does not assume that other nodes are acting > cooperatively, or even that they are using or understand the same set of > metrics. One node could be optimizing for latency, another node could be > optimizing for ETX, and a third could be optimizing for > minimum energy. > > This doesn't seem very useful to me. To the extent that > these three are independent, you could easily end up with > routes that were bad at all of them. Why is this a key > design point? > Agreed that this situation would not be very useful in practice- why would anyone deploy such a network? Certainly such a network is not likely to be optimized. BUT RPL does not currently specify any particular metrics or how the implementation may constrain or optimize them. And this then leads to the possibilities that, e.g. different vendors/software version/configurations may be deployed into the LLN, intentionally or accidentally or over the course of years of maintenance and upgrades, which do not work well together- they may not understand each others metrics, they may not propagate each others metrics in expected ways, or their constraints may work against each other. RPL has been specified in such a way that even such a case where nodes are not working cooperatively, they can still interoperate to the point that a LLN can be formed with some loop avoidance and even ought to be stable (but not necessarily optimal). And, as you have demonstrated, in some cases RPL can be too conservative in getting to this solution. I am hopeful that we can come up with a way to let this aspect of RPL work more closely with the metrics in cases where it is safe from the loop avoidance perspective. As this effort proceeds maybe some more work in the metrics draft can help to clarify what a routing solution ought to be prepared to handle. With regard to RPL, I think that so far some of the other threads regarding the loop avoidance metrics, etc. are making some good progress... > Also, it seems to me that this interacts poorly with having > a DAG. With a tree a node receives a single value for each > metric from its parent. With a DAG, one parent may have a a > low latency but high energy cost while another parent has > high latency and low energy cost. What metric values should > the child advertise? Generally, if the loop avoidance mechanism is in place to cover the `worst case', then a child could be safe to advertise the values from the DIO propagating from its typical case (or best case if you want to be optimistic) parent. If the loop avoidance mechanism comes to rely directly on a metric, then it seems that a node should tend to propagate the worst-case metric, for the same reason that a node gives its depth today as deeper than its deepest feasible parent. > > Given the dubious benefits of having different nodes > optimize different metrics, and the bad interaction with > having multiple parents, I really don't understand the > emphasis on this feature. > > -Richard Kelsey > It is perhaps mostly a question of interoperability. Should such a scenario come to pass, what should the LLN do? Can we expect that all nodes in the LLN will be having the same software, the same understanding of metrics and constraints and optimization goals, etc. When we look at a typical LLN deployment today, maybe this is true more often than not. But as we open up the possibility for LLN nodes to truly interoperate with standards-based IPv6, what then? RPL in its present form is trying to establish some base guidelines as to how such a heterogeneous LLN might organize itself, while leaving some freedoms for the implementors... -Tim From wintert@acm.org Mon Jul 6 16:01:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8743A6D11 for ; Mon, 6 Jul 2009 16:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DajGXqheq87r for ; Mon, 6 Jul 2009 16:01:04 -0700 (PDT) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 31B3B28C26C for ; Mon, 6 Jul 2009 16:01:04 -0700 (PDT) Received: (qmail 78647 invoked from network); 6 Jul 2009 23:00:04 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 06 Jul 2009 16:00:04 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: RDufSUUVM1mhur0i9hFLVRGZ.ysd0sFd3050wJ8wfPV1CjCbNm4zBBbd2i9X4Md88WbE52ZjRy8GNNXVLPkXVAZ.i8CvmT9uctyvw.yky._Nq.6y76XBdN25qBtIa9md.hEnIEmCrJ22QSReBWkh3BJMV5NWP6lNObF4TlBmCjxdYXS0S2WK.5bbKxeo5YBkl.yek9dEU8up.oIw_V77NdQ__6uRWG.BdC6QVVDhmONCvOLlGnJ.MmGhMz99OrmxUTEPs1v_J1NAN_77eit53Z04ai0_iZc75UzUL_U9UXn4l4v.KE0k8qPvA14rvYXh_drZNtYBzwYZL2DkMoD3x0EgVzyHV8NNc8go X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5281F0.5050306@acm.org> Date: Mon, 06 Jul 2009 19:00:00 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Richard Kelsey References: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:01:05 -0000 Richard, Good catch, it does seem we ought to remove the "at a same depth" case. In the other case, two nodes rooting their own floating DAGs might still have a collision if they at the same time decide to join each other's DAG. Thanks, -Tim Richard Kelsey wrote: > I do not understand the need for the collision avoidance > mechanism. The draft says: > > 5.4.3.3. Collision > > A race condition occurs if 2 nodes send Router Advertisement - DAG > Information Option at the same time and wish to join each other. > This might happen between nodes at a same depth, or nodes which act > as DAG root of their own DAGs. [...] > > Section 5.2 states that candidate neighbors at the same > depth cannot be considered as candidate parents. If two > nodes at the same depth transmit DIOs at the same time there > are no new candidate parents and however much they may wish > to join each other, such moves are prohibited. Joining to > another node at the same level requires leaving the DAG, > waiting for the DAG sequence number to change, and then > rejoining. Two devices cannot collide while doing this > because they cannot advertise the new sequence number > without first rejoining to someone that already has it. > > Am I missing something? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jhui@archrock.com Mon Jul 6 16:06:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4053A6A51 for ; Mon, 6 Jul 2009 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 H9PFgfe3qmGb for ; Mon, 6 Jul 2009 16:06: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 5A3C73A6842 for ; Mon, 6 Jul 2009 16:06:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 06F3FAF8A6; Mon, 6 Jul 2009 16:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvV-mHeEaDWB; Mon, 6 Jul 2009 16:06:06 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 10C52AF881; Mon, 6 Jul 2009 16:06:06 -0700 (PDT) Message-Id: <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87bpnxfn1a.fsf@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 v935.3) Date: Mon, 6 Jul 2009 16:06:04 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:06:41 -0000 Hi Richard, On Jul 6, 2009, at 3:45 PM, Richard Kelsey wrote: > Using a more precise metric produces fewer siblings, with > the remainder being either 'ignored' or inward siblings. > category. The net effect is to increase the number of > neighbors that can be used to forward messages without > creating into a loop, while decreasing the number that might > create a loop. > > I don't have any idea which is likely to work better in > practice. In the end we are saying the same things just in different words. A less precise route cost produces more siblings and leaves more edges undirected. A more precise route cost makes more edges directed. The one that works better in practice depends on the density and number of feasible successors. In other words, if there are many edges to choose from - why not orient them and avoid loops altogether? In a sparse network, you might want to leave them undirected to give greater opportunity of routing around failures. > Making k>1 means that a packet can actually make > backwards progress, so I'm not sure that's exactly what > we want. I personally favor your original approach with k > = 1. It does move us closer to a true DAG, but I think > robustness will still be good in networks that aren't > dangerously sparse. > > I am not sure what 'k' means here. Sorry - too many uses of 'k' in this thread. It's the same 'k' that you used when defining "inward/outward" siblings. I was just observing that outward siblings is worse that strict siblings in that a packet may make reverse progress when following outward siblings. > Now that we've gone down a path where ETX can be embedded > in the loop detection information, one open question I'm > still grappling with is why define a route cost for loop > detection separate from the actual routing metrics used? > > One advantage of having multiple metrics is that it > indicates the actual properties of the route. It > might make a difference whether it was a low-latency > or low-energy route. This works well only if there > are not multiple parents (a tree, not a DAG), so > that picking a parent also picks a path. The advertised metric in the DAG case can just be the upper bound. In the hop-count case that's in the current RPL draft, the advertised depth indicates that all of it's parents will have a smaller hop count. > I suppose that a root could create two separate DAGs > with different metrics. For time-critical messages > you use the low latency DAG, for ordinary messages you > use the low energy one, even though they go to the > same root. Keeping track of two DAGs would be costly. The Cisco guys would say that this is a classic use case of Multiple Topology Routing (MTR). Maintaining two DAGs is basically what they would propose to do :-). I do agree that maintaining multiple topologies is not cheap. > In most cases, I would expect a single route cost metric > will be used. In cases when multiple metrics are used, > they will often be combined into a single number using > some polynomial. Are there cases where multiple metrics > are used without any combination? If so, why not simply > designate one of those metrics to be used for loop > detection? > > If you do that, the loop detection metric will trump > the other ones in some cases. Yes, but at least you're using a metric that you care about. What is a good example of having two disjoint metrics that you would prefer not to combine for a routing cost, but would combine for loop avoidance? > Isn't the real issue here that the loop detection metrics were > disjoint from the desired routing metrics? > > Yes. A related issue is that for lossy links I think any > metric works better if the second best link cost is not > twice the best. With hop count you have no choice. Agree. -- Jonathan Hui From jvasseur@cisco.com Tue Jul 7 01:04:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C382A3A6DE6 for ; Tue, 7 Jul 2009 01:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 E3gvoHYn7RYW for ; Tue, 7 Jul 2009 01:04:10 -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 050D628C349 for ; Tue, 7 Jul 2009 01:04:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,361,1243814400"; d="scan'208,217";a="44516994" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2009 08:04:04 +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 n67844fw002896 for ; Tue, 7 Jul 2009 10:04:04 +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.14.3) with ESMTP id n67844kT010919 for ; Tue, 7 Jul 2009 08:04:04 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 10:04:04 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 10:04:03 +0200 Message-Id: <53B2CA8C-1FF1-42F8-A901-0E806CC295EF@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-7-211187509 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 10:04:03 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 08:04:03.0779 (UTC) FILETIME=[7E577930:01C9FED9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=37592; t=1246953844; x=1247817844; 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:=20Final=20Agenda |Sender:=20; bh=EkCJoVAzjXgBXqsHZ0dn6oUk5uY0YqLxcl312hCgtYk=; b=iju7DaISJgr/hCnlchpN2FwwoPYw1EvVr/t7bX76b6+OSElVG1oV8AH60w LmzjW3L3vmAvSE0rIktJU1WDmq4FYABINYM06qV33OurIq4lwzDiYRJ4vPCv Xm7hIydbkh; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Final Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 08:04:11 -0000 --Apple-Mail-7-211187509 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit It is now finalized (since yesterday): 1500-1520 Afternoon Beverage and Snack Break II - Congresshall Foyer 1520-1700 Afternoon Session II Room 300 APP ogpx Open Grid Protocol BOF Congresshall A INT mext Mobility EXTensions for IPv6 WG Cabaret OPS dime Diameter Maintenance and Extensions WG Room 307 OPS v6ops IPv6 Operations WG Large Stage RAI p2psip Peer-to-Peer Session Initiation Protocol WG Congresshall B RTG forces Forwarding and Control Element Separation WG Congresshall C RTG roll Routing Over Low power and Lossy networks WG Small Stage TSV rmt Reliable Multicast Transport WG 1710-1810 Afternoon Session III Room 300 APP vcarddav vCard and CardDAV WG Congresshall A INT mext Mobility EXTensions for IPv6 WG Congresshall B INT multimob Multicast Mobility BOF Cabaret OPS dime Diameter Maintenance and Extensions WG Room 307 OPS v6ops IPv6 Operations WG Large Stage RAI p2psip Peer-to-Peer Session Initiation Protocol WG Congresshall C RTG roll Routing Over Low power and Lossy networks WG ps: There will not be any break in between the two consecutive slots. Cheers! JP. --Apple-Mail-7-211187509 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable It is now finalized (since = yesterday): 

= = = Room = 300= = =
= Congresshall Foyer
Room = 300APPogpxOpen Grid Protocol BOF
Cong= resshall AINTmextCabaret= OPSdimeRoom = 307OPSv6opsLarge = StageRAIp2psip<= /td>Peer-to-Peer Session Initiation Protocol = WG
Cong= resshall BRTGforces<= /td>Forwarding and Control Element Separation = WG
Cong= resshall CRTGrollRouting = Over Low power and Lossy networks WG
Small = StageTSVrmtAPPvcarddav<= /a>vCard and CardDAV WG
Cong= resshall AINTmextCong= resshall BINTmultimobMultic= ast Mobility BOF
Cabaret= OPSdimeRoom = 307OPSv6opsLarge = StageRAIp2psip<= /td>Peer-to-Peer Session Initiation Protocol = WG
Cong= resshall CRTGrollRouting = Over Low power and Lossy networks WG
In-Reply-To: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt Thread-Index: Acn+ZiijVNXKI07zSN6zTQOsSC7cHwAhHbmA References: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , X-OriginalArrivalTime: 07 Jul 2009 10:08:48.0845 (UTC) FILETIME=[EBC9E7D0:01C9FEEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1778; t=1246961329; x=1247825329; 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[Roll]=20collision=20avoidance=20in=20d raft-dt-roll-rpl-00.txt |Sender:=20; bh=aGNc99yLvmwzuWWSUih8/x7HSGgx/NzJ7sMUTiAj8Y4=; b=UoV2rDbZvtligzAHsJukRYQl2xShlOFquTAskSrnC1PB1YmwF05y3Gtb2F hzIietJQ2rG4rnWST5d9F2Ahw43OUa2+QH9AxP5wWJaeVEL55h7IAnXNMLJI 6d/sVxu1qw; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:09:45 -0000 Hi Richard: This is not for siblings but for inter DAG jumps. This is a very old thing, the first snag you hit when you simulate but mostly never happens in real life. You need A and B boot synchronously and send their RAs at the very same time so they cross. In that case, they might attach to one another and form a sticky loop. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: lundi 6 juillet 2009 20:15 >To: roll@ietf.org >Subject: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt > >I do not understand the need for the collision avoidance >mechanism. The draft says: > > 5.4.3.3. Collision > > A race condition occurs if 2 nodes send Router Advertisement - DAG > Information Option at the same time and wish to join each other. > This might happen between nodes at a same depth, or nodes which act > as DAG root of their own DAGs. [...] > >Section 5.2 states that candidate neighbors at the same >depth cannot be considered as candidate parents. If two >nodes at the same depth transmit DIOs at the same time there >are no new candidate parents and however much they may wish >to join each other, such moves are prohibited. Joining to >another node at the same level requires leaving the DAG, >waiting for the DAG sequence number to change, and then >rejoining. Two devices cannot collide while doing this >because they cannot advertise the new sequence number >without first rejoining to someone that already has it. > >Am I missing something? > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Jul 7 03:13:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212613A6992 for ; Tue, 7 Jul 2009 03:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 mRd2A6zmeHuo for ; Tue, 7 Jul 2009 03:13:23 -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 893703A696F for ; Tue, 7 Jul 2009 03:13:23 -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 n679GxIa030943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jul 2009 11:17:00 +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 n679JJq6019081; Tue, 7 Jul 2009 11:19: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 n679JHoO009745; Tue, 7 Jul 2009 11:19:19 +0200 Message-ID: <4A531314.1080307@gmail.com> Date: Tue, 07 Jul 2009 11:19:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Philip Levis References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:13:25 -0000 Philip Levis a crit : > > On Jul 3, 2009, at 1:57 AM, Alexandru Petrescu wrote: > >>> Richard, This seems like a totally reasonable metric to use, but >>> I'd be wary of saying it's *the* metric to use. Some >>> implementations are going to want to consider hopcount, others >>> won't. It's just another metric. Rather than hardwire hopcount >>> based assumptions into the protocol design, we should put it on >>> equal footing as other metrics. Correspondingly, the protocol >>> should have general, metric-independent mechanisms for detecting >>> and avoiding loops. >> >> Phil, what does 'loop' mean when metrics other than hopcount are >> used? What does a loop look like when e.g. ETX is used as metric? > > If there's a loop in an ETX graph, then ETX does not monotonically > decrease along the route. This goes back to Jonathan's comment on > metric vectors. I personally haven't yet grasped the notion of a loop in terms of ETX (Expected Transmission count metric [De Couto 2003]). I do understand a loop in terms of the hop count metric. By your definition above it may seem that an ETX-loop appears when the ETX increases arbitrarily along a path. From this I think there may be loop-free paths (in terms of hopcount) which are ETX-loops. Alex Alex From pthubert@cisco.com Tue Jul 7 05:21:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5CE3A67CC for ; Tue, 7 Jul 2009 05:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.004 X-Spam-Level: X-Spam-Status: No, score=-8.004 tagged_above=-999 required=5 tests=[AWL=-1.405, 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 PLfDgIt4rqXb for ; Tue, 7 Jul 2009 05:21: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 980703A6B02 for ; Tue, 7 Jul 2009 05:21:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,362,1243814400"; d="scan'208";a="339050740" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2009 12:21: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 n67CLTqj030176; Tue, 7 Jul 2009 14:21:29 +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.14.3) with ESMTP id n67CLSu1021760; Tue, 7 Jul 2009 12:21:29 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 14:21: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: Tue, 7 Jul 2009 14:21:23 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07C04072@xmb-ams-337.emea.cisco.com> In-Reply-To: <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn+i3m4uP7nA4TETx2EG3rKULn0/AAcZk6w References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Jonathan Hui" X-OriginalArrivalTime: 07 Jul 2009 12:21:28.0955 (UTC) FILETIME=[74624CB0:01C9FEFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4427; t=1246969289; x=1247833289; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=yMIjRzyOviQUbv9nyyLV97gIXjRAMhW9a7YczQoudJk=; b=Ih6Sefzz1enT19fiBC3BDJVOyshOdJUV9FcMEH4Yh2+cMBraQ5NpXM6NLh bYK+qYEPQapCEatgpKQPPuyef+PcJXJ40OKSYrblwSGXiO3t2fcadB1p9Yc6 jsb6qZ6Fne; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:21:51 -0000 Hi Richard: I do not follow your inward sibling idea. Being sibling is a symmetrical relationship.=20 I am your siblings <=3D> you are my sibling. Inward is not like that so it's not siblings. What you could do instead is mask off the least significant M bits. Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: mardi 7 juillet 2009 00:46 >To: Jonathan Hui >Cc: Pascal Thubert (pthubert); roll@ietf.org >Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? > >Hi Jonathan, > > From: Jonathan Hui > Date: Mon, 6 Jul 2009 12:51:49 -0700 > > On Jul 6, 2009, at 10:31 AM, Richard Kelsey wrote: > > > From that standpoint, I fail to see that k>1 yields a huge benefit > > for the cost of the extra complexity. > > > > It's a side issue and not particularly important, so > > we needn't go into it. We can leave that siblings > > are nodes with the same cost to the root. > > If I understand properly, the fundamental difference in philosophy > between Pascal's approach and yours is the orthogonal reasons behind > coarse vs. fine in the route cost precision. Pascal wants to encourage > a undirected sibling edges using lower precision. You want to allow > greater information in the route cost by making it have greater > precision. Both are fruitful, but are unfortunately at odds. > >With hop count neighbors are either: > parents (lower hop count) > siblings (same hop count) > ignored (higher hp count) > >With a more precise metric, where the optimal link has cost k, >neighbors can be divided into four categories: > parents (cost less by k or more) > inward siblings (cost less by k-1 or less) > siblings (same cost) > ignored (higher cost) > >In either case, forwarding via siblings or 'ignored' can >send a message around a loop. Forwarding via parents or >inward siblings cannot. > >Using a more precise metric produces fewer siblings, with >the remainder being either 'ignored' or inward siblings. >category. The net effect is to increase the number of >neighbors that can be used to forward messages without >creating into a loop, while decreasing the number that might >create a loop. > >I don't have any idea which is likely to work better in >practice. > > Making k>1 means that a packet can actually make > backwards progress, so I'm not sure that's exactly what > we want. I personally favor your original approach with k > =3D 1. It does move us closer to a true DAG, but I think > robustness will still be good in networks that aren't > dangerously sparse. > >I am not sure what 'k' means here. > > Now that we've gone down a path where ETX can be embedded > in the loop detection information, one open question I'm > still grappling with is why define a route cost for loop > detection separate from the actual routing metrics used? > >One advantage of having multiple metrics is that it >indicates the actual properties of the route. It >might make a difference whether it was a low-latency >or low-energy route. This works well only if there >are not multiple parents (a tree, not a DAG), so >that picking a parent also picks a path. > >I suppose that a root could create two separate DAGs >with different metrics. For time-critical messages >you use the low latency DAG, for ordinary messages you >use the low energy one, even though they go to the >same root. Keeping track of two DAGs would be costly. > > In most cases, I would expect a single route cost metric > will be used. In cases when multiple metrics are used, > they will often be combined into a single number using > some polynomial. Are there cases where multiple metrics > are used without any combination? If so, why not simply > designate one of those metrics to be used for loop > detection? > >If you do that, the loop detection metric will trump >the other ones in some cases. > > Isn't the real issue here that the loop detection metrics were > disjoint from the desired routing metrics? > >Yes. A related issue is that for lossy links I think any >metric works better if the second best link cost is not >twice the best. With hop count you have no choice. > > -Richard Kelsey From pthubert@cisco.com Tue Jul 7 05:22:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15053A6A2E for ; Tue, 7 Jul 2009 05:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.966 X-Spam-Level: X-Spam-Status: No, score=-9.966 tagged_above=-999 required=5 tests=[AWL=0.633, 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 2W+bnFjpdcwl for ; Tue, 7 Jul 2009 05:22:22 -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 24F933A67CC for ; Tue, 7 Jul 2009 05:22:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,362,1243814400"; d="scan'208";a="44551714" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2009 12:21:28 +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 n67CLSRX020936; Tue, 7 Jul 2009 14:21:28 +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.14.3) with ESMTP id n67CLSdl021755; Tue, 7 Jul 2009 12:21:28 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jul 2009 14:21:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: DFpT E3qe GzwX HfG8 NNpo NYgd OHkA TDhD VgwC WDR1 XV78 cc3N eDxx gjLN gk7d gxyO; 3; agBoAHUAaQBAAGEAcgBjAGgAcgBvAGMAawAuAGMAbwBtADsAcgBpAGMAaABhAHIAZAAuAGsAZQBsAHMAZQB5AEAAZQBtAGIAZQByAC4AYwBvAG0AOwByAG8AbABsAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5915CED7-CC7F-40C9-A5D0-D5D621312734}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 07 Jul 2009 12:16:14 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAFIAUABMADoAIAB3AGgAeQAgAG4AbwB0ACAAYgBhAHMAZQAgAGEAIABEAEEARwAgAG8AbgAgAHQAaABlACAAbQBpAG4AIABoAG8AcAAgAGQAaQBzAHQAYQBuAGMAZQAgAGYAcgBvAG0AIAB0AGgAZQByAG8AbwB0AD8A x-cr-puzzleid: {5915CED7-CC7F-40C9-A5D0-D5D621312734} Content-class: urn:content-classes:message Date: Tue, 7 Jul 2009 14:21:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07C04071@xmb-ams-337.emea.cisco.com> In-Reply-To: <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL: why not base a DAG on the min hop distance from theroot? Thread-Index: Acn+jlthi8nabfHnSISmh7PFP+l1mQAYNphg References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 07 Jul 2009 12:21:28.0298 (UTC) FILETIME=[73FE0CA0:01C9FEFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4963; t=1246969288; x=1247833288; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=emxAb8TGiKytZWI13AfIl3z+H/H5RYEI0pKz31iR6yY=; b=r7PdyIaLDzeiOKuDhHUw/TiUsJDnDY6K0IIuqIoY/Rd6mnszQQs9X6ZkAQ Wd0tIbGtX4wHeBWWCEq4z90lntrwc3swNfbkrBGDLmiWURyWUTsB1oxGotvg yII1iTV0cE; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:22:23 -0000 > >On Jul 6, 2009, at 3:45 PM, Richard Kelsey wrote: >> Using a more precise metric produces fewer siblings, with >> the remainder being either 'ignored' or inward siblings. >> category. The net effect is to increase the number of >> neighbors that can be used to forward messages without >> creating into a loop, while decreasing the number that might >> create a loop. >> >> I don't have any idea which is likely to work better in >> practice. > >In the end we are saying the same things just in different words. A >less precise route cost produces more siblings and leaves more edges >undirected. A more precise route cost makes more edges directed. The >one that works better in practice depends on the density and number of >feasible successors. In other words, if there are many edges to choose >from - why not orient them and avoid loops altogether? In a sparse >network, you might want to leave them undirected to give greater >opportunity of routing around failures. I'd say that in dense networks the routers should have enough parents to choose from so they would never need the siblings or even keep track of them by lack of resources. So the coarse metric seems to obtain the desired result in both cases, use parents when there are enough of them, enable siblings in sparse conditions.=20 We can carry many metrics and their aggregation over a path will be the factor to select a parent. Then again depth is there for loop avoidance and stability, not for parent selection.=20 Form this thread I gather that: - Improving the definition of the metric (that is providing decimals) improves only the likelihood that alternate parents provide similar services, and that will be true only if with homogeneous devices.=20 - allowing a hop to cost several times more than another hop can also help abstract a bad but still usable link. I understand from this discussion that there's value in allowing something like that and I tend to agree if we keep it tightly constrained. How much could be link type or deployment dependent so we need sensible defaults (per link type?) for instance enable a reasonable range to cover ETX in radios. We also need to be consistent along a DAG to make any sense so we need a representation to be able to advertize that in DIO. So why not enable to split the depth increment in 3 zones. The size of a zone is expressed in bits. - The least significant bits would be "decimals" of a normalized hop (d-field of D bits) - The middle bits would de usable to represent that the number of normalized hop (n-field of N bits) - The most significant bits represents how many hops across we can do before the depth can reach infinity. (h-field of H bits 0 X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDEE3A6856 for ; Tue, 7 Jul 2009 05:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.983 X-Spam-Level: X-Spam-Status: No, score=-7.983 tagged_above=-999 required=5 tests=[AWL=-1.384, 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 eMdzCg-d4P41 for ; Tue, 7 Jul 2009 05:29:26 -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 4CDE93A67CC for ; Tue, 7 Jul 2009 05:29:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,362,1243814400"; d="scan'208";a="210403618" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2009 12:27:15 +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 n67CRFu7032051; Tue, 7 Jul 2009 14:27:15 +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.14.3) with ESMTP id n67CRFMu023788; Tue, 7 Jul 2009 12:27:15 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, 7 Jul 2009 14:27:15 +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: Tue, 7 Jul 2009 14:27:09 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07C0407C@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A5281F0.5050306@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt Thread-Index: Acn+jigAliN4nS5GRgKHWbZ06eh0UwAb+WuQ References: <87iqi5wuda.fsf@kelsey-ws.hq.ember.com> <4A5281F0.5050306@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" , "Richard Kelsey" X-OriginalArrivalTime: 07 Jul 2009 12:27:15.0194 (UTC) FILETIME=[42C22DA0:01C9FEFE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2009; t=1246969635; x=1247833635; 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[Roll]=20collision=20avoidance=20in=20d raft-dt-roll-rpl-00.txt |Sender:=20; bh=6mFz6ZQD3n4Z4ewirXR12R7x/0numw/veN1IKPCfxWM=; b=tcs6OwSF8QDFgZQIHW9jgTUy2lhNqv5UDfDCA4SZaEc3tID/CPpLCyGyt8 Itpb15QNnS2n1r9QGS1eBABJxpExiH4rJ6ZatTiZkDNtu4eijOpNLX9g+3BR wi4kRTfh7M; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:29:27 -0000 I had read that too quickly. Sure, you're both correct, thanks Richard :) Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter >Sent: mardi 7 juillet 2009 01:00 >To: Richard Kelsey >Cc: ROLL WG >Subject: Re: [Roll] collision avoidance in draft-dt-roll-rpl-00.txt > >Richard, > >Good catch, it does seem we ought to remove the "at a same depth" case. > >In the other case, two nodes rooting their own floating DAGs might still >have a collision if they at the same time decide to join each other's DAG. > >Thanks, > >-Tim > >Richard Kelsey wrote: >> I do not understand the need for the collision avoidance >> mechanism. The draft says: >> >> 5.4.3.3. Collision >> >> A race condition occurs if 2 nodes send Router Advertisement - DAG >> Information Option at the same time and wish to join each other. >> This might happen between nodes at a same depth, or nodes which act >> as DAG root of their own DAGs. [...] >> >> Section 5.2 states that candidate neighbors at the same >> depth cannot be considered as candidate parents. If two >> nodes at the same depth transmit DIOs at the same time there >> are no new candidate parents and however much they may wish >> to join each other, such moves are prohibited. Joining to >> another node at the same level requires leaving the DAG, >> waiting for the DAG sequence number to change, and then >> rejoining. Two devices cannot collide while doing this >> because they cannot advertise the new sequence number >> without first rejoining to someone that already has it. >> >> Am I missing something? >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Tue Jul 7 06:24:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EEEC3A6E6E for ; Tue, 7 Jul 2009 06:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OndG5iU53XoN for ; Tue, 7 Jul 2009 06:24:12 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DB4703A67CC for ; Tue, 7 Jul 2009 06:23:44 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 09:12:04 -0400 Date: Tue, 07 Jul 2009 09:12:35 -0400 Message-Id: <87eisswsak.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> (message from Jonathan Hui on Mon, 6 Jul 2009 16:06:04 -0700) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> X-OriginalArrivalTime: 07 Jul 2009 13:12:04.0818 (UTC) FILETIME=[85E63B20:01C9FF04] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:24:13 -0000 Hi Jonathan, From: Jonathan Hui Date: Mon, 6 Jul 2009 16:06:04 -0700 In the end we are saying the same things just in different words. A less precise route cost produces more siblings and leaves more edges undirected. A more precise route cost makes more edges directed. The one that works better in practice depends on the density and number of feasible successors. In other words, if there are many edges to choose from - why not orient them and avoid loops altogether? In a sparse network, you might want to leave them undirected to give greater opportunity of routing around failures. With more precision in route cost you can increase the number of undirected links by partioning costs into horizontal bands. Pick a constant h and define siblings to be nodes that have the same value for floor(cost / h) If h is the same as the optimal link cost you get siblings that are analogous to those produced by hop count. In theory you could make h greater than the optimal link cost, but that could get complicated, depending on the mechanism used to avoid loops when routing through siblings. If we have a reliable way to prevent looping when routing through siblings, then I would propose that we use h equal to the optimal link cost. This would gives us close to what we have now in terms of siblings. This is what you meant by having k=1, correct? If we cannot prevent looping when routing through siblings, it would be better to only allow forwarding via nodes with lower cost (parents and 'inward siblings'). -Richard Kelsey From quentin.lampin@orange-ftgroup.com Tue Jul 7 06:41:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384203A6A8A for ; Tue, 7 Jul 2009 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[AWL=1.890, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+0ef6nxUSgd for ; Tue, 7 Jul 2009 06:41:55 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C4F963A689B for ; Tue, 7 Jul 2009 06:41:54 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:41:43 +0200 Received: from [10.194.4.252] ([10.194.4.252]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:41:43 +0200 Message-ID: <4A535093.1050807@orange-ftgroup.com> Date: Tue, 07 Jul 2009 15:41:39 +0200 From: quentin.lampin@orange-ftgroup.com User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4A4E32E3.90804@orange-ftgroup.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 13:41:43.0704 (UTC) FILETIME=[AA32B180:01C9FF08] Cc: roll@ietf.org Subject: Re: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:41:56 -0000

Pascal Thubert (pthubert) wrote:

Salut Quentin:

Salut Pascal,

 

If DAGs expose different prefixes then the longest match rule applies all the way to follow the graph that advertise that longest match prefix. You can use that to implement a power utility gateway that would get specific traffic but not default.

ok.

 

If DAGs expose a same prefix (default) then packets must be tagged (colored) to indicate which one of the topologies they are supposed to follow, otherwise loops will occur (your point I guess).

If I understand well, in the case of multiple DAGs advertising the same prefix, packet originators have to specify which DAG the packets must follow. I also understand that the intention is to tailor DAGs to address specific constraints/metrics so that it makes little sense, in general, to forward packets accross DAGs. But I can see cases where this would be useful. For example, when a node in a frozen sub-DAG receives a packet tagged with this DAGID. If  it's allowed, it could decide, according to the advertised traffic class, to forward the packet to another DAG such that the packet is not dropped. We could think of a per prefix "default" (kind of emergency) DAG.
A simple way to ensure loops avoidance would be to forbid nodes to forward packets tagged "default" outside of the default DAG.
Another (more generic and thus more powerful) way would be to add a Hop by Hop option to the packet specifying visited DAGs and depths of nodes  which made the cross DAGs forward moves. Ensuring that a node cannot be re-forwarded to a node in a visited DAG at a depth higher (deeper) or equal to the depth corresponding to the visited DAG should be sufficient to avoid most probable loops.
Moreover, the last option would allow us to handle complex packet constraints such as { Tdeliver < Tref (weight w1), Nhop < Nref (weigth w2)}. A node receiving such a packet could evaluate if the major constraint (higher weight) is likely to be respected and, in this case, forward the packet accross another DAG to address the other constraints.
This would permit to build "multi-dimensional" QoS based forwarding engines.

 

Finally, it is always possible to leave a topology to a strictly lower one, if you have structured your set of topologies as a tree. Like a default spanning topology would be the lowest (root) topology, and constrained control topologies would be the highest (leaves).

This is the start point of the last proposition ;)

 

Will you be in Stockholm?

Unfortunately not, but Dominique Barthel will be there. You can discuss about this with him.

 

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of quentin.lampin@orange-ftgroup.com
Sent: vendredi 3 juillet 2009 18:34
To: roll@ietf.org
Subject: [Roll] [RPL]About Nodes subscribing to multiple DAGs

 

Hi everyone,

RPL specifies that a node can subscribe to more than one DAG.
Is it the intention to allow nodes to forward packets received from one DAG to another one?
If so, is there any mechanism that we could think of to prevent cross-DAGS loops?
If a packet arrives at a node which knows that the root is no longer reachable, forwarding accross DAGs might be useful...


Thanks for your comments,

Quentin Lampin

 


Quentin
From richard.kelsey@ember.com Tue Jul 7 07:18:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D50028C4AB for ; Tue, 7 Jul 2009 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 eUwmVEtcfwvw for ; Tue, 7 Jul 2009 07:18:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A35E528C13F for ; Tue, 7 Jul 2009 07:18:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:18:10 -0400 Date: Tue, 07 Jul 2009 10:18:41 -0400 Message-Id: <878wj0wp8e.fsf@kelsey-ws.hq.ember.com> To: Tim Winter In-reply-to: <4A527EAA.4060603@acm.org> (message from Tim Winter on Mon, 06 Jul 2009 18:46:02 -0400) From: Richard Kelsey References: <4A527EAA.4060603@acm.org> X-OriginalArrivalTime: 07 Jul 2009 14:18:10.0834 (UTC) FILETIME=[C1D43F20:01C9FF0D] Cc: roll@ietf.org Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:18:09 -0000 Hi Tim, > Date: Mon, 06 Jul 2009 18:46:02 -0400 > From: Tim Winter > > Richard Kelsey wrote: > > > > Given the dubious benefits of having different nodes > > optimize different metrics, and the bad interaction with > > having multiple parents, I really don't understand the > > emphasis on this feature. > > > It is perhaps mostly a question of interoperability. Should such a > scenario come to pass, what should the LLN do? Can we expect that > all nodes in the LLN will be having the same software, the same > understanding of metrics and constraints and optimization goals, > etc. When we look at a typical LLN deployment today, maybe this is > true more often than not. But as we open up the possibility for LLN > nodes to truly interoperate with standards-based IPv6, what then? > RPL in its present form is trying to establish some base guidelines > as to how such a heterogeneous LLN might organize itself, while > leaving some freedoms for the implementors... In the interests of promoting interoperability, I think that we could give implemetors and anyone designing a metric a bit more help in interoperating with other, possibly unknown, metrics. Having a DAGcost metric that is additive with a minimum link cost greater than one gives interoperation a big step up. Different devices in a mixed network will still be optimizing different metrics, but at least paths will be chosen with some attempt at overall optimization. This is epecially useful with metrics that are interdependent. The same links are likely to have a low ETX, low latency, and high reliabilty, for example. As it stands now, a device which has several potential parents at the same depth but who do not advertise a known metric has only the last hop metric for making a choice. -Richard Kelsey From richard.kelsey@ember.com Tue Jul 7 08:44:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC6528C4CC for ; Tue, 7 Jul 2009 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 aRoGcmoFfjKG for ; Tue, 7 Jul 2009 08:44:51 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1B59628C4C0 for ; Tue, 7 Jul 2009 08:44:51 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 11:44:47 -0400 Date: Tue, 07 Jul 2009 11:45:17 -0400 Message-Id: <8763e4wl82.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07C04072@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07C04072@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 07 Jul 2009 15:44:47.0006 (UTC) FILETIME=[DAFD2BE0:01C9FF19] Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 15:44:52 -0000 Hi Pascal, > Date: Tue, 7 Jul 2009 14:21:23 +0200 > From: "Pascal Thubert (pthubert)" > > I do not follow your inward sibling idea. Being sibling is a symmetrical > relationship. > I am your siblings <=> you are my sibling. Inward is not like that so > it's not siblings. > What you could do instead is mask off the least significant M bits. You are correct that inward siblings and outward siblings are not siblings. 'Siblings', 'inward siblings, and 'outward siblings' are three disjoint sets of neighbors. For node N, its 'inward siblings' are nodes that whose cost is less than N's but not enough less that N can use them as parents. N's 'outward siblings' are neighbors whose costs are greater than N's, but not enough greater that they can be children of N. And yes, you could do instead is mask off the least significant M bits, or, more generally, divide by some constant. Which method is better depends on the circumstants, including whether or not routing to siblings may create a loop. -Richard Kelsey P.S. Strictly speaking, only nodes with the same parent are siblings. Nodes at the same depth in a DAG are usually called a 'level', I think, but that doesn't work as well grammatically. 'Cousins' might be a better term for us than 'siblings'. From jhui@archrock.com Tue Jul 7 09:44:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CAE28C2F9 for ; Tue, 7 Jul 2009 09:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnJf-i4hBE1H for ; Tue, 7 Jul 2009 09:44:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4F81328C4E5 for ; Tue, 7 Jul 2009 09:44:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8FCF9AF8D3; Tue, 7 Jul 2009 09:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XwBN8E6AOPI; Tue, 7 Jul 2009 09:44:23 -0700 (PDT) Received: from [192.168.7.22] (69-12-164-139.sfo.archrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id BB56EAF8B2; Tue, 7 Jul 2009 09:44:22 -0700 (PDT) Message-Id: <3986B609-FDE0-4756-9F48-DAD29F1BBD26@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87eisswsak.fsf@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 v935.3) Date: Tue, 7 Jul 2009 09:44:21 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <87eisswsak.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:44:18 -0000 Hi Richard, On Jul 7, 2009, at 6:12 AM, Richard Kelsey wrote: > From: Jonathan Hui > Date: Mon, 6 Jul 2009 16:06:04 -0700 > > In the end we are saying the same things just in different words. A > less precise route cost produces more siblings and leaves more edges > undirected. A more precise route cost makes more edges directed. The > one that works better in practice depends on the density and > number of > feasible successors. In other words, if there are many edges to > choose > from - why not orient them and avoid loops altogether? In a sparse > network, you might want to leave them undirected to give greater > opportunity of routing around failures. > > With more precision in route cost you can increase the > number of undirected links by partioning costs into > horizontal bands. Pick a constant h and define siblings to > be nodes that have the same value for > > floor(cost / h) > > If h is the same as the optimal link cost you get siblings > that are analogous to those produced by hop count. In > theory you could make h greater than the optimal link cost, > but that could get complicated, depending on the mechanism > used to avoid loops when routing through siblings. Sure. You can arbitrarily truncate the route cost and make it less precise for use with loop detection. Having hard bounds defining each band is useful to make sure packets never make reverse progress. > If we have a reliable way to prevent looping when routing > through siblings, then I would propose that we use h equal > to the optimal link cost. This would gives us close to what > we have now in terms of siblings. This is what you meant > by having k=1, correct? Yes, that's what I meant. I don't think there's a particular mechanism to *prevent* loops. Pascal's assumptions are that a packet will only continue to loop with some small-ish probability. If a packet does get stuck in a loop, then the hop limit will expire it. Only annoying thing with relying on the hop limit is ICMPv6 time exceeded errors. > If we cannot prevent looping when routing through siblings, > it would be better to only allow forwarding via nodes with > lower cost (parents and 'inward siblings'). I also like that this encourages fewer loops. The special case, however, is when you're near the root. Assuming perfect information, there will be one node that has no alternate parents. -- Jonathan Hui From jhui@archrock.com Tue Jul 7 10:06:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28A23A6955 for ; Tue, 7 Jul 2009 10:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 0kTd37JdeK6c for ; Tue, 7 Jul 2009 10:06:17 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id F2AF428C1A0 for ; Tue, 7 Jul 2009 10:06:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B5593AF91F; Tue, 7 Jul 2009 10:05:54 -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 1U9pugWoyoGT; Tue, 7 Jul 2009 10:05:50 -0700 (PDT) Received: from [192.168.7.22] (69-12-164-139.sfo.archrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 5FF0CAF8B2; Tue, 7 Jul 2009 10:05:49 -0700 (PDT) Message-Id: <66E90D4D-3420-48ED-B2A8-6306B25809E7@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07C04071@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 v935.3) Date: Tue, 7 Jul 2009 10:05:47 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07C04071@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:06:17 -0000 Hi Pascal, On Jul 7, 2009, at 5:21 AM, Pascal Thubert (pthubert) wrote: > So why not enable to split the depth increment in 3 zones. The size > of a > zone is expressed in bits. > > - The least significant bits would be "decimals" of a normalized hop > (d-field of D bits) > - The middle bits would de usable to represent that the number of > normalized hop (n-field of N bits) > - The most significant bits represents how many hops across we can do > before the depth can reach infinity. (h-field of H bits > 0 0 or > 1 of all the other fields have a length of zero. While this is certainly more general and interesting, I think it's going a bit too far :-). We should be able to settle on some fixed- point format - identify the number of fractional and integral bits. I do like the ability to specify the maximum number of hops (i.e. infinity). I'm also good with carrying the hop count as a separate "metric" that won't be used for loop avoidance. I've found that hop information can be useful as management information - more so than an actual route metric. -- Jonathan Hui From jvasseur@cisco.com Tue Jul 7 10:45:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4514C3A6961 for ; Tue, 7 Jul 2009 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Vso4xjiZ2cY9 for ; Tue, 7 Jul 2009 10:45:20 -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 D520228C29E for ; Tue, 7 Jul 2009 10:45:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="339258101" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2009 17:45:35 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n67HjZfo010168; Tue, 7 Jul 2009 10:45:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n67HjZMT025853; Tue, 7 Jul 2009 17:45:35 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:34 -0700 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:33 -0700 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <811770612.58961246849997271.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 14:21:24 +0200 References: <811770612.58961246849997271.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 17:45:33.0802 (UTC) FILETIME=[BA6A7CA0:01C9FF2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10100; t=1246988735; x=1247852735; c=relaxed/simple; s=sjdkim3002; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=wvuY/CbL46ULoaO1TufHYt5L4edLoGp52LV/6v3whKM=; b=kr88YU+bE753+mMxlxETnIpRjHH/zYMFklymNJ1ig95Q7EIOFA5nW9qo+t wXbApFhQgjAnEt+zNEdf0uSTyQdp9jBJvqbHygHWZyc+M7z/Do1076xJkx+R kuiW9Ygy5U; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:45:22 -0000 Hi Mukul, On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote: > Tim > > Thanks for this explanation. I think most of this email should > become part of RPL draft. > > I would like to convey the discomfort that many of us feel because > RPL does not yet support a good P2P routing solution. Tree based P2P > routing is not acceptable in many cases. We need to give this > problem a high priority. > The solution MUST of course support P2P and this is the case of RPL. Now we need to define what we mean by "Good" P2P routing solution. As of today RPL will branch the traffic as soon as the packet reaches a node that has the destination address in its routing table pointing to one of its children or sibling. This path may not be the most optimal path indeed and may even be unacceptable. Furthermore it is constrained by the shape of the DAG, which are dependent upon the metrics used by nodes closer to the root. The question is to determine how optimal should that path, and should we decide to adopt a routing solution a la RPL, do we need to complement it with another mechanism when optimal P2P path are required ? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Tim Winter" > To: "ROLL WG" > Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central > Subject: [Roll] Some clarifications on RPL > > WG, > > Thanks to everyone for their feedback and comments to the RPL draft > so far. > There are some good threads here that will definitely help us to > improve > the RPL design- and there is no doubt more work to be done. I would > like > to make some clarifications that may be useful in discussing some of > the > common concerns so far: > > 1) Why a DAG? > A dominant traffic flow in the requirements drafts is MP2P, > flowing > from the sensors inwards towards a sink, typically an LBR. The design > approach taken was to handle this case, use it to restrict the routing > problem, and then try to build support for P2MP, P2P, and other > cases on > top of it. A tree provides the simplest structure for supporting > the MP2P > flows, but a tree has many single points of failure along the edges > from > children to parents. A DAG, allowing each node to select and maintain > multiple successors in order to forward traffic inwards toward the > root, > offers the advantage of ready-to-use options. An implementation may > then > select from the successors as necessary, possibly in response to a > temporary failure to forward to one parent, or a load balancing > algorithm, > or a short-term fluctuation in a link metric that leads the forwarding > engine to prefer one next hop over the other. > > 2) What about other flows? > The DAG, and the orientation of the edges in the DAG, is used > in > routing the MP2P traffic towards the DAG root. The structure of the > DAG is > then used to restrict the complexity of the P2MP routing problem on > the > nodes. The Destination Advertisement mechanism lets a node set up > routes > in support of outward traffic flows, from the DAG root towards the > leaf > nodes in the LLN. The Destination Advertisement mechanism distributes > routing state inwards along the DAG, allowing nodes to learn routing > state > in support of the sub-DAGs below them. Nodes who are unable to learn > routing state pass the Destination Advertisements inward, building up > source routing information along the way so that they may be traversed > again on the outward flow. The exact implementation of source > routing in > support of this mechanism is not something that has been addressed > by RPL > as yet. > > Further, arbitrary P2P traffic can be supported by the DAG as > is by > sending traffic inwards along the DAG until a parent is encountered, > who > has stored routing state and is common to the source and destination > of the > traffic, who is able to direct the traffic towards the destination. > > RPL does not discuss any mechanisms to install more optimal P2P > routes, but nor does it preclude them, once the fundamentals have been > addressed we can have a look at such mechanism to more efficiently > route > `across' the DAG. > > 3) Metrics > RPL allows for each node to select its set of DAG parents > according > to its own set of constraints, utilizing whatever subset of metrics it > requires to do so. The exact considerations and weighting can be > implementation specific. > > A key design point, one that may need to be further > constrained, is > that under RPL each node does not assume that other nodes are acting > cooperatively, or even that they are using or understand the same > set of > metrics. One node could be optimizing for latency, another node > could be > optimizing for ETX, and a third could be optimizing for > minimum energy. This design point informs some of the loop avoidance > rules, such as the use of depth as a `common language'. > > Once a node as selected its DAG parents, according to whatever > metrics and constraints it chooses, then it has effectively taken up a > position in the DAG. It now has a best-case path to the DAG root, > through > its best parent, and a worst-case path to the DAG root, through its > worst > parent. Now, as a *consequence* of selecting parents according to its > metrics, the node has taken on a depth within the DAG. > > 4) Loop avoidance > The DAG, and the nodes position within the DAG, are used in > support > of some loop avoidance rules. > > RPL always allows a node to move inwards along the DAG, > towards the > root. Moving inwards along the DAG has little chance of creating a > loop; > the node has only improved its position. Such a move would be based > on > receiving and processing DIOs with superior metrics from a node of a > lesser > depth in the DAG. > > RPL does not allow a node to move outwards along the DAG, > increasing its depth. Such a move is possible, but would require > the node > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > attach at > the lower point. RPL would not allow this movement unless the DAG > parents > of the node have failed, requiring the node to detach and re-attach > to the > DAG. > > In general, RPL is taking a conservative approach. For a > node N, > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > node N. Suppose that node N thought it could improve its metrics > through > node M. By detaching first, and waiting to observe node M to see > that node > M remains attached to the DAG, node N may then determine that node M > is not > part of its own sub-DAG and may safely re-attach at the lower point. > BUT if > node N is wrong, then an instability has been created for no gain. > For this reason, in its current specification, RPL does not allow a > node N > to process and DIO from node M and detach from the DAG based on > information > in the DIO from node M. NOTE that this is in part a consequence of > the > design consideration that not all nodes may be using the same > metrics and > making the same optimizations. For example, if all nodes in the > network > were minimizing ETX, then node N may be mostly certain that any node > M advertising a superior ETX is NOT in its own sub-DAG. > > A further complication may come if node N and node M are > trying to > make optimizations which are antagonistic to each other. For > example, if > node N where to try to move under node M, it could create a chain of > events > whereby node M tried to reverse its position with respect to node M, > and a > chain reaction of instability could result. A simple example of > such a > case would be where both nodes M and N have a common neighbor and > parent P, > and nodes M and N subsequently each try to increase the size of their > parent set to be 2. (This case has been more thoroughly explained by > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > sent 30 > June 2009.) > > RPL has nodes advertise a depth deeper than that of their > deepest > DAG parent. Consider an example where node X has parents of depth > {2, 7}, > and node Y chooses X as a parent. Suppose that nodes then advertise > their > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > advertise a depth of 4. Then suppose node Z adds node Y as a > parent, and > advertises a depth of 5. Now, Z can actually come to be a successor > of > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > parent)->(...)->Z and then there is a loop. By advertising a depth > deeper > that of its deepest parent, a node advertises its worst case > scenario, and > in the worst case scenario a loop can be avoided. > > RPL does not require that the DAG is invariant, rather that the > movement of the node with respect to the DAG is coordinated in such > a way > so as to avoid loops. The thought is, whatever the topology, > uncoordinated > movement in LLNs may increase overhead and churn and require more > reliance > on expensive mechanisms such as count-to-infinity. > > The use of depth (~ hop count) in RPL is not meant to trump > other > metrics, but once a node has taken up a position in the DAG by using > its > metrics the node acquires a depth, which then restricts the further > options > that the node has in order to avoid loops. > > > > Regards, > > -Tim > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jul 7 10:45:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6461028C4E9 for ; Tue, 7 Jul 2009 10:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 8P-S2sIenW+n for ; Tue, 7 Jul 2009 10:45:29 -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 9921E28C4DC for ; Tue, 7 Jul 2009 10:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="210582052" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2009 17:45:42 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67Hjg5q021910; Tue, 7 Jul 2009 10:45:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n67HjgZS013908; Tue, 7 Jul 2009 17:45:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:42 -0700 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:41 -0700 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87r5wuvwzf.fsf@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 v935.3) Date: Tue, 7 Jul 2009 14:29:11 +0200 References: <87eisxyds9.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCA@xmb-ams-337.emea.cisco.com> <87ocryepw2.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93F0C@xmb-ams-337.emea.cisco.com> <87r5wuvwzf.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 17:45:42.0068 (UTC) FILETIME=[BF57C740:01C9FF2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2259; t=1246988742; x=1247852742; c=relaxed/simple; s=sjdkim1004; 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[Roll]=20ROLL=20and=20new=20technology |Sender:=20; bh=qpcpMgAG7MGg9mx4AMXhd9WR/pE6B7PjLIh5JZF8Bco=; b=gNoT7fC/A9DEQrvpLYPY550mJxlZhmaKSRdssTFz8GJNMNY0BEjgWNfDwT vgno5fDL6MR9Dq6Q32Gf4+I3j1Osfd+ezuURfeUkREVWljSX6mHYOxYjhVJl j+V+A+AmoLQ2eWK7plyAhK5xnX96owgQw2UMWDQP5x/R8n7ZNTwI0=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL and new technology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:45:30 -0000 Hi Richard, On Jul 6, 2009, at 2:04 PM, Richard Kelsey wrote: > Hi Pascal, > > Date: Mon, 6 Jul 2009 10:23:36 +0200 > From: "Pascal Thubert (pthubert)" > >> I cannot argue on the specific implementation that you know best. > > This is not about implementation. [...] > > You wrote that line, not I. > > My point here is that we are going L3. We need to learn > from both sides, IETF and WSN engineering, and make sense > to the cross-breeding. You can't just reject the > experience form the other side because you're not > familiar with it. > You are perfectly when saying that both communities may benefit from the experience of each other. It has been a challenge since day 1 *but* we are all making excellent progress with a community that now "almost" speak the same language and thanks to all of you for the time and energy to make it a success. > Many of the things in RPL have been tried before in the WSN > community. I am unhappy with them precisely because they > are familiar. I know the problems that are going to arise > because I have already seen them happen. > > I am not rejecting the ideas in RPL. I have been pointing > out flaws that need to be fixed and arguing that given the > tight schedule we need to stick to what is already in use > rather than inventing something new. Flaws must be resolved, I fully agree and I also have some concerns (like the DT) about some of existing mechanisms. The lack of determinism worries me, and we cannot rely on a solution that does not allow to re-attach to a deeper node that offers a better path. Let's collectively work on those issues. I asked the DT to provide more explanation how the design choices thanks to concrete examples. Let's use them to work this out. Then the best thing to do is I think to work on these issues one by one. One last note, we cannot because of the timing reject new ideas (still we need to be cautious !), since we first need a solution that works. Thanks. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jul 7 10:45:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A7A28C4C0 for ; Tue, 7 Jul 2009 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLvvXWCqniV2 for ; Tue, 7 Jul 2009 10:45:39 -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 32EEF28C4AC for ; Tue, 7 Jul 2009 10:45:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208,217";a="175148742" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2009 17:45:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67HjoIh008300; Tue, 7 Jul 2009 10:45:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67HjoAp022373; Tue, 7 Jul 2009 17:45:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:50 -0700 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:45:49 -0700 Message-Id: <45DCD6D7-7175-4A05-A27F-11177197111F@cisco.com> From: JP Vasseur To: Tim Winter In-Reply-To: <4A512E97.1030000@acm.org> Content-Type: multipart/alternative; boundary=Apple-Mail-24-229957827 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 15:16:53 +0200 References: <4A512E97.1030000@acm.org> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 17:45:49.0349 (UTC) FILETIME=[C3AEC550:01C9FF2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23707; t=1246988750; x=1247852750; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=CRuImoGeBwzga9nrQmJ5fqV7pLtN5pre6sYqn3jhPFY=; b=Pm9XzcOttre+Pnp7bAYim1nwVTbuBt4yVXggyjpLFvTP1HtuNg0M4uOLfB BRacdNfqXQMGR7zZr+vjEWBrsTQJCe1a7ddWMHZvxXuCzZIz3v2aj1jW9Ww9 XHZughwwsn; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:45:41 -0000 --Apple-Mail-24-229957827 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Tim, Thanks for taking the timing to write this text, On Jul 6, 2009, at 12:52 AM, Tim Winter wrote: > WG, > > Thanks to everyone for their feedback and comments to the RPL draft > so far. > There are some good threads here that will definitely help us to > improve > the RPL design- and there is no doubt more work to be done. I would > like > to make some clarifications that may be useful in discussing some of > the > common concerns so far: > > 1) Why a DAG? > A dominant traffic flow in the requirements drafts is MP2P, > flowing > from the sensors inwards towards a sink, typically an LBR. The design > approach taken was to handle this case, use it to restrict the routing > problem, and then try to build support for P2MP, P2P, and other > cases on > top of it. A tree provides the simplest structure for supporting > the MP2P > flows, but a tree has many single points of failure along the edges > from > children to parents. A DAG, allowing each node to select and maintain > multiple successors in order to forward traffic inwards toward the > root, > offers the advantage of ready-to-use options. An implementation may > then > select from the successors as necessary, possibly in response to a > temporary failure to forward to one parent, or a load balancing > algorithm, > or a short-term fluctuation in a link metric that leads the forwarding > engine to prefer one next hop over the other. Note also that one may decide to make use of more than one DAG for the same destination, when DAGs may be used using different metrics or constraints. > > 2) What about other flows? > The DAG, and the orientation of the edges in the DAG, is used > in > routing the MP2P traffic towards the DAG root. The structure of the > DAG is > then used to restrict the complexity of the P2MP routing problem on > the > nodes. The Destination Advertisement mechanism lets a node set up > routes > in support of outward traffic flows, from the DAG root towards the > leaf > nodes in the LLN. The Destination Advertisement mechanism distributes > routing state inwards along the DAG, allowing nodes to learn routing > state > in support of the sub-DAGs below them. Nodes who are unable to learn > routing state pass the Destination Advertisements inward, building up > source routing information along the way so that they may be traversed > again on the outward flow. The exact implementation of source > routing in > support of this mechanism is not something that has been addressed > by RPL > as yet. The choice was made to make it an open item. Options (to be discussed later on in the WG) are (compressed) IP source routing or label switching. > > Further, arbitrary P2P traffic can be supported by the DAG as > is by > sending traffic inwards along the DAG until a parent is encountered, > who > has stored routing state and is common to the source and destination > of the > traffic, who is able to direct the traffic towards the destination. > Let's just point out that the level of optimality of that P2P route is not deterministic and more optimal P2P path may require additional functionality to be defined. > RPL does not discuss any mechanisms to install more optimal P2P > routes, but nor does it preclude them, once the fundamentals have been > addressed we can have a look at such mechanism to more efficiently > route > `across' the DAG. > > 3) Metrics > RPL allows for each node to select its set of DAG parents > according > to its own set of constraints, utilizing whatever subset of metrics it > requires to do so. The exact considerations and weighting can be > implementation specific. I would like to mention that the use of non coherent policy between nodes may lead to some undesirable lack of determinism in the DAG optimality. Should RPL be adopted by the WG, this will be discussed in the METRIC ID. > > A key design point, one that may need to be further > constrained, is > that under RPL each node does not assume that other nodes are acting > cooperatively, or even that they are using or understand the same > set of > metrics. One node could be optimizing for latency, another node > could be > optimizing for ETX, and a third could be optimizing for > minimum energy. This is a point I am not comfortable with since the result is simply not deterministic and may not make any sense .... still provides a "path" but the use of non coherent metrics means not using any metric. My proposal is to add the selected metric advertised in the RA at a minimum. Let's flag this as an open issue and discuss it in Stockholm. > This design point informs some of the loop avoidance > rules, such as the use of depth as a `common language'. > > Once a node as selected its DAG parents, according to whatever > metrics and constraints it chooses, then it has effectively taken up a > position in the DAG. It now has a best-case path to the DAG root, > through > its best parent, and a worst-case path to the DAG root, through its > worst > parent. Now, as a *consequence* of selecting parents according to its > metrics, the node has taken on a depth within the DAG. > > 4) Loop avoidance > The DAG, and the nodes position within the DAG, are used in > support > of some loop avoidance rules. > > RPL always allows a node to move inwards along the DAG, > towards the > root. Moving inwards along the DAG has little chance of creating a > loop; > the node has only improved its position. Such a move would be based > on > receiving and processing DIOs with superior metrics from a node of a > lesser > depth in the DAG. > > RPL does not allow a node to move outwards along the DAG, > increasing its depth. Such a move is possible, but would require > the node > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > attach at > the lower point. RPL would not allow this movement unless the DAG > parents > of the node have failed, requiring the node to detach and re-attach > to the > DAG. Which may or may not be acceptable since it requires a temporary loss of connectivity with no guarantee that a better route exists. We need to discuss the ability to still listen RAs from deeper nodes. > > In general, RPL is taking a conservative approach. For a > node N, > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > node N. Suppose that node N thought it could improve its metrics > through > node M. By detaching first, and waiting to observe node M to see > that node > M remains attached to the DAG, node N may then determine that node M > is not > part of its own sub-DAG and may safely re-attach at the lower point. > BUT if > node N is wrong, then an instability has been created for no gain. > For this reason, in its current specification, RPL does not allow a > node N > to process and DIO from node M and detach from the DAG based on > information > in the DIO from node M. Currently traveling (not easy to draw a picture ...) but it could be useful to illustrate such instability with an example ... and add it to the ID (to be removed eventually or moved to an appendix). > NOTE that this is in part a consequence of the > design consideration that not all nodes may be using the same > metrics and > making the same optimizations. For example, if all nodes in the > network > were minimizing ETX, then node N may be mostly certain that any node > M advertising a superior ETX is NOT in its own sub-DAG. Yet another reason for using a consistent metric (although not sufficient). > > A further complication may come if node N and node M are > trying to > make optimizations which are antagonistic to each other. For > example, if > node N where to try to move under node M, it could create a chain of > events > whereby node M tried to reverse its position with respect to node M, > and a > chain reaction of instability could result. A simple example of > such a > case would be where both nodes M and N have a common neighbor and > parent P, > and nodes M and N subsequently each try to increase the size of their > parent set to be 2. (This case has been more thoroughly explained by > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > sent 30 > June 2009.) Our well-known count to infinity problem if we do not poison. But ignoring RAs does not allow for finding more optimal routes unless explicitly detaching. Let's add Pascal text in there. > > RPL has nodes advertise a depth deeper than that of their > deepest > DAG parent. Just mention that this is to avoid loops. > Consider an example where node X has parents of depth {2, 7}, > and node Y chooses X as a parent. Suppose that nodes then advertise > their > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > advertise a depth of 4. Then suppose node Z adds node Y as a > parent, and > advertises a depth of 5. Now, Z can actually come to be a successor > of > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > parent)->(...)->Z and then there is a loop. By advertising a depth > deeper > that of its deepest parent, a node advertises its worst case > scenario, and > in the worst case scenario a loop can be avoided. > > RPL does not require that the DAG is invariant, rather that the > movement of the node with respect to the DAG is coordinated in such > a way > so as to avoid loops. The thought is, whatever the topology, > uncoordinated > movement in LLNs may increase overhead and churn and require more > reliance > on expensive mechanisms such as count-to-infinity. > > The use of depth (~ hop count) in RPL is not meant to trump > other > metrics, but once a node has taken up a position in the DAG by using > its > metrics the node acquires a depth, which then restricts the further > options > that the node has in order to avoid loops. > That is a weak point that we need to address though. Cheers. JP. > > > Regards, > > -Tim > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-24-229957827 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Tim,

Thanks for taking the timing = to write this text,

On Jul 6, 2009, = at 12:52 AM, Tim Winter wrote:

WG,

Thanks to everyone for their feedback and = comments to the RPL draft so far.
There are some good threads here = that will definitely help us to improve
the RPL design- and there is = no doubt more work to be done.  I would like
to make some = clarifications that may be useful in discussing some of the
common = concerns so far:

1) Why a DAG?
=        A dominant traffic flow in the = requirements drafts is MP2P, flowing
from the sensors inwards towards = a sink, typically an LBR.  The design
approach taken was to = handle this case, use it to restrict the routing
problem, and then = try to build support for P2MP, P2P, and other cases on
top of it. =  A tree provides the simplest structure for supporting the = MP2P
flows, but a tree has many single points of failure along the = edges from
children to parents.  A DAG, allowing each node to = select and maintain
multiple successors in order to forward traffic = inwards toward the root,
offers the advantage of ready-to-use = options.  An implementation may then
select from the successors = as necessary, possibly in response to a
temporary failure to forward = to one parent, or a load balancing algorithm,
or a short-term = fluctuation in a link metric that leads the forwarding
engine to = prefer one next hop over the = other.

Note also that one may = decide to make use of more than one DAG for the same destination, when = DAGs may be used using different metrics or = constraints.


2) What about = other flows?
       The DAG, and = the orientation of the edges in the DAG, is used in
routing the MP2P = traffic towards the DAG root.  The structure of the DAG is
then = used to restrict the complexity of the P2MP routing problem on = the
nodes.  The Destination Advertisement mechanism lets a node = set up routes
in support of outward traffic flows, from the DAG root = towards the leaf
nodes in the LLN.  The Destination = Advertisement mechanism distributes
routing state inwards along the = DAG, allowing nodes to learn routing state
in support of the sub-DAGs = below them.  Nodes who are unable to learn
routing state pass = the Destination Advertisements inward, building up
source routing = information along the way so that they may be traversed
again on the = outward flow.  The exact implementation of source routing = in
support of this mechanism is not something that has been addressed = by RPL
as yet.

The choice = was made to make it an open item. Options (to be discussed later on in = the WG) are (compressed) IP source routing or label = switching.


=        Further, arbitrary P2P traffic = can be supported by the DAG as is by
sending traffic inwards along = the DAG until a parent is encountered, who
has stored routing state = and is common to the source and destination of the
traffic, who is = able to direct the traffic towards the = destination.


Let's just = point out that the level of optimality of that P2P route is not = deterministic and more optimal P2P path may require additional = functionality to be defined.

=        RPL does not discuss any = mechanisms to install more optimal P2P
routes, but nor does it = preclude them, once the fundamentals have been
addressed we can have = a look at such mechanism to more efficiently route
`across' the = DAG.

3) Metrics
       RPL = allows for each node to select its set of DAG parents according
to = its own set of constraints, utilizing whatever subset of metrics = it
requires to do so.  The exact considerations and weighting = can be
implementation = specific.

I would like to = mention that the use of non coherent policy between nodes may lead to = some undesirable lack of determinism in the DAG optimality. Should RPL = be adopted by the WG, this will be discussed in the METRIC = ID.


=        A key design point, one that = may need to be further constrained, is
that under RPL each node does = not assume that other nodes are acting
cooperatively, or even that = they are using or understand the same set of
metrics.  One node = could be optimizing for latency, another node could be
optimizing for = ETX, and a third could be optimizing for
minimum energy. =  

This is a point I am not = comfortable with since the result is simply not deterministic and may = not make any sense .... still provides a "path" but the use of non = coherent metrics means not using any = metric. 

My proposal is to add the = selected metric advertised in the RA at a = minimum.

Let's flag this as an open issue and = discuss it in Stockholm.

This = design point informs some of the loop avoidance
rules, such as the = use of depth as a `common language'.

=        Once a node as selected its = DAG parents, according to whatever
metrics and constraints it = chooses, then it has effectively taken up a
position in the DAG. =  It now has a best-case path to the DAG root, through
its best = parent, and a worst-case path to the DAG root, through its = worst
parent.  Now, as a *consequence* of selecting parents = according to its
metrics, the node has taken on a depth within the = DAG.

4) Loop avoidance
=        The DAG, and the nodes = position within the DAG, are used in support
of some loop avoidance = rules.

       RPL always = allows a node to move inwards along the DAG, towards the
root. =  Moving inwards along the DAG has little chance of creating a = loop;
the node has only improved its position.  Such a move = would be based on
receiving and processing DIOs with superior metrics = from a node of a lesser
depth in the DAG.

=        RPL does not allow a node to = move outwards along the DAG,
increasing its depth.  Such a move = is possible, but would require the node
to leave the DAG, wait for a = DAG Hop timer to elapse, and then re-attach at
the lower point. =  RPL would not allow this movement unless the DAG parents
of the = node have failed, requiring the node to detach and re-attach to = the
DAG.

Which may or may = not be acceptable since it requires a temporary loss of connectivity = with no guarantee that a better route exists. We need to discuss the = ability to still listen RAs from deeper nodes.


       In = general, RPL is taking a conservative approach.  For a node = N,
any node M such that depth(M)>depth(N) MAY be in the sub-DAG = of
node N.  Suppose that node N thought it could improve its = metrics through
node M.  By detaching first, and waiting to = observe node M to see that node
M remains attached to the DAG, node N = may then determine that node M is not
part of its own sub-DAG and may = safely re-attach at the lower point. BUT if
node N is wrong, then an = instability has been created for no gain.
For this reason, in its = current specification, RPL does not allow a node N
to process and DIO = from node M and detach from the DAG based on information
in the DIO = from node M.  

Currently = traveling (not easy to draw a picture ...) but it could be useful to = illustrate such instability with an example ... and add it to the ID (to = be removed eventually or moved to an appendix).

NOTE that this is in part a consequence of = the
design consideration that not all nodes may be using the same = metrics and
making the same optimizations.  For example, if all = nodes in the network
were minimizing ETX, then node N may be mostly = certain that any node
M advertising a superior ETX is NOT in its own = sub-DAG.

Yet another reason = for using a consistent metric (although not = sufficient).


=        A further complication may = come if node N and node M are trying to
make optimizations which are = antagonistic to each other.  For example, if
node N where to try = to move under node M, it could create a chain of events
whereby node = M tried to reverse its position with respect to node M, and a
chain = reaction of instability could result.  A simple example of such = a
case would be where both nodes M and N have a common neighbor and = parent P,
and nodes M and N subsequently each try to increase the = size of their
parent set to be 2.  (This case has been more = thoroughly explained by
Pascal, see "Re: [Roll] Fwd: I-D = Action:draft-dt-roll-rpl-00.txt Q1" sent 30
June = 2009.)

Our well-known count to = infinity problem if we do not poison. But ignoring RAs does not allow = for finding more optimal routes unless explicitly detaching. Let's add = Pascal text in there.


=        RPL has nodes advertise a = depth deeper than that of their deepest
DAG parent. =  

Just mention that this is = to avoid loops.

Consider an = example where node X has parents of depth {2, 7},
and node Y chooses = X as a parent.  Suppose that nodes then advertise their
`best' = depth, i.e. node X advertises a depth of 3.  Then node Y = will
advertise a depth of 4.  Then suppose node Z adds node Y as = a parent, and
advertises a depth of 5.  Now, Z can actually come = to be a successor of
node X's depth 7 parent.  The result could = be Z->Y->X->(cost 7
parent)->(...)->Z and then there = is a loop.  By advertising a depth deeper
that of its deepest = parent, a node advertises its worst case scenario, and
in the worst = case scenario a loop can be avoided.

=        RPL does not require that the = DAG is invariant, rather that the
movement of the node with respect = to the DAG is coordinated in such a way
so as to avoid loops. =  The thought is, whatever the topology, uncoordinated
movement = in LLNs may increase overhead and churn and require more reliance
on = expensive mechanisms such as count-to-infinity.

=        The use of depth (~ hop count) = in RPL is not meant to trump other
metrics, but once a node has taken = up a position in the DAG by using its
metrics the node acquires a = depth, which then restricts the further options
that the node has in = order to avoid loops.


That = is a weak point that we need to address = though.

Cheers.

JP.


Regards,

-Tim
_______________________= ________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-24-229957827-- From jvasseur@cisco.com Tue Jul 7 10:45:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0933A6961 for ; Tue, 7 Jul 2009 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 kwo8ypHUquHx for ; Tue, 7 Jul 2009 10:45:44 -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 9B78428C4AC for ; Tue, 7 Jul 2009 10:45:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="339258445" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2009 17:46:01 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67Hk1vM008756; Tue, 7 Jul 2009 10:46:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n67Hk18j014032; Tue, 7 Jul 2009 17:46:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:46:01 -0700 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:46:00 -0700 Message-Id: <0ED6CA3C-5C28-4BD4-98F2-BE088D85D48B@cisco.com> From: JP Vasseur To: Tim Winter In-Reply-To: <4A527EAA.4060603@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 15:30:24 +0200 References: <4A527EAA.4060603@acm.org> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 17:46:00.0615 (UTC) FILETIME=[CA65D370:01C9FF2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6932; t=1246988761; x=1247852761; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=2jzuxr4zpQg2ht/zz3QZm+jIPQGSvmGhf1ifZAMJmiQ=; b=pnzqf6P5PSTq+BrArScxYwxknZfwe3AwUUxr/w/ZaAnwM44McaEznhiMIU DJeXX1NmqFgBRjMxkHvI8NkSCNoVZdt4u/1JQyOJtyoEszVcAaDkpdnEKaON afgvz7SnFF; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:45:46 -0000 Hi Tim, On Jul 7, 2009, at 12:46 AM, Tim Winter wrote: > > Hi Richard, > > Richard Kelsey wrote: >> Date: Sun, 05 Jul 2009 18:52:07 -0400 >> From: Tim Winter >> >> 2) What about other flows? >> [...] Nodes who are unable to learn >> routing state pass the Destination Advertisements inward, >> building up >> source routing information along the way so that they may be >> traversed >> again on the outward flow. The exact implementation of source >> routing in >> support of this mechanism is not something that has been >> addressed by RPL >> as yet. >> >> In general, is adding an IP source route to a forwarded >> packet allowed? Could a root add a source route to an >> incoming packet before forwarding it down the DAG? > There is nothing that prevents you from doing this (RH0 has been deprecated though but this is not a major issue). Still and I have been trying to resist from discussing this issue until we had the basics sorted out and agreed upon, there are several options to do this: 1) Classic source routing: although not used for IP, it has been in use for years by MPLS with strict and loose source routing with RSVP- TE. Still we may have a serious issue with deep networks if using uncompressed addresses ... defining statefull address compression brings its own challenge. 2) Label switching: not just because I spent many years working on MPLS but this may solve several issues although we would need to add label management with in band or out of band label allocation. If OK with you I would suggest to leave it as an open action item for the time being. > It seems that such action on the part of the DAG root would make this > mechanism work much better, e.g. adding the proper source routing > information to the packet as it traverses the root and not requiring > the > source of the packet to know of LLN routing internals. But the > details, and > the proper mechanisms in light of IPv6 architecture, would have to > be worked > out. There would certainly be some security considerations, etc. as > well. > >> >> 3) Metrics >> A key design point, one that may need to be further >> constrained, is >> that under RPL each node does not assume that other nodes are >> acting >> cooperatively, or even that they are using or understand the same >> set of >> metrics. One node could be optimizing for latency, another node >> could be >> optimizing for ETX, and a third could be optimizing for >> minimum energy. >> >> This doesn't seem very useful to me. To the extent that >> these three are independent, you could easily end up with >> routes that were bad at all of them. Why is this a key >> design point? >> > Agreed that this situation would not be very useful in practice- why > would > anyone deploy such a network? Certainly such a network is not > likely to be > optimized. BUT RPL does not currently specify any particular > metrics or how > the implementation may constrain or optimize them. And this then > leads to > the possibilities that, e.g. different vendors/software > version/configurations may be deployed into the LLN, intentionally or > accidentally or over the course of years of maintenance and > upgrades, which > do not work well together- they may not understand each others > metrics, they > may not propagate each others metrics in expected ways, or their > constraints > may work against each other. > RPL has been specified in such a way that even such a case where > nodes are > not working cooperatively, they can still interoperate to the point > that a > LLN can be formed with some loop avoidance and even ought to be > stable (but > not necessarily optimal). > And, as you have demonstrated, in some cases RPL can be too > conservative in > getting to this solution. I am hopeful that we can come up with a > way to > let this aspect of RPL work more closely with the metrics in cases > where it > is safe from the loop avoidance perspective. > As this effort proceeds maybe some more work in the metrics draft > can help > to clarify what a routing solution ought to be prepared to handle. > With > regard to RPL, I think that so far some of the other threads > regarding the > loop avoidance metrics, etc. are making some good progress... Yes, see my comments on the use of consistent metrics though. Richard, don't you see the need for using several metrics? In this case, you may end up with nodes trying to optimize for different metrics ... > > > >> Also, it seems to me that this interacts poorly with having >> a DAG. With a tree a node receives a single value for each >> metric from its parent. With a DAG, one parent may have a a >> low latency but high energy cost while another parent has >> high latency and low energy cost. What metric values should >> the child advertise? > > Generally, if the loop avoidance mechanism is in place to cover the > `worst > case', then a child could be safe to advertise the values from the DIO > propagating from its typical case (or best case if you want to be > optimistic) parent. If the loop avoidance mechanism comes to rely > directly > on a metric, then it seems that a node should tend to propagate the > worst-case metric, for the same reason that a node gives its depth > today as > deeper than its deepest feasible parent. > >> >> Given the dubious benefits of having different nodes >> optimize different metrics, and the bad interaction with >> having multiple parents, I really don't understand the >> emphasis on this feature. It is not just a feature ... you may indeed mix nodes interesting in optimizing different metrics. My suggestion is to make sure that we do not end up with path mixing up metrics of different types. >> >> -Richard Kelsey >> > It is perhaps mostly a question of interoperability. Should such a > scenario > come to pass, what should the LLN do? Can we expect that all nodes > in the > LLN will be having the same software, the same understanding of > metrics and > constraints and optimization goals, etc. When we look at a typical > LLN > deployment today, maybe this is true more often than not. But as we > open up > the possibility for LLN nodes to truly interoperate with standards- > based > IPv6, what then? RPL in its present form is trying to establish > some base > guidelines as to how such a heterogeneous LLN might organize itself, > while > leaving some freedoms for the implementors... > Right. JP. > > -Tim > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jul 7 10:45:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD7D3A6961 for ; Tue, 7 Jul 2009 10:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 d5k5wqD1v5nF for ; Tue, 7 Jul 2009 10:45:53 -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 ECDC328C4EA for ; Tue, 7 Jul 2009 10:45:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="210582445" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2009 17:46:08 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67Hk8X1023171; Tue, 7 Jul 2009 10:46:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67Hk8KW022875; Tue, 7 Jul 2009 17:46:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:46:08 -0700 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 10:46:07 -0700 Message-Id: From: JP Vasseur To: Philip Levis , Omprakash Gnawali , "Pascal Thubert (pthubert)" 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 v935.3) Date: Tue, 7 Jul 2009 15:40:43 +0200 References: <87bpo5y74l.fsf@kelsey-ws.hq.ember.com><852B8D1D-C07F-49CC-9368-CCCAE7B375DE@cs.stanford.edu><877hytqrzg.fsf@kelsey-ws.hq.ember.com><243111A7-189D-4FF9-8B50-87553D77A233@archrock.com><8763ecy368.fsf@kelsey-ws.hq.ember.com><3ACA79F9-8C9B-4B32-BBE8-5A7D16159382@archrock.com> <1AED648B-B718-4701-A59B-DC5075B3316E@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC07B93CD8@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 17:46:07.0677 (UTC) FILETIME=[CE9B66D0:01C9FF2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2264; t=1246988768; x=1247852768; c=relaxed/simple; s=sjdkim1004; 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[Roll]=20Trickle=20in=20draft-dt-roll-r pl-00.txt |Sender:=20; bh=v/OTNV3rAwa0srv33HyGfuq9ZalZvsUDly4aIzldeAk=; b=jkyDEVDAUFgi2d0oaLpqR9yqO5BNlryuN3NFhXO3j0T04NdbPaRmiasQpO uJtzKUBH5D/4z14KPj17q0Hg3iu20d91W+L7B00LKxEQAvJ3bexGSGpvCOuX iLYpYqN7gmsJNwUt2LesUgQGWdxwcnenibl8CzebC+7WZS5+xnN7s=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ROLL WG Subject: Re: [Roll] Trickle in draft-dt-roll-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:45:54 -0000 but the goal of using trickle here is not to activate and disactivate routers, simply to reduce the frequency at which RAs are being sent w/ o compromising too much the reaction time. JP. On Jul 6, 2009, at 6:56 PM, Philip Levis wrote: > > On Jul 3, 2009, at 6:51 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> I think I asked you that same question in Dublin but now we have a >> context. >> >> What I'd really like to suppress is the behavior of a router being a >> router, as opposed to suppressing some RAs from every routers. >> >> Like if I have many of other routers around I could yield and >> suppress >> RAs totally. The idea being that some nodes act as routers for some >> time >> and then they stop because they think they've done enough. Neighbors >> node discovering a lesser density take over and now act as routers. >> >> Could you adapt your trickle thinking to get there? > > Can you be more precise? Is it that you want a router to more > aggressively suppress others, or is it that you want a router to > decide it should suppress itself more? Two questions. The first is: > where is the decision is made? Is it: > > 1) Node A decides node B should stop being a router, or > 2) Node B decides it should stop being a router? > > 1) has problematic security implications. > > The second is whether node B (who thinks it's done enough) should > suppress its RAs even if there are no other nodes around it sending > RAs. I.e., what happens when every node thinks it's done enough? > > The simplest way to get (reasonably) deterministic suppression > through priorities is by having different interval lengths. If node > A has an interval of length T and node B has an interval of length > 2T, node A will always transmit in node B's quiet period and > suppress it. But this assumes k=1. > > Ultimately, Trickle is a randomized algorithm, and there are always > chances of packet drops. So without entertaining the possibility of > disconnection, B will send *some* RAs, albeit perhaps far fewer than > A. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From philip.levis@gmail.com Tue Jul 7 10:06:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955C528C4C9 for ; Tue, 7 Jul 2009 10:06:43 -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 FE53BWHG8KF6 for ; Tue, 7 Jul 2009 10:06:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id CAE7328C1A0 for ; Tue, 7 Jul 2009 10:06:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so17545wff.31 for ; Tue, 07 Jul 2009 10:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=06WhjX6sxwWI5IXm5N45gHlF+S1YqV0I/W/JnwYkb8Q=; b=YhsbsED6ppkzSuA8EVlq0oSs6uIlkmKI3UwBAMLwsBo95AkOn53nvvVpc+6w6nfpWf YO14BPwNfv191TazA77yuHxAuETvYO/XP96fbhtoHvSlsghM8KzEXb3nUR1po5K8HiLo EIj90KJF4TXCPR6BFQWemDbN/p26K6quEUwNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=dEjXOerM6xugsYG+BmNMbZEtL+02puw7hOPeh4u7jxw9dPQ/B+ZCT6AsVBp0aBY0eL RCm/CYAnSX9JSWUXABzqX8JdN0KuIeWtursaL6i4NNKRluMB6LtIGLvApGrX6WmAvGE+ pAHIzKojI0duNqcK39Cjqr8K7t/WpH1amB3v4= Received: by 10.142.155.8 with SMTP id c8mr2031359wfe.130.1246986360522; Tue, 07 Jul 2009 10:06:00 -0700 (PDT) Received: from DNab404671.Stanford.EDU (DNab404671.Stanford.EDU [171.64.70.113]) by mx.google.com with ESMTPS id 29sm11871787wfg.1.2009.07.07.10.05.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 10:05:59 -0700 (PDT) Message-Id: From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4A531314.1080307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 09:28:48 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 07 Jul 2009 13:38:27 -0700 Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:37:45 -0000 On Jul 7, 2009, at 2:19 AM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On Jul 3, 2009, at 1:57 AM, Alexandru Petrescu wrote: >>>> Richard, This seems like a totally reasonable metric to use, but >>>> I'd be wary of saying it's *the* metric to use. Some >>>> implementations are going to want to consider hopcount, others >>>> won't. It's just another metric. Rather than hardwire hopcount >>>> based assumptions into the protocol design, we should put it on >>>> equal footing as other metrics. Correspondingly, the protocol >>>> should have general, metric-independent mechanisms for detecting >>>> and avoiding loops. >>> Phil, what does 'loop' mean when metrics other than hopcount are >>> used? What does a loop look like when e.g. ETX is used as metric? >> If there's a loop in an ETX graph, then ETX does not monotonically =20= >> decrease along the route. This goes back to Jonathan's comment on >> metric vectors. > > I personally haven't yet grasped the notion of a loop in terms of ETX > (Expected Transmission count metric [De Couto 2003]). I do =20 > understand a > loop in terms of the hop count metric. > > By your definition above it may seem that an ETX-loop appears when =20 > the ETX increases arbitrarily along a path. =46rom this I think there = =20 > may be loop-free paths (in terms of hopcount) which are ETX-loops. Have you read the CTP paper? It talks about this in depth. A loop =20 *can* occur when a metric that should monotonically decrease along a =20 route (hop count, ETX, etc.) doesn't do so due to inconsistencies in =20 tables. Phil= From philip.levis@gmail.com Tue Jul 7 10:07:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D834D28C301 for ; Tue, 7 Jul 2009 10:07:43 -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 Uugo2TLcS0AC for ; Tue, 7 Jul 2009 10:07:43 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 0973528C1A0 for ; Tue, 7 Jul 2009 10:07:43 -0700 (PDT) Received: by pzk36 with SMTP id 36so5030122pzk.29 for ; Tue, 07 Jul 2009 10:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=N6vv3xJC541CgwoFiDcsjMT0xRQp4nOl0tAz1FnkukQ=; b=wVYheDNT+/0Vw4i5XuzVkMUZN++ibShpcYNMznI/Sn16VM1r9ez8oglZzj2rqQ7ZHr TXT8HYZGIbkyvfnig8Q0WPUqnQ/NPt3CxPD+KFQizQTA9EKoDGsG3VqkrK7jYhu2u+FM p8zCm0wt3OtWQ5YmhuLeDMJ0CG/ihS/yuwuqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=iOSu+vCrJpvNseadGEm/7MI74HxMSol5H4jzZFIubZUZ2duArMweEUMidV6S/LRS0W eg58VHfMqqtPi1BqxCT/ny+dN+mcxNotgbTKbwdWWizRPakzh+FPb+/f60IEKUb8WmLi 6/qT1PapC4cH1CuREdi6AaH8Uc+5wf4lRSqkk= Received: by 10.142.199.15 with SMTP id w15mr1983149wff.305.1246986362403; Tue, 07 Jul 2009 10:06:02 -0700 (PDT) Received: from DNab404671.Stanford.EDU (DNab404671.Stanford.EDU [171.64.70.113]) by mx.google.com with ESMTPS id 29sm11871787wfg.1.2009.07.07.10.06.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 10:06:01 -0700 (PDT) Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07C04071@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 v935.3) Date: Tue, 7 Jul 2009 09:59:00 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07C04071@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 07 Jul 2009 13:38:27 -0700 Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:37:58 -0000 On Jul 7, 2009, at 5:21 AM, Pascal Thubert (pthubert) wrote: >> >> On Jul 6, 2009, at 3:45 PM, Richard Kelsey wrote: >>> Using a more precise metric produces fewer siblings, with >>> the remainder being either 'ignored' or inward siblings. >>> category. The net effect is to increase the number of >>> neighbors that can be used to forward messages without >>> creating into a loop, while decreasing the number that might >>> create a loop. >>> >>> I don't have any idea which is likely to work better in >>> practice. >> >> In the end we are saying the same things just in different words. A >> less precise route cost produces more siblings and leaves more edges >> undirected. A more precise route cost makes more edges directed. The >> one that works better in practice depends on the density and number >> of >> feasible successors. In other words, if there are many edges to >> choose >> from - why not orient them and avoid loops altogether? In a sparse >> network, you might want to leave them undirected to give greater >> opportunity of routing around failures. > > I'd say that in dense networks the routers should have enough > parents to > choose from so they would never need the siblings or even keep track > of > them by lack of resources. So the coarse metric seems to obtain the > desired result in both cases, use parents when there are enough of > them, > enable siblings in sparse conditions. Routing loops are only a problem if they persist, such that they waste transmissions and lose packets. If the protocol can detect loops and repair them on the order of a few packet times -- loops are always transient -- they aren't a problem. It can be that all of the mechanisms you put in place to avoid/prevent loops are more expensive than simply detecting and repairing them. Phil From philip.levis@gmail.com Tue Jul 7 10:08:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2F328C4ED for ; Tue, 7 Jul 2009 10:08:32 -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 WvTpTwPEsNQW for ; Tue, 7 Jul 2009 10:08:32 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 2110228C4DF for ; Tue, 7 Jul 2009 10:08:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so17908wff.31 for ; Tue, 07 Jul 2009 10:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=J/iKOXuMjqi/mS4+R02hpnSxIBcGGukzEgG6rHRyW40=; b=pmjWsW7W1Sn/G8WEDFeC5poVatJiK/VDNN4NO39TjAyOW2aigyTz1v8teHY2eao/Ez ojYWkQe1Fx7prt3h7F7Ir+SxUOSW7rTIvu8RnREy2ZtpGVIUTrwouNqzgEuzHFngY44g uw72MZ6fkVqP/D/XIj1ZlMCgSVkmq6pT3MUBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=C5cxTqtqEGi3/dwED/FHNPlZQZKA9+H21Uu2uJ99xjjKQSG2WODg+5me56uhcU8Qqj JXWFhA4Qav469HnQNldA9W3pRj3sLHk7UDZkKdruLt5F4nyhnCAgUqm5Z58//ZNcZbHd OjlJ6D7UilBktDyq4jZSxjE1ryxPB/TP2XGX4= Received: by 10.142.223.20 with SMTP id v20mr1972523wfg.17.1246986481845; Tue, 07 Jul 2009 10:08:01 -0700 (PDT) Received: from DNab404671.Stanford.EDU (DNab404671.Stanford.EDU [171.64.70.113]) by mx.google.com with ESMTPS id 22sm4288731wfi.12.2009.07.07.10.08.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 10:08:01 -0700 (PDT) Message-Id: From: Philip Levis To: Jonathan Hui In-Reply-To: <3986B609-FDE0-4756-9F48-DAD29F1BBD26@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 10:08:02 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <87eisswsak.fsf@kelsey-ws.hq.ember.com> <3986B609-FDE0-4756-9F48-DAD29F1BBD26@archrock.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 07 Jul 2009 13:38:27 -0700 Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:07:41 -0000 On Jul 7, 2009, at 9:44 AM, Jonathan Hui wrote: >> If we have a reliable way to prevent looping when routing >> through siblings, then I would propose that we use h equal >> to the optimal link cost. This would gives us close to what >> we have now in terms of siblings. This is what you meant >> by having k=1, correct? > > Yes, that's what I meant. I don't think there's a particular > mechanism to *prevent* loops. Pascal's assumptions are that a packet > will only continue to loop with some small-ish probability. If a > packet does get stuck in a loop, then the hop limit will expire it. > Only annoying thing with relying on the hop limit is ICMPv6 time > exceeded errors. > >> If we cannot prevent looping when routing through siblings, >> it would be better to only allow forwarding via nodes with >> lower cost (parents and 'inward siblings'). > > > I also like that this encourages fewer loops. The special case, > however, is when you're near the root. Assuming perfect information, > there will be one node that has no alternate parents. This seems like towards the right approach -- avoid loops and quickly detect them when they occur, rather than go through gymnastics to prevent them. Phil From Jerald.P.Martocci@jci.com Tue Jul 7 13:47:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AE03A68DC; Tue, 7 Jul 2009 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgn1O9UDISgg; Tue, 7 Jul 2009 13:47:31 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id D55533A682B; Tue, 7 Jul 2009 13:47:30 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKSlO0QOeyULNeEa3Inzhj3tF8hfQQ4z6o@postini.com; Tue, 07 Jul 2009 13:47:58 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009070715471087-1132785 ; Tue, 7 Jul 2009 15:47:10 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 7 Jul 2009 15:46:40 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/07/2009 03:46:51 PM, Serialize complete at 07/07/2009 03:46:51 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/07/2009 03:47:10 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/07/2009 03:48:17 PM, Serialize complete at 07/07/2009 03:48:17 PM Content-Type: multipart/alternative; boundary="=_alternative 00722615862575EC_=" Cc: ROLL WG , Mukul Goyal , roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:47:34 -0000 This is a multipart message in MIME format. --=_alternative 00722615862575EC_= Content-Type: text/plain; charset="US-ASCII" JP, I agree with Mukal. If two or more nodes are all within radio proximity and hence neighbors they should all be able to exchange messages amongst themselves without needing to traverse the DAG. In the commercial building environment this will happen in the equipment rooms. These rooms are electromechanical rooms holding air handling, heating and air conditioning equipment. There may me as many as 20 controllers (routing devices), 20 sensors and 20 actuators (non-routing devices) all in the same 500 sq ft room. The concept of finding candidate parents and connecting into the DAG for this simple communication seems to be overkill. I am only to page 41 of the draft and may be pleasantly surprised as I read on; but the sense I have of the draft so far is it is optimizing router efficiency of devices (i.e. no loops) while ignoring the logical cohesion of many of the devices. Again, in a commercial building there are hundreds of rooms. Each room is a microcosm of the overall network (e.g occupancy, lights, heating/cooling, shade control). For the most part these devices are completely independent of all the other rooms. They should be able to communicate bidirectionally and freely amongst themselves with minimal impact to the rest of the LLN. The DAG discovery and maintenance policies described in the draft looks like each device positions itself on the DAG as best as it can and then communicates as high up and then back down the DAG as necessary to reach its intended destination. I would think this would create an unbalanced network traffic where the higher layers are unfairly taxed at forwarding uninteresting messages while the lower layers are awaiting message delivery. As I mentioned in a previous email, this architecture tends to make some devices more important to the LLN than others which has negative fault tolerance impact. My definition of 'Good P2P Routing' is that if a device has direct radio contact with another device; these devices can pass messages between themselves directly as needed. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 07/07/2009 12:45 PM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Some clarifications on RPL Hi Mukul, On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote: > Tim > > Thanks for this explanation. I think most of this email should > become part of RPL draft. > > I would like to convey the discomfort that many of us feel because > RPL does not yet support a good P2P routing solution. Tree based P2P > routing is not acceptable in many cases. We need to give this > problem a high priority. > The solution MUST of course support P2P and this is the case of RPL. Now we need to define what we mean by "Good" P2P routing solution. As of today RPL will branch the traffic as soon as the packet reaches a node that has the destination address in its routing table pointing to one of its children or sibling. This path may not be the most optimal path indeed and may even be unacceptable. Furthermore it is constrained by the shape of the DAG, which are dependent upon the metrics used by nodes closer to the root. The question is to determine how optimal should that path, and should we decide to adopt a routing solution a la RPL, do we need to complement it with another mechanism when optimal P2P path are required ? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Tim Winter" > To: "ROLL WG" > Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central > Subject: [Roll] Some clarifications on RPL > > WG, > > Thanks to everyone for their feedback and comments to the RPL draft > so far. > There are some good threads here that will definitely help us to > improve > the RPL design- and there is no doubt more work to be done. I would > like > to make some clarifications that may be useful in discussing some of > the > common concerns so far: > > 1) Why a DAG? > A dominant traffic flow in the requirements drafts is MP2P, > flowing > from the sensors inwards towards a sink, typically an LBR. The design > approach taken was to handle this case, use it to restrict the routing > problem, and then try to build support for P2MP, P2P, and other > cases on > top of it. A tree provides the simplest structure for supporting > the MP2P > flows, but a tree has many single points of failure along the edges > from > children to parents. A DAG, allowing each node to select and maintain > multiple successors in order to forward traffic inwards toward the > root, > offers the advantage of ready-to-use options. An implementation may > then > select from the successors as necessary, possibly in response to a > temporary failure to forward to one parent, or a load balancing > algorithm, > or a short-term fluctuation in a link metric that leads the forwarding > engine to prefer one next hop over the other. > > 2) What about other flows? > The DAG, and the orientation of the edges in the DAG, is used > in > routing the MP2P traffic towards the DAG root. The structure of the > DAG is > then used to restrict the complexity of the P2MP routing problem on > the > nodes. The Destination Advertisement mechanism lets a node set up > routes > in support of outward traffic flows, from the DAG root towards the > leaf > nodes in the LLN. The Destination Advertisement mechanism distributes > routing state inwards along the DAG, allowing nodes to learn routing > state > in support of the sub-DAGs below them. Nodes who are unable to learn > routing state pass the Destination Advertisements inward, building up > source routing information along the way so that they may be traversed > again on the outward flow. The exact implementation of source > routing in > support of this mechanism is not something that has been addressed > by RPL > as yet. > > Further, arbitrary P2P traffic can be supported by the DAG as > is by > sending traffic inwards along the DAG until a parent is encountered, > who > has stored routing state and is common to the source and destination > of the > traffic, who is able to direct the traffic towards the destination. > > RPL does not discuss any mechanisms to install more optimal P2P > routes, but nor does it preclude them, once the fundamentals have been > addressed we can have a look at such mechanism to more efficiently > route > `across' the DAG. > > 3) Metrics > RPL allows for each node to select its set of DAG parents > according > to its own set of constraints, utilizing whatever subset of metrics it > requires to do so. The exact considerations and weighting can be > implementation specific. > > A key design point, one that may need to be further > constrained, is > that under RPL each node does not assume that other nodes are acting > cooperatively, or even that they are using or understand the same > set of > metrics. One node could be optimizing for latency, another node > could be > optimizing for ETX, and a third could be optimizing for > minimum energy. This design point informs some of the loop avoidance > rules, such as the use of depth as a `common language'. > > Once a node as selected its DAG parents, according to whatever > metrics and constraints it chooses, then it has effectively taken up a > position in the DAG. It now has a best-case path to the DAG root, > through > its best parent, and a worst-case path to the DAG root, through its > worst > parent. Now, as a *consequence* of selecting parents according to its > metrics, the node has taken on a depth within the DAG. > > 4) Loop avoidance > The DAG, and the nodes position within the DAG, are used in > support > of some loop avoidance rules. > > RPL always allows a node to move inwards along the DAG, > towards the > root. Moving inwards along the DAG has little chance of creating a > loop; > the node has only improved its position. Such a move would be based > on > receiving and processing DIOs with superior metrics from a node of a > lesser > depth in the DAG. > > RPL does not allow a node to move outwards along the DAG, > increasing its depth. Such a move is possible, but would require > the node > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > attach at > the lower point. RPL would not allow this movement unless the DAG > parents > of the node have failed, requiring the node to detach and re-attach > to the > DAG. > > In general, RPL is taking a conservative approach. For a > node N, > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > node N. Suppose that node N thought it could improve its metrics > through > node M. By detaching first, and waiting to observe node M to see > that node > M remains attached to the DAG, node N may then determine that node M > is not > part of its own sub-DAG and may safely re-attach at the lower point. > BUT if > node N is wrong, then an instability has been created for no gain. > For this reason, in its current specification, RPL does not allow a > node N > to process and DIO from node M and detach from the DAG based on > information > in the DIO from node M. NOTE that this is in part a consequence of > the > design consideration that not all nodes may be using the same > metrics and > making the same optimizations. For example, if all nodes in the > network > were minimizing ETX, then node N may be mostly certain that any node > M advertising a superior ETX is NOT in its own sub-DAG. > > A further complication may come if node N and node M are > trying to > make optimizations which are antagonistic to each other. For > example, if > node N where to try to move under node M, it could create a chain of > events > whereby node M tried to reverse its position with respect to node M, > and a > chain reaction of instability could result. A simple example of > such a > case would be where both nodes M and N have a common neighbor and > parent P, > and nodes M and N subsequently each try to increase the size of their > parent set to be 2. (This case has been more thoroughly explained by > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > sent 30 > June 2009.) > > RPL has nodes advertise a depth deeper than that of their > deepest > DAG parent. Consider an example where node X has parents of depth > {2, 7}, > and node Y chooses X as a parent. Suppose that nodes then advertise > their > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > advertise a depth of 4. Then suppose node Z adds node Y as a > parent, and > advertises a depth of 5. Now, Z can actually come to be a successor > of > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > parent)->(...)->Z and then there is a loop. By advertising a depth > deeper > that of its deepest parent, a node advertises its worst case > scenario, and > in the worst case scenario a loop can be avoided. > > RPL does not require that the DAG is invariant, rather that the > movement of the node with respect to the DAG is coordinated in such > a way > so as to avoid loops. The thought is, whatever the topology, > uncoordinated > movement in LLNs may increase overhead and churn and require more > reliance > on expensive mechanisms such as count-to-infinity. > > The use of depth (~ hop count) in RPL is not meant to trump > other > metrics, but once a node has taken up a position in the DAG by using > its > metrics the node acquires a depth, which then restricts the further > options > that the node has in order to avoid loops. > > > > Regards, > > -Tim > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00722615862575EC_= Content-Type: text/html; charset="US-ASCII"
JP,


I agree with Mukal.  

If two or more nodes are all within radio proximity and hence neighbors they should all be able to exchange messages amongst themselves without needing to traverse the DAG.  In the commercial building environment this will happen in the equipment rooms.  These rooms are electromechanical rooms holding air handling, heating and air conditioning equipment.  There may me as many as 20 controllers (routing devices), 20 sensors and 20 actuators (non-routing devices) all in the same 500 sq ft room.  The concept of finding candidate parents and connecting into the DAG for this simple communication seems to be overkill.

I am only to page 41 of the draft and may be pleasantly surprised as I read on; but the sense I have of the draft so far is it is optimizing router efficiency of devices (i.e. no loops) while ignoring the logical cohesion of many of the devices.  Again, in a commercial building there are hundreds of rooms.  Each room is a microcosm of the overall network (e.g occupancy, lights, heating/cooling, shade control).  For the most part these devices are completely independent of all the other rooms.  They should be able to communicate bidirectionally and freely amongst themselves with minimal impact to the rest of the LLN.  

The DAG discovery and maintenance policies described in the draft looks like each device positions itself on the DAG as best as it can and then communicates as high up and then back down the DAG as necessary to reach its intended destination.  I would think this would create an unbalanced network traffic where the higher layers are unfairly taxed at forwarding uninteresting messages while the lower layers are awaiting message delivery.  As I mentioned in a previous email, this architecture tends to make some devices more important to the LLN than others which has negative fault tolerance impact.

My definition of 'Good P2P Routing' is that if a device has direct radio contact with another device; these devices can pass messages between themselves directly as needed.

Regards,

Jerry




JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

07/07/2009 12:45 PM

To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Some clarifications on RPL





Hi Mukul,

On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote:

> Tim
>
> Thanks for this explanation. I think most of this email should  
> become part of RPL draft.
>
> I would like to convey the discomfort that many of us feel because  
> RPL does not yet support a good P2P routing solution. Tree based P2P  
> routing is not acceptable in many cases. We need to give this  
> problem a high priority.
>

The solution MUST of course support P2P and this is the case of RPL.  
Now we need to define what we mean by "Good" P2P routing solution. As  
of today RPL will branch the traffic as soon as the packet reaches a  
node that has the destination address in its routing table pointing to  
one of its children or sibling. This path may not be the most optimal  
path indeed and may even be unacceptable. Furthermore it is  
constrained by the shape of the DAG, which are dependent upon the  
metrics used by nodes closer to the root. The question is to determine  
how optimal should that path, and should we decide to adopt a routing  
solution a la RPL, do we need to complement it with another mechanism  
when optimal P2P path are required ?

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "Tim Winter" <wintert@acm.org>
> To: "ROLL WG" <roll@ietf.org>
> Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central
> Subject: [Roll] Some clarifications on RPL
>
> WG,
>
> Thanks to everyone for their feedback and comments to the RPL draft  
> so far.
> There are some good threads here that will definitely help us to  
> improve
> the RPL design- and there is no doubt more work to be done.  I would  
> like
> to make some clarifications that may be useful in discussing some of  
> the
> common concerns so far:
>
> 1) Why a DAG?
>        A dominant traffic flow in the requirements drafts is MP2P,  
> flowing
> from the sensors inwards towards a sink, typically an LBR.  The design
> approach taken was to handle this case, use it to restrict the routing
> problem, and then try to build support for P2MP, P2P, and other  
> cases on
> top of it.  A tree provides the simplest structure for supporting  
> the MP2P
> flows, but a tree has many single points of failure along the edges  
> from
> children to parents.  A DAG, allowing each node to select and maintain
> multiple successors in order to forward traffic inwards toward the  
> root,
> offers the advantage of ready-to-use options.  An implementation may  
> then
> select from the successors as necessary, possibly in response to a
> temporary failure to forward to one parent, or a load balancing  
> algorithm,
> or a short-term fluctuation in a link metric that leads the forwarding
> engine to prefer one next hop over the other.
>
> 2) What about other flows?
>        The DAG, and the orientation of the edges in the DAG, is used  
> in
> routing the MP2P traffic towards the DAG root.  The structure of the  
> DAG is
> then used to restrict the complexity of the P2MP routing problem on  
> the
> nodes.  The Destination Advertisement mechanism lets a node set up  
> routes
> in support of outward traffic flows, from the DAG root towards the  
> leaf
> nodes in the LLN.  The Destination Advertisement mechanism distributes
> routing state inwards along the DAG, allowing nodes to learn routing  
> state
> in support of the sub-DAGs below them.  Nodes who are unable to learn
> routing state pass the Destination Advertisements inward, building up
> source routing information along the way so that they may be traversed
> again on the outward flow.  The exact implementation of source  
> routing in
> support of this mechanism is not something that has been addressed  
> by RPL
> as yet.
>
>        Further, arbitrary P2P traffic can be supported by the DAG as  
> is by
> sending traffic inwards along the DAG until a parent is encountered,  
> who
> has stored routing state and is common to the source and destination  
> of the
> traffic, who is able to direct the traffic towards the destination.
>
>        RPL does not discuss any mechanisms to install more optimal P2P
> routes, but nor does it preclude them, once the fundamentals have been
> addressed we can have a look at such mechanism to more efficiently  
> route
> `across' the DAG.
>
> 3) Metrics
>        RPL allows for each node to select its set of DAG parents  
> according
> to its own set of constraints, utilizing whatever subset of metrics it
> requires to do so.  The exact considerations and weighting can be
> implementation specific.
>
>        A key design point, one that may need to be further  
> constrained, is
> that under RPL each node does not assume that other nodes are acting
> cooperatively, or even that they are using or understand the same  
> set of
> metrics.  One node could be optimizing for latency, another node  
> could be
> optimizing for ETX, and a third could be optimizing for
> minimum energy.  This design point informs some of the loop avoidance
> rules, such as the use of depth as a `common language'.
>
>        Once a node as selected its DAG parents, according to whatever
> metrics and constraints it chooses, then it has effectively taken up a
> position in the DAG.  It now has a best-case path to the DAG root,  
> through
> its best parent, and a worst-case path to the DAG root, through its  
> worst
> parent.  Now, as a *consequence* of selecting parents according to its
> metrics, the node has taken on a depth within the DAG.
>
> 4) Loop avoidance
>        The DAG, and the nodes position within the DAG, are used in  
> support
> of some loop avoidance rules.
>
>        RPL always allows a node to move inwards along the DAG,  
> towards the
> root.  Moving inwards along the DAG has little chance of creating a  
> loop;
> the node has only improved its position.  Such a move would be based  
> on
> receiving and processing DIOs with superior metrics from a node of a  
> lesser
> depth in the DAG.
>
>        RPL does not allow a node to move outwards along the DAG,
> increasing its depth.  Such a move is possible, but would require  
> the node
> to leave the DAG, wait for a DAG Hop timer to elapse, and then re-
> attach at
> the lower point.  RPL would not allow this movement unless the DAG  
> parents
> of the node have failed, requiring the node to detach and re-attach  
> to the
> DAG.
>
>        In general, RPL is taking a conservative approach.  For a  
> node N,
> any node M such that depth(M)>depth(N) MAY be in the sub-DAG of
> node N.  Suppose that node N thought it could improve its metrics  
> through
> node M.  By detaching first, and waiting to observe node M to see  
> that node
> M remains attached to the DAG, node N may then determine that node M  
> is not
> part of its own sub-DAG and may safely re-attach at the lower point.  
> BUT if
> node N is wrong, then an instability has been created for no gain.
> For this reason, in its current specification, RPL does not allow a  
> node N
> to process and DIO from node M and detach from the DAG based on  
> information
> in the DIO from node M.  NOTE that this is in part a consequence of  
> the
> design consideration that not all nodes may be using the same  
> metrics and
> making the same optimizations.  For example, if all nodes in the  
> network
> were minimizing ETX, then node N may be mostly certain that any node
> M advertising a superior ETX is NOT in its own sub-DAG.
>
>        A further complication may come if node N and node M are  
> trying to
> make optimizations which are antagonistic to each other.  For  
> example, if
> node N where to try to move under node M, it could create a chain of  
> events
> whereby node M tried to reverse its position with respect to node M,  
> and a
> chain reaction of instability could result.  A simple example of  
> such a
> case would be where both nodes M and N have a common neighbor and  
> parent P,
> and nodes M and N subsequently each try to increase the size of their
> parent set to be 2.  (This case has been more thoroughly explained by
> Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1"  
> sent 30
> June 2009.)
>
>        RPL has nodes advertise a depth deeper than that of their  
> deepest
> DAG parent.  Consider an example where node X has parents of depth  
> {2, 7},
> and node Y chooses X as a parent.  Suppose that nodes then advertise  
> their
> `best' depth, i.e. node X advertises a depth of 3.  Then node Y will
> advertise a depth of 4.  Then suppose node Z adds node Y as a  
> parent, and
> advertises a depth of 5.  Now, Z can actually come to be a successor  
> of
> node X's depth 7 parent.  The result could be Z->Y->X->(cost 7
> parent)->(...)->Z and then there is a loop.  By advertising a depth  
> deeper
> that of its deepest parent, a node advertises its worst case  
> scenario, and
> in the worst case scenario a loop can be avoided.
>
>        RPL does not require that the DAG is invariant, rather that the
> movement of the node with respect to the DAG is coordinated in such  
> a way
> so as to avoid loops.  The thought is, whatever the topology,  
> uncoordinated
> movement in LLNs may increase overhead and churn and require more  
> reliance
> on expensive mechanisms such as count-to-infinity.
>
>        The use of depth (~ hop count) in RPL is not meant to trump  
> other
> metrics, but once a node has taken up a position in the DAG by using  
> its
> metrics the node acquires a depth, which then restricts the further  
> options
> that the node has in order to avoid loops.
>
>
>
> Regards,
>
> -Tim
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00722615862575EC_=-- From jvasseur@cisco.com Tue Jul 7 13:48:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00F83A6A8B for ; Tue, 7 Jul 2009 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9HMO1spwmjY for ; Tue, 7 Jul 2009 13:48:18 -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 2409A3A694A for ; Tue, 7 Jul 2009 13:48:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,364,1243814400"; d="scan'208";a="210693838" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2009 20:48:12 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67KmC4r015602; Tue, 7 Jul 2009 13:48:12 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n67KmCsX004048; Tue, 7 Jul 2009 20:48:12 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 16:48:12 -0400 Received: from [192.168.1.11] ([10.82.245.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 16:48:11 -0400 Message-Id: From: JP Vasseur To: Philip Levis 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 v935.3) Date: Tue, 7 Jul 2009 22:48:09 +0200 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07C04071@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Jul 2009 20:48:12.0009 (UTC) FILETIME=[3E042D90:01C9FF44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2212; t=1246999692; x=1247863692; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=YWj6o1g79Mt4f3j2/2TrODAQ354aj2u+QdYkTPgYezo=; b=jYb3FZ26YLdwVmoAh64faMUn4ytef94+woUP1dBhcKt+/E1WG1s2WsFs5H mEL9ZXWI2gzsN1FU6k60MMFh8N+vRJEQjXOhoX7dZa87EG700laSi2bS74Hj UY20XPmuv8; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:48:19 -0000 On Jul 7, 2009, at 6:59 PM, Philip Levis wrote: > > On Jul 7, 2009, at 5:21 AM, Pascal Thubert (pthubert) wrote: > >>> >>> On Jul 6, 2009, at 3:45 PM, Richard Kelsey wrote: >>>> Using a more precise metric produces fewer siblings, with >>>> the remainder being either 'ignored' or inward siblings. >>>> category. The net effect is to increase the number of >>>> neighbors that can be used to forward messages without >>>> creating into a loop, while decreasing the number that might >>>> create a loop. >>>> >>>> I don't have any idea which is likely to work better in >>>> practice. >>> >>> In the end we are saying the same things just in different words. A >>> less precise route cost produces more siblings and leaves more edges >>> undirected. A more precise route cost makes more edges directed. The >>> one that works better in practice depends on the density and >>> number of >>> feasible successors. In other words, if there are many edges to >>> choose >>> from - why not orient them and avoid loops altogether? In a sparse >>> network, you might want to leave them undirected to give greater >>> opportunity of routing around failures. >> >> I'd say that in dense networks the routers should have enough >> parents to >> choose from so they would never need the siblings or even keep >> track of >> them by lack of resources. So the coarse metric seems to obtain the >> desired result in both cases, use parents when there are enough of >> them, >> enable siblings in sparse conditions. > > Routing loops are only a problem if they persist, such that they > waste transmissions and lose packets. If the protocol can detect > loops and repair them on the order of a few packet times -- loops > are always transient -- they aren't a problem. It can be that all of > the mechanisms you put in place to avoid/prevent loops are more > expensive than simply detecting and repairing them. Excellent point and I fully agree ... this is true in most LLNs' application (not all but most). > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Tue Jul 7 18:19:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3293A696E for ; Tue, 7 Jul 2009 18:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg+awvWNiEBW for ; Tue, 7 Jul 2009 18:19:12 -0700 (PDT) Received: from fujitsu1.fujitsu.com (fujitsu1.fujitsu.com [192.240.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072413A6805 for ; Tue, 7 Jul 2009 18:18:56 -0700 (PDT) Received: from fujitsu1.fujitsu.com (localhost [127.0.0.1]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n681JKbl005040 for ; Tue, 7 Jul 2009 18:19:20 -0700 (PDT) Received: from mailserv1.fla.fujitsu.com (mailserv1.fla.fujitsu.com [128.8.244.161]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n681JKcl004996 for ; Tue, 7 Jul 2009 18:19:20 -0700 (PDT) Received: from [192.168.0.245] (ip68-110-239-10.dc.dc.cox.net [68.110.239.10]) (authenticated bits=0) by mailserv1.fla.fujitsu.com (8.13.8/8.13.8) with ESMTP id n681JGEV017111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 21:19:16 -0400 Message-ID: <4A53F413.7040802@us.fujitsu.com> Date: Tue, 07 Jul 2009 21:19:15 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:19:13 -0000 Dear ROLL WG, We, Fujitsu, have real experience of building an Ad-hoc network system with over 1000 nodes using proposed protocol, and we want to contribute to designing a new protocol within ROLL-WG. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ I asked ROLL-WG chairs to give us some presentation time for next IETF meeting. I hope we will have a good discussion. I would appreciate your comments. Thanks in advance and best regards, Sung Lee Fujitsu Laboratories of America, Inc roll-request@ietf.org wrote: > Message: 3 > Date: Mon, 6 Jul 2009 10:33:55 +0200 > From: JP Vasseur > Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt > To: ROLL WG > Message-ID: <141805D8-CBC0-4FDE-9CCD-07E24AE7E246@cisco.com> > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > At the agenda of the ROLL WG meeting. > > Begin forwarded message: > > >> From: Internet-Drafts@ietf.org >> Date: July 6, 2009 4:45:01 AM CEDT >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-iwao-roll-dadr-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Distributed Autonomous Depth-first Routing >> Protocol in LLN >> Author(s) : T. Iwao >> Filename : draft-iwao-roll-dadr-00.txt >> Pages : 24 >> Date : 2009-07-05 >> >> This document is a proposal of the distributed autonomous depth-first >> >> routing (DADR) protocol which is quite different from conventional >> >> algorithms such as AODV and OLSR. It proposes a traversable algorithm >> >> which can determine a direct path between the global source and the >> >> global destination in a low power and lossy network (LLN). We propose >> >> the DADR algorithm whose characteristics work well in LLNs with more >> >> than 10^4 nodes. This algorithm selects a direct path between the >> >> global source and the global destination based on a routing-cost- >> >> function which identifies path-candidates with good communication >> >> quality between each pair of nodes on the path. This protocol does >> >> not need to configure the equipment such as setting IP addresses, and >> >> thisresults in saving cost and time in deploying, establishing and >> >> operating a large scale network. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Iwao, et al. >> >> >> Expires January 2, 2010 >> >> >> >> >> [page 2] >> >> >> >> >> >> >> >> >> >> Internet-Draft >> >> >> >> DADR Protocol >> >> >> >> >> >> >> July 2009 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/plain
content-id: < > Size: 0 bytes > Desc: not available > Url : > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 18, Issue 26 > ************************************ > From Manhar.Goindi@landisgyr.com Tue Jul 7 22:07:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F181828C2C5 for ; Tue, 7 Jul 2009 22:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPobov8AvcGC for ; Tue, 7 Jul 2009 22:07:39 -0700 (PDT) Received: from mail.ap.landisgyr.com (mail.ap.landisgyr.com [61.8.13.202]) by core3.amsl.com (Postfix) with ESMTP id 6FF053A68BD for ; Tue, 7 Jul 2009 22:07:39 -0700 (PDT) Received: from mail pickup service by mail.ap.landisgyr.com with Microsoft SMTPSVC; Wed, 8 Jul 2009 15:08:05 +1000 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 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 Jul 2009 15:07:59 +1000 Message-ID: In-Reply-To: <4A53F413.7040802@us.fujitsu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt Thread-Index: Acn/ajM4mqW/+hakSi2d7Bb+T/IoKwAHcdbw References: <4A53F413.7040802@us.fujitsu.com> From: "Goindi, Manhar" To: "Sung Lee" , X-OriginalArrivalTime: 08 Jul 2009 05:08:05.0162 (UTC) FILETIME=[135420A0:01C9FF8A] Subject: Re: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 05:07:41 -0000 Hi, Thanks for sharing the DADR protocol. I have been able to scan through it & have some basic questions: 1. How is the path cost value computed? How does the originating node have the path cost value for the entire path? Is this done at the time of route discovery? 2. How does route discovery actually take place? Can it be illustrated with the help of Hello Messages? 3. How do we control the flooding of Hello messages as against the breadth-first search protocol? 4. What decides between Figure 1 & Figure 2 that time synchronization is successful? Does it carry any significance for the originator of Time Synchronization to be aware of the outcome of Time Synchronization initiated by it (I think it may not as time synchronization is quite a decentralized function)? 5. DFS mechanism depends on a Tree-like structure for route discovery. Is this what is being proposed for path information maintenance? Is there any concept of Parent, Sibling, Child, depth etc. between nodes? (The draft is very open and does not deal with any specific recommendation). Please let me know - if there is someplace I can find answers to these questions as this may still be evolving as a standard. Thanks & Best Regards, Manhar Goindi Manhar Goindi Technical Expert Landis+Gyr Phone: +91 120 3352149 manhar.goindi@landisgyr.com http://www.landisgyr.com/ Manage Energy Better -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Sung Lee Sent: Wednesday, July 08, 2009 6:49 AM To: roll@ietf.org Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt Dear ROLL WG, We, Fujitsu, have real experience of building an Ad-hoc network system with over 1000 nodes using proposed protocol, and we want to contribute to designing a new protocol within ROLL-WG. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ I asked ROLL-WG chairs to give us some presentation time for next IETF meeting. I hope we will have a good discussion. I would appreciate your comments. Thanks in advance and best regards, Sung Lee Fujitsu Laboratories of America, Inc =20 roll-request@ietf.org wrote: > Message: 3 > Date: Mon, 6 Jul 2009 10:33:55 +0200 > From: JP Vasseur > Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt > To: ROLL WG > Message-ID: <141805D8-CBC0-4FDE-9CCD-07E24AE7E246@cisco.com> > Content-Type: text/plain; charset=3D"us-ascii"; Format=3D"flowed"; > DelSp=3D"yes" > > At the agenda of the ROLL WG meeting. > > Begin forwarded message: > > =20 >> From: Internet-Drafts@ietf.org >> Date: July 6, 2009 4:45:01 AM CEDT >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-iwao-roll-dadr-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Distributed Autonomous Depth-first Routing >> Protocol in LLN >> Author(s) : T. Iwao >> Filename : draft-iwao-roll-dadr-00.txt >> Pages : 24 >> Date : 2009-07-05 >> >> This document is a proposal of the distributed autonomous depth-first >> >> routing (DADR) protocol which is quite different from conventional >> >> algorithms such as AODV and OLSR. It proposes a traversable algorithm >> >> which can determine a direct path between the global source and the >> >> global destination in a low power and lossy network (LLN). We propose >> >> the DADR algorithm whose characteristics work well in LLNs with more >> >> than 10^4 nodes. This algorithm selects a direct path between the >> >> global source and the global destination based on a routing-cost- >> >> function which identifies path-candidates with good communication >> >> quality between each pair of nodes on the path. This protocol does >> >> not need to configure the equipment such as setting IP addresses, and >> >> thisresults in saving cost and time in deploying, establishing and >> >> operating a large scale network. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Iwao, et al. >> >> >> Expires January 2, 2010 >> >> >> >> >> [page 2] >> >> >> >> >> >> >> >> >> >> Internet-Draft >> >> >> >> DADR Protocol >> >> >> >> >> >> >> July 2009 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> =20 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/plain
content-id: < > Size: 0 bytes > Desc: not available > Url : > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 18, Issue 26 > ************************************ > =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be = legally privileged. If you are not an intended recipient or an = authorized representative of an intended recipient, you are prohibited = from using, copying or distributing the information in this e-mail or = its attachments. If you have received this e-mail in error, please = notify the sender immediately by return e-mail and delete all copies of = this message and any attachments. Thank you. From alexandru.petrescu@gmail.com Wed Jul 8 03:15:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D08B3A6F19 for ; Wed, 8 Jul 2009 03:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 6ie6vyBvAASn for ; Wed, 8 Jul 2009 03:15:03 -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 9D59D3A6F15 for ; Wed, 8 Jul 2009 03:15:03 -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 n68A2IJP001264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jul 2009 12:02:18 +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 n68A2IMW005599; Wed, 8 Jul 2009 12:02:18 +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 n68A2Gbd008631; Wed, 8 Jul 2009 12:02:18 +0200 Message-ID: <4A546EA8.7000506@gmail.com> Date: Wed, 08 Jul 2009 12:02:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Philip Levis References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 10:15:05 -0000 Philip Levis a crit : > > On Jul 7, 2009, at 2:19 AM, Alexandru Petrescu wrote: > >> Philip Levis a crit : >>> On Jul 3, 2009, at 1:57 AM, Alexandru Petrescu wrote: >>>>> Richard, This seems like a totally reasonable metric to use, but >>>>> I'd be wary of saying it's *the* metric to use. Some >>>>> implementations are going to want to consider hopcount, others >>>>> won't. It's just another metric. Rather than hardwire hopcount >>>>> based assumptions into the protocol design, we should put it on >>>>> equal footing as other metrics. Correspondingly, the protocol >>>>> should have general, metric-independent mechanisms for detecting >>>>> and avoiding loops. >>>> Phil, what does 'loop' mean when metrics other than hopcount are >>>> used? What does a loop look like when e.g. ETX is used as metric? >>> If there's a loop in an ETX graph, then ETX does not monotonically >>> decrease along the route. This goes back to Jonathan's comment on >>> metric vectors. >> >> I personally haven't yet grasped the notion of a loop in terms of ETX >> (Expected Transmission count metric [De Couto 2003]). I do understand a >> loop in terms of the hop count metric. >> >> By your definition above it may seem that an ETX-loop appears when the >> ETX increases arbitrarily along a path. From this I think there may >> be loop-free paths (in terms of hopcount) which are ETX-loops. > > Have you read the CTP paper? It talks about this in depth. A loop *can* > occur when a metric that should monotonically decrease along a route > (hop count, ETX, etc.) doesn't do so due to inconsistencies in tables. Yes, I read the Collection Tree Protocol CTP paper at http://tinyos.net/tinyos-2.x/doc/txt/tep123.txt It indeed describes loops in terms of ETX. I have some doubts though. CTP addressing and 'routing' model seems different than IP addressing and routing. For example CTP doesn't use IP addresses, and considers that src and dst fields in packets are those of immediate neighbors, not further. CTP also considers a 'beacon' can be sent to the entire network. (I think many a source of confusion of the discussions here is from using terms such as routing/forwarding/loops mixing the expected meanings between networking and link-layer.) Routing and addressing at networking and link-layer are very different. Back to my remark, after reading the CTP paper I still have problems grasping the concept of an _IP_ loop in terms of ETX and of hopcount at the same time. Alex From alexandru.petrescu@gmail.com Wed Jul 8 04:03:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D2D28C53E for ; Wed, 8 Jul 2009 04:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 EhIpSGwi2Azg for ; Wed, 8 Jul 2009 04:03:14 -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 CA4773A694F for ; Wed, 8 Jul 2009 04:03:13 -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 n68B3XLU023384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jul 2009 13:03:33 +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 n68B3Xjc016079; Wed, 8 Jul 2009 13:03:33 +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 n68B3WCM024401; Wed, 8 Jul 2009 13:03:33 +0200 Message-ID: <4A547D04.6020403@gmail.com> Date: Wed, 08 Jul 2009 13:03:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Richard Kelsey References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07C04072@xmb-ams-337.emea.cisco.com> <8763e4wl82.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <8763e4wl82.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:03:15 -0000 Richard Kelsey a crit : > Hi Pascal, > >> Date: Tue, 7 Jul 2009 14:21:23 +0200 >> From: "Pascal Thubert (pthubert)" >> >> I do not follow your inward sibling idea. Being sibling is a symmetrical >> relationship. >> I am your siblings <=> you are my sibling. Inward is not like that so >> it's not siblings. >> What you could do instead is mask off the least significant M bits. > > You are correct that inward siblings and outward siblings > are not siblings. 'Siblings', 'inward siblings, and > 'outward siblings' are three disjoint sets of neighbors. > > For node N, its 'inward siblings' are nodes that whose cost > is less than N's but not enough less that N can use them as > parents. N's 'outward siblings' are neighbors whose costs > are greater than N's, but not enough greater that they can > be children of N. > > And yes, you could do instead is mask off the least > significant M bits, or, more generally, divide by some > constant. Which method is better depends on the > circumstants, including whether or not routing to siblings > may create a loop. > > -Richard Kelsey > > P.S. Strictly speaking, only nodes with the same parent are > siblings. Nodes at the same depth in a DAG are usually > called a 'level', I think, but that doesn't work as well > grammatically. 'Cousins' might be a better term for us than > 'siblings'. I agree to call 'siblings' only nodes having a same direct parent, in a tree (not DAG). I am used to it. Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Wed Jul 8 07:04:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768C03A696B for ; Wed, 8 Jul 2009 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.324 X-Spam-Level: X-Spam-Status: No, score=-8.324 tagged_above=-999 required=5 tests=[AWL=-1.769, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 wKTqRSnOKsOf for ; Wed, 8 Jul 2009 07:04:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 599703A6F72 for ; Wed, 8 Jul 2009 07:04:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,368,1243814400"; d="scan'208";a="183958999" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2009 14:03: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 n68E3IXL008346 for ; Wed, 8 Jul 2009 16:03: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.14.3) with ESMTP id n68E3I1r019229 for ; Wed, 8 Jul 2009 14:03: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); Wed, 8 Jul 2009 16:03:17 +0200 Received: from [192.168.1.11] ([10.61.66.190]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 16:03:17 +0200 Message-Id: <58337C66-4C85-4DE6-98AE-ACDE9457B626@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 12:02:15 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 08 Jul 2009 14:03:17.0462 (UTC) FILETIME=[D7C03F60:01C9FFD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=363; t=1247061798; x=1247925798; 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:=206LowApp=20Bar=20BOF |Sender:=20; bh=pZRJ97GxInDBh71+QP/RdY+o7FE9LMPeDZDIoDHohqY=; b=YAid9teMu0FXsWhDtGH0bZqOLUymlAtV1yDuS9C1y84Y/2/46uv3YQimOR pbtV5BkmWChp1ycAhTiEH0gnQsxfqBcs3/roGmFxZ3lSeLRJfs8uMhBOvvXI kCtlLC5h6y; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] 6LowApp Bar BOF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:04:26 -0000 Dear All, This is not related to ROLL but you may want to know about this Bar BOF - date and location will be announced on the Wiki, more than likely it will take place on Tuesday 6:30pm. Thanks to Carsten and Zach for the Wiki - Feel free to add your topics. http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp Thanks. JP. From richard.kelsey@ember.com Wed Jul 8 07:10:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181563A6AC2 for ; Wed, 8 Jul 2009 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 h5fuYZxnKDSA for ; Wed, 8 Jul 2009 07:10:23 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 272243A695C for ; Wed, 8 Jul 2009 07:10:23 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 10:08:58 -0400 Date: Wed, 08 Jul 2009 10:09:30 -0400 Message-Id: <87bpnvmfl1.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <0ED6CA3C-5C28-4BD4-98F2-BE088D85D48B@cisco.com> (message from JP Vasseur on Tue, 7 Jul 2009 15:30:24 +0200) From: Richard Kelsey References: <4A527EAA.4060603@acm.org> <0ED6CA3C-5C28-4BD4-98F2-BE088D85D48B@cisco.com> X-OriginalArrivalTime: 08 Jul 2009 14:08:59.0166 (UTC) FILETIME=[A36C23E0:01C9FFD5] Cc: roll@ietf.org Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:10:24 -0000 JP, From: JP Vasseur Date: Tue, 7 Jul 2009 15:30:24 +0200 Richard, don't you see the need for using several metrics? In this case, you may end up with nodes trying to optimize for different metrics ... Yes, I think we have to allow the use of different metrics. For networks that agree on a metric or set of metrics we should keep the loop avoidance from getting in the way more than necessary. For networks where different nodes are using different metrics we can supply a generic cost scaling that at allows related metrics to take advantage of their commonality. I think that using a DAGCost with three or four bits of fraction and with a minimal link cost of one works well in both cases. -Richard Kelsey From jvasseur@cisco.com Wed Jul 8 07:19:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7753A68DE; Wed, 8 Jul 2009 07:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 y9U5Ov3CJEW9; Wed, 8 Jul 2009 07:19:17 -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 AE4923A6944; Wed, 8 Jul 2009 07:19:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,369,1243814400"; d="scan'208,217";a="44663168" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2009 14:18:29 +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 n68EITHV003940; Wed, 8 Jul 2009 16:18: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.14.3) with ESMTP id n68EIT9q025122; Wed, 8 Jul 2009 14:18:29 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 16:18:29 +0200 Received: from [192.168.1.11] ([10.61.66.190]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 16:18:28 +0200 Message-Id: <26A25F70-2AB8-4D2F-80C4-B5BEF892D5A8@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-66-320050858 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 16:18:26 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 08 Jul 2009 14:18:28.0439 (UTC) FILETIME=[F6BC4E70:01C9FFD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=32953; t=1247062709; x=1247926709; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=hZz0uObHwEXUmXg3K1Ae+//c6XUOeWFGVzzjpGPa2QQ=; b=onuMn/eClfalm9n7wHxnpXpKQ+9Qk95yNS5MYvCxY818sw1Xz4HL+2nYSG VwWH6pEYV1t2tDRs61UR0QQlXt0+Q+GLSskJffJP2FknrWyrd5AVqJHYqxPR zgXjQEJd7H; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , Mukul Goyal , roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:19:21 -0000 --Apple-Mail-66-320050858 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Jul 7, 2009, at 10:46 PM, Jerald.P.Martocci@jci.com wrote: > > JP, > > > I agree with Mukal. > > If two or more nodes are all within radio proximity and hence > neighbors they should all be able to exchange messages amongst > themselves without needing to traverse the DAG. In the commercial > building environment this will happen in the equipment rooms. These > rooms are electromechanical rooms holding air handling, heating and > air conditioning equipment. There may me as many as 20 controllers > (routing devices), 20 sensors and 20 actuators (non-routing devices) > all in the same 500 sq ft room. The concept of finding candidate > parents and connecting into the DAG for this simple communication > seems to be overkill. > > I am only to page 41 of the draft and may be pleasantly surprised as > I read on; but the sense I have of the draft so far is it is > optimizing router efficiency of devices (i.e. no loops) while > ignoring the logical cohesion of many of the devices. Again, in a > commercial building there are hundreds of rooms. Each room is a > microcosm of the overall network (e.g occupancy, lights, heating/ > cooling, shade control). For the most part these devices are > completely independent of all the other rooms. They should be able > to communicate bidirectionally and freely amongst themselves with > minimal impact to the rest of the LLN. > > The DAG discovery and maintenance policies described in the draft > looks like each device positions itself on the DAG as best as it can > and then communicates as high up and then back down the DAG as > necessary to reach its intended destination. I would think this > would create an unbalanced network traffic where the higher layers > are unfairly taxed at forwarding uninteresting messages while the > lower layers are awaiting message delivery. As I mentioned in a > previous email, this architecture tends to make some devices more > important to the LLN than others which has negative fault tolerance > impact. > > My definition of 'Good P2P Routing' is that if a device has direct > radio contact with another device; these devices can pass messages > between themselves directly as needed. > Thanks for shedding some light on this important scenario. You are quite right that most focus has been given to P2MP/MP2P traffic patterns. In this scenario, the notion of sibling could help. Another alternative would be to first try to check neighbor reachability (nodes in direct neighborhood) before sending along the DAG. Still the DA may provide a non optimal path but optimal path from any point to any point required off-line path computation. How does this sound? Thanks. JP. > Regards, > > Jerry > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 07/07/2009 12:45 PM > > To > Mukul Goyal > cc > ROLL WG > Subject > Re: [Roll] Some clarifications on RPL > > > > > > Hi Mukul, > > On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote: > > > Tim > > > > Thanks for this explanation. I think most of this email should > > become part of RPL draft. > > > > I would like to convey the discomfort that many of us feel because > > RPL does not yet support a good P2P routing solution. Tree based P2P > > routing is not acceptable in many cases. We need to give this > > problem a high priority. > > > > The solution MUST of course support P2P and this is the case of RPL. > Now we need to define what we mean by "Good" P2P routing solution. As > of today RPL will branch the traffic as soon as the packet reaches a > node that has the destination address in its routing table pointing to > one of its children or sibling. This path may not be the most optimal > path indeed and may even be unacceptable. Furthermore it is > constrained by the shape of the DAG, which are dependent upon the > metrics used by nodes closer to the root. The question is to determine > how optimal should that path, and should we decide to adopt a routing > solution a la RPL, do we need to complement it with another mechanism > when optimal P2P path are required ? > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "Tim Winter" > > To: "ROLL WG" > > Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central > > Subject: [Roll] Some clarifications on RPL > > > > WG, > > > > Thanks to everyone for their feedback and comments to the RPL draft > > so far. > > There are some good threads here that will definitely help us to > > improve > > the RPL design- and there is no doubt more work to be done. I would > > like > > to make some clarifications that may be useful in discussing some of > > the > > common concerns so far: > > > > 1) Why a DAG? > > A dominant traffic flow in the requirements drafts is MP2P, > > flowing > > from the sensors inwards towards a sink, typically an LBR. The > design > > approach taken was to handle this case, use it to restrict the > routing > > problem, and then try to build support for P2MP, P2P, and other > > cases on > > top of it. A tree provides the simplest structure for supporting > > the MP2P > > flows, but a tree has many single points of failure along the edges > > from > > children to parents. A DAG, allowing each node to select and > maintain > > multiple successors in order to forward traffic inwards toward the > > root, > > offers the advantage of ready-to-use options. An implementation may > > then > > select from the successors as necessary, possibly in response to a > > temporary failure to forward to one parent, or a load balancing > > algorithm, > > or a short-term fluctuation in a link metric that leads the > forwarding > > engine to prefer one next hop over the other. > > > > 2) What about other flows? > > The DAG, and the orientation of the edges in the DAG, is used > > in > > routing the MP2P traffic towards the DAG root. The structure of the > > DAG is > > then used to restrict the complexity of the P2MP routing problem on > > the > > nodes. The Destination Advertisement mechanism lets a node set up > > routes > > in support of outward traffic flows, from the DAG root towards the > > leaf > > nodes in the LLN. The Destination Advertisement mechanism > distributes > > routing state inwards along the DAG, allowing nodes to learn routing > > state > > in support of the sub-DAGs below them. Nodes who are unable to > learn > > routing state pass the Destination Advertisements inward, building > up > > source routing information along the way so that they may be > traversed > > again on the outward flow. The exact implementation of source > > routing in > > support of this mechanism is not something that has been addressed > > by RPL > > as yet. > > > > Further, arbitrary P2P traffic can be supported by the DAG as > > is by > > sending traffic inwards along the DAG until a parent is encountered, > > who > > has stored routing state and is common to the source and destination > > of the > > traffic, who is able to direct the traffic towards the destination. > > > > RPL does not discuss any mechanisms to install more optimal > P2P > > routes, but nor does it preclude them, once the fundamentals have > been > > addressed we can have a look at such mechanism to more efficiently > > route > > `across' the DAG. > > > > 3) Metrics > > RPL allows for each node to select its set of DAG parents > > according > > to its own set of constraints, utilizing whatever subset of > metrics it > > requires to do so. The exact considerations and weighting can be > > implementation specific. > > > > A key design point, one that may need to be further > > constrained, is > > that under RPL each node does not assume that other nodes are acting > > cooperatively, or even that they are using or understand the same > > set of > > metrics. One node could be optimizing for latency, another node > > could be > > optimizing for ETX, and a third could be optimizing for > > minimum energy. This design point informs some of the loop > avoidance > > rules, such as the use of depth as a `common language'. > > > > Once a node as selected its DAG parents, according to > whatever > > metrics and constraints it chooses, then it has effectively taken > up a > > position in the DAG. It now has a best-case path to the DAG root, > > through > > its best parent, and a worst-case path to the DAG root, through its > > worst > > parent. Now, as a *consequence* of selecting parents according to > its > > metrics, the node has taken on a depth within the DAG. > > > > 4) Loop avoidance > > The DAG, and the nodes position within the DAG, are used in > > support > > of some loop avoidance rules. > > > > RPL always allows a node to move inwards along the DAG, > > towards the > > root. Moving inwards along the DAG has little chance of creating a > > loop; > > the node has only improved its position. Such a move would be based > > on > > receiving and processing DIOs with superior metrics from a node of a > > lesser > > depth in the DAG. > > > > RPL does not allow a node to move outwards along the DAG, > > increasing its depth. Such a move is possible, but would require > > the node > > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > > attach at > > the lower point. RPL would not allow this movement unless the DAG > > parents > > of the node have failed, requiring the node to detach and re-attach > > to the > > DAG. > > > > In general, RPL is taking a conservative approach. For a > > node N, > > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > > node N. Suppose that node N thought it could improve its metrics > > through > > node M. By detaching first, and waiting to observe node M to see > > that node > > M remains attached to the DAG, node N may then determine that node M > > is not > > part of its own sub-DAG and may safely re-attach at the lower point. > > BUT if > > node N is wrong, then an instability has been created for no gain. > > For this reason, in its current specification, RPL does not allow a > > node N > > to process and DIO from node M and detach from the DAG based on > > information > > in the DIO from node M. NOTE that this is in part a consequence of > > the > > design consideration that not all nodes may be using the same > > metrics and > > making the same optimizations. For example, if all nodes in the > > network > > were minimizing ETX, then node N may be mostly certain that any node > > M advertising a superior ETX is NOT in its own sub-DAG. > > > > A further complication may come if node N and node M are > > trying to > > make optimizations which are antagonistic to each other. For > > example, if > > node N where to try to move under node M, it could create a chain of > > events > > whereby node M tried to reverse its position with respect to node M, > > and a > > chain reaction of instability could result. A simple example of > > such a > > case would be where both nodes M and N have a common neighbor and > > parent P, > > and nodes M and N subsequently each try to increase the size of > their > > parent set to be 2. (This case has been more thoroughly explained > by > > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > > sent 30 > > June 2009.) > > > > RPL has nodes advertise a depth deeper than that of their > > deepest > > DAG parent. Consider an example where node X has parents of depth > > {2, 7}, > > and node Y chooses X as a parent. Suppose that nodes then advertise > > their > > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > > advertise a depth of 4. Then suppose node Z adds node Y as a > > parent, and > > advertises a depth of 5. Now, Z can actually come to be a successor > > of > > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > > parent)->(...)->Z and then there is a loop. By advertising a depth > > deeper > > that of its deepest parent, a node advertises its worst case > > scenario, and > > in the worst case scenario a loop can be avoided. > > > > RPL does not require that the DAG is invariant, rather that > the > > movement of the node with respect to the DAG is coordinated in such > > a way > > so as to avoid loops. The thought is, whatever the topology, > > uncoordinated > > movement in LLNs may increase overhead and churn and require more > > reliance > > on expensive mechanisms such as count-to-infinity. > > > > The use of depth (~ hop count) in RPL is not meant to trump > > other > > metrics, but once a node has taken up a position in the DAG by using > > its > > metrics the node acquires a depth, which then restricts the further > > options > > that the node has in order to avoid loops. > > > > > > > > Regards, > > > > -Tim > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-66-320050858 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Jul 7, 2009, at 10:46 PM, Jerald.P.Martocci@jci.com = wrote:


JP,
=

I agree with Mukal. =  

If two or = more nodes are all within radio proximity and hence neighbors they = should all be able to exchange messages amongst themselves without = needing to traverse the DAG.  In the commercial building = environment this will happen in the equipment rooms.  These rooms = are electromechanical rooms holding air handling, heating and air = conditioning equipment.  There may me as many as 20 controllers = (routing devices), 20 sensors and 20 actuators (non-routing devices) all = in the same 500 sq ft room.  The concept of finding candidate = parents and connecting into the DAG for this simple communication seems = to be overkill.

I = am only to page 41 of the draft and may be pleasantly surprised as I = read on; but the sense I have of the draft so far is it is optimizing = router efficiency of devices (i.e. no loops) while ignoring the logical = cohesion of many of the devices.  Again, in a commercial building = there are hundreds of rooms.  Each room is a microcosm of the = overall network (e.g occupancy, lights, heating/cooling, shade control). =  For the most part these devices are completely independent of all = the other rooms.  They should be able to communicate = bidirectionally and freely amongst themselves with minimal impact to the = rest of the LLN.  

The DAG discovery and maintenance policies described = in the draft looks like each device positions itself on the DAG as best = as it can and then communicates as high up and then back down the DAG as = necessary to reach its intended destination.  I would think this = would create an unbalanced network traffic where the higher layers are = unfairly taxed at forwarding uninteresting messages while the lower = layers are awaiting message delivery.  As I mentioned in a previous = email, this architecture tends to make some devices more important to = the LLN than others which has negative fault tolerance impact. =

My definition of 'Good P2P = Routing' is that if a device has direct radio contact with another = device; these devices can pass messages between themselves directly as = needed.


Thanks for = shedding some light on this important scenario. You are quite right that = most focus has been given to P2MP/MP2P traffic patterns. In this = scenario, the notion of sibling could help. Another alternative would be = to first try to check neighbor reachability (nodes in direct = neighborhood) before sending along the DAG. Still the DA may provide a = non optimal path but optimal path from any point to any point required = off-line path computation. How does this = sound?

Thanks.

JP.
=
Regards,

Jerry




JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">07/07/2009 12:45 PM =

To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Some clarifications on = RPL

=



Hi = Mukul,

On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote:

= > Tim
>
> Thanks for this explanation. I think most of = this email should  
> become part of RPL draft.
>
= > I would like to convey the discomfort that many of us feel because =  
> RPL does not yet support a good P2P routing solution. = Tree based P2P  
> routing is not acceptable in many cases. = We need to give this  
> problem a high priority.
= >

The solution MUST of course support P2P and this is the = case of RPL.  
Now we need to define what we mean by "Good" P2P = routing solution. As  
of today RPL will branch the traffic as = soon as the packet reaches a  
node that has the destination = address in its routing table pointing to  
one of its children = or sibling. This path may not be the most optimal  
path indeed = and may even be unacceptable. Furthermore it is  
constrained = by the shape of the DAG, which are dependent upon the  
metrics = used by nodes closer to the root. The question is to determine =  
how optimal should that path, and should we decide to adopt a = routing  
solution a la RPL, do we need to complement it with = another mechanism  
when optimal P2P path are required ?
=
Thanks.

JP.

> Thanks
> Mukul
= >
> ----- Original Message -----
> From: "Tim Winter" = <wintert@acm.org>
> = To: "ROLL WG" <roll@ietf.org>
> Sent: = Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central
> = Subject: [Roll] Some clarifications on RPL
>
> WG,
= >
> Thanks to everyone for their feedback and comments to the = RPL draft  
> so far.
> There are some good threads = here that will definitely help us to  
> improve
> = the RPL design- and there is no doubt more work to be done.  I = would  
> like
> to make some clarifications that may = be useful in discussing some of  
> the
> common = concerns so far:
>
> 1) Why a DAG?
>     =    A dominant traffic flow in the requirements drafts is MP2P, =  
> flowing
> from the sensors inwards towards a = sink, typically an LBR.  The design
> approach taken was to = handle this case, use it to restrict the routing
> problem, and = then try to build support for P2MP, P2P, and other  
> cases = on
> top of it.  A tree provides the simplest structure for = supporting  
> the MP2P
> flows, but a tree has many = single points of failure along the edges  
> from
> = children to parents.  A DAG, allowing each node to select and = maintain
> multiple successors in order to forward traffic = inwards toward the  
> root,
> offers the advantage = of ready-to-use options.  An implementation may  
> = then
> select from the successors as necessary, possibly in = response to a
> temporary failure to forward to one parent, or a = load balancing  
> algorithm,
> or a short-term = fluctuation in a link metric that leads the forwarding
> engine = to prefer one next hop over the other.
>
> 2) What about = other flows?
>        The DAG, and the = orientation of the edges in the DAG, is used  
> in
> = routing the MP2P traffic towards the DAG root.  The structure of = the  
> DAG is
> then used to restrict the complexity = of the P2MP routing problem on  
> the
> nodes. =  The Destination Advertisement mechanism lets a node set up =  
> routes
> in support of outward traffic flows, = from the DAG root towards the  
> leaf
> nodes in the = LLN.  The Destination Advertisement mechanism distributes
> = routing state inwards along the DAG, allowing nodes to learn routing =  
> state
> in support of the sub-DAGs below them. =  Nodes who are unable to learn
> routing state pass the = Destination Advertisements inward, building up
> source routing = information along the way so that they may be traversed
> again = on the outward flow.  The exact implementation of source  
= > routing in
> support of this mechanism is not something that = has been addressed  
> by RPL
> as yet.
>
= >        Further, arbitrary P2P traffic can be = supported by the DAG as  
> is by
> sending traffic = inwards along the DAG until a parent is encountered,  
> = who
> has stored routing state and is common to the source and = destination  
> of the
> traffic, who is able to = direct the traffic towards the destination.
>
>   =      RPL does not discuss any mechanisms to install more = optimal P2P
> routes, but nor does it preclude them, once the = fundamentals have been
> addressed we can have a look at such = mechanism to more efficiently  
> route
> `across' = the DAG.
>
> 3) Metrics
>       =  RPL allows for each node to select its set of DAG parents =  
> according
> to its own set of constraints, = utilizing whatever subset of metrics it
> requires to do so. =  The exact considerations and weighting can be
> = implementation specific.
>
>        A = key design point, one that may need to be further  
> = constrained, is
> that under RPL each node does not assume that = other nodes are acting
> cooperatively, or even that they are = using or understand the same  
> set of
> metrics. =  One node could be optimizing for latency, another node  
= > could be
> optimizing for ETX, and a third could be = optimizing for
> minimum energy.  This design point informs = some of the loop avoidance
> rules, such as the use of depth as a = `common language'.
>
>        Once a = node as selected its DAG parents, according to whatever
> metrics = and constraints it chooses, then it has effectively taken up a
> = position in the DAG.  It now has a best-case path to the DAG root, =  
> through
> its best parent, and a worst-case path = to the DAG root, through its  
> worst
> parent. =  Now, as a *consequence* of selecting parents according to its
= > metrics, the node has taken on a depth within the DAG.
>
= > 4) Loop avoidance
>        The DAG, and = the nodes position within the DAG, are used in  
> = support
> of some loop avoidance rules.
>
>   =      RPL always allows a node to move inwards along the = DAG,  
> towards the
> root.  Moving inwards = along the DAG has little chance of creating a  
> loop;
= > the node has only improved its position.  Such a move would be = based  
> on
> receiving and processing DIOs with = superior metrics from a node of a  
> lesser
> depth = in the DAG.
>
>        RPL does not = allow a node to move outwards along the DAG,
> increasing its = depth.  Such a move is possible, but would require  
> = the node
> to leave the DAG, wait for a DAG Hop timer to elapse, = and then re-
> attach at
> the lower point.  RPL = would not allow this movement unless the DAG  
> parents
= > of the node have failed, requiring the node to detach and re-attach =  
> to the
> DAG.
>
>     =    In general, RPL is taking a conservative approach. =  For a  
> node N,
> any node M such that = depth(M)>depth(N) MAY be in the sub-DAG of
> node N. =  Suppose that node N thought it could improve its metrics =  
> through
> node M.  By detaching first, and = waiting to observe node M to see  
> that node
> M = remains attached to the DAG, node N may then determine that node M =  
> is not
> part of its own sub-DAG and may safely = re-attach at the lower point.  
> BUT if
> node N is = wrong, then an instability has been created for no gain.
> For = this reason, in its current specification, RPL does not allow a =  
> node N
> to process and DIO from node M and = detach from the DAG based on  
> information
> in the = DIO from node M.  NOTE that this is in part a consequence of =  
> the
> design consideration that not all nodes may = be using the same  
> metrics and
> making the same = optimizations.  For example, if all nodes in the  
> = network
> were minimizing ETX, then node N may be mostly certain = that any node
> M advertising a superior ETX is NOT in its own = sub-DAG.
>
>        A further = complication may come if node N and node M are  
> trying = to
> make optimizations which are antagonistic to each other. =  For  
> example, if
> node N where to try to = move under node M, it could create a chain of  
> events
= > whereby node M tried to reverse its position with respect to node = M,  
> and a
> chain reaction of instability could = result.  A simple example of  
> such a
> case = would be where both nodes M and N have a common neighbor and  
= > parent P,
> and nodes M and N subsequently each try to = increase the size of their
> parent set to be 2.  (This case = has been more thoroughly explained by
> Pascal, see "Re: [Roll] = Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1"  
> sent 30
= > June 2009.)
>
>        RPL has = nodes advertise a depth deeper than that of their  
> = deepest
> DAG parent.  Consider an example where node X has = parents of depth  
> {2, 7},
> and node Y chooses X = as a parent.  Suppose that nodes then advertise  
> = their
> `best' depth, i.e. node X advertises a depth of 3. =  Then node Y will
> advertise a depth of 4.  Then = suppose node Z adds node Y as a  
> parent, and
> = advertises a depth of 5.  Now, Z can actually come to be a = successor  
> of
> node X's depth 7 parent.  The = result could be Z->Y->X->(cost 7
> = parent)->(...)->Z and then there is a loop.  By advertising a = depth  
> deeper
> that of its deepest parent, a node = advertises its worst case  
> scenario, and
> in the = worst case scenario a loop can be avoided.
>
>   =      RPL does not require that the DAG is invariant, = rather that the
> movement of the node with respect to the DAG is = coordinated in such  
> a way
> so as to avoid loops. =  The thought is, whatever the topology,  
> = uncoordinated
> movement in LLNs may increase overhead and churn = and require more  
> reliance
> on expensive = mechanisms such as count-to-infinity.
>
>     =    The use of depth (~ hop count) in RPL is not meant to trump =  
> other
> metrics, but once a node has taken up a = position in the DAG by using  
> its
> metrics the = node acquires a depth, which then restricts the further  
> = options
> that the node has in order to avoid loops.
>
= >
>
> Regards,
>
> -Tim
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-66-320050858-- From jvasseur@cisco.com Wed Jul 8 07:25:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E2F3A6967 for ; Wed, 8 Jul 2009 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tviqg9icQ3HS for ; Wed, 8 Jul 2009 07:25:15 -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 84E8D3A68DE for ; Wed, 8 Jul 2009 07:25:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,369,1243814400"; d="scan'208,217";a="44663594" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2009 14:24:51 +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 n68EOp3r006052; Wed, 8 Jul 2009 16:24:51 +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.14.3) with ESMTP id n68EOpUI027252; Wed, 8 Jul 2009 14:24:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 16:24:50 +0200 Received: from [192.168.1.11] ([10.61.66.190]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 16:24:49 +0200 Message-Id: <25C3CC8C-986D-4BAA-8E2B-E11208A10DA8@cisco.com> From: JP Vasseur To: quentin.lampin@orange-ftgroup.com In-Reply-To: <4A535093.1050807@orange-ftgroup.com> Content-Type: multipart/alternative; boundary=Apple-Mail-67-320431532 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 16:24:47 +0200 References: <4A4E32E3.90804@orange-ftgroup.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> <4A535093.1050807@orange-ftgroup.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 08 Jul 2009 14:24:49.0321 (UTC) FILETIME=[D9C24990:01C9FFD7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21904; t=1247063091; x=1247927091; 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[Roll]=20[RPL]About=20Nodes=20subscribi ng=20to=20multiple=20DAGs |Sender:=20; bh=BEKuVgWPu8CBMzVx6YZLSXRBiF+jLvZ0ZzkMbVAi1bo=; b=Z02xO32tomuQUIWxMZO3CyxwzmjR0RSGXEHQJ8tJ7zDfSWS11kKhkBjUOq AvHdp70ALQJd+2rx1yv5GxW9apZ9ZcyOltM3LTuUBG/jaQWGM7LF4bLY3oYP iJOOPuZ4o7; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:25:17 -0000 --Apple-Mail-67-320431532 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Quentin, On Jul 7, 2009, at 3:41 PM, quentin.lampin@orange-ftgroup.com wrote: > > > Pascal Thubert (pthubert) wrote: >> >> Salut Quentin: > Salut Pascal, >> >> >> If DAGs expose different prefixes then the longest match rule >> applies all the way to follow the graph that advertise that longest >> match prefix. You can use that to implement a power utility gateway >> that would get specific traffic but not default. > ok. >> >> >> If DAGs expose a same prefix (default) then packets must be tagged >> (colored) to indicate which one of the topologies they are supposed >> to follow, otherwise loops will occur (your point I guess). > If I understand well, in the case of multiple DAGs advertising the > same prefix, packet originators have to specify which DAG the > packets must follow. Right, similarly to what is done with MTR. > I also understand that the intention is to tailor DAGs to address > specific constraints/metrics so that it makes little sense, in > general, to forward packets accross DAGs. But I can see cases where > this would be useful. For example, when a node in a frozen sub-DAG > receives a packet tagged with this DAGID. If it's allowed, it could > decide, according to the advertised traffic class, to forward the > packet to another DAG such that the packet is not dropped. Yes, which is also an existing notion consisting of using a "default" DAG as a fall back option. But then you must not "re-color" the packet to avoid loops. > We could think of a per prefix "default" (kind of emergency) DAG. > A simple way to ensure loops avoidance would be to forbid nodes to > forward packets tagged "default" outside of the default DAG. Right. > Another (more generic and thus more powerful) way would be to add a > Hop by Hop option to the packet specifying visited DAGs and depths > of nodes which made the cross DAGs forward moves. Route Record option would be extremely expensive in term of overhead though. > Ensuring that a node cannot be re-forwarded to a node in a visited > DAG at a depth higher (deeper) or equal to the depth corresponding > to the visited DAG should be sufficient to avoid most probable loops. > Moreover, the last option would allow us to handle complex packet > constraints such as { Tdeliver < Tref (weight w1), Nhop < Nref > (weigth w2)}. A node receiving such a packet could evaluate if the > major constraint (higher weight) is likely to be respected and, in > this case, forward the packet accross another DAG to address the > other constraints. > This would permit to build "multi-dimensional" QoS based forwarding > engines. This can actually be achieved with the current RPL proposal ... that said, this brings several additional issues and complexity ... We probably need to evaluate if that requires such a level of complexity in practice. >> >> Finally, it is always possible to leave a topology to a strictly >> lower one, if you have structured your set of topologies as a tree. >> Like a default spanning topology would be the lowest (root) >> topology, and constrained control topologies would be the highest >> (leaves). > This is the start point of the last proposition ;) >> >> >> Will you be in Stockholm? > Unfortunately not, but Dominique Barthel will be there. You can > discuss about this with him. >> >> Pascal >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of quentin.lampin@orange-ftgroup.com >> Sent: vendredi 3 juillet 2009 18:34 >> To: roll@ietf.org >> Subject: [Roll] [RPL]About Nodes subscribing to multiple DAGs >> >> Hi everyone, >> >> RPL specifies that a node can subscribe to more than one DAG. >> Is it the intention to allow nodes to forward packets received from >> one DAG to another one? >> If so, is there any mechanism that we could think of to prevent >> cross-DAGS loops? >> If a packet arrives at a node which knows that the root is no >> longer reachable, forwarding accross DAGs might be useful... >> >> >> Thanks for your comments, >> >> Quentin Lampin >> > > Quentin > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-67-320431532 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Quentin,

On Jul 7, 2009, at 3:41 PM, quentin.lampin@orange-ft= group.com wrote:



Pascal Thubert (pthubert) wrote:
Salut = Quentin:
Salut Pascal,
If DAGs expose different prefixes then the longest = match rule applies all the way to follow the graph that advertise that = longest match prefix. You can use that to implement a power utility = gateway that would get specific traffic but not = default.
ok.
If DAGs expose a same prefix (default) then packets = must be tagged (colored) to indicate which one of the topologies they = are supposed to follow, otherwise loops will occur (your point I = guess).
If I understand well, in the case = of multiple DAGs advertising the same prefix, packet originators have to = specify which DAG the packets must follow. =

Right, similarly to what = is done with MTR.

I also understand that the intention is to tailor DAGs = to address specific constraints/metrics so that it makes little sense, = in general, to forward packets accross DAGs. But I can see cases where = this would be useful. For example, when a node in a frozen sub-DAG = receives a packet tagged with this DAGID. If  it's allowed, it = could decide, according to the advertised traffic class, to forward the = packet to another DAG such that the packet is not dropped. =

Yes, which is also an = existing notion consisting of using a "default" DAG as a fall back = option. But then you must not "re-color" the packet to avoid = loops.

We could think of a per prefix "default" (kind of = emergency) DAG.
A simple way to ensure loops avoidance would be to = forbid nodes to forward packets tagged "default" outside of the default = DAG.

Right.

Another (more generic and thus more powerful) way would = be to add a Hop by Hop option to the packet specifying visited DAGs and = depths of nodes  which made the cross DAGs forward moves. =

Route Record option would = be extremely expensive in term of overhead though.

Ensuring that a node cannot be re-forwarded to a node = in a visited DAG at a depth higher (deeper) or equal to the depth = corresponding to the visited DAG should be sufficient to avoid most = probable loops.
Moreover, the last option would allow us to handle = complex packet constraints such as { Tdeliver < Tref (weight w1), = Nhop < Nref (weigth w2)}. A node receiving such a packet could = evaluate if the major constraint (higher weight) is likely to be = respected and, in this case, forward the packet accross another DAG to = address the other constraints.
This would permit to build = "multi-dimensional" QoS based forwarding = engines.

This can actually = be achieved with the current RPL proposal ... that said, this brings = several additional issues and complexity ... We probably need to = evaluate if that requires such a level of complexity in = practice. 

Finally, it is always possible to leave a topology = to a strictly lower one, if you have structured your set of topologies = as a tree. Like a default spanning topology would be the lowest (root) = topology, and constrained control topologies would be the highest = (leaves).
This is the start point of the = last proposition ;)
Will you be in = Stockholm?
Unfortunately not, but = Dominique Barthel will be there. You can discuss about this with = him.
Pascal_______________________________________= ________
Roll mailing list
 07/08/2009 09:18 AM To Jerald.P.Martocci@jci.com cc ROLL WG , Mukul Goyal , roll-bounces@ietf.org, Ted.Humpal@jci.com Subject Re: [Roll] Some clarifications on RPL Hi Jerry, On Jul 7, 2009, at 10:46 PM, Jerald.P.Martocci@jci.com wrote: JP, I agree with Mukal. If two or more nodes are all within radio proximity and hence neighbors they should all be able to exchange messages amongst themselves without needing to traverse the DAG. In the commercial building environment this will happen in the equipment rooms. These rooms are electromechanical rooms holding air handling, heating and air conditioning equipment. There may me as many as 20 controllers (routing devices), 20 sensors and 20 actuators (non-routing devices) all in the same 500 sq ft room. The concept of finding candidate parents and connecting into the DAG for this simple communication seems to be overkill. I am only to page 41 of the draft and may be pleasantly surprised as I read on; but the sense I have of the draft so far is it is optimizing router efficiency of devices (i.e. no loops) while ignoring the logical cohesion of many of the devices. Again, in a commercial building there are hundreds of rooms. Each room is a microcosm of the overall network (e.g occupancy, lights, heating/cooling, shade control). For the most part these devices are completely independent of all the other rooms. They should be able to communicate bidirectionally and freely amongst themselves with minimal impact to the rest of the LLN. The DAG discovery and maintenance policies described in the draft looks like each device positions itself on the DAG as best as it can and then communicates as high up and then back down the DAG as necessary to reach its intended destination. I would think this would create an unbalanced network traffic where the higher layers are unfairly taxed at forwarding uninteresting messages while the lower layers are awaiting message delivery. As I mentioned in a previous email, this architecture tends to make some devices more important to the LLN than others which has negative fault tolerance impact. My definition of 'Good P2P Routing' is that if a device has direct radio contact with another device; these devices can pass messages between themselves directly as needed. Thanks for shedding some light on this important scenario. You are quite right that most focus has been given to P2MP/MP2P traffic patterns. In this scenario, the notion of sibling could help. Another alternative would be to first try to check neighbor reachability (nodes in direct neighborhood) before sending along the DAG. Still the DA may provide a non optimal path but optimal path from any point to any point required off-line path computation. How does this sound? Thanks. JP. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 07/07/2009 12:45 PM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Some clarifications on RPL Hi Mukul, On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote: > Tim > > Thanks for this explanation. I think most of this email should > become part of RPL draft. > > I would like to convey the discomfort that many of us feel because > RPL does not yet support a good P2P routing solution. Tree based P2P > routing is not acceptable in many cases. We need to give this > problem a high priority. > The solution MUST of course support P2P and this is the case of RPL. Now we need to define what we mean by "Good" P2P routing solution. As of today RPL will branch the traffic as soon as the packet reaches a node that has the destination address in its routing table pointing to one of its children or sibling. This path may not be the most optimal path indeed and may even be unacceptable. Furthermore it is constrained by the shape of the DAG, which are dependent upon the metrics used by nodes closer to the root. The question is to determine how optimal should that path, and should we decide to adopt a routing solution a la RPL, do we need to complement it with another mechanism when optimal P2P path are required ? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Tim Winter" > To: "ROLL WG" > Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central > Subject: [Roll] Some clarifications on RPL > > WG, > > Thanks to everyone for their feedback and comments to the RPL draft > so far. > There are some good threads here that will definitely help us to > improve > the RPL design- and there is no doubt more work to be done. I would > like > to make some clarifications that may be useful in discussing some of > the > common concerns so far: > > 1) Why a DAG? > A dominant traffic flow in the requirements drafts is MP2P, > flowing > from the sensors inwards towards a sink, typically an LBR. The design > approach taken was to handle this case, use it to restrict the routing > problem, and then try to build support for P2MP, P2P, and other > cases on > top of it. A tree provides the simplest structure for supporting > the MP2P > flows, but a tree has many single points of failure along the edges > from > children to parents. A DAG, allowing each node to select and maintain > multiple successors in order to forward traffic inwards toward the > root, > offers the advantage of ready-to-use options. An implementation may > then > select from the successors as necessary, possibly in response to a > temporary failure to forward to one parent, or a load balancing > algorithm, > or a short-term fluctuation in a link metric that leads the forwarding > engine to prefer one next hop over the other. > > 2) What about other flows? > The DAG, and the orientation of the edges in the DAG, is used > in > routing the MP2P traffic towards the DAG root. The structure of the > DAG is > then used to restrict the complexity of the P2MP routing problem on > the > nodes. The Destination Advertisement mechanism lets a node set up > routes > in support of outward traffic flows, from the DAG root towards the > leaf > nodes in the LLN. The Destination Advertisement mechanism distributes > routing state inwards along the DAG, allowing nodes to learn routing > state > in support of the sub-DAGs below them. Nodes who are unable to learn > routing state pass the Destination Advertisements inward, building up > source routing information along the way so that they may be traversed > again on the outward flow. The exact implementation of source > routing in > support of this mechanism is not something that has been addressed > by RPL > as yet. > > Further, arbitrary P2P traffic can be supported by the DAG as > is by > sending traffic inwards along the DAG until a parent is encountered, > who > has stored routing state and is common to the source and destination > of the > traffic, who is able to direct the traffic towards the destination. > > RPL does not discuss any mechanisms to install more optimal P2P > routes, but nor does it preclude them, once the fundamentals have been > addressed we can have a look at such mechanism to more efficiently > route > `across' the DAG. > > 3) Metrics > RPL allows for each node to select its set of DAG parents > according > to its own set of constraints, utilizing whatever subset of metrics it > requires to do so. The exact considerations and weighting can be > implementation specific. > > A key design point, one that may need to be further > constrained, is > that under RPL each node does not assume that other nodes are acting > cooperatively, or even that they are using or understand the same > set of > metrics. One node could be optimizing for latency, another node > could be > optimizing for ETX, and a third could be optimizing for > minimum energy. This design point informs some of the loop avoidance > rules, such as the use of depth as a `common language'. > > Once a node as selected its DAG parents, according to whatever > metrics and constraints it chooses, then it has effectively taken up a > position in the DAG. It now has a best-case path to the DAG root, > through > its best parent, and a worst-case path to the DAG root, through its > worst > parent. Now, as a *consequence* of selecting parents according to its > metrics, the node has taken on a depth within the DAG. > > 4) Loop avoidance > The DAG, and the nodes position within the DAG, are used in > support > of some loop avoidance rules. > > RPL always allows a node to move inwards along the DAG, > towards the > root. Moving inwards along the DAG has little chance of creating a > loop; > the node has only improved its position. Such a move would be based > on > receiving and processing DIOs with superior metrics from a node of a > lesser > depth in the DAG. > > RPL does not allow a node to move outwards along the DAG, > increasing its depth. Such a move is possible, but would require > the node > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > attach at > the lower point. RPL would not allow this movement unless the DAG > parents > of the node have failed, requiring the node to detach and re-attach > to the > DAG. > > In general, RPL is taking a conservative approach. For a > node N, > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > node N. Suppose that node N thought it could improve its metrics > through > node M. By detaching first, and waiting to observe node M to see > that node > M remains attached to the DAG, node N may then determine that node M > is not > part of its own sub-DAG and may safely re-attach at the lower point. > BUT if > node N is wrong, then an instability has been created for no gain. > For this reason, in its current specification, RPL does not allow a > node N > to process and DIO from node M and detach from the DAG based on > information > in the DIO from node M. NOTE that this is in part a consequence of > the > design consideration that not all nodes may be using the same > metrics and > making the same optimizations. For example, if all nodes in the > network > were minimizing ETX, then node N may be mostly certain that any node > M advertising a superior ETX is NOT in its own sub-DAG. > > A further complication may come if node N and node M are > trying to > make optimizations which are antagonistic to each other. For > example, if > node N where to try to move under node M, it could create a chain of > events > whereby node M tried to reverse its position with respect to node M, > and a > chain reaction of instability could result. A simple example of > such a > case would be where both nodes M and N have a common neighbor and > parent P, > and nodes M and N subsequently each try to increase the size of their > parent set to be 2. (This case has been more thoroughly explained by > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > sent 30 > June 2009.) > > RPL has nodes advertise a depth deeper than that of their > deepest > DAG parent. Consider an example where node X has parents of depth > {2, 7}, > and node Y chooses X as a parent. Suppose that nodes then advertise > their > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > advertise a depth of 4. Then suppose node Z adds node Y as a > parent, and > advertises a depth of 5. Now, Z can actually come to be a successor > of > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > parent)->(...)->Z and then there is a loop. By advertising a depth > deeper > that of its deepest parent, a node advertises its worst case > scenario, and > in the worst case scenario a loop can be avoided. > > RPL does not require that the DAG is invariant, rather that the > movement of the node with respect to the DAG is coordinated in such > a way > so as to avoid loops. The thought is, whatever the topology, > uncoordinated > movement in LLNs may increase overhead and churn and require more > reliance > on expensive mechanisms such as count-to-infinity. > > The use of depth (~ hop count) in RPL is not meant to trump > other > metrics, but once a node has taken up a position in the DAG by using > its > metrics the node acquires a depth, which then restricts the further > options > that the node has in order to avoid loops. > > > > Regards, > > -Tim > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0054B7AF862575ED_= Content-Type: text/html; charset="US-ASCII"


JP,

I'm not quite sure I understand the last phrase of the last sentence of your email ("but optimal path from any point to any point required off-line path computation"); but yes I think that first checking for direct radio communication  to a node (i.e. neighbors) and then using the DAG would allow isolated communication between neighbor nodes to proceed locally without affecting the overall traffic patterns of the LLN.  

Jerry





JP Vasseur <jvasseur@cisco.com>

07/08/2009 09:18 AM

To
Jerald.P.Martocci@jci.com
cc
ROLL WG <roll@ietf.org>, Mukul Goyal <mukul@UWM.EDU>, roll-bounces@ietf.org, Ted.Humpal@jci.com
Subject
Re: [Roll] Some clarifications on RPL





Hi Jerry,

On Jul 7, 2009, at 10:46 PM, Jerald.P.Martocci@jci.com wrote:


JP,


I agree with Mukal.  

If two or more nodes are all within radio proximity and hence neighbors they should all be able to exchange messages amongst themselves without needing to traverse the DAG.  In the commercial building environment this will happen in the equipment rooms.  These rooms are electromechanical rooms holding air handling, heating and air conditioning equipment.  There may me as many as 20 controllers (routing devices), 20 sensors and 20 actuators (non-routing devices) all in the same 500 sq ft room.  The concept of finding candidate parents and connecting into the DAG for this simple communication seems to be overkill.

I am only to page 41 of the draft and may be pleasantly surprised as I read on; but the sense I have of the draft so far is it is optimizing router efficiency of devices (i.e. no loops) while ignoring the logical cohesion of many of the devices.  Again, in a commercial building there are hundreds of rooms.  Each room is a microcosm of the overall network (e.g occupancy, lights, heating/cooling, shade control).  For the most part these devices are completely independent of all the other rooms.  They should be able to communicate bidirectionally and freely amongst themselves with minimal impact to the rest of the LLN.  

The DAG discovery and maintenance policies described in the draft looks like each device positions itself on the DAG as best as it can and then communicates as high up and then back down the DAG as necessary to reach its intended destination.  I would think this would create an unbalanced network traffic where the higher layers are unfairly taxed at forwarding uninteresting messages while the lower layers are awaiting message delivery.  As I mentioned in a previous email, this architecture tends to make some devices more important to the LLN than others which has negative fault tolerance impact.

My definition of 'Good P2P Routing' is that if a device has direct radio contact with another device; these devices can pass messages between themselves directly as needed.


Thanks for shedding some light on this important scenario. You are quite right that most focus has been given to P2MP/MP2P traffic patterns. In this scenario, the notion of sibling could help. Another alternative would be to first try to check neighbor reachability (nodes in direct neighborhood) before sending along the DAG. Still the DA may provide a non optimal path but optimal path from any point to any point required off-line path computation. How does this sound?

Thanks.

JP.

Regards,

Jerry



JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

07/07/2009 12:45 PM


To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Some clarifications on RPL







Hi Mukul,

On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote:

> Tim
>
> Thanks for this explanation. I think most of this email should  
> become part of RPL draft.
>
> I would like to convey the discomfort that many of us feel because  
> RPL does not yet support a good P2P routing solution. Tree based P2P  
> routing is not acceptable in many cases. We need to give this  
> problem a high priority.
>

The solution MUST of course support P2P and this is the case of RPL.  
Now we need to define what we mean by "Good" P2P routing solution. As  
of today RPL will branch the traffic as soon as the packet reaches a  
node that has the destination address in its routing table pointing to  
one of its children or sibling. This path may not be the most optimal  
path indeed and may even be unacceptable. Furthermore it is  
constrained by the shape of the DAG, which are dependent upon the  
metrics used by nodes closer to the root. The question is to determine  
how optimal should that path, and should we decide to adopt a routing  
solution a la RPL, do we need to complement it with another mechanism  
when optimal P2P path are required ?

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "Tim Winter" <wintert@acm.org>
> To: "ROLL WG" <roll@ietf.org>
> Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central
> Subject: [Roll] Some clarifications on RPL
>
> WG,
>
> Thanks to everyone for their feedback and comments to the RPL draft  
> so far.
> There are some good threads here that will definitely help us to  
> improve
> the RPL design- and there is no doubt more work to be done.  I would  
> like
> to make some clarifications that may be useful in discussing some of  
> the
> common concerns so far:
>
> 1) Why a DAG?
>        A dominant traffic flow in the requirements drafts is MP2P,  
> flowing
> from the sensors inwards towards a sink, typically an LBR.  The design
> approach taken was to handle this case, use it to restrict the routing
> problem, and then try to build support for P2MP, P2P, and other  
> cases on
> top of it.  A tree provides the simplest structure for supporting  
> the MP2P
> flows, but a tree has many single points of failure along the edges  
> from
> children to parents.  A DAG, allowing each node to select and maintain
> multiple successors in order to forward traffic inwards toward the  
> root,
> offers the advantage of ready-to-use options.  An implementation may  
> then
> select from the successors as necessary, possibly in response to a
> temporary failure to forward to one parent, or a load balancing  
> algorithm,
> or a short-term fluctuation in a link metric that leads the forwarding
> engine to prefer one next hop over the other.
>
> 2) What about other flows?
>        The DAG, and the orientation of the edges in the DAG, is used  
> in
> routing the MP2P traffic towards the DAG root.  The structure of the  
> DAG is
> then used to restrict the complexity of the P2MP routing problem on  
> the
> nodes.  The Destination Advertisement mechanism lets a node set up  
> routes
> in support of outward traffic flows, from the DAG root towards the  
> leaf
> nodes in the LLN.  The Destination Advertisement mechanism distributes
> routing state inwards along the DAG, allowing nodes to learn routing  
> state
> in support of the sub-DAGs below them.  Nodes who are unable to learn
> routing state pass the Destination Advertisements inward, building up
> source routing information along the way so that they may be traversed
> again on the outward flow.  The exact implementation of source  
> routing in
> support of this mechanism is not something that has been addressed  
> by RPL
> as yet.
>
>        Further, arbitrary P2P traffic can be supported by the DAG as  
> is by
> sending traffic inwards along the DAG until a parent is encountered,  
> who
> has stored routing state and is common to the source and destination  
> of the
> traffic, who is able to direct the traffic towards the destination.
>
>        RPL does not discuss any mechanisms to install more optimal P2P
> routes, but nor does it preclude them, once the fundamentals have been
> addressed we can have a look at such mechanism to more efficiently  
> route
> `across' the DAG.
>
> 3) Metrics
>        RPL allows for each node to select its set of DAG parents  
> according
> to its own set of constraints, utilizing whatever subset of metrics it
> requires to do so.  The exact considerations and weighting can be
> implementation specific.
>
>        A key design point, one that may need to be further  
> constrained, is
> that under RPL each node does not assume that other nodes are acting
> cooperatively, or even that they are using or understand the same  
> set of
> metrics.  One node could be optimizing for latency, another node  
> could be
> optimizing for ETX, and a third could be optimizing for
> minimum energy.  This design point informs some of the loop avoidance
> rules, such as the use of depth as a `common language'.
>
>        Once a node as selected its DAG parents, according to whatever
> metrics and constraints it chooses, then it has effectively taken up a
> position in the DAG.  It now has a best-case path to the DAG root,  
> through
> its best parent, and a worst-case path to the DAG root, through its  
> worst
> parent.  Now, as a *consequence* of selecting parents according to its
> metrics, the node has taken on a depth within the DAG.
>
> 4) Loop avoidance
>        The DAG, and the nodes position within the DAG, are used in  
> support
> of some loop avoidance rules.
>
>        RPL always allows a node to move inwards along the DAG,  
> towards the
> root.  Moving inwards along the DAG has little chance of creating a  
> loop;
> the node has only improved its position.  Such a move would be based  
> on
> receiving and processing DIOs with superior metrics from a node of a  
> lesser
> depth in the DAG.
>
>        RPL does not allow a node to move outwards along the DAG,
> increasing its depth.  Such a move is possible, but would require  
> the node
> to leave the DAG, wait for a DAG Hop timer to elapse, and then re-
> attach at
> the lower point.  RPL would not allow this movement unless the DAG  
> parents
> of the node have failed, requiring the node to detach and re-attach  
> to the
> DAG.
>
>        In general, RPL is taking a conservative approach.  For a  
> node N,
> any node M such that depth(M)>depth(N) MAY be in the sub-DAG of
> node N.  Suppose that node N thought it could improve its metrics  
> through
> node M.  By detaching first, and waiting to observe node M to see  
> that node
> M remains attached to the DAG, node N may then determine that node M  
> is not
> part of its own sub-DAG and may safely re-attach at the lower point.  
> BUT if
> node N is wrong, then an instability has been created for no gain.
> For this reason, in its current specification, RPL does not allow a  
> node N
> to process and DIO from node M and detach from the DAG based on  
> information
> in the DIO from node M.  NOTE that this is in part a consequence of  
> the
> design consideration that not all nodes may be using the same  
> metrics and
> making the same optimizations.  For example, if all nodes in the  
> network
> were minimizing ETX, then node N may be mostly certain that any node
> M advertising a superior ETX is NOT in its own sub-DAG.
>
>        A further complication may come if node N and node M are  
> trying to
> make optimizations which are antagonistic to each other.  For  
> example, if
> node N where to try to move under node M, it could create a chain of  
> events
> whereby node M tried to reverse its position with respect to node M,  
> and a
> chain reaction of instability could result.  A simple example of  
> such a
> case would be where both nodes M and N have a common neighbor and  
> parent P,
> and nodes M and N subsequently each try to increase the size of their
> parent set to be 2.  (This case has been more thoroughly explained by
> Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1"  
> sent 30
> June 2009.)
>
>        RPL has nodes advertise a depth deeper than that of their  
> deepest
> DAG parent.  Consider an example where node X has parents of depth  
> {2, 7},
> and node Y chooses X as a parent.  Suppose that nodes then advertise  
> their
> `best' depth, i.e. node X advertises a depth of 3.  Then node Y will
> advertise a depth of 4.  Then suppose node Z adds node Y as a  
> parent, and
> advertises a depth of 5.  Now, Z can actually come to be a successor  
> of
> node X's depth 7 parent.  The result could be Z->Y->X->(cost 7
> parent)->(...)->Z and then there is a loop.  By advertising a depth  
> deeper
> that of its deepest parent, a node advertises its worst case  
> scenario, and
> in the worst case scenario a loop can be avoided.
>
>        RPL does not require that the DAG is invariant, rather that the
> movement of the node with respect to the DAG is coordinated in such  
> a way
> so as to avoid loops.  The thought is, whatever the topology,  
> uncoordinated
> movement in LLNs may increase overhead and churn and require more  
> reliance
> on expensive mechanisms such as count-to-infinity.
>
>        The use of depth (~ hop count) in RPL is not meant to trump  
> other
> metrics, but once a node has taken up a position in the DAG by using  
> its
> metrics the node acquires a depth, which then restricts the further  
> options
> that the node has in order to avoid loops.
>
>
>
> Regards,
>
> -Tim
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--=_alternative 0054B7AF862575ED_=-- From philip.levis@gmail.com Wed Jul 8 10:05:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726D43A691A for ; Wed, 8 Jul 2009 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7xZhr+cc5ZK for ; Wed, 8 Jul 2009 10:05:25 -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 273103A67A1 for ; Wed, 8 Jul 2009 10:05:25 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1207342rvb.5 for ; Wed, 08 Jul 2009 10:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=vjYM2Ht8uslnSLgWC3FMcWw7NeOPDlOHATjWym+GLv8=; b=Ni44dKAHrBN0OJhJL4DZPfSwUyBUWa2OvghHTmjFxmYj0DZqQs0WCgHn0Sy3GjR/tk 0JIyoKVt6/ODyTHdnKZN/LaMN4VwyotRmqqb1Bxovl0pZutHiDXcfcMTiR61BErNkSzs G/udcthP5aW7EqJoVkcjAHUj01fza+/ePHIeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=DMJzB2RF3shqVFE+LGUpuRfHNDBdCThzBEJo3vFCfBLtA4KDdbOiGtAnVNvpgf5E9+ VDpBtZz+xuYlQ65jgH38IBhoAorS0FAGPPGcBNqMaRXj82huaHubk7fkGv2lDljcP1Fv 2QSsWX3rh5mOiFs3PTphwc94/y1e6+1t5zcLo= Received: by 10.140.171.15 with SMTP id t15mr3970514rve.134.1247072748720; Wed, 08 Jul 2009 10:05:48 -0700 (PDT) Received: from ?192.168.1.101? ([76.14.71.8]) by mx.google.com with ESMTPS id k2sm10502975rvb.2.2009.07.08.10.05.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 10:05:46 -0700 (PDT) Message-Id: <8142BFBB-A593-4AA4-9D20-2D0B788CADD2@gmail.com> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4A546EA8.7000506@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 10:05:43 -0700 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> <4A546EA8.7000506@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:05:30 -0000 On Jul 8, 2009, at 3:02 AM, Alexandru Petrescu wrote: > > Yes, I read the Collection Tree Protocol CTP paper at http://tinyos.net/tinyos-2.x/doc/txt/tep123.txt > It indeed describes loops in terms of ETX. That's the specification. This is the paper: http://sing.stanford.edu/pubs/sing-09-01.pdf > Back to my remark, after reading the CTP paper I still have problems > grasping the concept of an _IP_ loop in terms of ETX and of hopcount > at the same time. Both hopcount and ETX define a gradient to a destination. In both cases, the value of the destination is 0. In the case of hopcount, the gradient decreases by 1 on each hop. So a route (source, X, Y, Z, destination) looks like this: Source (4) -> X (3) -> Y (2) -> Z (1) -> Destination (0) In the case of ETX, the gradient decreases by >=1 on each hop. So a route (source, X, Y, Z, destination) could look like this: Source (6.4) -> X (5.1) -> Y (3.3) -> Z (1.8) -> Destination (0) In both cases, a loop can exist if and only if the gradient value does not decrease across a hop. If the gradient value decreases monotonically, it will reach zero and there is no loop. But here's a possible loop: Case A: Source (3) -> X (2) -> Y (3) -> X (2) -> Y (3) or Case B: Source (3) -> X (2) -> Y (2) -> X (2) These can occur when a node changes its route and updates its gradient value but its children have not yet learned the new value. E.g., the link between Y and Z breaks, leading to case A, where Y's best choice for a next hop is X. Phil From jvasseur@cisco.com Thu Jul 9 07:33:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C8328C150 for ; Thu, 9 Jul 2009 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 Nhd5YjYCHyIK for ; Thu, 9 Jul 2009 07:33:31 -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 520613A683A for ; Thu, 9 Jul 2009 07:33:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208";a="44756068" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2009 14:33:59 +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 n69EXxXV031908; Thu, 9 Jul 2009 16:33:59 +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.14.3) with ESMTP id n69EXwYj016866; Thu, 9 Jul 2009 14:33:59 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); Thu, 9 Jul 2009 16:33:58 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 16:33:58 +0200 Message-Id: <71002404-9343-4A63-8C29-B0D683BC8CF0@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <8142BFBB-A593-4AA4-9D20-2D0B788CADD2@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 08:38:36 +0200 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> <4A546EA8.7000506@gmail.com> <8142BFBB-A593-4AA4-9D20-2D0B788CADD2@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 14:33:58.0597 (UTC) FILETIME=[4B90E750:01CA00A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2137; t=1247150039; x=1248014039; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20the=20root? |Sender:=20; bh=iJ2W6iRIcuj1/5qGYcU4gp+c8vaLh2OwHHTnLl6B6a8=; b=a4mbZsDIAADCro2YDA8hw0xVWjynU9Aa2HHkDCWFv8tqTF152VxioaaKKG cJUH23AZOZyiP/sZj/KbzH8EG66shetWD9mb4mXUXS1oFeVNStecTyNVfpDW CVRhl8xBHM; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:33:33 -0000 On Jul 8, 2009, at 7:05 PM, Philip Levis wrote: > > On Jul 8, 2009, at 3:02 AM, Alexandru Petrescu wrote: > >> >> Yes, I read the Collection Tree Protocol CTP paper at http://tinyos.net/tinyos-2.x/doc/txt/tep123.txt >> It indeed describes loops in terms of ETX. > > That's the specification. This is the paper: > > http://sing.stanford.edu/pubs/sing-09-01.pdf > >> Back to my remark, after reading the CTP paper I still have >> problems grasping the concept of an _IP_ loop in terms of ETX and >> of hopcount at the same time. > > Both hopcount and ETX define a gradient to a destination. In both > cases, the value of the destination is 0. In the case of hopcount, > the gradient decreases by 1 on each hop. So a route (source, X, Y, > Z, destination) looks like this: > > Source (4) -> X (3) -> Y (2) -> Z (1) -> Destination (0) > > In the case of ETX, the gradient decreases by >=1 on each hop. So a > route (source, X, Y, Z, destination) could look like this: > > Source (6.4) -> X (5.1) -> Y (3.3) -> Z (1.8) -> Destination (0) > > In both cases, a loop can exist if and only if the gradient value > does not decrease across a hop. If the gradient value decreases > monotonically, it will reach zero and there is no loop. But here's a > possible loop: > > Case A: Source (3) -> X (2) -> Y (3) -> X (2) -> Y (3) > > or > > Case B: Source (3) -> X (2) -> Y (2) -> X (2) > > These can occur when a node changes its route and updates its > gradient value but its children have not yet learned the new value. > E.g., the link between Y and Z breaks, leading to case A, where Y's > best choice for a next hop is X. But the loop is transient. Note that the exact same situation exist with link state protocol, we call it a micro-loop since it is quickly resolve but time scale are different and although loop duration may be much shorter, the number of impacted packets may be much larger. Cheers. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 9 07:33:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB28028C150; Thu, 9 Jul 2009 07:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, 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 r-S+KN0IyT0v; Thu, 9 Jul 2009 07:33:31 -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 23FA23A67FD; Thu, 9 Jul 2009 07:33:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208,217";a="44756063" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2009 14:33:55 +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 n69EXtA8022133; Thu, 9 Jul 2009 16:33:55 +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.14.3) with ESMTP id n69EXtZs016850; Thu, 9 Jul 2009 14:33:55 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); Thu, 9 Jul 2009 16:33:55 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 16:33:54 +0200 Message-Id: From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-89-378419021 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 08:31:14 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 14:33:54.0863 (UTC) FILETIME=[495723F0:01CA00A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39808; t=1247150035; x=1248014035; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=16v9h6l2lj0kFLqfR2Q8Cj2oVtK3bsJ35Wb7R7Zd1Jk=; b=lWFX5/8claaG1LFpFMSTZgH+5zySkdT0jLZZVCuSW8xrPaf3Ja64nRHWTh QBqQyTzlbv2PJVG7QaCN+Idh4A9NRyJy2WZ0BrtW7M8gWzo0Qo9SN9fnGLTD 0l0icMENwc; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , Mukul Goyal , roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:33:33 -0000 --Apple-Mail-89-378419021 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Jul 8, 2009, at 5:25 PM, Jerald.P.Martocci@jci.com wrote: > > > > JP, > > I'm not quite sure I understand the last phrase of the last sentence > of your email ("but optimal path from any point to any point > required off-line path computation"); I meant to say that a distributed DV protocol will always lead to areas of sub-optimality. One approach could consist of relying on RPL to build connectivity and augment it with a PCE-based approach whereby more optimal would be built by the path computation engine (off-line path computation) having a global view of the system (thanks to topology acquisition using a mechanism similar to what HYDRO proposed since by contrast with other PCE-based approach running the link state routing protocol, we would need a topology acquisition mechanism). We can discuss such an option later on. PCE-based architecture are now very well understood, we have been working on them for several years in the PCE WG (see RFC4655 for architecture) > but yes I think that first checking for direct radio communication > to a node (i.e. neighbors) and then using the DAG would allow > isolated communication between neighbor nodes to proceed locally > without affecting the overall traffic patterns of the LLN. > Excellent. Cheers. JP. > Jerry > > > > > > JP Vasseur > 07/08/2009 09:18 AM > > To > Jerald.P.Martocci@jci.com > cc > ROLL WG , Mukul Goyal , roll-bounces@ietf.org > , Ted.Humpal@jci.com > Subject > Re: [Roll] Some clarifications on RPL > > > > > > Hi Jerry, > > On Jul 7, 2009, at 10:46 PM, Jerald.P.Martocci@jci.com wrote: > > > JP, > > > I agree with Mukal. > > If two or more nodes are all within radio proximity and hence > neighbors they should all be able to exchange messages amongst > themselves without needing to traverse the DAG. In the commercial > building environment this will happen in the equipment rooms. These > rooms are electromechanical rooms holding air handling, heating and > air conditioning equipment. There may me as many as 20 controllers > (routing devices), 20 sensors and 20 actuators (non-routing devices) > all in the same 500 sq ft room. The concept of finding candidate > parents and connecting into the DAG for this simple communication > seems to be overkill. > > I am only to page 41 of the draft and may be pleasantly surprised as > I read on; but the sense I have of the draft so far is it is > optimizing router efficiency of devices (i.e. no loops) while > ignoring the logical cohesion of many of the devices. Again, in a > commercial building there are hundreds of rooms. Each room is a > microcosm of the overall network (e.g occupancy, lights, heating/ > cooling, shade control). For the most part these devices are > completely independent of all the other rooms. They should be able > to communicate bidirectionally and freely amongst themselves with > minimal impact to the rest of the LLN. > > The DAG discovery and maintenance policies described in the draft > looks like each device positions itself on the DAG as best as it can > and then communicates as high up and then back down the DAG as > necessary to reach its intended destination. I would think this > would create an unbalanced network traffic where the higher layers > are unfairly taxed at forwarding uninteresting messages while the > lower layers are awaiting message delivery. As I mentioned in a > previous email, this architecture tends to make some devices more > important to the LLN than others which has negative fault tolerance > impact. > > My definition of 'Good P2P Routing' is that if a device has direct > radio contact with another device; these devices can pass messages > between themselves directly as needed. > > > Thanks for shedding some light on this important scenario. You are > quite right that most focus has been given to P2MP/MP2P traffic > patterns. In this scenario, the notion of sibling could help. > Another alternative would be to first try to check neighbor > reachability (nodes in direct neighborhood) before sending along the > DAG. Still the DA may provide a non optimal path but optimal path > from any point to any point required off-line path computation. How > does this sound? > > Thanks. > > JP. > > Regards, > > Jerry > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 07/07/2009 12:45 PM > > > To > Mukul Goyal > cc > ROLL WG > Subject > Re: [Roll] Some clarifications on RPL > > > > > > > > Hi Mukul, > > On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote: > > > Tim > > > > Thanks for this explanation. I think most of this email should > > become part of RPL draft. > > > > I would like to convey the discomfort that many of us feel because > > RPL does not yet support a good P2P routing solution. Tree based P2P > > routing is not acceptable in many cases. We need to give this > > problem a high priority. > > > > The solution MUST of course support P2P and this is the case of RPL. > Now we need to define what we mean by "Good" P2P routing solution. As > of today RPL will branch the traffic as soon as the packet reaches a > node that has the destination address in its routing table pointing to > one of its children or sibling. This path may not be the most optimal > path indeed and may even be unacceptable. Furthermore it is > constrained by the shape of the DAG, which are dependent upon the > metrics used by nodes closer to the root. The question is to determine > how optimal should that path, and should we decide to adopt a routing > solution a la RPL, do we need to complement it with another mechanism > when optimal P2P path are required ? > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "Tim Winter" > > To: "ROLL WG" > > Sent: Sunday, July 5, 2009 5:52:07 PM GMT -06:00 US/Canada Central > > Subject: [Roll] Some clarifications on RPL > > > > WG, > > > > Thanks to everyone for their feedback and comments to the RPL draft > > so far. > > There are some good threads here that will definitely help us to > > improve > > the RPL design- and there is no doubt more work to be done. I would > > like > > to make some clarifications that may be useful in discussing some of > > the > > common concerns so far: > > > > 1) Why a DAG? > > A dominant traffic flow in the requirements drafts is MP2P, > > flowing > > from the sensors inwards towards a sink, typically an LBR. The > design > > approach taken was to handle this case, use it to restrict the > routing > > problem, and then try to build support for P2MP, P2P, and other > > cases on > > top of it. A tree provides the simplest structure for supporting > > the MP2P > > flows, but a tree has many single points of failure along the edges > > from > > children to parents. A DAG, allowing each node to select and > maintain > > multiple successors in order to forward traffic inwards toward the > > root, > > offers the advantage of ready-to-use options. An implementation may > > then > > select from the successors as necessary, possibly in response to a > > temporary failure to forward to one parent, or a load balancing > > algorithm, > > or a short-term fluctuation in a link metric that leads the > forwarding > > engine to prefer one next hop over the other. > > > > 2) What about other flows? > > The DAG, and the orientation of the edges in the DAG, is used > > in > > routing the MP2P traffic towards the DAG root. The structure of the > > DAG is > > then used to restrict the complexity of the P2MP routing problem on > > the > > nodes. The Destination Advertisement mechanism lets a node set up > > routes > > in support of outward traffic flows, from the DAG root towards the > > leaf > > nodes in the LLN. The Destination Advertisement mechanism > distributes > > routing state inwards along the DAG, allowing nodes to learn routing > > state > > in support of the sub-DAGs below them. Nodes who are unable to > learn > > routing state pass the Destination Advertisements inward, building > up > > source routing information along the way so that they may be > traversed > > again on the outward flow. The exact implementation of source > > routing in > > support of this mechanism is not something that has been addressed > > by RPL > > as yet. > > > > Further, arbitrary P2P traffic can be supported by the DAG as > > is by > > sending traffic inwards along the DAG until a parent is encountered, > > who > > has stored routing state and is common to the source and destination > > of the > > traffic, who is able to direct the traffic towards the destination. > > > > RPL does not discuss any mechanisms to install more optimal > P2P > > routes, but nor does it preclude them, once the fundamentals have > been > > addressed we can have a look at such mechanism to more efficiently > > route > > `across' the DAG. > > > > 3) Metrics > > RPL allows for each node to select its set of DAG parents > > according > > to its own set of constraints, utilizing whatever subset of > metrics it > > requires to do so. The exact considerations and weighting can be > > implementation specific. > > > > A key design point, one that may need to be further > > constrained, is > > that under RPL each node does not assume that other nodes are acting > > cooperatively, or even that they are using or understand the same > > set of > > metrics. One node could be optimizing for latency, another node > > could be > > optimizing for ETX, and a third could be optimizing for > > minimum energy. This design point informs some of the loop > avoidance > > rules, such as the use of depth as a `common language'. > > > > Once a node as selected its DAG parents, according to > whatever > > metrics and constraints it chooses, then it has effectively taken > up a > > position in the DAG. It now has a best-case path to the DAG root, > > through > > its best parent, and a worst-case path to the DAG root, through its > > worst > > parent. Now, as a *consequence* of selecting parents according to > its > > metrics, the node has taken on a depth within the DAG. > > > > 4) Loop avoidance > > The DAG, and the nodes position within the DAG, are used in > > support > > of some loop avoidance rules. > > > > RPL always allows a node to move inwards along the DAG, > > towards the > > root. Moving inwards along the DAG has little chance of creating a > > loop; > > the node has only improved its position. Such a move would be based > > on > > receiving and processing DIOs with superior metrics from a node of a > > lesser > > depth in the DAG. > > > > RPL does not allow a node to move outwards along the DAG, > > increasing its depth. Such a move is possible, but would require > > the node > > to leave the DAG, wait for a DAG Hop timer to elapse, and then re- > > attach at > > the lower point. RPL would not allow this movement unless the DAG > > parents > > of the node have failed, requiring the node to detach and re-attach > > to the > > DAG. > > > > In general, RPL is taking a conservative approach. For a > > node N, > > any node M such that depth(M)>depth(N) MAY be in the sub-DAG of > > node N. Suppose that node N thought it could improve its metrics > > through > > node M. By detaching first, and waiting to observe node M to see > > that node > > M remains attached to the DAG, node N may then determine that node M > > is not > > part of its own sub-DAG and may safely re-attach at the lower point. > > BUT if > > node N is wrong, then an instability has been created for no gain. > > For this reason, in its current specification, RPL does not allow a > > node N > > to process and DIO from node M and detach from the DAG based on > > information > > in the DIO from node M. NOTE that this is in part a consequence of > > the > > design consideration that not all nodes may be using the same > > metrics and > > making the same optimizations. For example, if all nodes in the > > network > > were minimizing ETX, then node N may be mostly certain that any node > > M advertising a superior ETX is NOT in its own sub-DAG. > > > > A further complication may come if node N and node M are > > trying to > > make optimizations which are antagonistic to each other. For > > example, if > > node N where to try to move under node M, it could create a chain of > > events > > whereby node M tried to reverse its position with respect to node M, > > and a > > chain reaction of instability could result. A simple example of > > such a > > case would be where both nodes M and N have a common neighbor and > > parent P, > > and nodes M and N subsequently each try to increase the size of > their > > parent set to be 2. (This case has been more thoroughly explained > by > > Pascal, see "Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1" > > sent 30 > > June 2009.) > > > > RPL has nodes advertise a depth deeper than that of their > > deepest > > DAG parent. Consider an example where node X has parents of depth > > {2, 7}, > > and node Y chooses X as a parent. Suppose that nodes then advertise > > their > > `best' depth, i.e. node X advertises a depth of 3. Then node Y will > > advertise a depth of 4. Then suppose node Z adds node Y as a > > parent, and > > advertises a depth of 5. Now, Z can actually come to be a successor > > of > > node X's depth 7 parent. The result could be Z->Y->X->(cost 7 > > parent)->(...)->Z and then there is a loop. By advertising a depth > > deeper > > that of its deepest parent, a node advertises its worst case > > scenario, and > > in the worst case scenario a loop can be avoided. > > > > RPL does not require that the DAG is invariant, rather that > the > > movement of the node with respect to the DAG is coordinated in such > > a way > > so as to avoid loops. The thought is, whatever the topology, > > uncoordinated > > movement in LLNs may increase overhead and churn and require more > > reliance > > on expensive mechanisms such as count-to-infinity. > > > > The use of depth (~ hop count) in RPL is not meant to trump > > other > > metrics, but once a node has taken up a position in the DAG by using > > its > > metrics the node acquires a depth, which then restricts the further > > options > > that the node has in order to avoid loops. > > > > > > > > Regards, > > > > -Tim > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-89-378419021 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Jul 8, 2009, at 5:25 PM, Jerald.P.Martocci@jci.com = wrote:



 =
JP,

I'm not quite sure I understand the last = phrase of the last sentence of your email ("but= optimal path from any point to any point required off-line path = computation");

I meant to = say that a distributed DV protocol will always lead to areas of = sub-optimality. One approach could consist of relying on RPL to build = connectivity and augment it with a PCE-based approach whereby more = optimal would be built by the path computation engine (off-line path = computation) having a global view of the system (thanks to topology = acquisition using a mechanism similar to what HYDRO proposed since by = contrast with other PCE-based approach running the link state routing = protocol, we would need a topology acquisition mechanism). We can = discuss such an option later on. PCE-based architecture are now very = well understood, we have been working on them for several years in the = PCE WG (see RFC4655 for architecture)

but yes I think that first checking for = direct radio communication  to a node (i.e. neighbors) and then = using the DAG would allow isolated communication between neighbor nodes = to proceed locally without affecting the overall traffic patterns of the = LLN.  
=

Excellent.

C= heers.

JP.

Jerry




=
JP Vasseur <jvasseur@cisco.com> =

07/08/2009 09:18 = AM

To
Jerald.P.Martocci@jci.com
cc
ROLL WG <roll@ietf.org>, Mukul Goyal <mukul@UWM.EDU>, roll-bounces@ietf.org, Ted.Humpal@jci.com =
Subject
Re: [Roll] Some clarifications on = RPL

=



Hi = Jerry,

On Jul 7, 2009, at 10:46 PM, = Jerald.P.Martocci@jci.com wrote:


JP,


I agree with Mukal. =  

If two or more nodes are all within radio = proximity and hence neighbors they should all be able to exchange = messages amongst themselves without needing to traverse the DAG. =  In the commercial building environment this will happen in the = equipment rooms.  These rooms are electromechanical rooms holding = air handling, heating and air conditioning equipment.  There may me = as many as 20 controllers (routing devices), 20 sensors and 20 actuators = (non-routing devices) all in the same 500 sq ft room.  The concept = of finding candidate parents and connecting into the DAG for this simple = communication seems to be overkill.
=
I am only to page 41 of = the draft and may be pleasantly surprised as I read on; but the sense I = have of the draft so far is it is optimizing router efficiency of = devices (i.e. no loops) while ignoring the logical cohesion of many of = the devices.  Again, in a commercial building there are hundreds of = rooms.  Each room is a microcosm of the overall network (e.g = occupancy, lights, heating/cooling, shade control).  For the most = part these devices are completely independent of all the other rooms. =  They should be able to communicate bidirectionally and freely = amongst themselves with minimal impact to the rest of the LLN. =  

The DAG discovery and maintenance policies = described in the draft looks like each device positions itself on the = DAG as best as it can and then communicates as high up and then back = down the DAG as necessary to reach its intended destination.  I = would think this would create an unbalanced network traffic where the = higher layers are unfairly taxed at forwarding uninteresting messages = while the lower layers are awaiting message delivery.  As I = mentioned in a previous email, this architecture tends to make some = devices more important to the LLN than others which has negative fault = tolerance impact.

My definition of 'Good P2P Routing' is that if = a device has direct radio contact with another device; these devices can = pass messages between themselves directly as needed.


Thanks for shedding = some light on this important scenario. You are quite right that most = focus has been given to P2MP/MP2P traffic patterns. In this scenario, = the notion of sibling could help. Another alternative would be to first = try to check neighbor reachability (nodes in direct neighborhood) before = sending along the DAG. Still the DA may provide a non optimal path but = optimal path from any point to any point required off-line path = computation. How does this sound?

Thanks.

JP.
=
Regards, =

Jerry



=
JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

07/07/2009 12:45 PM=


=
To
Mukul Goyal = <mukul@UWM.EDU> =
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Some clarifications on = RPL


=

=



Hi = Mukul,

On Jul 6, 2009, at 5:13 AM, Mukul Goyal wrote:

= > Tim
>
> Thanks for this explanation. I think most of = this email should  
> become part of RPL draft.
>
= > I would like to convey the discomfort that many of us feel because =  
> RPL does not yet support a good P2P routing solution. = Tree based P2P  
> routing is not acceptable in many cases. = We need to give this  
> problem a high priority.
= >

The solution MUST of course support P2P and this is the = case of RPL.  
Now we need to define what we mean by "Good" P2P = routing solution. As  
of today RPL will branch the traffic as = soon as the packet reaches a  
node that has the destination = address in its routing table pointing to  
one of its children = or sibling. This path may not be the most optimal  
path indeed = and may even be unacceptable. Furthermore it is  
constrained = by the shape of the DAG, which are dependent upon the  
metrics = used by nodes closer to the root. The question is to determine =  
how optimal should that path, and should we decide to adopt a = routing  
solution a la RPL, do we need to complement it with = another mechanism  
when optimal P2P path are required ?
=
Thanks.

JP.

> Thanks
> Mukul
= >
> ----- Original Message -----
> From: "Tim Winter" = <wintert@acm.org>
> To: "ROLL WG" <roll@ietf.org>
> Sent: Sunday, July 5, 2009 5:52:07 PM GMT = -06:00 US/Canada Central
> Subject: [Roll] Some clarifications on = RPL
>
> WG,
>
> Thanks to everyone for their = feedback and comments to the RPL draft  
> so far.
> = There are some good threads here that will definitely help us to =  
> improve
> the RPL design- and there is no doubt = more work to be done.  I would  
> like
> to = make some clarifications that may be useful in discussing some of =  
> the
> common concerns so far:
>
> = 1) Why a DAG?
>        A dominant traffic = flow in the requirements drafts is MP2P,  
> flowing
= > from the sensors inwards towards a sink, typically an LBR. =  The design
> approach taken was to handle this case, use it = to restrict the routing
> problem, and then try to build support = for P2MP, P2P, and other  
> cases on
> top of it. =  A tree provides the simplest structure for supporting  
= > the MP2P
> flows, but a tree has many single points of = failure along the edges  
> from
> children to = parents.  A DAG, allowing each node to select and maintain
> = multiple successors in order to forward traffic inwards toward the =  
> root,
> offers the advantage of ready-to-use = options.  An implementation may  
> then
> = select from the successors as necessary, possibly in response to a
= > temporary failure to forward to one parent, or a load balancing =  
> algorithm,
> or a short-term fluctuation in a = link metric that leads the forwarding
> engine to prefer one next = hop over the other.
>
> 2) What about other flows?
= >        The DAG, and the orientation of the = edges in the DAG, is used  
> in
> routing the MP2P = traffic towards the DAG root.  The structure of the  
> = DAG is
> then used to restrict the complexity of the P2MP routing = problem on  
> the
> nodes.  The Destination = Advertisement mechanism lets a node set up  
> routes
= > in support of outward traffic flows, from the DAG root towards the =  
> leaf
> nodes in the LLN.  The Destination = Advertisement mechanism distributes
> routing state inwards along = the DAG, allowing nodes to learn routing  
> state
> = in support of the sub-DAGs below them.  Nodes who are unable to = learn
> routing state pass the Destination Advertisements inward, = building up
> source routing information along the way so that = they may be traversed
> again on the outward flow.  The = exact implementation of source  
> routing in
> = support of this mechanism is not something that has been addressed =  
> by RPL
> as yet.
>
>     =    Further, arbitrary P2P traffic can be supported by the DAG = as  
> is by
> sending traffic inwards along the DAG = until a parent is encountered,  
> who
> has stored = routing state and is common to the source and destination  
= > of the
> traffic, who is able to direct the traffic towards = the destination.
>
>        RPL does = not discuss any mechanisms to install more optimal P2P
> routes, = but nor does it preclude them, once the fundamentals have been
> = addressed we can have a look at such mechanism to more efficiently =  
> route
> `across' the DAG.
>
> 3) = Metrics
>        RPL allows for each node to = select its set of DAG parents  
> according
> to its = own set of constraints, utilizing whatever subset of metrics it
> = requires to do so.  The exact considerations and weighting can = be
> implementation specific.
>
>     =    A key design point, one that may need to be further =  
> constrained, is
> that under RPL each node does = not assume that other nodes are acting
> cooperatively, or even = that they are using or understand the same  
> set of
= > metrics.  One node could be optimizing for latency, another = node  
> could be
> optimizing for ETX, and a third = could be optimizing for
> minimum energy.  This design point = informs some of the loop avoidance
> rules, such as the use of = depth as a `common language'.
>
>       =  Once a node as selected its DAG parents, according to whatever
= > metrics and constraints it chooses, then it has effectively taken = up a
> position in the DAG.  It now has a best-case path to = the DAG root,  
> through
> its best parent, and a = worst-case path to the DAG root, through its  
> worst
= > parent.  Now, as a *consequence* of selecting parents = according to its
> metrics, the node has taken on a depth within = the DAG.
>
> 4) Loop avoidance
>     =    The DAG, and the nodes position within the DAG, are used in =  
> support
> of some loop avoidance rules.
= >
>        RPL always allows a node to = move inwards along the DAG,  
> towards the
> root. =  Moving inwards along the DAG has little chance of creating a =  
> loop;
> the node has only improved its position. =  Such a move would be based  
> on
> receiving = and processing DIOs with superior metrics from a node of a  
= > lesser
> depth in the DAG.
>
>     =    RPL does not allow a node to move outwards along the = DAG,
> increasing its depth.  Such a move is possible, but = would require  
> the node
> to leave the DAG, wait = for a DAG Hop timer to elapse, and then re-
> attach at
> = the lower point.  RPL would not allow this movement unless the DAG =  
> parents
> of the node have failed, requiring the = node to detach and re-attach  
> to the
> DAG.
= >
>        In general, RPL is taking a = conservative approach.  For a  
> node N,
> any = node M such that depth(M)>depth(N) MAY be in the sub-DAG of
> = node N.  Suppose that node N thought it could improve its metrics =  
> through
> node M.  By detaching first, and = waiting to observe node M to see  
> that node
> M = remains attached to the DAG, node N may then determine that node M =  
> is not
> part of its own sub-DAG and may safely = re-attach at the lower point.  
> BUT if
> node N is = wrong, then an instability has been created for no gain.
> For = this reason, in its current specification, RPL does not allow a =  
> node N
> to process and DIO from node M and = detach from the DAG based on  
> information
> in the = DIO from node M.  NOTE that this is in part a consequence of =  
> the
> design consideration that not all nodes may = be using the same  
> metrics and
> making the same = optimizations.  For example, if all nodes in the  
> = network
> were minimizing ETX, then node N may be mostly certain = that any node
> M advertising a superior ETX is NOT in its own = sub-DAG.
>
>        A further = complication may come if node N and node M are  
> trying = to
> make optimizations which are antagonistic to each other. =  For  
> example, if
> node N where to try to = move under node M, it could create a chain of  
> events
= > whereby node M tried to reverse its position with respect to node = M,  
> and a
> chain reaction of instability could = result.  A simple example of  
> such a
> case = would be where both nodes M and N have a common neighbor and  
= > parent P,
> and nodes M and N subsequently each try to = increase the size of their
> parent set to be 2.  (This case = has been more thoroughly explained by
> Pascal, see "Re: [Roll] = Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q1"  
> sent 30
= > June 2009.)
>
>        RPL has = nodes advertise a depth deeper than that of their  
> = deepest
> DAG parent.  Consider an example where node X has = parents of depth  
> {2, 7},
> and node Y chooses X = as a parent.  Suppose that nodes then advertise  
> = their
> `best' depth, i.e. node X advertises a depth of 3. =  Then node Y will
> advertise a depth of 4.  Then = suppose node Z adds node Y as a  
> parent, and
> = advertises a depth of 5.  Now, Z can actually come to be a = successor  
> of
> node X's depth 7 parent.  The = result could be Z->Y->X->(cost 7
> = parent)->(...)->Z and then there is a loop.  By advertising a = depth  
> deeper
> that of its deepest parent, a node = advertises its worst case  
> scenario, and
> in the = worst case scenario a loop can be avoided.
>
>   =      RPL does not require that the DAG is invariant, = rather that the
> movement of the node with respect to the DAG is = coordinated in such  
> a way
> so as to avoid loops. =  The thought is, whatever the topology,  
> = uncoordinated
> movement in LLNs may increase overhead and churn = and require more  
> reliance
> on expensive = mechanisms such as count-to-infinity.
>
>     =    The use of depth (~ hop count) in RPL is not meant to trump =  
> other
> metrics, but once a node has taken up a = position in the DAG by using  
> its
> metrics the = node acquires a depth, which then restricts the further  
> = options
> that the node has in order to avoid loops.
>
= >
>
> Regards,
>
> -Tim
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll<= /font>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll<= /font>

= _______________________________________________
Roll mailing = list
= Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= /font>

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
=

= --Apple-Mail-89-378419021-- From jvasseur@cisco.com Thu Jul 9 07:33:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30AD328C22C for ; Thu, 9 Jul 2009 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.759 X-Spam-Level: X-Spam-Status: No, score=-9.759 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 xcD6n1O35Ypu for ; Thu, 9 Jul 2009 07:33:33 -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 F17463A683A for ; Thu, 9 Jul 2009 07:33:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208";a="44756074" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2009 14:34:00 +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 n69EY0XP031922; Thu, 9 Jul 2009 16:34:00 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69EY0uS016884; Thu, 9 Jul 2009 14:34:00 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); Thu, 9 Jul 2009 16:34:00 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 16:33:59 +0200 Message-Id: <50A8A272-D0BA-4A8F-AE8A-57202208DC75@cisco.com> From: JP Vasseur To: Philip Levis 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 v935.3) Date: Thu, 9 Jul 2009 08:41:34 +0200 References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <8EA323E3-70AC-47A1-BB79-44E32B5DA540@archrock.com> <87eisswsak.fsf@kelsey-ws.hq.ember.com> <3986B609-FDE0-4756-9F48-DAD29F1BBD26@archrock.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 14:34:00.0238 (UTC) FILETIME=[4C8B4CE0:01CA00A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1690; t=1247150040; x=1248014040; 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[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20theroot? |Sender:=20; bh=by7pNTikyeT2zoTu212cyWuG5VXOF1bU/hscl8J53qU=; b=HzswsEq2q5s8t1eUwPWahnJktbbP69mmXKhY5lewOmb5g66IsV54tTNfan INbH4BhvDxr1lpPZj/9cFXEmDtxMloVhNxP/6BYK/iXhfImFATgn0AKWNwKw WtEpC3Vkd7; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:33:34 -0000 On Jul 7, 2009, at 7:08 PM, Philip Levis wrote: > > On Jul 7, 2009, at 9:44 AM, Jonathan Hui wrote: >>> If we have a reliable way to prevent looping when routing >>> through siblings, then I would propose that we use h equal >>> to the optimal link cost. This would gives us close to what >>> we have now in terms of siblings. This is what you meant >>> by having k=1, correct? >> >> Yes, that's what I meant. I don't think there's a particular >> mechanism to *prevent* loops. Pascal's assumptions are that a >> packet will only continue to loop with some small-ish probability. >> If a packet does get stuck in a loop, then the hop limit will >> expire it. Only annoying thing with relying on the hop limit is >> ICMPv6 time exceeded errors. And this is acceptable as long as we detect them and then break those loops, as opposed to imposing strict rules to avoid them especially when they impose severe constraints. >> >>> If we cannot prevent looping when routing through siblings, >>> it would be better to only allow forwarding via nodes with >>> lower cost (parents and 'inward siblings'). >> >> >> I also like that this encourages fewer loops. The special case, >> however, is when you're near the root. Assuming perfect >> information, there will be one node that has no alternate parents. > > This seems like towards the right approach -- avoid loops and > quickly detect them when they occur, rather than go through > gymnastics to prevent them. > Yes indeed. JP. > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 9 07:33:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00BD28C24B for ; Thu, 9 Jul 2009 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 GOGwqXR8sf5k for ; Thu, 9 Jul 2009 07:33:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8A52F3A67FD for ; Thu, 9 Jul 2009 07:33:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208";a="44756076" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2009 14:34: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 n69EY1D8022165; Thu, 9 Jul 2009 16:34:01 +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.14.3) with ESMTP id n69EY1bX016890; Thu, 9 Jul 2009 14:34:02 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); Thu, 9 Jul 2009 16:34:01 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 16:34:01 +0200 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <878wj0wp8e.fsf@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 v935.3) Date: Thu, 9 Jul 2009 08:43:57 +0200 References: <4A527EAA.4060603@acm.org> <878wj0wp8e.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 14:34:01.0628 (UTC) FILETIME=[4D5F65C0:01CA00A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2340; t=1247150041; x=1248014041; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=pd3DkcDcmKLJqFV7sehcE5DTQTKunTZfyAbTrCDBVM0=; b=R1qeKM1G2CUFCzp2fVDPsscuPrSUZgFQyfgfEhJ6DvsCDGriYgDE6O05Ep 0y+y1q7lwEF2ERvODwMf2hyy/OKoTO/1EW34RtNIPRIIkwn4KBSgaYdPlIwx oCl8AET9xx; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:33:36 -0000 Hi Richard, On Jul 7, 2009, at 4:18 PM, Richard Kelsey wrote: > Hi Tim, > >> Date: Mon, 06 Jul 2009 18:46:02 -0400 >> From: Tim Winter >> >> Richard Kelsey wrote: >>> >>> Given the dubious benefits of having different nodes >>> optimize different metrics, and the bad interaction with >>> having multiple parents, I really don't understand the >>> emphasis on this feature. >>> >> It is perhaps mostly a question of interoperability. Should such a >> scenario come to pass, what should the LLN do? Can we expect that >> all nodes in the LLN will be having the same software, the same >> understanding of metrics and constraints and optimization goals, >> etc. When we look at a typical LLN deployment today, maybe this is >> true more often than not. But as we open up the possibility for LLN >> nodes to truly interoperate with standards-based IPv6, what then? >> RPL in its present form is trying to establish some base guidelines >> as to how such a heterogeneous LLN might organize itself, while >> leaving some freedoms for the implementors... > > In the interests of promoting interoperability, I think that > we could give implemetors and anyone designing a metric a > bit more help in interoperating with other, possibly > unknown, metrics. This is the aim of the METRIC ID: metrics will be standardize as well as probably the objective function. Agree. > Having a DAGcost metric that is additive > with a minimum link cost greater than one gives > interoperation a big step up. Different devices in a mixed > network will still be optimizing different metrics, but at > least paths will be chosen with some attempt at overall > optimization. This is epecially useful with metrics that > are interdependent. The same links are likely to have a low > ETX, low latency, and high reliabilty, for example. As it > stands now, a device which has several potential parents at > the same depth but who do not advertise a known metric has > only the last hop metric for making a choice. We discussed adding the set of metrics in use in the RA, fully agree. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 9 07:35:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB2D3A67FD for ; Thu, 9 Jul 2009 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.281 X-Spam-Level: X-Spam-Status: No, score=-10.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 TBSVNEzVoPYm for ; Thu, 9 Jul 2009 07:35:22 -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 9E7F528C23D for ; Thu, 9 Jul 2009 07:34:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,373,1243814400"; d="scan'208";a="44756221" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2009 14:35:00 +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 n69EZ0fB032255; Thu, 9 Jul 2009 16:35:00 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69EZ0Cu017211; Thu, 9 Jul 2009 14:35:00 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); Thu, 9 Jul 2009 16:35:00 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 16:34:59 +0200 Message-Id: <07C3875F-ACDD-404D-AA6F-4CED9D0C090F@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <878wj0wp8e.fsf@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 v935.3) Date: Thu, 9 Jul 2009 16:34:03 +0200 References: <4A527EAA.4060603@acm.org> <878wj0wp8e.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Jul 2009 14:34:59.0736 (UTC) FILETIME=[7001F980:01CA00A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2339; t=1247150100; x=1248014100; 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[Roll]=20Some=20clarifications=20on=20R PL |Sender:=20; bh=zUscw5cmHzgEj9VyJ8RwD0XO2ESCkRtoLTviJImFg0Q=; b=fdlzkOVE5Lenk33z2IZkJE7g6zc72SdvqEdLlxTYK3TEM6+C+R5B8BQE8o t+yg/DhuwN5S+crUXcN+zVzOqw2TC9cxlZZcuAgfkWXkMpplgSMTnx5/T6I0 aV/ieWVsxT; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Some clarifications on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:35:23 -0000 Hi Richard, On Jul 7, 2009, at 4:18 PM, Richard Kelsey wrote: > Hi Tim, > >> Date: Mon, 06 Jul 2009 18:46:02 -0400 >> From: Tim Winter >> >> Richard Kelsey wrote: >>> >>> Given the dubious benefits of having different nodes >>> optimize different metrics, and the bad interaction with >>> having multiple parents, I really don't understand the >>> emphasis on this feature. >>> >> It is perhaps mostly a question of interoperability. Should such a >> scenario come to pass, what should the LLN do? Can we expect that >> all nodes in the LLN will be having the same software, the same >> understanding of metrics and constraints and optimization goals, >> etc. When we look at a typical LLN deployment today, maybe this is >> true more often than not. But as we open up the possibility for LLN >> nodes to truly interoperate with standards-based IPv6, what then? >> RPL in its present form is trying to establish some base guidelines >> as to how such a heterogeneous LLN might organize itself, while >> leaving some freedoms for the implementors... > > In the interests of promoting interoperability, I think that > we could give implemetors and anyone designing a metric a > bit more help in interoperating with other, possibly > unknown, metrics. This is the aim of the METRIC ID: metrics will be standardize as well as probably the objective function. Agree. > Having a DAGcost metric that is additive > with a minimum link cost greater than one gives > interoperation a big step up. Different devices in a mixed > network will still be optimizing different metrics, but at > least paths will be chosen with some attempt at overall > optimization. This is epecially useful with metrics that > are interdependent. The same links are likely to have a low > ETX, low latency, and high reliabilty, for example. As it > stands now, a device which has several potential parents at > the same depth but who do not advertise a known metric has > only the last hop metric for making a choice. We discussed adding the set of metrics in use in the RA, fully agree. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dominique.barthel@orange-ftgroup.com Fri Jul 10 09:29:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD1B3A6957 for ; Fri, 10 Jul 2009 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UifToqlkq42h for ; Fri, 10 Jul 2009 09:29:26 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 7BF1D3A6E69 for ; Fri, 10 Jul 2009 09:28:54 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 18:29:18 +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, 10 Jul 2009 18:27:16 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF3F9999@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B93DCC@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL] multiple roots in a DAG Thread-Index: Acn7/Nb7Fgb7KDlvRKeFZdNIzid3AwAqy9uQATOQf3A= References: <8E09C72DBC577D489F13A71228C0B7BF371391@ftrdmel0.rd.francetelecom.fr> <7892795E1A87F04CADFCCF41FADD00FC07B93DCC@xmb-ams-337.emea.cisco.com> From: To: , X-OriginalArrivalTime: 10 Jul 2009 16:29:18.0820 (UTC) FILETIME=[92C0E240:01CA017B] Subject: Re: [Roll] [RPL] multiple roots in a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:29:27 -0000 Hello Pascal, all, > Salut Dominique=20 >> If I understand the draft correctly, multiple roots shall send "identical" DIOs with synchronized sequence numbers.=20 >> Therefore, nodes will only know of one root (because they discard DIOs with same or lower seqnum).=20 >> Most nodes will likely hear from only one root anyway, since intermediate nodes only propagate *one* DIO per DAGID.=20 >> This results in a watershed effect.=20 > Exactly. Only nodes on the ridges might hear of 2 roots. The interesting part is that the ridges define themselves by the choice of nodes on the ridges.=20 > Having multiple DAGs with as many DAGIDs is what we expect in general (divide and conquer) so that problem is isolated within its drainage basin. For instance, the loss of a sink only impacts nodes in that basin that have to migrate to the nearest next one. > I understand that you're really talking about, though, is multiple sinks for a same DAGID, what I'd call a delta in a watershed analogy. This is exactly what I was refering to. > The only use case for a delta that I have in mind for this is a 6LoWPAN backbone. What's required there is, as you indicate, a sync of the "roots" so that they used consistent sequence numbers and DAGIDs. This can be seen as a single root (the backbone itself ) of a single DAG and the multiple secondary roots advertise depth 1 in that same DAG. What I'd do there is use one of the root to source the protocol over the backbone. I think we had good text on that in the fundamentals draft, maybe we should integrate some of that in RPL. The point is that, with the current draft, there is no delta possible. If I understand correctly, all DIOs with same or earlier sequence numbers are discarded, so a node hardly ever knows about other roots than the closest one. Which amounts to watersheds separated by ridges, not a delta. Am I mistaken here? In an outdoor WSN, I could think of LLNs with multiple exit points that use different technologies, (cellular on one side, wired on another one, for example. That would not be a backbone, and synchronizing the roots would be less obvious. If the exit points belong to different telcos, they would even advertize different prefixes. Currently, nodes are prevented from knowing all of these different prefixes. (a quick fix might seem to propagate DIOs coming from various roots even if seqnum is older, but that alone wouldn't work : since we don't have root IDs in the DIOs, there's no way to differentiate an old DIO by the same root from a new DIO by a different root). BTW, adding RootIDs in the DIOs would eliminate the need for synchronizing the roots, wouldn't it? Any comment? Cheers Quentin & Dominique >> The routing algorithm at a node can therefore only chose among parents that lead to the same root in that DAG.=20 >> Was there any consideration given to nodes knowing about several roots? >> Or is the use of multiple DAGs recommended instead : this would go counter the advocated intention of using multiple DAGs for serving competing constraints (3.3.1.2)...=20 > There's really one DAG per DAGID. A delta is still one DAG with the first hop in a backbone. I see multiple DAGs as multiple routing topologies. Whether that's needed is a use case thing, but we allow it. > That multiplies the cost of control though. Not recommended for every simple destination but useful for a few well chosen ones like gateways. > Cheers, > Pascal >> Best regards,=20 >> Dominique=20 From prvs=4378041aa=mukul@uwm.edu Sun Jul 12 11:56:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6886428C0EA for ; Sun, 12 Jul 2009 11:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMz1WzXMRRiJ for ; Sun, 12 Jul 2009 11:56:15 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 76A423A6B66 for ; Sun, 12 Jul 2009 11:56:11 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 12 Jul 2009 13:56:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id ED96EC085A3 for ; Sun, 12 Jul 2009 13:56:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbfyU7Xr5ZB8 for ; Sun, 12 Jul 2009 13:56:40 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CA2B5C085A0 for ; Sun, 12 Jul 2009 13:56:40 -0500 (CDT) Date: Sun, 12 Jul 2009 13:56:40 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 18:56:41 -0000 The tree/DAG based P2P routing proposed in RPL may not be desirable in many situations. Here is the outline of an alternative P2P routing solution: 1. The P2P routing would follow a basic DV approach, where nodes would advertize their "cost" to various destinations in Hello/"Router Advertisement" messages and next-hop(s) selection (for a destination) is based on the advertised costs by neighbors. 1.1 A node may solicit advertisements from its neighbors regarding a destination. 1.2 The generation of Hello messages may follow a trickle-like approach. 1.3 In the absence of new advertisements about a destination from a neighbor, the perceived cost of reaching the destination through this neighbor deteriorates with time. 2. The LLN would be divided into "domains" such that (costs to) destinations in one domain would be advertized (in Hello messages)by nodes within that domain only. This is to limit the destinations a node may have to advertize. There may be some _super_ destinations that can be advertised across domains. 3. There is no loop avoidance/prevention. 4. There is a loop detection and correction mechanism in place. Periodically, a source node would send a control packet towards the destination. This packet accumulates the path it travels over. If a receiving node finds itself already listed in the path, the routing loop is detected. The node corrects the loop by excluding and punishing the offending nexthop. Please comment. Thanks Mukul From pal@cs.stanford.edu Sun Jul 12 22:42:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FD43A6922 for ; Sun, 12 Jul 2009 22:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwAsrPmPyl7N for ; Sun, 12 Jul 2009 22:42:23 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 82E2D3A67F1 for ; Sun, 12 Jul 2009 22:42:23 -0700 (PDT) Received: from md30f36d0.tmodns.net ([208.54.15.211] helo=90.226.246.10.in-addr.arpa) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MQEJQ-0005al-4o; Sun, 12 Jul 2009 22:42:52 -0700 Message-Id: From: Philip Levis To: Mukul Goyal In-Reply-To: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 22:42:49 -0700 References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 05:42:24 -0000 On Jul 12, 2009, at 11:56 AM, Mukul Goyal wrote: > The tree/DAG based P2P routing proposed in RPL may not be desirable > in many situations. > > Here is the outline of an alternative P2P routing solution: > > 1. The P2P routing would follow a basic DV approach, where nodes > would advertize their "cost" to various destinations in > Hello/"Router Advertisement" messages and next-hop(s) selection (for > a destination) is based on the advertised costs by neighbors. > 1.1 A node may solicit advertisements from its neighbors > regarding a destination. > 1.2 The generation of Hello messages may follow a trickle-like > approach. > 1.3 In the absence of new advertisements about a destination from > a neighbor, the perceived cost of reaching the destination through > this neighbor deteriorates with time. > > 2. The LLN would be divided into "domains" such that (costs to) > destinations in one domain would be advertized (in Hello messages)by > nodes within that domain only. This is to limit the destinations a > node may have to advertize. There may be some _super_ destinations > that can be advertised across domains. > > 3. There is no loop avoidance/prevention. > > 4. There is a loop detection and correction mechanism in place. > Periodically, a source node would send a control packet towards the > destination. This packet accumulates the path it travels over. If a > receiving node finds itself already listed in the path, the routing > loop is detected. The node corrects the loop by excluding and > punishing the offending nexthop. > > Please comment. In wireless protocols, the devil tends to be in the details. I'd want to see a detailed protocol description before commenting. Phil From alexandru.petrescu@gmail.com Mon Jul 13 02:01:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FC028C27F for ; Mon, 13 Jul 2009 02:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGqMHwPgcef0 for ; Mon, 13 Jul 2009 02:01:29 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 86FAA28C27E for ; Mon, 13 Jul 2009 02:01:27 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0B0FED480E3; Mon, 13 Jul 2009 11:01:54 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id B83BAD48092; Mon, 13 Jul 2009 11:01:51 +0200 (CEST) Message-ID: <4A5AF7F9.1050407@gmail.com> Date: Mon, 13 Jul 2009 11:01:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Mukul Goyal References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090712-0, 12/07/2009), Outbound message X-Antivirus-Status: Clean Cc: roll Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 09:01:30 -0000 The routing proposed in RPL does not say how many interfaces a sensor has, and in some of its pictures shows a sensor with as many as 8 interfaces. I believe this was not the intention. However, my interpretation of it does not mean that it is clearer. How many interfaces does a ROLL node have? What is the subnet structure in a ROLL network? Are all sensors in the same IP subnet? Or not? Is there a subnet uniquely between each each two points? Or not? Can IPv6 use link-local multicast in RPL? Or not? Without these things clear it is impossible to design a dynamic routing protocol, let alone an IP addressing structure, not even a static routing mechanism. Deciding distance-vector vs link-state vs path-vector, or proactive vs reactive, or source-routing vs table-based routing, or stateful routing vs soft-state vs hard-state routing is too early. TO clarify the IP addressing things (mandatorily preceding what RPL has to design), I am optimistically waiting for results of AUTOCONF DT, a draft seems to be out about it, but that seems to go against my opinions too :-) Yours, Alex Mukul Goyal a crit : > The tree/DAG based P2P routing proposed in RPL may not be desirable > in many situations. > > Here is the outline of an alternative P2P routing solution: > > 1. The P2P routing would follow a basic DV approach, where nodes > would advertize their "cost" to various destinations in Hello/"Router > Advertisement" messages and next-hop(s) selection (for a > destination) is based on the advertised costs by neighbors. 1.1 A > node may solicit advertisements from its neighbors regarding a > destination. 1.2 The generation of Hello messages may follow a > trickle-like approach. 1.3 In the absence of new advertisements about > a destination from a neighbor, the perceived cost of reaching the > destination through this neighbor deteriorates with time. > > 2. The LLN would be divided into "domains" such that (costs to) > destinations in one domain would be advertized (in Hello messages)by > nodes within that domain only. This is to limit the destinations a > node may have to advertize. There may be some _super_ destinations > that can be advertised across domains. > > 3. There is no loop avoidance/prevention. > > 4. There is a loop detection and correction mechanism in place. > Periodically, a source node would send a control packet towards the > destination. This packet accumulates the path it travels over. If a > receiving node finds itself already listed in the path, the routing > loop is detected. The node corrects the loop by excluding and > punishing the offending nexthop. > > Please comment. > > Thanks Mukul _______________________________________________ Roll > mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > From dokaspar.ietf@gmail.com Mon Jul 13 05:28:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A71E28C401 for ; Mon, 13 Jul 2009 05:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zuFno453sKd for ; Mon, 13 Jul 2009 05:28:22 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id CE3FE28C3DF for ; Mon, 13 Jul 2009 05:28:21 -0700 (PDT) Received: by fxm18 with SMTP id 18so2142091fxm.37 for ; Mon, 13 Jul 2009 05:27:57 -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=S8F6+VlXT8ouDLT4n8cRqxde/VV2RPRWAUIeBy0V/C0=; b=vZHEXM77fIGIPDBE72VqGors7jnd+fDH0/zR9wsxzrFCuNS1tlm7ncyCj9wAgPGSE/ yfIazVExyXRVHNmc8W5pcY3ApG1L2/Z/q9BxMqykJ1jA+OC1fuU3q76RsV6M4Aj6dckO kiraIP054Ptz8H3TrOWVW4qALSxtlNRKpBg+k= 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=TU2uoPy5m+b3VaRAcyUD957PHNCn73II1nvHWo1erFKU+f7u2SIf/giVcfpXUZm0yJ QplhKmWsSFQ0h0/w1jnRY1L9l6XGMsfg0HLf9GoWL1vwE92HYPpdTKrkCkhmejwW1Hx4 zfntRKUW1v49/z0zsWGYy+D/53qi70bA9JYoA= MIME-Version: 1.0 Received: by 10.103.189.18 with SMTP id r18mr2602338mup.80.1247488077110; Mon, 13 Jul 2009 05:27:57 -0700 (PDT) In-Reply-To: <4A5AF7F9.1050407@gmail.com> References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> <4A5AF7F9.1050407@gmail.com> Date: Mon, 13 Jul 2009 14:27:57 +0200 Message-ID: <2a3692de0907130527l67f6caf3w8d65bc6fcda19b1c@mail.gmail.com> From: Dominik Kaspar To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 12:28:23 -0000 Hi, I am also curious about an answer to the question about the number of interfaces on a ROLL node. Are there any existing sensor network nodes with a "tiny" form factor, that utilize multiple physical interfaces? By the way... it might be a good idea to put all the terminology of the RPL draft into the already existing terminology document. Greetings, Dominik On Mon, Jul 13, 2009 at 11:01 AM, Alexandru Petrescu wrote: > The routing proposed in RPL does not say how many interfaces a sensor > has, and in some of its pictures shows a sensor with as many as 8 > interfaces. =A0I believe this was not the intention. > > However, my interpretation of it does not mean that it is clearer. > > How many interfaces does a ROLL node have? > > What is the subnet structure in a ROLL network? =A0Are all sensors in the > same IP subnet? =A0Or not? =A0Is there a subnet uniquely between each eac= h > two points? =A0Or not? > > Can IPv6 use link-local multicast in RPL? =A0Or not? > > Without these things clear it is impossible to design a dynamic routing > protocol, let alone an IP addressing structure, not even a static > routing mechanism. > > Deciding distance-vector vs link-state vs path-vector, or proactive vs > reactive, or source-routing vs table-based routing, or stateful routing > vs soft-state vs hard-state routing is too early. > > TO clarify the IP addressing things (mandatorily preceding what RPL has t= o > design), I am optimistically waiting for results of AUTOCONF DT, a draft > seems to be out about it, but that seems to go against my opinions too :-= ) > > Yours, > > Alex > > Mukul Goyal a =E9crit : >> >> The tree/DAG based P2P routing proposed in RPL may not be desirable in >> many situations. >> >> Here is the outline of an alternative P2P routing solution: >> >> 1. The P2P routing would follow a basic DV approach, where nodes would >> advertize their "cost" to various destinations in Hello/"Router >> =A0Advertisement" messages and next-hop(s) selection (for a >> destination) is based on the advertised costs by neighbors. 1.1 A >> node may solicit advertisements from its neighbors regarding a >> destination. 1.2 The generation of Hello messages may follow a >> trickle-like approach. 1.3 In the absence of new advertisements about >> a destination from a neighbor, the perceived cost of reaching the >> destination through this neighbor deteriorates with time. >> >> 2. The LLN would be divided into "domains" such that (costs to) >> destinations in one domain would be advertized (in Hello messages)by nod= es >> within that domain only. This is to limit the destinations a node may ha= ve >> to advertize. There may be some _super_ destinations that can be adverti= sed >> across domains. >> >> 3. There is no loop avoidance/prevention. >> >> 4. There is a loop detection and correction mechanism in place. >> Periodically, a source node would send a control packet towards the >> destination. This packet accumulates the path it travels over. If a >> receiving node finds itself already listed in the path, the routing loop= is >> detected. The node corrects the loop by excluding and punishing the >> offending nexthop. >> >> Please comment. >> >> Thanks Mukul _______________________________________________ Roll mailin= g >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mcr@marajade.sandelman.ca Mon Jul 13 13:52:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181AC28C383 for ; Mon, 13 Jul 2009 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4gLflhY17wJ for ; Mon, 13 Jul 2009 13:52:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DB15928C36F for ; Mon, 13 Jul 2009 13:52:27 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [205.233.53.81]) by relay.sandelman.ca (Postfix) with ESMTPS id C76DF3424E for ; Mon, 13 Jul 2009 20:52:50 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id CBB023EC5 for ; Mon, 13 Jul 2009 07:03:51 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 07:03:51 -0400 Message-ID: <14339.1247483031@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:52:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" =3D=3D Richard Kelsey writes: Richard> precision. Both are fruitful, but are unfortunately at odds. Richard> With hop count neighbors are either: Richard> parents (lower hop count) Richard> siblings (same hop count) Richard> ignored (higher hp count) Richard> With a more precise metric, where the optimal link has cost k, Richard> neighbors can be divided into four categories: Richard> parents (cost less by k or more) Richard> inward siblings (cost less by k-1 or less) Richard> siblings (same cost) Richard> ignored (higher cost) Richard> In either case, forwarding via siblings or 'ignored' can Richard> send a message around a loop. Forwarding via parents or Richard> inward siblings cannot. Let's say that I have a network that looks like this: R / \ X Y | | A B / \ / \ C D E I thought that one of the goals of this protocol was such that one could have a route E->B->D->A->X-R as well as a route E->B->Y->R for the situation where X had a good power supply, while Y had a power budget. or is this handled by another part of the protocol? If Y shows a high enough hop-cost to prefer the longer route, then it never gets used, which perhaps is an issue if the links are at capacity. This is why I do not understand the focus on a DAG, when I thought that the problem was more complex. (Back to reading the documents and this long thread) - --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy")= ; [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSlsUlICLcPvd0N1lAQJALwf9E0PAWFpkbO5Rc9r9DLYQxzVDoY3uVgdr rgUqhXCnpTdedp3QBHf49LG1qmdffbz7nm5vjrSUKfToOwl8nt2dZSQjF3w/I9Yz B/OMD8XexDGANTdZvELQKmreVNf2Fcadh83hTOxbuZArhNroPFB42HGIy8hY+JYy 8yMjNLNfRTXsL92y2aIs/RKu09RCHVsHRQFC9UIHtZPkNvYQksLZcySLd/6m047H tyHpg8GQqdxx17WzBjlzBpJ8v1I2SIEeSPgQ9E2RgkDdT++PQLOU28SiHVlToEV4 pi0scJLCXGGj/738vxCOf6UaWdy41PyCRuigZV8c1QtvcUkP1fpk9w=3D=3D =3DWMJG -----END PGP SIGNATURE----- From cabo@tzi.org Mon Jul 13 14:15:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC08828C37E; Mon, 13 Jul 2009 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 weUFKJQYUOd9; Mon, 13 Jul 2009 14:15:35 -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 5BC8A28C36C; Mon, 13 Jul 2009 14:15:35 -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.3/8.14.3) with ESMTP id n6DLFtvs004933; Mon, 13 Jul 2009 23:15:55 +0200 (CEST) Received: from [192.168.217.107] (p5489C4F4.dip.t-dialin.net [84.137.196.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 47C39B607; Mon, 13 Jul 2009 23:15:55 +0200 (CEST) Message-Id: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org, ROLL WG 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 v935.3) Date: Mon, 13 Jul 2009 23:15:54 +0200 References: X-Mailer: Apple Mail (2.935.3) Subject: Re: [Roll] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:15:36 -0000 Based on the extensive feedback I got for the 6LowApp Bar BOF, I have slightly extended the problem statement: http://u.nu/2bfj = http://www.ietf.org/internet-drafts/draft-bormann-6lowpan-6lowapp-problem-01.txt Thanks to all the additional contributors. (I don't agree with all their comments, but I tried to err on the side of capturing as many requirements as possible.) The Bar BOF is still scheduled at ->Tue 18:30<-. I'm going to ask the ADs for a room so we can hear each other (and maybe use a projector). Again, please tell me if you want a slot in the structured part. Even after the I-D deadline, you can continue to capture information at the Bar BOF Wiki: http://u.nu/6jfh = http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp Gruesse, Carsten On Jul 6, 2009, at 12:56, Carsten Bormann wrote: > The 6LoWPAN and ROLL WGs are laying the groundwork to make the > Wireless Embedded Internet a reality, but what application protocols > will we use? Request-response protocols like HTTP are a poor fit to > a communication model with battery-operated, mostly sleeping nodes. > In addition, the usual data formats (both headers and body) are > perceived to be too chatty for the 50-60 byte payloads possible in > LoWPANs and to require too much code for the 8-bit and 16-bit > processors dominating the Internet of Things. Still, it would be a > mistake to start a new silo of application protocols that do not > benefit from existing application area Internet experience. > > At IETF75, we will hold a Bar BOF to scope out possible IETF work > and maybe form an opinion on which part should be done in which IETF > area. > > Tentative information is at http://u.nu/6jfh = > http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/6LowApp > (and you are welcome to contribute to this Wiki page). > > -> Please tell us whether the envisaged date and time of ->Tue > 18:30<- will work for you! > > A first version of a problem statement (where the above paragraph > was stolen from) is at: > > http://tools.ietf.org/id/6lowapp > (draft-bormann-6lowpan-6lowapp-problem-00.txt) > > I will start planning an agenda for the Bar BOF soon, so if you have > something to say that would help in this conversation, please tell > me (with an estimated amount of time). > > Gruesse, Carsten From cabo@tzi.org Mon Jul 13 15:06:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AC63A696D; Mon, 13 Jul 2009 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 lFhoYC2GVWbS; Mon, 13 Jul 2009 15:06:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C3A0A28C678; Mon, 13 Jul 2009 15:04:31 -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.3/8.14.3) with ESMTP id n6DM4pda019968; Tue, 14 Jul 2009 00:04:51 +0200 (CEST) Received: from [192.168.217.107] (p5489C4F4.dip.t-dialin.net [84.137.196.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 50FE7B615; Tue, 14 Jul 2009 00:04:51 +0200 (CEST) Message-Id: From: Carsten Bormann To: Carsten Bormann In-Reply-To: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 00:04:50 +0200 References: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org Subject: Re: [Roll] [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 22:06:07 -0000 On Jul 13, 2009, at 23:15, Carsten Bormann wrote: > slightly extended the problem statement (For those not aware of tools.ietf.org: side-by-side diff at:) http://u.nu/8pfj Gruesse, Carsten From d.sturek@att.net Mon Jul 13 16:07:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662AB28C340 for ; Mon, 13 Jul 2009 16:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ytjXTJ0apoY for ; Mon, 13 Jul 2009 16:07:40 -0700 (PDT) Received: from smtp109-mob.biz.mail.ac4.yahoo.com (smtp109-mob.biz.mail.ac4.yahoo.com [76.13.13.230]) by core3.amsl.com (Postfix) with SMTP id 36F5C28C33D for ; Mon, 13 Jul 2009 16:07:40 -0700 (PDT) Received: (qmail 93777 invoked from network); 13 Jul 2009 22:41:31 -0000 Received: from unknown (HELO bda1055.bisx.prod.on.blackberry) (d.sturek@67.223.70.32 with xymcookie) by smtp109-mob.biz.mail.ac4.yahoo.com with SMTP; 13 Jul 2009 22:41:30 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: JM6jJmgVM1kmAm819XTlPQhhXJfyC_ufqwt9eFYLTN.3xwpg0LKLJ2JibMuZE0KFcGBOjoP6gvky37ToWbnm7m8mixE2PnrTYR1mqDu7xFheRnr_WCapcsNCTHP7Drx2ALntdEoGO3y3FTCx1pws8Eus_jTsmMg1nolQ7OzlstW0SiLe0cMW2mXOTy3FQjjgj4rXBhIGceuwZcXNQ530MblXHLjAzLLqs9.VxM5oAeoYKpk9q9x70TezUYdYqIxLqmb88M4friK0NiYJ2uj185LI X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 1819178574 Message-ID: <1819178574-1247524889-cardhu_decombobulator_blackberry.rim.net-1146920564-@bxe1266.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> In-Reply-To: <827B8C0A-667E-441B-8396-D33FF007A7A0@tzi.org> Sensitivity: Normal Importance: Normal To: "Carsten Bormann" , roll-bounces@ietf.org, "6lowpan" <6lowpan@ietf.org>, apps-discuss@ietf.org, "ROLL WG" From: d.sturek@att.net Date: Mon, 13 Jul 2009 22:44:02 +0000 Content-Type: text/plain MIME-Version: 1.0 Subject: Re: [Roll] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 23:07:41 -0000 SGkgY2Fyc3RlbiwNCg0KSSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgdGhlIHRpbWVsaW5lIGFuZCBy ZXF1aXJlbWVudHMgZm9yIHRoZSB6aWdiZWUgc21hcnQgZW5lcmd5IHdvcmsuICBTaG91bGQgYmUg bm90IG1vcmUgdGhhbiA1IHNsaWRlcyBhbmQgMTUgbWludXRlcy4NCg0KRG9uDQpTZW50IHZpYSBC bGFja0JlcnJ5IGZyb20gVC1Nb2JpbGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KDQpEYXRlOiBNb24sIDEzIEp1bCAy MDA5IDIzOjE1OjU0IA0KVG86IDZsb3dwYW48Nmxvd3BhbkBpZXRmLm9yZz47IDxhcHBzLWRpc2N1 c3NAaWV0Zi5vcmc+OyBST0xMIFdHPHJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxd IDZMb3dBcHA6IEFwcGxpY2F0aW9uIHByb3RvY29scyBmb3IgNkxvV1BBTiBhbmQgb3RoZXIgTExO DQoNCg0KQmFzZWQgb24gdGhlIGV4dGVuc2l2ZSBmZWVkYmFjayBJIGdvdCBmb3IgdGhlIDZMb3dB cHAgQmFyIEJPRiwgSSBoYXZlICANCnNsaWdodGx5IGV4dGVuZGVkIHRoZSBwcm9ibGVtIHN0YXRl bWVudDoNCg0KaHR0cDovL3UubnUvMmJmaiAgPQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYm9ybWFubi02bG93cGFuLTZsb3dhcHAtcHJvYmxlbS0wMS50eHQNCg0K VGhhbmtzIHRvIGFsbCB0aGUgYWRkaXRpb25hbCBjb250cmlidXRvcnMuIChJIGRvbid0IGFncmVl IHdpdGggYWxsICANCnRoZWlyIGNvbW1lbnRzLCBidXQgSSB0cmllZCB0byBlcnIgb24gdGhlIHNp ZGUgb2YgY2FwdHVyaW5nIGFzIG1hbnkgIA0KcmVxdWlyZW1lbnRzIGFzIHBvc3NpYmxlLikNCg0K VGhlIEJhciBCT0YgaXMgc3RpbGwgc2NoZWR1bGVkIGF0IC0+VHVlIDE4OjMwPC0uDQpJJ20gZ29p bmcgdG8gYXNrIHRoZSBBRHMgZm9yIGEgcm9vbSBzbyB3ZSBjYW4gaGVhciBlYWNoIG90aGVyIChh bmQgIA0KbWF5YmUgdXNlIGEgcHJvamVjdG9yKS4NCkFnYWluLCBwbGVhc2UgdGVsbCBtZSBpZiB5 b3Ugd2FudCBhIHNsb3QgaW4gdGhlIHN0cnVjdHVyZWQgcGFydC4NCg0KRXZlbiBhZnRlciB0aGUg SS1EIGRlYWRsaW5lLCB5b3UgY2FuIGNvbnRpbnVlIHRvIGNhcHR1cmUgaW5mb3JtYXRpb24gIA0K YXQgdGhlIEJhciBCT0YgV2lraToNCmh0dHA6Ly91Lm51LzZqZmggID0NCmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9CYXJCb2ZzL0lFVEY3NS82TG93QXBwDQoN CkdydWVzc2UsIENhcnN0ZW4NCg0KDQpPbiBKdWwgNiwgMjAwOSwgYXQgMTI6NTYsIENhcnN0ZW4g Qm9ybWFubiB3cm90ZToNCg0KPiAgIFRoZSA2TG9XUEFOIGFuZCBST0xMIFdHcyBhcmUgbGF5aW5n IHRoZSBncm91bmR3b3JrIHRvIG1ha2UgdGhlDQo+ICAgV2lyZWxlc3MgRW1iZWRkZWQgSW50ZXJu ZXQgYSByZWFsaXR5LCBidXQgd2hhdCBhcHBsaWNhdGlvbiBwcm90b2NvbHMNCj4gICB3aWxsIHdl IHVzZT8gIFJlcXVlc3QtcmVzcG9uc2UgcHJvdG9jb2xzIGxpa2UgSFRUUCBhcmUgYSBwb29yIGZp dCB0bw0KPiAgIGEgY29tbXVuaWNhdGlvbiBtb2RlbCB3aXRoIGJhdHRlcnktb3BlcmF0ZWQsIG1v c3RseSBzbGVlcGluZyBub2Rlcy4NCj4gICBJbiBhZGRpdGlvbiwgdGhlIHVzdWFsIGRhdGEgZm9y bWF0cyAoYm90aCBoZWFkZXJzIGFuZCBib2R5KSBhcmUNCj4gICBwZXJjZWl2ZWQgdG8gYmUgdG9v IGNoYXR0eSBmb3IgdGhlIDUwLTYwIGJ5dGUgcGF5bG9hZHMgcG9zc2libGUgaW4NCj4gICBMb1dQ QU5zIGFuZCB0byByZXF1aXJlIHRvbyBtdWNoIGNvZGUgZm9yIHRoZSA4LWJpdCBhbmQgMTYtYml0 DQo+ICAgcHJvY2Vzc29ycyBkb21pbmF0aW5nIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MuICBTdGls bCwgaXQgd291bGQgYmUgYQ0KPiAgIG1pc3Rha2UgdG8gc3RhcnQgYSBuZXcgc2lsbyBvZiBhcHBs aWNhdGlvbiBwcm90b2NvbHMgdGhhdCBkbyBub3QNCj4gICBiZW5lZml0IGZyb20gZXhpc3Rpbmcg YXBwbGljYXRpb24gYXJlYSBJbnRlcm5ldCBleHBlcmllbmNlLg0KPg0KPiBBdCBJRVRGNzUsIHdl IHdpbGwgaG9sZCBhIEJhciBCT0YgdG8gc2NvcGUgb3V0IHBvc3NpYmxlIElFVEYgd29yayAgDQo+ IGFuZCBtYXliZSBmb3JtIGFuIG9waW5pb24gb24gd2hpY2ggcGFydCBzaG91bGQgYmUgZG9uZSBp biB3aGljaCBJRVRGICANCj4gYXJlYS4NCj4NCj4gVGVudGF0aXZlIGluZm9ybWF0aW9uIGlzIGF0 IGh0dHA6Ly91Lm51LzZqZmggPQ0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2Fw cC90cmFjL3dpa2kvQmFyQm9mcy9JRVRGNzUvNkxvd0FwcA0KPiAoYW5kIHlvdSBhcmUgd2VsY29t ZSB0byBjb250cmlidXRlIHRvIHRoaXMgV2lraSBwYWdlKS4NCj4NCj4gLT4gUGxlYXNlIHRlbGwg dXMgd2hldGhlciB0aGUgZW52aXNhZ2VkIGRhdGUgYW5kIHRpbWUgb2YgLT5UdWUgIA0KPiAxODoz MDwtIHdpbGwgd29yayBmb3IgeW91IQ0KPg0KPiBBIGZpcnN0IHZlcnNpb24gb2YgYSBwcm9ibGVt IHN0YXRlbWVudCAod2hlcmUgdGhlIGFib3ZlIHBhcmFncmFwaCAgDQo+IHdhcyBzdG9sZW4gZnJv bSkgaXMgYXQ6DQo+DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC82bG93YXBwDQo+IChkcmFm dC1ib3JtYW5uLTZsb3dwYW4tNmxvd2FwcC1wcm9ibGVtLTAwLnR4dCkNCj4NCj4gSSB3aWxsIHN0 YXJ0IHBsYW5uaW5nIGFuIGFnZW5kYSBmb3IgdGhlIEJhciBCT0Ygc29vbiwgc28gaWYgeW91IGhh dmUgIA0KPiBzb21ldGhpbmcgdG8gc2F5IHRoYXQgd291bGQgaGVscCBpbiB0aGlzIGNvbnZlcnNh dGlvbiwgcGxlYXNlIHRlbGwgIA0KPiBtZSAod2l0aCBhbiBlc3RpbWF0ZWQgYW1vdW50IG9mIHRp bWUpLg0KPg0KPiBHcnVlc3NlLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From prvs=439c7d550=mukul@uwm.edu Tue Jul 14 04:47:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82573A6941 for ; Tue, 14 Jul 2009 04:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcBLeMLcB0R8 for ; Tue, 14 Jul 2009 04:47:01 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 966B53A6824 for ; Tue, 14 Jul 2009 04:47:01 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 14 Jul 2009 06:46:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A949AC085A6 for ; Tue, 14 Jul 2009 06:46:01 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05Q0CCwDH-YG for ; Tue, 14 Jul 2009 06:46:01 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 71C13C085A0 for ; Tue, 14 Jul 2009 06:46:01 -0500 (CDT) Date: Tue, 14 Jul 2009 06:46:01 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1734253621.2168001247571961278.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <807766048.2167711247571801088.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 11:54:25 -0000 Hi all Here is a simple loop avoidance mechanism that can be used in a P2P routing solution that does not use DAGs. Thanks Mukul In DV protocols, the routing loops are triggered when the cost to reach a destination via the current next hop increases so much that a new next hop needs to be selected. Suppose, a node, B, determines that its current next hop, A, for a destination, X, may no longer be the best ("minimum cost") neighbor to forward packets to. Such determination could be based on an increase in the link cost to node A or the receipt of a new advertisement from node A showing an increased cost to reach the destination X. In case of such an event, node B should not choose a new next hop immediately. This is because the current cost advertisements by its neighbors, as well as any new advertisements generated in the immediate aftermath of the event, may be based on node B's erstwhile cost to reach the destination. Immediate selection of a new next hop based on the current or new cost advertisements by the neighbors may lead to a routing loop and a "count to infinity" situation. Rather, node B should initiate the propagation of new cost information down the tree (of nodes for whom it currently lies on the route to X)and wait for some time before calculating its new next hop. The hope is that by the time the node calculates its new next hop, its increased cost along the current next hop is known to all its neighbors and they have generated new advertisements if their previous advertisements were based on the old cost of node B to reach X. So, when node B determines that its current next hop A for destination X is no longer the best neighbor to forward packets to, it generates a new specially _marked_ advertisement that lists node B's new cost to reach X via A, the current next hop. The generation of a _marked_ advertizement regarding destination X puts the node in the "loop avoidance" state for a time period during which the node can neither change its next hop to destination X nor generate a regular advertisement for the destination X. All nodes that receive node B's _marked_ advertisement regarding destination X update their cost to reach X via B. If a node currently considers node B as its next hop to destination X, it additionally does the following: 1. it enters the "loop avoidance" state and hence consequently keeps node B as its next hop to X 2. originates a _marked_ advertizement listing its new cost to destination X via node B Once a node exits the "loop avoidance" state, it is allowed to select a new next hop to X and generate a regular advertisement listing its new cost to X. Here is an example showing the efficacy of this proposal: X | A / \ B-C / \ D E \ / F X is the destination. Suppose all unidirectional link costs are 1 except the following: B->C:5, B->D:5 and E->B:5 Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X and node B's perceived cost to reach X via each neighbor is as follows: via A:2, via C:7, via D:8, via E:6 Suppose the cost of link B->A changes to 100. In a simple DV protocol, B's cost to reach X via A becomes 101 and hence it immediately chooses E as the next hop (declaring its new cost to X as 6), thereby creating routing loop B->E->F->D->B and a "count to infinity" situation. Under the proposed protocol, B would generate a _marked_ advertisement listing its cost to X as 101 and enter the "loop avoidance" state. This _marked_ advertisement is received by A, C, D and E. Since D considers B as its next hop to X, it enters the "loop avoidance" state as well and generates its own _marked_ advertisement listing its cost to X as 102. On receiving this advertisement, node F enters the "loop avoidance" state and generates its own _marked_ advertisement listing its cost to X as 103. On receiving this advertisement, node E enters the "loop avoidance" state and generates its own _marked_ advertisement listing its cost to X as 104. If node B comes out of the "loop avoidance" state only after the receipt of this advertisement from E, B would correctly choose node C as its new next hop to X and generate a new advertisement listing its cost to X as 7. When nodes D, F and E come out of the "loop avoidance" state, they would ultimately update their cost to X to 8, 9 and 10 respectively without any loops. This policy does cause a delay in convergence. Suppose B->C cost is 1 in the example above. B enters the "loop avoidance" state when cost of link B->A changes to 100. Node B would not select C as next hop (and advertize a cost 3 to X) until it comes out of the "loop avoidance" state. From prvs=439c7d550=mukul@uwm.edu Tue Jul 14 04:54:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB7E3A695E for ; Tue, 14 Jul 2009 04:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyUyevlVZ+Zf for ; Tue, 14 Jul 2009 04:54:35 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 998863A68E2 for ; Tue, 14 Jul 2009 04:54:35 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 14 Jul 2009 06:53:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7D369C085AB; Tue, 14 Jul 2009 06:53:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezz+XFHUkspq; Tue, 14 Jul 2009 06:53:38 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4D546C085AA; Tue, 14 Jul 2009 06:53:38 -0500 (CDT) Date: Tue, 14 Jul 2009 06:53:38 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1865766337.2168631247572418103.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 11:54:36 -0000 Phil I think that the discussion regarding vital components such as loop avoidance and loop detection & correction techniques can take place even without a draft. I am working on a draft but I would like to discuss these things on the mailing list as well. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Monday, July 13, 2009 12:42:49 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P routing On Jul 12, 2009, at 11:56 AM, Mukul Goyal wrote: > The tree/DAG based P2P routing proposed in RPL may not be desirable > in many situations. > > Here is the outline of an alternative P2P routing solution: > > 1. The P2P routing would follow a basic DV approach, where nodes > would advertize their "cost" to various destinations in > Hello/"Router Advertisement" messages and next-hop(s) selection (for > a destination) is based on the advertised costs by neighbors. > 1.1 A node may solicit advertisements from its neighbors > regarding a destination. > 1.2 The generation of Hello messages may follow a trickle-like > approach. > 1.3 In the absence of new advertisements about a destination from > a neighbor, the perceived cost of reaching the destination through > this neighbor deteriorates with time. > > 2. The LLN would be divided into "domains" such that (costs to) > destinations in one domain would be advertized (in Hello messages)by > nodes within that domain only. This is to limit the destinations a > node may have to advertize. There may be some _super_ destinations > that can be advertised across domains. > > 3. There is no loop avoidance/prevention. > > 4. There is a loop detection and correction mechanism in place. > Periodically, a source node would send a control packet towards the > destination. This packet accumulates the path it travels over. If a > receiving node finds itself already listed in the path, the routing > loop is detected. The node corrects the loop by excluding and > punishing the offending nexthop. > > Please comment. In wireless protocols, the devil tends to be in the details. I'd want to see a detailed protocol description before commenting. Phil From wintert@acm.org Tue Jul 14 06:34:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED32F3A6CCA for ; Tue, 14 Jul 2009 06:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8fPQ9Zt9HXW for ; Tue, 14 Jul 2009 06:34:46 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id 2F6083A67E6 for ; Tue, 14 Jul 2009 06:34:09 -0700 (PDT) Received: (qmail 73607 invoked from network); 14 Jul 2009 13:33:06 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 14 Jul 2009 06:33:06 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: uNrvQCoVM1m1Eky.cnwRXAEYY.SpKjLeFr6rUTSG6CzUMFYLjZZVD.d9OwjYd3Y0q9NDFd7c8fmuncGFnofkE.zlWghsF00OvwecV2ZK4a3hugO7oiQeyMQzuzRIyoR0fY77mqgBQVpYs8_mhIWppnEqVGTtpsrBh5z3bLJa6h5.U52_bBjMIJlEDvlBAAoiRpkPnaau_qAGWjqDptd9Mrqwxu61gxyj.hZBtaqL1OIKaIb3TbGxNymi8CYhaY39Dp1_RvAPYQg2Zqq.cinFO21FK6YZJvdHxhHcAOI7_Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5C890A.9080506@acm.org> Date: Tue, 14 Jul 2009 09:32:58 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG References: <20090713215647.1668228C642@core3.amsl.com> In-Reply-To: <20090713215647.1668228C642@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] New Version Notification for draft-dt-roll-rpl-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 13:34:47 -0000 WG, We have posted a new revision of RPL to account for some of the feedback so far- Changes in this revision include: - Clarifications and additional examples of RPL mechanisms - Introduction of Objective Code Points - cleanup some nits The clarifications reflect some of the discussion and feedback that we have had on the WG list, in order to better demonstrate what RPL is about. The Objective Code Point is a proposed way to handle the issue of multiple metrics and optimization objectives in a way that decouples policy (application/implementation specific) from the protocol, but not so much at the cost of optimization as the prior proposal. The Objective Code Point is a value signaled along the DAG in DIOs that is intended to index a Registry in order to define: - What metrics are in use - What are the optimization goals (objective function) with the metrics? - How is depth calculated In this way nodes in the DAG may become aware of what optimizations and metrics are in use. For example, an OCP may indicate that ETX is being minimized, and the consideration of depth for loop avoidance purposes should closely track ETX. In a future draft we can refine the expected (default) behaviors for a node that does not understand the OCP in use. Other issues (suppression mechanism, ...) that have been raised on the list have not yet been explicitly addressed in this draft. Thanks to everyone who has provided inputs and feedback thus far. Regards, -Tim IETF I-D Submission Tool wrote: > A new version of I-D, draft-dt-roll-rpl-01.txt has been successfuly submitted by Tim Winter and posted to the IETF repository. > > Filename: draft-dt-roll-rpl > Revision: 01 > Title: RPL: Routing Protocol for Low Power and Lossy Networks > Creation_date: 2009-07-12 > WG ID: Independent Submission > Number_of_pages: 69 > > Abstract: > This document specifies the Routing Protocol for Low Power and Lossy > Networks (RPL), in accordance with the requirements described in > [I-D.ietf-roll-building-routing-reqs], > [I-D.ietf-roll-home-routing-reqs], > [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. > > > > The IETF Secretariat. > > > From Peter.Burnett@philips.com Tue Jul 14 07:30:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5523A6AC3 for ; Tue, 14 Jul 2009 07:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyAdmWsx1+-T for ; Tue, 14 Jul 2009 07:30:18 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 4AE133A6EDB for ; Tue, 14 Jul 2009 07:30:18 -0700 (PDT) Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 14 Jul 2009 16:29:36 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.32]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Tue, 14 Jul 2009 16:29:27 +0200 From: "Burnett, Peter" To: "roll@ietf.org" Date: Tue, 14 Jul 2009 16:29:27 +0200 Thread-Topic: [Roll] Questions about multiple DAGs Thread-Index: AcoEjcy1nDCAFVt3Q7e6J9HwQsDaXgAAVvYg Message-ID: <8E9C227490A7614B87D90C0AE18CF22CBC938EE3CD@NLCLUEXM06.connect1.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8E9C227490A7614B87D90C0AE18CF22CBC938EE3CDNLCLUEXM06con_" MIME-Version: 1.0 Subject: [Roll] Questions about multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 14:30:23 -0000 --_000_8E9C227490A7614B87D90C0AE18CF22CBC938EE3CDNLCLUEXM06con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The RPL spec describes the use of multiple DAGs to provide different routin= g constraints to the same DAG root but doesn't really describe their use to= provide collection paths towards multiple roots. It seems that one such us= e case would be for BACNET concentrators having lots of sensor devices atta= ched. The sensors only talk to one particular BACNET concentrator and each = concentrator consolidates the information to be sent elsewhere possibly ove= r the grounded DAG. In this case the BACNET concentrator could start its ow= n DAG for which it is the root. The path from a sensor to the concentrator = DAG may have the opposite direction from the path to the grounded DAG root.= Is that an intended use case? Some questions arise: 1. Given resource constraints how do routers decide which DAGs to att= ach to and which to ignore? For instance, a sensor may not be within radio = range of its BACNET concentrator and so require an intermediate router to j= oin the BACNET concentrator DAG to route its messages even though that inte= rmediate router doesn't need to belong the BACNET concentrator DAG. 2. If a device has joined several DAGs and requires to send a P2P mes= sage how does it decide which DAG root to direct it towards? Thanks Peter Burnett ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_8E9C227490A7614B87D90C0AE18CF22CBC938EE3CDNLCLUEXM06con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RPL spec describes the use of multiple DAGs to p= rovide different routing constraints to the same DAG root but doesn’t= really describe their use to provide collection paths towards multiple roo= ts. It seems that one such use case would be for BACNET concentrators having lots of sensor devices attached. The se= nsors only talk to one particular BACNET concentrator and each concentrator= consolidates the information to be sent elsewhere possibly over the ground= ed DAG. In this case the BACNET concentrator could start its own DAG for which it is the root. The path fr= om a sensor to the concentrator DAG may have the opposite direction from th= e path to the grounded DAG root. Is that an intended use case?

 

Some questions arise:

1.     &= nbsp; Given resource constraints how do routers decide wh= ich DAGs to attach to and which to ignore? For instance, a sensor may not b= e within radio range of its BACNET concentrator and so require an intermedi= ate router to join the BACNET concentrator DAG to route its messages even though that intermediate router doesn’= ;t need to belong the BACNET concentrator DAG.

2.     &= nbsp; If a device has joined several DAGs and requires to= send a P2P message how does it decide which DAG root to direct it towards?=

 

Thanks

Peter Burnett

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_8E9C227490A7614B87D90C0AE18CF22CBC938EE3CDNLCLUEXM06con_-- From russ@cisco.com Tue Jul 14 08:38:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03E43A6D06 for ; Tue, 14 Jul 2009 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHe7cKz50ZQW for ; Tue, 14 Jul 2009 08:38:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 925CD3A6AF8 for ; Tue, 14 Jul 2009 08:38:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,398,1243814400"; d="scan'208";a="50383179" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2009 15:34:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6EFYAh6029261; Tue, 14 Jul 2009 11:34:10 -0400 Received: from [127.0.0.1] (rtp-vpn3-1691.cisco.com [10.82.222.162]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6EFY96a018608; Tue, 14 Jul 2009 15:34:09 GMT Message-ID: <4A5CA567.1020906@cisco.com> Date: Tue, 14 Jul 2009 11:33:59 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> <4A546EA8.7000506@gmail.com> <8142BFBB-A593-4AA4-9D20-2D0B788CADD2@gmail.com> <71002404-9343-4A63-8C29-B0D683BC8CF0@cisco.com> In-Reply-To: <71002404-9343-4A63-8C29-B0D683BC8CF0@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1379; t=1247585650; x=1248449650; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=russ@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20the=0A=20ro ot? |Sender:=20 |To:=20JP=20Vasseur=20; bh=8h6bQW9BnwXMSdwkCXcpMlYEorZ0ePAJ+M8BJM8eDpk=; b=d0/qjsqRti1+TVuLjJ/DEhbkMW007Y7ZZGrJUXWpH0moQspTYQyZoRLubf wuwlDMJncpFLMtg7RJGq++RH22qbwCmq4UFZlSJPXYp+mTZ05LWKR0h9kOxU ip/eUquFlR; Authentication-Results: rtp-dkim-1; header.From=russ@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org, Philip Levis Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 15:38:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Case A: Source (3) -> X (2) -> Y (3) -> X (2) -> Y (3) >> >> or >> >> Case B: Source (3) -> X (2) -> Y (2) -> X (2) >> >> These can occur when a node changes its route and updates its gradient >> value but its children have not yet learned the new value. E.g., the >> link between Y and Z breaks, leading to case A, where Y's best choice >> for a next hop is X. > > But the loop is transient. Note that the exact same situation exist with > link state protocol, we call it a micro-loop since it is quickly resolve > but time scale are different and although loop duration may be much > shorter, the number of impacted packets may be much larger. Yes--this isn't what we would call a loop, but a transient loop, because it resolves itself. RIP and BGP do the same thing. In fact, there is only one routing protocol in widespread use that doesn't have microloops, as far as I know. :-) Russ - -- riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone What makes us happy in life is not what we've acquired. What makes us happy in life is what we appreciate. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpcpWYACgkQER27sUhU9OROygCfaiXIgjh5sjTQAOeEduZMpSRD 5kMAniLYQd20W9bZsTp9BgZEyuSDTiQ1 =Occ3 -----END PGP SIGNATURE----- From wintert@acm.org Tue Jul 14 10:04:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6D23A6D56 for ; Tue, 14 Jul 2009 10:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9edrlzo-F6gm for ; Tue, 14 Jul 2009 10:04:44 -0700 (PDT) Received: from smtp109.prem.mail.ac4.yahoo.com (smtp109.prem.mail.ac4.yahoo.com [76.13.13.92]) by core3.amsl.com (Postfix) with SMTP id 4977928C10E for ; Tue, 14 Jul 2009 10:04:15 -0700 (PDT) Received: (qmail 69968 invoked from network); 14 Jul 2009 17:03:58 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp109.prem.mail.ac4.yahoo.com with SMTP; 14 Jul 2009 10:03:58 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 00LVXo8VM1kWjibpE1XQUU9aRMDRuKmDvTpLEfnRaODxufq9KChHCtVF0fmsRlY0.znpmyZJk31HXLiRc4WlsIz_ajE1ZJKF8tSyoU6Kqr.k.Pp7LqqExrE93W.ifF3oERFNmoX5cYMlbYVvcJlsP4ZDiIpQpJXpLadOYjJVKVYWn0hdMm2dKKhTJLUInomgjFdm.wCuoBQ0NzODJdonXOC5Kj90Zv5Nca73YdL0azAlmKU01iXP4RhiXyJ8gQcVut0MoWtWG2CmdghcLvRifyitN.ZHO_u2Be2h2xKSSiSH2w.yA4EvHQ6pdXHLVMjcFGJhwUIBG.jkOicZ0X9zwor5dYpKJdy_PkeP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5CBA79.9060400@acm.org> Date: Tue, 14 Jul 2009 13:03:53 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> <4A5AF7F9.1050407@gmail.com> <2a3692de0907130527l67f6caf3w8d65bc6fcda19b1c@mail.gmail.com> In-Reply-To: <2a3692de0907130527l67f6caf3w8d65bc6fcda19b1c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:04:45 -0000 Hi Alex, Dominik, Dominik Kaspar wrote: > Hi, > > I am also curious about an answer to the question about the number of > interfaces on a ROLL node. Are there any existing sensor network nodes > with a "tiny" form factor, that utilize multiple physical interfaces? > > By the way... it might be a good idea to put all the terminology of > the RPL draft into the already existing terminology document. > > Greetings, > Dominik > One transceiver, e.g. one physical interface, seems to be a general case with LLN nodes. But there may be multiple logical interfaces as necessary to support the routing function, depending in part on the subnetwork design / how the link layer technology interfaces to IP. Regarding the underlying implementation of link-local multicast and related subnetwork issues, I think that RFC3819 provides a great starting point to understand how a particular link layer technology might be interfaced to IP, and by extension a ROLL routing solution. The details of this should be outside of the scope of ROLL. --Tim > > On Mon, Jul 13, 2009 at 11:01 AM, Alexandru > Petrescu wrote: >> The routing proposed in RPL does not say how many interfaces a sensor >> has, and in some of its pictures shows a sensor with as many as 8 >> interfaces. I believe this was not the intention. >> >> However, my interpretation of it does not mean that it is clearer. >> >> How many interfaces does a ROLL node have? >> >> What is the subnet structure in a ROLL network? Are all sensors in the >> same IP subnet? Or not? Is there a subnet uniquely between each each >> two points? Or not? >> >> Can IPv6 use link-local multicast in RPL? Or not? >> >> Without these things clear it is impossible to design a dynamic routing >> protocol, let alone an IP addressing structure, not even a static >> routing mechanism. >> >> Deciding distance-vector vs link-state vs path-vector, or proactive vs >> reactive, or source-routing vs table-based routing, or stateful routing >> vs soft-state vs hard-state routing is too early. >> >> TO clarify the IP addressing things (mandatorily preceding what RPL has to >> design), I am optimistically waiting for results of AUTOCONF DT, a draft >> seems to be out about it, but that seems to go against my opinions too :-) >> >> Yours, >> >> Alex >> >> Mukul Goyal a crit : >>> The tree/DAG based P2P routing proposed in RPL may not be desirable in >>> many situations. >>> >>> Here is the outline of an alternative P2P routing solution: >>> >>> 1. The P2P routing would follow a basic DV approach, where nodes would >>> advertize their "cost" to various destinations in Hello/"Router >>> Advertisement" messages and next-hop(s) selection (for a >>> destination) is based on the advertised costs by neighbors. 1.1 A >>> node may solicit advertisements from its neighbors regarding a >>> destination. 1.2 The generation of Hello messages may follow a >>> trickle-like approach. 1.3 In the absence of new advertisements about >>> a destination from a neighbor, the perceived cost of reaching the >>> destination through this neighbor deteriorates with time. >>> >>> 2. The LLN would be divided into "domains" such that (costs to) >>> destinations in one domain would be advertized (in Hello messages)by nodes >>> within that domain only. This is to limit the destinations a node may have >>> to advertize. There may be some _super_ destinations that can be advertised >>> across domains. >>> >>> 3. There is no loop avoidance/prevention. >>> >>> 4. There is a loop detection and correction mechanism in place. >>> Periodically, a source node would send a control packet towards the >>> destination. This packet accumulates the path it travels over. If a >>> receiving node finds itself already listed in the path, the routing loop is >>> detected. The node corrects the loop by excluding and punishing the >>> offending nexthop. >>> >>> Please comment. >>> >>> Thanks Mukul _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Jul 14 10:26:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A5F3A6A22 for ; Tue, 14 Jul 2009 10:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hGUTII5XFMv for ; Tue, 14 Jul 2009 10:26:16 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 417933A68B6 for ; Tue, 14 Jul 2009 10:26:14 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 32E42D4818C; Tue, 14 Jul 2009 19:25:31 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D8AE0D48130; Tue, 14 Jul 2009 19:25:28 +0200 (CEST) Message-ID: <4A5CBF81.50103@gmail.com> Date: Tue, 14 Jul 2009 19:25:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tim Winter References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> <4A5AF7F9.1050407@gmail.com> <2a3692de0907130527l67f6caf3w8d65bc6fcda19b1c@mail.gmail.com> <4A5CBA79.9060400@acm.org> In-Reply-To: <4A5CBA79.9060400@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090713-0, 13/07/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:26:18 -0000 Hello Tim, Tim Winter a crit : > Hi Alex, Dominik, > > Dominik Kaspar wrote: >> Hi, >> >> I am also curious about an answer to the question about the number >> of interfaces on a ROLL node. Are there any existing sensor network >> nodes with a "tiny" form factor, that utilize multiple physical >> interfaces? >> >> By the way... it might be a good idea to put all the terminology of >> the RPL draft into the already existing terminology document. >> >> Greetings, Dominik >> > > One transceiver, e.g. one physical interface, seems to be a general > case with LLN nodes. But there may be multiple logical interfaces as > necessary to support the routing function, depending in part on the > subnetwork design / how the link layer technology interfaces to IP. I doubt a constrained device has enough resources to implement logical or virtual interfaces. If however it _is_ the case that a ROLL device has several interfaces then there must be at least one physical interface and there should be a clear relationship in terms of addressing and routing between the logical virtual interface(s) and the physical one. What addresses are on what interfaces and what routes from which interface to which one. For example, when the draft-01 pictures a ROLL device with two interfaces - does it mean that one is physical and the other logical? Or both are logical and the physical transceiver is absent from the picture? If this is not clarified and if we continue to assume only one physical interface then this risks being very theoretical to my reading. > Regarding the underlying implementation of link-local multicast and > related subnetwork issues, I think that RFC3819 provides a great > starting point to understand how a particular link layer technology > might be interfaced to IP, and by extension a ROLL routing solution. > The details of this should be outside of the scope of ROLL. I think the RPL draft should at least say the ROLL node does join all the link-layer multicast groups as suggested in a certain IPv6 RFC. It should also say on which interface it does this joining (the logical? the physical?) I think it would be attractive for ROLL protocol to run over link layers which do support multicast: is this a requirement? Or could RPL run over link-layers which don't support link-layer multicast? Just some remarks, and thank you for the quick earlier incorporation of some of my previous remarks, Alex > > --Tim > >> On Mon, Jul 13, 2009 at 11:01 AM, Alexandru >> Petrescu wrote: >>> The routing proposed in RPL does not say how many interfaces a >>> sensor has, and in some of its pictures shows a sensor with as >>> many as 8 interfaces. I believe this was not the intention. >>> >>> However, my interpretation of it does not mean that it is >>> clearer. >>> >>> How many interfaces does a ROLL node have? >>> >>> What is the subnet structure in a ROLL network? Are all sensors >>> in the same IP subnet? Or not? Is there a subnet uniquely >>> between each each two points? Or not? >>> >>> Can IPv6 use link-local multicast in RPL? Or not? >>> >>> Without these things clear it is impossible to design a dynamic >>> routing protocol, let alone an IP addressing structure, not even >>> a static routing mechanism. >>> >>> Deciding distance-vector vs link-state vs path-vector, or >>> proactive vs reactive, or source-routing vs table-based routing, >>> or stateful routing vs soft-state vs hard-state routing is too >>> early. >>> >>> TO clarify the IP addressing things (mandatorily preceding what >>> RPL has to design), I am optimistically waiting for results of >>> AUTOCONF DT, a draft seems to be out about it, but that seems to >>> go against my opinions too :-) >>> >>> Yours, >>> >>> Alex >>> >>> Mukul Goyal a crit : >>>> The tree/DAG based P2P routing proposed in RPL may not be >>>> desirable in many situations. >>>> >>>> Here is the outline of an alternative P2P routing solution: >>>> >>>> 1. The P2P routing would follow a basic DV approach, where >>>> nodes would advertize their "cost" to various destinations in >>>> Hello/"Router Advertisement" messages and next-hop(s) selection >>>> (for a destination) is based on the advertised costs by >>>> neighbors. 1.1 A node may solicit advertisements from its >>>> neighbors regarding a destination. 1.2 The generation of Hello >>>> messages may follow a trickle-like approach. 1.3 In the absence >>>> of new advertisements about a destination from a neighbor, the >>>> perceived cost of reaching the destination through this >>>> neighbor deteriorates with time. >>>> >>>> 2. The LLN would be divided into "domains" such that (costs to) >>>> destinations in one domain would be advertized (in Hello >>>> messages)by nodes within that domain only. This is to limit the >>>> destinations a node may have to advertize. There may be some >>>> _super_ destinations that can be advertised across domains. >>>> >>>> 3. There is no loop avoidance/prevention. >>>> >>>> 4. There is a loop detection and correction mechanism in place. >>>> Periodically, a source node would send a control packet >>>> towards the destination. This packet accumulates the path it >>>> travels over. If a receiving node finds itself already listed >>>> in the path, the routing loop is detected. The node corrects >>>> the loop by excluding and punishing the offending nexthop. >>>> >>>> Please comment. >>>> >>>> Thanks Mukul _______________________________________________ >>>> Roll mailing list Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From wintert@acm.org Tue Jul 14 10:29:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0763A68B6 for ; Tue, 14 Jul 2009 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjgWRK7D37ZL for ; Tue, 14 Jul 2009 10:29:52 -0700 (PDT) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id 57B4D3A682F for ; Tue, 14 Jul 2009 10:29:52 -0700 (PDT) Received: (qmail 9945 invoked from network); 14 Jul 2009 17:28:48 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 14 Jul 2009 10:28:47 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: PzHDGOYVM1m5kCgSxpNcOLLCrP1bk2ZSZyXTIMrfnziZjLGobQmhQ.RoiQOIpM3lRfz6Zzjp__A5.321w1pPvqypIJlhsvt1F1W8i.YuMgIc4XigfAHxlPkD5e_0eem59oXwjhb_GmbHO_QjzAf.lrUuMRRtpwzHH8BChOOY3SNnMFmfKJmincLZujnjRZPNeozPJ5TUpV.jbmiZwOyBjrUx2Td4SFybrpE7IC0KJkPPequNEj2l0kYq38TKQ2VgHqeNmX7JEv96m8CIJsgxK8EJU6_6k3WKyxpwkUrEbFHxCiz8otRPVlhtwRgNSgxXErCbLWx3V9ZpQv6EjhWqljWLowUgiUjjPtZb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5CC04C.3090404@acm.org> Date: Tue, 14 Jul 2009 13:28:44 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu><87y6r7w0cy.fsf@kelsey-ws.hq.ember.com><69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com><87vdmbvvu4.fsf@kelsey-ws.hq.ember.com><84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com><87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DDA@xmb-ams-337.emea.cisco.com> <87ocryvsu4.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07B94241@xmb-ams-337.emea.cisco.com> <87k52lwwff.fsf@kelsey-ws.hq.ember.com> <87bpnxfn1a.fsf@kelsey-ws.hq.ember.com> <14339.1247483031@marajade.sandelman.ca> In-Reply-To: <14339.1247483031@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from theroot? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:29:53 -0000 Hi Michael, Michael Richardson wrote: > >>>>>> "Richard" == Richard Kelsey writes: > Richard> precision. Both are fruitful, but are unfortunately at odds. > > Richard> With hop count neighbors are either: > Richard> parents (lower hop count) > Richard> siblings (same hop count) > Richard> ignored (higher hp count) > > Richard> With a more precise metric, where the optimal link has cost k, > Richard> neighbors can be divided into four categories: > Richard> parents (cost less by k or more) > Richard> inward siblings (cost less by k-1 or less) > Richard> siblings (same cost) > Richard> ignored (higher cost) > > Richard> In either case, forwarding via siblings or 'ignored' can > Richard> send a message around a loop. Forwarding via parents or > Richard> inward siblings cannot. > > Let's say that I have a network that looks like this: > > R > / \ > X Y > | | > A B > / \ / \ > C D E > > I thought that one of the goals of this protocol was such that one > could have a route E->B->D->A->X-R as well as a route E->B->Y->R for the > situation where X had a good power supply, while Y had a power budget. > or is this handled by another part of the protocol? > > If Y shows a high enough hop-cost to prefer the longer route, then it > never gets used, which perhaps is an issue if the links are at capacity. > > This is why I do not understand the focus on a DAG, when I thought > that the problem was more complex. (Back to reading the documents and > this long thread) > First, I would like to clarify (just in case there is any doubt) that RPL is not generally trying to minimize hop count. ;) (Although it could if that was the defined metric and optimization goal). Finding the `least cost' path across multiple intermediate nodes according to some metric using distance vector protocols should tend to yield a tree- allowing for multiple choices of parents is how we get to a DAG. RPL is capable to employ whatever metrics and objective functions that have been defined in a particular implementation in order to construct the least-cost DAG to the DAG Root. (As a *consequence*, a node takes up a position in a DAG, has a related rank (depth), and this is taken advantage of for some loop avoidance as the DAG undergoes maintenance -- which is another topic). In your example, if I understand right, you want to use one path (E->B->D->A->X->R) when you want to avoid node Y, e.g. to avoid using Y's limited energy, and to use path E->B->Y->R in another case, e.g. to reduce latency. In the case you have stated as I understand it, it is really as if you are trying to maintain 2 routing topologies, one to minimize energy (where using Y is expensive) and one to minimize latency/hop-count (where avoiding Y is expensive). In this case, RPL would in fact construct 2 DAGs, both rooted at `R'. One DAG would be constructed using the `min latency' objective and the second with the `min energy' objective. If we follow the conventions of the recently posted -01 draft, each DAG would be defined by a different Objective Code Point (OCP)- one to indicate the `min latency' goal and one for the `min energy' goal. Subsequently, the traffic would have to be marked in the IPv6 header in such a way that it can follow the correct DAG. For example, a particular Traffic Class might follow the `min latency' DAG by administrative convention, and all other traffic might default to the `min energy' DAG. To extend your example, the use of multiple metrics does not necessarily mean that RPL must maintain multiple DAGs. In some cases it may be possible/appropriate to define a `synthesis' function that digests/weights multiple metrics into a single scalar value and subsequently uses that scalar for the purpose of finding the least cost path. In the case of RPL this is not part of the core specification, but would be application/implementation specific and defined in the specification of a particular OCP. Does this help? -Tim _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Tue Jul 14 11:25:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E723A6A79 for ; Tue, 14 Jul 2009 11:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 ayO21haAJ12A for ; Tue, 14 Jul 2009 11:25:17 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5FBD43A69EB for ; Tue, 14 Jul 2009 11:25:17 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 14:23:35 -0400 Date: Tue, 14 Jul 2009 14:24:15 -0400 Message-Id: <87tz1funqo.fsf@kelsey-ws.hq.ember.com> To: "Burnett, Peter" In-reply-to: <8E9C227490A7614B87D90C0AE18CF22CBC938EE3CD@NLCLUEXM06.connect1.local> (Peter.Burnett@philips.com) From: Richard Kelsey References: <8E9C227490A7614B87D90C0AE18CF22CBC938EE3CD@NLCLUEXM06.connect1.local> X-OriginalArrivalTime: 14 Jul 2009 18:23:35.0968 (UTC) FILETIME=[3395A200:01CA04B0] Cc: roll@ietf.org Subject: Re: [Roll] Questions about multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 18:25:18 -0000 Peter, > From: "Burnett, Peter" > Date: Tue, 14 Jul 2009 16:29:27 +0200 > > The RPL spec describes the use of multiple DAGs to provide different > routing constraints to the same DAG root but doesn't really describe > their use to provide collection paths towards multiple roots. The RPL draft doesn't say much about which nodes are the roots of floating DAGs. Presumably any node can be a floating root, although resource constraints may become a problem if too many nodes become roots. > Some questions arise: > > 1. Given resource constraints how do routers decide which DAGs to > attach to and which to ignore? For instance, a sensor may not be > within radio range of its BACNET concentrator and so require an > intermediate router to join the BACNET concentrator DAG to route its > messages even though that intermediate router doesn't need to belong > the BACNET concentrator DAG. Having every node join every DAG clearly won't scale. My suggestion would be to recommend that nodes join as many DAGs as resources permit, with preference given to 1. joining at least one grounded DAG 2. DAGs with lower depth in that order. It might also make sense to allow a DAG to have a maximum DAGDepth, either in the DIO Base or as a suboption. We might want to consider having a suboption that specifies a service type. Currently there is only one service that is differentiated, namely having a default route. Having other service options would allow nodes to differentiate between DAGs in order to have a complete set of services available. > 2. If a device has joined several DAGs and requires to send a P2P > message how does it decide which DAG root to direct it towards? Absent any other route information, I would assume it would be forwarded using the grounded DAG with the least depth. -Richard Kelsey From Peter.Burnett@philips.com Tue Jul 14 14:24:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65823A677E for ; Tue, 14 Jul 2009 14:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 jBgc+lvkPNUM for ; Tue, 14 Jul 2009 14:24:32 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id C04453A67E1 for ; Tue, 14 Jul 2009 14:23:55 -0700 (PDT) Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 14 Jul 2009 23:08:19 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.32]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Tue, 14 Jul 2009 23:08:25 +0200 From: "Burnett, Peter" To: Richard Kelsey Date: Tue, 14 Jul 2009 23:08:24 +0200 Thread-Topic: [Roll] Questions about multiple DAGs Thread-Index: AcoEsDFIrO4SFlDkTQK8Y9HOTeDYAAAFDHI1 Message-ID: <8E9C227490A7614B87D90C0AE18CF22CBC938484C4@NLCLUEXM06.connect1.local> References: <8E9C227490A7614B87D90C0AE18CF22CBC938EE3CD@NLCLUEXM06.connect1.local>, <87tz1funqo.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87tz1funqo.fsf@kelsey-ws.hq.ember.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Questions about multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:24:33 -0000 Richard Kelsey wrote: > Having every node join every DAG clearly won't scale. > My suggestion would be to recommend that nodes join > as many DAGs as resources permit, with preference > given to > 1. joining at least one grounded DAG > 2. DAGs with lower depth > in that order. It might also make sense to allow a > DAG to have a maximum DAGDepth, either in the DIO Base > or as a suboption. > For a permanent floating DAG (i.e. not one temporarily detached from the gr= ounded DAG) how about operating a locking scheme using something a bit like= datapath feedback. So a router receiving RA-DIO from such a DAG will attac= h for a timeout period. Then any device wanting to talk to that DAG root wi= ll trickle back a DAO containing a path length slightly larger than the pat= h length through its worst parent. This will be decremented en-route. If an= intervening router sees that the remaining path length is greater than the= path length to the DAG root then it locks the DAG attachment. If it is les= s it discards the DAO and the DAG attachment will be timed out. This way on= ly the intervening routers on the best routes from the device to the root w= ill remain attached to the DAG. (I know DAOs are not trickled right now but= it has to be something like that) > We might want to consider having a suboption that specifies > a service type. Currently there is only one service that is > differentiated, namely having a default route. Having other > service options would allow nodes to differentiate between > DAGs in order to have a complete set of services available. That sounds good Peter Burnett The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From anand@ekasystems.com Tue Jul 14 16:49:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6083A68E6 for ; Tue, 14 Jul 2009 16:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QLZ3cPzMNG5 for ; Tue, 14 Jul 2009 16:49:47 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id E13593A6B55 for ; Tue, 14 Jul 2009 16:49:28 -0700 (PDT) Received: (qmail 12506 invoked from network); 14 Jul 2009 23:13:46 -0000 Received: from unknown (HELO ?10.0.2.15?) (anand@71.252.109.221 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 14 Jul 2009 23:13:46 -0000 X-Yahoo-SMTP: 3TTE9ZuswBDjm418o.Cs96VdW5xVWZ0m0ORthqgtzk2N X-YMail-OSG: X0M4eP8VM1kqQfUALWFY5mgo52WsHz03d.diLKzxPx24g7mWI0_udeHFAOScWBC4MON4weQpnvgHVjDca_LdpBteMgnSmAmtF6H82IbfW27zpaYfkoR5FUBcMiEFquAsOSXTk.BZvJzNObEhsXcMHsgNSddwDbwxMIR_zed1g_mYOnlEmjJr5zu2W0AKb3tPraE4PHNHG3mO5uo9hjaNrVTACs1QRJmhNOATExl9nI871Ze1YmLvGP.5PcFHjT92V9WgiE7BBFxCiNfcKy4zrmK39QxN75Ss0Z2grJ_RxTgL.u9WyHTwXHOJBocHy523UtRU819U5xXCwT9JsR.Ns6xMvdkv9NG_DA_S5Q0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5D1129.1050606@ekasystems.com> Date: Tue, 14 Jul 2009 19:13:45 -0400 From: "M. B. Anand" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: roll References: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <797210522.1715541247425000693.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 23:49:52 -0000 Mukul, In *very* general terms, nothing wrong this approach. By personal experience, pretty much this approach - with added optimizations - has been used for networks of over 10s of K nodes with "domains", as you called them, over 2K or so nodes. (sorry, no public reference). The ideas of RFC 2091, using incremental updates, can be very effective as well. The ROLL protocol survey, draft-ietf-roll-protocols-survey-07 mentions this. If the "divided" into domains is supposed to be automatic and nodes can change domains - and thus drag other nodes into and out of domains - that introduces a whole new set of complications involving marking and purging destinations and you probably would not be able to avoid counting up. Keep in mind in all of this though, the fundamental point is, simply put, the price you pay for generally optimal peer-to-peer routing is a massive explosion of state information to be maintained and exchanged - every node pretty much has to form a tree rooted at itself. Lot of memory to keep all destinations. On top of that, given typical bandwidth restrictions, and consequently the rate and scope of dissemination that is feasible, it has never been quite clear if in fact optimality (in shortest path terms) can really be achieved in real-life large networks. For a good general discussion of this, please see BBN Technical Memorandum No. 1301 (available at www.ir.bbn.com/documents/techmemos/TM1301.ps) Trees and DAGs being discussed in the LLN context all attempt to minimize state information by trying to take advantage of certain (presumed) flow properties to sacrifice some generality and gain the corresponding simplicity benefit. Of course, the application you envision may only require, or is capable of providing, very small domains. In which case, full circle, you might want to consider: is the stretch you will presumably get with DAGs and trees worth the price of the much larger complexity of general optimal peer-to-peer routing ? Because it will be, much more complex I mean. Regards, Anand. > The tree/DAG based P2P routing proposed in RPL may not be desirable in many situations. > > Here is the outline of an alternative P2P routing solution: > > 1. The P2P routing would follow a basic DV approach, where nodes would advertize their "cost" to various destinations in Hello/"Router Advertisement" messages and next-hop(s) selection (for a destination) is based on the advertised costs by neighbors. > 1.1 A node may solicit advertisements from its neighbors regarding a destination. > 1.2 The generation of Hello messages may follow a trickle-like approach. > 1.3 In the absence of new advertisements about a destination from a neighbor, the perceived cost of reaching the destination through this neighbor deteriorates with time. > > 2. The LLN would be divided into "domains" such that (costs to) destinations in one domain would be advertized (in Hello messages)by nodes within that domain only. This is to limit the destinations a node may have to advertize. There may be some _super_ destinations that can be advertised across domains. > > 3. There is no loop avoidance/prevention. > > 4. There is a loop detection and correction mechanism in place. Periodically, a source node would send a control packet towards the destination. This packet accumulates the path it travels over. If a receiving node finds itself already listed in the path, the routing loop is detected. The node corrects the loop by excluding and punishing the offending nexthop. > > Please comment. > > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Wed Jul 15 00:37:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60E028C0D9 for ; Wed, 15 Jul 2009 00:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.989 X-Spam-Level: X-Spam-Status: No, score=-7.989 tagged_above=-999 required=5 tests=[AWL=-1.991, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTkos4MDW9Ks for ; Wed, 15 Jul 2009 00:37:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF63F3A6828 for ; Wed, 15 Jul 2009 00:37:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8FAFYjXUqrR7PD/2dsb2JhbACCJxUYhTivdIgjkG4FhAk X-IronPort-AV: E=Sophos;i="4.42,403,1243814400"; d="scan'208,217";a="186201365" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2009 07:36:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6F7aPE7027168 for ; Wed, 15 Jul 2009 00:36:25 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6F7aOU5008988 for ; Wed, 15 Jul 2009 07:36:25 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:36:18 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 09:36:17 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-211-900720924 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 09:36:16 +0200 References: <15443.1247484449@marajade.sandelman.ca> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 15 Jul 2009 07:36:17.0785 (UTC) FILETIME=[F0A2F690:01CA051E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4426; t=1247643385; x=1248507385; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20section=203.3.1.2 |Sender:=20; bh=D0hTnYD8dgFAUwbU8Wf3UMF0HTpOO4QWmEiDWaX4W7E=; b=eLxrDwZj6I1qw8oD7VJCjO/UTwt3sV/nclxEisJHaIPAWkGGOVKuXWR1H6 LyDJfzXJLjNgpBeDvlBPr8bF5QTbwKtqMAQrRwKpDsHv/CTTX/NbgcrCX/ia qGl1BKG1hr; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] Fwd: section 3.3.1.2 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 07:37:09 -0000 --Apple-Mail-211-900720924 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: Michael Richardson > Date: July 13, 2009 1:27:29 PM CEDT > To: dtroll@external.cisco.com > Subject: section 3.3.1.2 > > > You write: > > includes paths through siblings. Consider Node (24) in the DAG > Example depicted in Figure 2, with reference to the connectivity in > Figure 1. In this example, the shadow cone of Node (42) is =20 > comprised > of Nodes (53), (54), (55), and Nodes (51), (52), and (56) through > sibling paths. If (51), (52), and (56) had any nodes in their sub- > DAGs, the shadow cone would grow accordingly. > > You mention Node (24), and then talk about Node (42). > Typo? > > --=20 > ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | =20= > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net =20= > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |=20 > device driver[ > ] h("Just another Debian GNU/Linux using, kernel hacking, =20 > ruby guy"); [ > --Apple-Mail-211-900720924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = Michael Richardson <mcr@sandelman.ottawa.on.ca&= gt;
Date: July 13, 2009 1:27:29 PM = CEDT
Subject: section 3.3.1.2


You = write:

  includes paths through siblings. =  Consider Node (24) in the DAG
  Example depicted in = Figure 2, with reference to the connectivity in
  Figure = 1.  In this example, the shadow cone of Node (42) is comprised
=   of Nodes (53), (54), (55), and Nodes (51), (52), and (56) = through
  sibling paths.  If (51), (52), and (56) had = any nodes in their sub-
  DAGs, the shadow cone would grow = accordingly.

You mention Node (24), and then talk about Node = (42).
Typo?

--
]     Y'avait une poule = de jamm=E9 dans l'muffler!!!!!!!!! =        |  firewalls  [
] =   Michael Richardson, Sandelman Software Works, Ottawa, ON =    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on= .ca/ |device driver[
]    h("Just another Debian = GNU/Linux using, kernel hacking,    ruby  guy"); =  [


= --Apple-Mail-211-900720924-- From quentin.lampin@orange-ftgroup.com Wed Jul 15 04:18:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D7C3A68B9 for ; Wed, 15 Jul 2009 04:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.04 X-Spam-Level: X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[AWL=1.689, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0eDjQ4jP1CI for ; Wed, 15 Jul 2009 04:18:07 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 3A1163A67A6 for ; Wed, 15 Jul 2009 04:18:07 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:06:07 +0200 Received: from [10.194.4.252] ([10.194.4.252]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:06:07 +0200 Message-ID: <4A5DAA0E.9080100@orange-ftgroup.com> Date: Wed, 15 Jul 2009 12:06:06 +0200 From: quentin.lampin@orange-ftgroup.com User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: jvasseur@cisco.com, "Pascal Thubert (pthubert)" , roll@ietf.org References: <4A4E32E3.90804@orange-ftgroup.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> <4A535093.1050807@orange-ftgroup.com> <25C3CC8C-986D-4BAA-8E2B-E11208A10DA8@cisco.com> In-Reply-To: <25C3CC8C-986D-4BAA-8E2B-E11208A10DA8@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 10:06:07.0588 (UTC) FILETIME=[DEFA0A40:01CA0533] Subject: Re: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 11:18:08 -0000 Hi JP, Rollers, JP Vasseur wrote: > Hi Quentin, > > On Jul 7, 2009, at 3:41 PM, quentin.lampin@orange-ftgroup.com wrote: > >> >> >> Pascal Thubert (pthubert) wrote: >>> >>> Salut Quentin: >> Salut Pascal, >>> >>> >>> If DAGs expose different prefixes then the longest match rule >>> applies all the way to follow the graph that advertise that longest >>> match prefix. You can use that to implement a power utility gateway >>> that would get specific traffic but not default. >> ok. >>> >>> >>> If DAGs expose a same prefix (default) then packets must be tagged >>> (colored) to indicate which one of the topologies they are supposed >>> to follow, otherwise loops will occur (your point I guess). >> If I understand well, in the case of multiple DAGs advertising the >> same prefix, packet originators have to specify which DAG the packets >> must follow. > > Right, similarly to what is done with MTR. > >> I also understand that the intention is to tailor DAGs to address >> specific constraints/metrics so that it makes little sense, in >> general, to forward packets accross DAGs. But I can see cases where >> this would be useful. For example, when a node in a frozen sub-DAG >> receives a packet tagged with this DAGID. If it's allowed, it could >> decide, according to the advertised traffic class, to forward the >> packet to another DAG such that the packet is not dropped. > > Yes, which is also an existing notion consisting of using a "default" > DAG as a fall back option. But then you must not "re-color" the packet > to avoid loops. > >> We could think of a per prefix "default" (kind of emergency) DAG. >> A simple way to ensure loops avoidance would be to forbid nodes to >> forward packets tagged "default" outside of the default DAG. > > Right. > >> Another (more generic and thus more powerful) way would be to add a >> Hop by Hop option to the packet specifying visited DAGs and depths of >> nodes which made the cross DAGs forward moves. > > Route Record option would be extremely expensive in term of overhead > though. Well, the intention was not to memorize all traversed nodes but only nodes which forward packets accross DAGs. We can assume that there will be only a few of these nodes compared to the number of traversed nodes, thus we can expect the overhead to be small(see the discussion below the options format proposition). By the way, there is no Route Record for IPv6. Thus, if we want to support forwarding accross multiple DAGS, we need to specify a new HbH option. We could think of something similar to this: 0 7 15 23 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type TBD (HR) | Opt Data Len | Rsvd | Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | DAGID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Node address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or if we follow the suggestion made in the discussion on Multiple roots in DAG and differentiate the DAGID from the DAG Root address and reduce the DAGID field size to a more reasonable one, say 8bits: 0 7 15 23 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type TBD (HR) | Opt Data Len | DAGID | Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Node address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Some points would still need to be investigated if we want to use such an option. First, can we add an HbH header en-route? It would mean that intermediate nodes can change the packet payload size. Similarly, can we add options to the HbH Header en-route (thus changing the HbH Header Extension Length). This may break the IPv6 full compliance but would allow powerful, scalable and extensible usages of ROLL. The fallback option would be to add a fix-sized HbH to every packet that may be routed over DAGs, leading to huge overhead (I guess this is what you were referring to)... > >> Ensuring that a node cannot be re-forwarded to a node in a visited >> DAG at a depth higher (deeper) or equal to the depth corresponding to >> the visited DAG should be sufficient to avoid most probable loops. >> Moreover, the last option would allow us to handle complex packet >> constraints such as { Tdeliver < Tref (weight w1), Nhop < Nref >> (weigth w2)}. A node receiving such a packet could evaluate if the >> major constraint (higher weight) is likely to be respected and, in >> this case, forward the packet accross another DAG to address the >> other constraints. >> This would permit to build "multi-dimensional" QoS based forwarding >> engines. > > This can actually be achieved with the current RPL proposal ... that > said, this brings several additional issues and complexity ... We > probably need to evaluate if that requires such a level of complexity > in practice. > The way we can achieve this with the current RPL proposal is not obvious to us. The obvious solution to inter-DAG loops is to not forward packets across DAGs, as suggested by Pascal. We are interested in studying mechanisms to forward across DAGS while still avoiding loops. We understand this may be a long shot compared to other more immediates issues at hand. However, at your leisure, would you care elaborating how the current proposal can do this? Quentin & Dominique From Bernard.Tourancheau@ens-lyon.fr Wed Jul 15 05:05:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C993A6829 for ; Wed, 15 Jul 2009 05:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SLMeWGS3P7MG for ; Wed, 15 Jul 2009 05:05:35 -0700 (PDT) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by core3.amsl.com (Postfix) with ESMTP id 349A83A67B3 for ; Wed, 15 Jul 2009 05:05:35 -0700 (PDT) Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by jabiru.ens-lyon.fr (Postfix) with ESMTPSA id 64BCD1EB143; Wed, 15 Jul 2009 13:49:23 +0200 (CEST) Message-Id: <0659925B-961B-4B95-BE4B-CC9AEC8AE4B1@ens-lyon.fr> From: Bernard Tourancheau To: quentin.lampin@orange-ftgroup.com In-Reply-To: <4A5DAA0E.9080100@orange-ftgroup.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-915906349 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 13:49:22 +0200 References: <4A4E32E3.90804@orange-ftgroup.com> <7892795E1A87F04CADFCCF41FADD00FC07B93DCB@xmb-ams-337.emea.cisco.com> <4A535093.1050807@orange-ftgroup.com> <25C3CC8C-986D-4BAA-8E2B-E11208A10DA8@cisco.com> <4A5DAA0E.9080100@orange-ftgroup.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] [RPL]About Nodes subscribing to multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 12:05:36 -0000 --Apple-Mail-6-915906349 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > >> >>> Ensuring that a node cannot be re-forwarded to a node in a visited >>> DAG at a depth higher (deeper) or equal to the depth corresponding >>> to the visited DAG should be sufficient to avoid most probable >>> loops. >>> Moreover, the last option would allow us to handle complex packet >>> constraints such as { Tdeliver < Tref (weight w1), Nhop < Nref >>> (weigth w2)}. A node receiving such a packet could evaluate if the >>> major constraint (higher weight) is likely to be respected and, in >>> this case, forward the packet accross another DAG to address the >>> other constraints. >>> This would permit to build "multi-dimensional" QoS based >>> forwarding engines. >> >> This can actually be achieved with the current RPL proposal ... >> that said, this brings several additional issues and complexity ... >> We probably need to evaluate if that requires such a level of >> complexity in practice. >> > The way we can achieve this with the current RPL proposal is not > obvious > to us. The obvious solution to inter-DAG loops is to not forward > packets > across DAGs, as suggested by Pascal. We are interested in studying > mechanisms to forward across DAGS while still avoiding loops. Hi, Assuming there is an ordering of DAGs' numbers, you can avoid loops if a packet goes from DAG to DAG following a strict progression in that ordering (direction < or >). This can be implemented by a bit giving the direction and the DAG number represented on a fixed number of bits (which gives the max number of DAGs). Hence, the operation of passing a packet to another DAG without any loop is possible if and only if : new DAG # > [respectively <] (current DAG # + my DAG # ) % max number of DAGs This implies to keep "direction bit", "my DAG #" and "current DAG #", no recording of the nodes traversed. In the best case you got max number of DAGs possibilities of changing DAG, in the worst case, you choose to go from my DAG # to my DAG # - 1, leading to only one DAG hop. As this operation seems to be rare a good ordering of DAGs should ensure several possibilities for a very small number of bits. My2cents, Bernard. > We understand this may be a long shot compared to other more > immediates > issues at hand. However, at your leisure, would you care elaborating > how > the current proposal can do this? > > Quentin & Dominique > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-6-915906349 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable


Ensuring that a node cannot be re-forwarded to a node in a = visited DAG at a depth higher (deeper) or equal to the depth = corresponding to the visited DAG should be sufficient to avoid most = probable loops.
Moreover, the last option would = allow us to handle complex packet constraints such as { Tdeliver < = Tref (weight w1), Nhop < Nref (weigth w2)}. A node receiving such a = packet could evaluate if the major constraint (higher weight) is likely = to be respected and, in this case, forward the packet accross another = DAG to address the other = constraints.
This would permit to build = "multi-dimensional" QoS based forwarding = engines.

This can = actually be achieved with the current RPL proposal ... that said, this = brings several additional issues and complexity ... We probably need to = evaluate if that requires such a level of complexity in = practice.

The = way we can achieve this with the current RPL proposal is not = obvious
to us. The obvious solution to inter-DAG loops is to not = forward packets
across DAGs, as suggested by Pascal. We are = interested in studying
mechanisms to forward across DAGS while still = avoiding = loops.

Hi,
Assuming = there is an ordering of DAGs' numbers, you can avoid loops if a packet = goes from DAG to DAG following a strict progression in that ordering = (direction < or >).
This can be implemented by a bit = giving the direction and the DAG number represented on a fixed number of = bits (which gives the max number of DAGs). Hence,  the = operation of passing a packet to another DAG without any loop  is = possible if and only if :

new DAG #  > = [respectively <] (current DAG # + my DAG # ) % max number of = DAGs

This implies to keep "direction bit", "my = DAG #" and "current DAG #", no recording of the nodes = traversed.
In the best case you got max number of DAGs = possibilities of changing DAG, in the worst case, you choose to go from = my DAG # to my DAG # - 1, leading to only one DAG hop. As this operation = seems to be rare a good ordering of DAGs should ensure several = possibilities for a very small number of = bits.

My2cents,
Bernard.

We understand this may be a long shot compared = to other more immediates
issues at hand. However, at your leisure, = would you care elaborating how
the current proposal can do = this?

Quentin & = Dominique




_____________________________________________= __
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-6-915906349-- From jabeille@cisco.com Wed Jul 15 07:32:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A00F3A6A30 for ; Wed, 15 Jul 2009 07:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 COg+ZIwTiRT4 for ; Wed, 15 Jul 2009 07:32:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BF76E3A6947 for ; Wed, 15 Jul 2009 07:32:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAALeFXUqQ/uCKe2dsb2JhbACCJi6WZAEBFiQGnjuII5ERBYQJ X-IronPort-AV: E=Sophos;i="4.42,404,1243814400"; d="scan'208,217";a="45156602" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2009 14:31:40 +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 n6FEVePG029864 for ; Wed, 15 Jul 2009 16:31:40 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FEVeld009049 for ; Wed, 15 Jul 2009 14:31:40 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 16:31:40 +0200 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_01CA0558.F7C69E22" Date: Wed, 15 Jul 2009 16:31:39 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPL] Grounded flag Thread-Index: AcoFWPcDWHclQnXBSMWMv7umYTVc2Q== From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 15 Jul 2009 14:31:40.0797 (UTC) FILETIME=[F7E8CAD0:01CA0558] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4140; t=1247668300; x=1248532300; 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:=20[RPL]=20Grounded=20flag |Sender:=20; bh=GMANe2aQpUZ37FS4u1i60QFlhuWs2HfNe+axvtwAgSs=; b=nP+DysV0cNWmDiIV2QCJyn7zRUF8NT8pH61gZKXiy+AAV8eJexne13xhmo h1CaG+MQwzOiToLm3J5yhQ5eyPZkVWxLMJ/Gh3QzD+hVLrMJFqiW+rMsuNHb 4mx0m+3vaj; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] [RPL] Grounded flag X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:32:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0558.F7C69E22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 - could you clarify how the Grounded flag in DIO interferes with the router lifetime in RAs?=20 a router with a default route usually sets non 0 router lifetime in RA to indicate so, and sets it to 0 if does not want to be considered a default router. Hence the meaning of the grounded flag is similar to the router lifetime being 0 or not. =20 If the idea is to force nodes that receives a RA with router lifetime non 0 not to configure the sender as a default router (to allow nodes to choose which default router they want using parent selection), then it could be precised that routers should set router lifetime to 0 even if they have a default route. =20 - in section 5.1.1.5: "Note that Destination Prefixes specified in this manner inherit the Router Lifetime of their parent RA" if the router has no default route, router lifetime is 0. Hence the prefix will not be added, or will be deleted, simply because the sender has no default route. - what happens if a node receives a DIO with G flag not set and no destination prefix? what is the meaning of such a message? =20 Best, Julien ------_=_NextPart_001_01CA0558.F7C69E22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
- = could you clarify=20 how the Grounded flag in DIO interferes with the router lifetime in RAs? =
a = router with a=20 default route usually sets non 0 router lifetime in RA to = indicate so,=20 and sets it to 0 if does not want to be considered a default router. = Hence the=20 meaning of the grounded flag is similar to the router lifetime being 0 = or=20 not.
 
If the = idea is to=20 force nodes that receives a RA with router lifetime non 0 not to = configure the=20 sender as a default router (to allow nodes to choose which default = router they=20 want using parent selection), then it could be precised that routers = should set=20 router lifetime to 0 even if they have a default = route.
 
- in = section=20 5.1.1.5:
"Note that Destination =
Prefixes specified in this manner inherit the
   Router Lifetime of their parent RA"
if the router has no default route, router lifetime is 0. Hence =
the prefix will not be added, or will be deleted, simply because the sender has no default =
route.
- what happens=20 if a node receives a DIO with G flag not set and no destination prefix? = what is=20 the meaning of such a message?
 
Best,
Julien
------_=_NextPart_001_01CA0558.F7C69E22-- From jabeille@cisco.com Wed Jul 15 07:56:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E4F3A6BF0 for ; Wed, 15 Jul 2009 07:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY0EwHciovMS for ; Wed, 15 Jul 2009 07:56:07 -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 C9C803A6813 for ; Wed, 15 Jul 2009 07:56:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAGiKXUqrR7PE/2dsb2JhbACCKCy1fogjkRMFhAk X-IronPort-AV: E=Sophos;i="4.42,404,1243814400"; d="scan'208,217";a="177097747" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2009 14:54:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6FEsnfh027203 for ; Wed, 15 Jul 2009 07:54:49 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FEsbtU029476 for ; Wed, 15 Jul 2009 14:54:48 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 16:54:48 +0200 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_01CA055C.32F37FE4" Date: Wed, 15 Jul 2009 16:54:47 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RA-DIO timer Thread-Index: AcoFXDJdkpJ1iUFJQ+iGXouoqx180g== From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 15 Jul 2009 14:54:48.0527 (UTC) FILETIME=[330F95F0:01CA055C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1668; t=1247669689; x=1248533689; c=relaxed/simple; s=sjdkim4002; 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:=20RA-DIO=20timer |Sender:=20; bh=wzZJj6Yu4KjdKyK+UW63undl1riLIF0+pm6TDf1ChBU=; b=IDoBFWqZHtoDMDQzN51GTsew3D2inhy0PGMbSr1NDQEcMuOI1Y0syOP9UC BId7wOgzD6+Zo5OBzAPVfVYA3ToJ/Y7yDRds5jLHYAKvVuWJJkQm5GJvMoGV f1AJTS4GUY; Authentication-Results: sj-dkim-4; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Roll] RA-DIO timer X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:56:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA055C.32F37FE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 ND specifies rules as to when unsolicited RAs are sent (RFC4861 section 6.2.4). Is it the intention here to update ND? If separate timers are maintained and do not timeout at the same time, what is the use of putting the DIO in a RA? =20 Best, Julien ------_=_NextPart_001_01CA055C.32F37FE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
ND = specifies rules=20 as to when unsolicited RAs are sent (RFC4861 section 6.2.4). Is it the = intention=20 here to update ND? If separate timers are maintained and do = not timeout at=20 the same time, what is the use of putting the DIO in a=20 RA?
 
Best,
Julien
------_=_NextPart_001_01CA055C.32F37FE4-- From jvasseur@cisco.com Wed Jul 15 08:12:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502DC3A6D4E for ; Wed, 15 Jul 2009 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 79rsrIZTG3tL for ; Wed, 15 Jul 2009 08:12:33 -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 E2FEC3A6947 for ; Wed, 15 Jul 2009 08:12:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoAAOuNXUqQ/uCKe2dsb2JhbACCJy2WZAEBFiQGnnmII5EVBYQJ X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208,217";a="45160794" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2009 15:10:06 +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 n6FFA6eU008374 for ; Wed, 15 Jul 2009 17:10:06 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FFA6s9020635 for ; Wed, 15 Jul 2009 15:10:06 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:10:06 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 17:10:05 +0200 Message-Id: <24F7661B-BE61-4B46-8D94-43BCB6AD26C0@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-217-927948822 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 17:10:04 +0200 References: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 15 Jul 2009 15:10:05.0772 (UTC) FILETIME=[55C810C0:01CA055E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2364; t=1247670606; x=1248534606; 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[Roll]=20RA-DIO=20timer |Sender:=20; bh=Ln4Gn3GWV17w8P3Vk6vITB3iKRci+26nhvLr4quCMkE=; b=s07BXaZefUZFMpPeOIK9rT3kWsdpJAWknLooHm8REy7P9GtM97Y6J4JNOh 6adT6HsTZkLSb6xISU4CNJUFAxtDNlueV/kG6HYkB67xOZ6tmQE4wNAMRqmP l33+nUlk6Z; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RA-DIO timer X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:12:34 -0000 --Apple-Mail-217-927948822 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jul 15, 2009, at 4:54 PM, Julien Abeille (jabeille) wrote: > Hi all, > > ND specifies rules as to when unsolicited RAs are sent (RFC4861 > section 6.2.4). Is it the intention here to update ND? I hope not ... > If separate timers are maintained and do not timeout at the same > time, what is the use of putting the DIO in a RA? > > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-217-927948822 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Jul = 15, 2009, at 4:54 PM, Julien Abeille (jabeille) wrote:

=
Hi= all,
 
ND = specifies rules as to when unsolicited RAs are sent (RFC4861 section = 6.2.4). Is it the intention here to update ND? =

I hope not = ...

If separate = timers are maintained and do not timeout at the same time, what is = the use of putting the DIO in a RA?
 
Best,
Julien
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-217-927948822-- From cabo@tzi.org Wed Jul 15 08:36:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577AF3A6BDF for ; Wed, 15 Jul 2009 08:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.618, 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 DL38Ukt-sasc for ; Wed, 15 Jul 2009 08:36:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 401D13A6AD6 for ; Wed, 15 Jul 2009 08:36:41 -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.3/8.14.3) with ESMTP id n6FFav4B014085; Wed, 15 Jul 2009 17:36:57 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 43864BD71; Wed, 15 Jul 2009 17:36:57 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> References: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 17:36:49 +0200 X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RA-DIO timer X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:36:43 -0000 On Jul 15, 2009, at 16:54, Julien Abeille (jabeille) wrote: > Is it the intention here to update ND? There is certainly an intention to have an optimized ND in 6LoWPAN. http://tools.ietf.org/html/draft-ietf-6lowpan-nd I don't know if any other ROLL LLNs can live with 4861 as is. Gruesse, Carsten From jvasseur@cisco.com Wed Jul 15 08:58:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612773A6947 for ; Wed, 15 Jul 2009 08:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.247 X-Spam-Level: X-Spam-Status: No, score=-10.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 JcPgyymOuYIR for ; Wed, 15 Jul 2009 08:58:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 032443A69C0 for ; Wed, 15 Jul 2009 08:58:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAEuXXUqQ/uCLe2dsb2JhbACZOAEBFiQGnn6II5EZBYQJ X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208";a="45165579" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2009 15:49:31 +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 n6FFnVad031395; Wed, 15 Jul 2009 17:49:31 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FFnVCH004200; Wed, 15 Jul 2009 15:49:31 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:49:31 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 17:49:30 +0200 Message-Id: From: JP Vasseur To: Carsten Bormann 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 v935.3) Date: Wed, 15 Jul 2009 17:49:29 +0200 References: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 15 Jul 2009 15:49:31.0021 (UTC) FILETIME=[D7946BD0:01CA0563] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=802; t=1247672971; x=1248536971; 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[Roll]=20RA-DIO=20timer |Sender:=20; bh=DRzHI+JSmJI2UKaMd4p3x3k8SxKzt3/XV/LMqz+cSXs=; b=TJgZroRDAWXXhaQYhFEiThF7JpOBKdPfaCt4aYC6Do1x1ezPh6sBcIcJT8 nfDuecJ9jM8diQuJBu+ogw49hZlJj8pAPfe+uRZxeK/sosdAUiSJ0lxzPnqq eKk1d8tc7z; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RA-DIO timer X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:58:36 -0000 On Jul 15, 2009, at 5:36 PM, Carsten Bormann wrote: > On Jul 15, 2009, at 16:54, Julien Abeille (jabeille) wrote: > >> Is it the intention here to update ND? > > There is certainly an intention to have an optimized ND in 6LoWPAN. > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > > I don't know if any other ROLL LLNs can live with 4861 as is. To be determined ... we are right now in the process of agreeing on the basics but I completely agree with Julien's point of view here. We do need to be cautious here and resist from the attempt of modifying all existing IP protocols if not needed. Cheers. JP. > > Gruesse, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Wed Jul 15 09:41:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96C03A6EC1 for ; Wed, 15 Jul 2009 09:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 p2P83qlpnUU7 for ; Wed, 15 Jul 2009 09:41:11 -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 8B4AA3A6E76 for ; Wed, 15 Jul 2009 09:41:10 -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.3/8.14.3) with ESMTP id n6FGfThL014719; Wed, 15 Jul 2009 18:41:29 +0200 (CEST) Received: from [192.168.217.107] (p5489DB44.dip.t-dialin.net [84.137.219.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 16036BDA8; Wed, 15 Jul 2009 18:41:29 +0200 (CEST) From: Carsten Bormann To: JP Vasseur In-Reply-To: References: <38F26F36EAA981478A49D1F37F474A86035B5167@xmb-ams-33d.emea.cisco.com> Message-Id: <44211F53-64DB-4D2C-A105-1FD2D2572184@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 18:41:27 +0200 X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RA-DIO timer X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:41:11 -0000 On Jul 15, 2009, at 17:49, JP Vasseur wrote: > the attempt of modifying all existing IP protocols That would indeed take a lot of time. My observation is that 4861 ND as is is much more useful for Ethernets than for LLNs. But then a ROLL protocol could simply leave open what is used to carry its announcement traffic and leave it to a specific link-layer mapping to piggyback it on beacons, RAs, whatever. The RA embedding could be defined to maximize the commonality between LLNs that optimize ND LoWPAN-style. Gruesse, Carsten From prvs=441eb7f02=mukul@uwm.edu Wed Jul 15 17:32:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD53928C11C for ; Wed, 15 Jul 2009 17:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miNYyfNzSuVw for ; Wed, 15 Jul 2009 17:32:21 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id C30EB3A6C87 for ; Wed, 15 Jul 2009 17:32:20 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 15 Jul 2009 19:32:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AE30DC085A1; Wed, 15 Jul 2009 19:32:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlnfbUW6ZSDA; Wed, 15 Jul 2009 19:32:52 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 2BF40C085A6; Wed, 15 Jul 2009 19:32:52 -0500 (CDT) Date: Wed, 15 Jul 2009 19:32:52 -0500 (CDT) From: Mukul Goyal To: "M. B. Anand" Message-ID: <250386978.2859601247704372048.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1513409377.2859071247703984597.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] P2P routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 00:32:52 -0000 Anand Thanks for your email. It allows me a satisfaction that my emails to this list are not an exercise in soliloquy. :) > In *very* general terms, nothing wrong this approach. By personal > experience, pretty much this approach - with added optimizations - has > been used for networks of over 10s of K nodes with "domains", as you > called them, over 2K or so nodes. (sorry, no public reference). The > ideas of RFC 2091, using incremental updates, can be very effective as > well. The ROLL protocol survey, draft-ietf-roll-protocols-survey-07 > mentions this. If the "divided" into domains is supposed to be automatic > and nodes can change domains - and thus drag other nodes into and out of > domains - that introduces a whole new set of complications involving > marking and purging destinations and you probably would not be able to > avoid counting up. The "domains" is just one approach to limit the spread of reachability information (about a destination) in an LLN. I agree that dymanic membership to a domain is perhaps not a good idea. For LLN with static nodes, the node locations may naturally provide domain boundaries. We can also borrow ideas from fish-eye routing where the probability of whether a node maintains state regarding a destination depends on its distance from the destination. It seems to me that the LLN may enforce GLOBAL policies (e.g. domains) and then nodes may additionally have LOCAL policies (e.g. fish-eye routing etc.) regarding the maintenance and advertizing of the routing state. Within the constraints imposed by GLOBAL policy, the nodes MUST be able to enforce its LOCAL policy. For example, a node MUST be able to not advertize a destination even if it belongs to the same domain as the node. The local policy could very well be to advertize no destination at all (i.e. the node refuses to participate in routing packets) or a default destination or any subset of destinations allowed under the global policy. >Keep in mind in all of this though, the fundamental point is, simply > put, the price you pay for generally optimal peer-to-peer routing is a >massive explosion of state information to be maintained and exchanged - >every node pretty much has to form a tree rooted at itself. Lot of >memory to keep all destinations. A desirable solution should not _enforce_ optimal P2P routing; it should _allow_ optimal (whatever that means) P2P routing, which RPL does not. The quality of routes would be a function of how much routing state the nodes maintain and advertize. As I mentioned before, the nodes MUST be allowed to implement local policies regarding routing state. There is no requirement that all nodes maintain state regarding all destinations. Another point to consider is that the problem of routing state explosion seems universal. Even in RPL, facilitating P2MP routing risks state space explosion. The RPL nodes, especially at higher echelons in the DAG, may have tough time storing all the DAOs they may receive. >On top of that, given typical bandwidth restrictions, and consequently >the rate and scope of dissemination that is feasible, it has never been >quite clear if in fact optimality (in shortest path terms) can really be >achieved in real-life large networks. For a good general discussion of >this, please see BBN Technical Memorandum No. 1301 (available at >www.ir.bbn.com/documents/techmemos/TM1301.ps) I agree that optimality may be a mirage. But that seems like an issue involving proper selection of routing metrics. >Trees and DAGs being discussed in the LLN context all attempt to >minimize state information by trying to take advantage of certain >(presumed) flow properties to sacrifice some generality and gain the >corresponding simplicity benefit. I love DAGs (and RPL) for GLOBAL MP2P traffic. Where such traffic is dominant, RPL is great. But, there has to be an alternative available when this is not so. There are LLN applications where there exist several localized P2P or MP2P traffic flows that do not form a natural DAG when considered together. Why enforce a DAG in such cases? > Of course, the application you envision may only require, or is capable >of providing, very small domains. In which case, full circle, you might >want to consider: is the stretch you will presumably get with DAGs and >trees worth the price of the much larger complexity of general optimal >peer-to-peer routing ? Because it will be, much more complex I mean. The LLN applications deserve a choice. Choice to use DAGs and RPL where they are appropriate and use some other solution when RPL is not appropriate. If the stretch in routes caused by RPL's routing along a DAG is acceptable, the application should use RPL by all means. If not, there must be an alternative available. As I mentioned before, we can design the alternative solution so that it allows a tradeoff between the quality (or optimality) of routes and the routing state the nodes maintain. Again, thanks for taking time to send comments. Regards Mukul >Regards, >Anand. > The tree/DAG based P2P routing proposed in RPL may not be desirable in many situations. > > Here is the outline of an alternative P2P routing solution: > > 1. The P2P routing would follow a basic DV approach, where nodes would advertize their "cost" to various destinations in Hello/"Router Advertisement" messages and next-hop(s) selection (for a destination) is based on the advertised costs by neighbors. > 1.1 A node may solicit advertisements from its neighbors regarding a destination. > 1.2 The generation of Hello messages may follow a trickle-like approach. > 1.3 In the absence of new advertisements about a destination from a neighbor, the perceived cost of reaching the destination through this neighbor deteriorates with time. > > 2. The LLN would be divided into "domains" such that (costs to) destinations in one domain would be advertized (in Hello messages)by nodes within that domain only. This is to limit the destinations a node may have to advertize. There may be some _super_ destinations that can be advertised across domains. > > 3. There is no loop avoidance/prevention. > > 4. There is a loop detection and correction mechanism in place. Periodically, a source node would send a control packet towards the destination. This packet accumulates the path it travels over. If a receiving node finds itself already listed in the path, the routing loop is detected. The node corrects the loop by excluding and punishing the offending nexthop. > > Please comment. > > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Wed Jul 15 20:45:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE12C3A6B83 for ; Wed, 15 Jul 2009 20:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.116 X-Spam-Level: X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2al10ZVogW5 for ; Wed, 15 Jul 2009 20:45:14 -0700 (PDT) Received: from fujitsu2.fujitsu.com (fujitsu2.fna.fujitsu.com [192.240.0.2]) by core3.amsl.com (Postfix) with ESMTP id 8F0BE3A683F for ; Wed, 15 Jul 2009 20:45:14 -0700 (PDT) Received: from fujitsu2.fujitsu.com (localhost [127.0.0.1]) by fujitsu2.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6G3japR012530; Wed, 15 Jul 2009 20:45:36 -0700 (PDT) Received: from mailserv1.fla.fujitsu.com (mailserv1.fla.fujitsu.com [128.8.244.161]) by fujitsu2.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6G3jato012524; Wed, 15 Jul 2009 20:45:36 -0700 (PDT) Received: from [192.168.0.245] (ip68-110-239-10.dc.dc.cox.net [68.110.239.10]) (authenticated bits=0) by mailserv1.fla.fujitsu.com (8.13.8/8.13.8) with ESMTP id n6G3jWa0024803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2009 23:45:32 -0400 Message-ID: <4A5EA259.7030900@us.fujitsu.com> Date: Wed, 15 Jul 2009 23:45:29 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Goindi, Manhar" References: <4A53F413.7040802@us.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: smartnetpro-iwao_std@ml.css.fujitsu.com, roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 03:45:16 -0000 Hi Manhar, Thanks for your interest and questions. My apologies for a slow response - I did take a few days off and am just getting back to work. Please see inline for my response. Hope that my response adequately answers your questions. Best regards, Sung Goindi, Manhar wrote: > Hi, > > Thanks for sharing the DADR protocol. I have been able to scan through > it & have some basic questions: > > 1. How is the path cost value computed? How does the originating node > have the path cost value for the entire path? Is this done at the time > of route discovery? > DADR is flexible in that the path cost computation can be adjusted to fit one's needs. It can be as simple as hop count, for example. The cost of the entire path does not need to be known. Once again, depending on the network characteristics and requirements, the entire path cost could be computed or estimated, if desired. > 2. How does route discovery actually take place? Can it be illustrated > with the help of Hello Messages? > Could you describe your definition of "route discovery"? If you mean the construction of route table, DADR roughly constructs routes using Hello Messages (destinations and routing table information are shared to next hop neighbors which in turn will be propagated to the entire network). Please note that the route tables need not be complete or loop free. The final route is learned as packets are transmitted through the network. When a loop is detected, the node will try an alternate route or backtrack to the "parent" node (that sent the message). > 3. How do we control the flooding of Hello messages as against the > breadth-first search protocol? > DADR does not employ the flooding method. It uses a periodic transmission of Hello messages. The period of Hello message transmission can be configurable. > 4. What decides between Figure 1 & Figure 2 that time synchronization > is successful? Does it carry any significance for the originator of > Time Synchronization to be aware of the outcome of Time Synchronization > initiated by it (I think it may not as time synchronization is quite a > decentralized function)? > We need to update the figures. The Gateway/NTP node usually triggers a synchronization message. Figure 1 will represent an incorrect procedure where only the present time is propogated. Figure 2 will represent the proposed scheme where both the original synchronization time and the current time are propogated, resulting in desired network synchronization. Manhar, you are correct that the originator of Time Synch does not care about the outcome of time synch. > 5. DFS mechanism depends on a Tree-like structure for route discovery. > Is this what is being proposed for path information maintenance? Is > there any concept of Parent, Sibling, Child, depth etc. between nodes? > (The draft is very open and does not deal with any specific > recommendation). > Hello messages are used to maintain a rough routing information. However, DADR does not require a strict tree like structure or a loop free structure. We do not have sibling concept. Parent and child information is only existing during the transmission of data packet as a node keeps track of where the packet came from (for backtracking purpose in the case of unsuccessful delivery). Thanks and best regards, Sung > Please let me know - if there is someplace I can find answers to these > questions as this may still be evolving as a standard. > > > Thanks & Best Regards, > Manhar Goindi > > > Manhar Goindi > Technical Expert > Landis+Gyr > Phone: +91 120 3352149 > manhar.goindi@landisgyr.com > http://www.landisgyr.com/ > > Manage Energy Better > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Sung Lee > Sent: Wednesday, July 08, 2009 6:49 AM > To: roll@ietf.org > Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt > > Dear ROLL WG, > > We, Fujitsu, have real experience of building an Ad-hoc network system > with over 1000 nodes using proposed protocol, and we want to contribute > to designing a new protocol within ROLL-WG. > > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> > > > I asked ROLL-WG chairs to give us some presentation time for next IETF > meeting. I hope we will have a good discussion. > > I would appreciate your comments. > > Thanks in advance and best regards, > > Sung Lee > Fujitsu Laboratories of America, Inc > > roll-request@ietf.org wrote: > >> Message: 3 >> Date: Mon, 6 Jul 2009 10:33:55 +0200 >> From: JP Vasseur >> Subject: [Roll] Fwd: I-D Action:draft-iwao-roll-dadr-00.txt >> To: ROLL WG >> Message-ID: <141805D8-CBC0-4FDE-9CCD-07E24AE7E246@cisco.com> >> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; >> DelSp="yes" >> >> At the agenda of the ROLL WG meeting. >> >> Begin forwarded message: >> >> >> >>> From: Internet-Drafts@ietf.org >>> Date: July 6, 2009 4:45:01 AM CEDT >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-iwao-roll-dadr-00.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Distributed Autonomous Depth-first Routing >>> Protocol in LLN >>> Author(s) : T. Iwao >>> Filename : draft-iwao-roll-dadr-00.txt >>> Pages : 24 >>> Date : 2009-07-05 >>> >>> This document is a proposal of the distributed autonomous depth-first >>> >>> routing (DADR) protocol which is quite different from conventional >>> >>> algorithms such as AODV and OLSR. It proposes a traversable >>> > algorithm > >>> which can determine a direct path between the global source and the >>> >>> global destination in a low power and lossy network (LLN). We >>> > propose > >>> the DADR algorithm whose characteristics work well in LLNs with more >>> >>> than 10^4 nodes. This algorithm selects a direct path between the >>> >>> global source and the global destination based on a routing-cost- >>> >>> function which identifies path-candidates with good communication >>> >>> quality between each pair of nodes on the path. This protocol does >>> >>> not need to configure the equipment such as setting IP addresses, >>> > and > >>> thisresults in saving cost and time in deploying, establishing and >>> >>> operating a large scale network. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Iwao, et al. >>> >>> >>> Expires January 2, 2010 >>> >>> >>> >>> >>> [page 2] >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Internet-Draft >>> >>> >>> >>> DADR Protocol >>> >>> >>> >>> >>> >>> >>> July 2009 >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-iwao-roll-dadr-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > /attachment.htm> > >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: not available >> Type: text/plain
content-id: < >> Size: 0 bytes >> Desc: not available >> Url : >> > /attachment.bin> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > /attachment-0001.htm> > >> ------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> End of Roll Digest, Vol 18, Issue 26 >> ************************************ >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. > From Jerald.P.Martocci@jci.com Thu Jul 16 12:34:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD433A69D3 for ; Thu, 16 Jul 2009 12:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9meex17bxxa for ; Thu, 16 Jul 2009 12:34:34 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with ESMTP id 571293A67E9 for ; Thu, 16 Jul 2009 12:34:33 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKSl+A6fQiDr/qMQQ2iikhcjQrcT23lxY6@postini.com; Thu, 16 Jul 2009 12:35:07 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009071614345206-698725 ; Thu, 16 Jul 2009 14:34:52 -0500 MIME-Version: 1.0 To: roll@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 16 Jul 2009 14:34:47 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/16/2009 02:35:03 PM, Serialize complete at 07/16/2009 02:35:03 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/16/2009 02:34:52 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/16/2009 02:34:55 PM, Serialize complete at 07/16/2009 02:34:55 PM Content-Type: multipart/alternative; boundary="=_alternative 006B914B862575F5_=" Cc: Yusuf.Bashir@jci.com, Ted.Humpal@jci.com Subject: [Roll] I-D Action:draft-iwao-roll-dadr-00.txt Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 19:34:36 -0000 This is a multipart message in MIME format. --=_alternative 006B914B862575F5_= Content-Type: text/plain; charset="US-ASCII" Following are comments on the I-D Action:draft-iwao-roll-dadr-00.txt. I realize you just sent out a new version Tuesday. I will read that version in the next few days. However, I wanted to get my comments out to the ROLL ML. First, to set perspective, I authored the ROLL Building Requirement ID last year; hence, my comments are slanted toward the commercial building space requirements. As the document notes, we have no more than a few hundred devices in the LLN with a high level of sensor-to-controller, or controller-to-controller messaging. Event based messages such as alarms will be MP2P based. Every message must be application acknowledged to assure it has been properly delivered. This therefore requires bidirectional communication. All messages are timed out and hence long convergence times to repair floating DAGs could be problematic. We also need to discover devices and objects on-line by using broadcast (or multicast) services. There was really no detail in the ID about how multicast would operate on the LNN and the DAG. Installation methods require that all nodes use auto configuration policies hence the IPv6 prefix will be zeros and therefore not usable for routing discrimination. That said, my gut tells me that the approach described in the 00 version of the draft is not yet suitable for commercial building traffic flow. While there is a need for sensors and controllers to move important event data to the higher layers, by far most of the control is performed at the room or equipment room level and will not be migrated north. I realize the DT noted that P2P communication was not included in the 1st draft and am anxiously awaiting the new and improved version. My detailed comments are below: p5: DAGID "This knowledge is used to identify peer nodes ..." - The word 'peer' is confusing here since it might be considered only nodes at the same DAG layer. I believe the meaning meant to be conveyed was all members of the DAG. Maybe 'member' nodes would be more clearly understood. p5: DAG Sibling nit - 'node node' typo should be 'node' p6: para7 nit - "Note that in this document, the terms `node' and `LLN router' are used interchangeably". There are no references to 'LLN Router' in the ID. There are many references to 'LLN Node'. You may want to change the text to read "Note that in this document, the terms `node' and `LLN node' are used interchangeably". p7: section 3.2.2 "The use of multiple paths include sending duplicated traffic along diverse paths" - while noted here, I saw no mentioned of duplicating packets across multiple paths anywhere within the draft. p9: para 3 nit - 'As nodes join the DAG they are able advertise...' should be 'As nodes join the DAG they are able to advertise...' p9: para 4 nit - '...is greedy and tries to pick to many DAG parents' should be '...is greedy and tries to pick too many DAG parents' p13:section 3.3.1.4 nit - 'Note that in such a case traffic may directed along the appropriate constrained ...' should be 'Note that in such a case traffic may be directed along the appropriately constrained ...' p17:para 8 "Destination Advertisement Options to a subset of their DAG Parents" - What defines 'subset'. Is this a 1-hop multicast to neighbor nodes? As drafted it sounds like the device randomly selects so paths. This seems completely nondeterministic. nit - perios (.) missing at end of paragraph. p19: section 3.3.4.1 "Such a change would require node (56) to detach from the DAG, to defer reattachment until a loop avoidance algorithm has completed ..." Detaching and reattaching at a lower layer of the DAG seems to leave communication to the LBR nondeterministic with regard to latency. When a node detaches, it must wait its timeout and a RA from a higher layer before it can reattach. The higher layers may not even detect the disturbance and not proactively reset their trickle timers. This could leave a large part of the DAG ungrounded for an inordinate amount of time. In a real-time system pertinent life-safety alarms could be unable to be migrated northbound for far too long. nit - '...as it's DAG parents' should be 'as its DAG parents' nit - 'There is then little change ...' should be 'There is then little chance...' p23: section 3.4.1 "Although implementation specific, it is worth noting that a node may decide to implement some local routing decision based on some metrics..." The interoperability requirement is very strong inside commercial buildings since the equipment is provided by a bevy of manufacturers. Allowing each manufacturer to select its own metric will lead minimally to suboptimal routing paths and more like to orthogonal operation that may not allow even a single path to be established across nodes. I understand that the IETF typically leaves routing algorithms to the manufacturers. In this case I believe the IETF must be more prescriptive since the routers are not stand-alone infrastructure devices (Cisco, Alcatel-Lucent), but instead HVAC, lighting and fire controllers developed by application manufacturers that happen to also do routing as a sideline activity. 'These decisions may be local and/or temporary with the objective to maintain the DAG shape while preserving routing stability.' - herein lies what I believe is a philosophical problem (which I alluded to in the previous paragraph) that runs pervasively across this ID. Unlike many (or all) the protocols supported in the IETF where routers are a special breed of devices distinguished from hosts; in an LLN the hosts typically have a primary function (control the room temperature) and happen to do routing as a secondary task. As a manufacturer, I want to spend as little time as possible worrying about 'maintaining the DAG shape' and more time solving building control issues. p24: section 4 nit - 'This aim of this section ...' s/b 'The aim of this section ...' p25: para 4 nit - 'in as antagonistic' s/b 'in an antagonistic' p28: DIOIntervalDoublings nit - 'should be send' s/b 'should be sent' p29: DAGID nit - 'identify' s/b 'identifies' p32:para 1 nit - 'an node MAY decide' s/b 'a node MAY decide' (NOTE: There are many occurrences of this nit throughout the spec). p35:last para nit - ' One of these information, ' s/b 'One attribute,' p36:para 3 nit "it's" s/b "its" nit "looses" s/b "loses" p36:para 4 nit "it's" s/b "its" p36:#5 "Nodes MUST ignore RAs that are received from other routers located deeper within the same DAG". The above sentence and actually all of paragraph 5 is confusing. It reads that a node at any lay 'i' must ignore all RAs from all layers 'i+n'. However, earlier there was a discussion about how a node must first leave the DAG if it wants to move to a lower layer. How would a node ever decide it might want to connect at a lower layer if it must ignore all RAs from lower layers? Furthermore a node may want to reconnect at a lower layer of the DAG for application reasons. That is a room temperature sensor would ideally like to be as close as possible in the DAG hierarchy to is associated room controller. Hence the DAG composition should be malleable to meet the application layer requirements as well as the routing requirements. p37:#7 "If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable and refrains from sending Router Advertisement" If a node is simply awaiting the timeout of a hop timer before it starts its move, it is not yet unstable. Why would it cease its RAs? I can believe that once it has gone ungrounded it is unstable and may want to prohibit RAs, but not before it moves. p37:#8 "If the node was the last DAG parent then the node SHOULD follow that parent." If for some reason my last DAG parent decides to secede from the DAG and hence I have no path to the LBR, I certainly want to pull the plug from my radical parent and find a new parent that is still grounded. Why should I have to stay? p38:para 3 "...use a specific visitor-counter suboption in the DIO." I don't see the visitor-counter suboption defined in the DIO subheader section. p38:Section 5.4.2 i) 'For instance, a node that has limited battery..." How does a sleeping device operate within the DAG since it's not awake to get RA, DIO and DAO solicitations? ii) 'In particular, a node might expose a depth which is incremented by more than one from its deepest DAG parent's depth' While this could be done, I see no utility in doing it. You mention that it can be done 'in order to fit in its own administrative range'. I don't get this. I don't think layer definition can be defined apriori since the number of DAG layers is highly dependent on the job radio configuration. Please explain. p40:Section 5.4.3.3 'In order to detect the situation, LLN Nodes time stamp the sending of Router Advertisement' The use of time stamps indicate at a minimum clock synchronization requirements of the LLN. It may also be setting a real-time clock requirement on the nodes. Neither of these are acceptable requirements to be placed on sensor class devices. p40:Last para '...the node with lowest extended preference processes the Router Advertisement' Can you reference where we can find out about 'lowest extended preference'? This term seems to be an external reference. p42: sect 5.5 I am very concerned about the approach defined for referencing nodes down the DAG. The approach described seems very ad hoc and optional. If Node A want to communicate to Node B (even if it's within radio range), it must traverse up the DAG until it finds a 'helper' node that will supply the path back down the DAG to the destination. I suspect that in WSNs inward DAG nodes will not provide these links unless they themselves coincidentally need to talk to the same node. There's just no RAM available for these nodes to build expansive router tables to nodes that one-day might need to be traversed. That said, it is highly likely that the packet will ascend up the DAG all the way to the LBR. However, there is no mandate that even the LBR has connectivity to all subservient nodes. So it's quite possible that there is no connectivity defined in the DAG for Node A to talk to Node B even though there is ample radio coverage to access the node. It is highly undesirable for a packet to traverse through many DAG layers when it might be able to pass the packet P2P or a single hop. It is unacceptable if there are nodes that simply can't be accessed at all because of the defined DAG map. p42: As noted above that it's possible that some nodes may have no communication to other nodes, I wonder how multicasts will work on the DAG. I support multicasts may not be in the province of the DAG and hence has some orthogonal solution. However, the ID should clearly state whether the DAG map is used to forward multicast packets across the entire LLN. p44: DAO Depth DAO Depth is set to 0 rather than the relative DAG layer address of the node. Why would that be? I would think we would want all references within the DAG to be based on the relative position of the node within the DAG.. p44:Prefix My read of the 6LoWPAN ID indicated that for 6LoWPAN devices using auto-configuration, the prefix was simply the PAN ID and 53 trailing zeros. This seems to indicate that the prefix is carrying much more topological information. p44:5.5.2.1 The DAO algorithm as previously noted seems unreliable since it can't guarantee connectivity to all nodes within the DAG. Reading this section further concerns me that we need to consider data queries from outside the LNN through the LBR onto the DAG. That is the data flow through the LBR is bidirectional not unidirectional. p45:para4 nit - 'A no-DAO is a conveyed' s/b 'A no-DAO is conveyed' p46:para 2 In this way the Reverse Route Stack will come to contain a vector of next hops that must be traversed along the reverse path that the DAO has traveled. This sentence implies that the metrics used to defined the inward (northbound) DAG structure can be used to deliver outbound (southbound) DAG messages. Empirical tests show this is not true. A high percentage of our paths (upwards to 70%) are asymmetrical. That is the Node A to Node B path is not the same as the Node B to Node A path. Assuming we can use the DAG paths defined for inbound traffic successfully for outbound traffic may be erroneous. --=_alternative 006B914B862575F5_= Content-Type: text/html; charset="US-ASCII"

Following are comments on the  I-D Action:draft-iwao-roll-dadr-00.txt.   I realize you just sent out a new version Tuesday.  I will read that version in the next few days.  However, I wanted to get my comments out to the ROLL ML.

First, to set perspective, I authored the ROLL Building Requirement ID last year; hence, my comments are slanted toward the commercial building space requirements.  As the document notes, we have no more than a few hundred devices in the LLN with a high level of sensor-to-controller, or controller-to-controller messaging.  Event based messages such as alarms will be MP2P based.  Every message must be application acknowledged to assure it has been properly delivered.  This therefore requires bidirectional communication.  All messages are timed out and hence long convergence times to repair floating DAGs could be problematic.

We also need to discover devices and objects on-line by using broadcast (or multicast) services.  There was really no detail in the ID about how multicast would operate on the LNN and the DAG.  Installation methods require that all nodes use auto configuration policies hence the IPv6 prefix will be zeros and therefore not usable for routing discrimination.

That said, my gut tells me that the approach described in the 00 version of the draft is not yet suitable for commercial building traffic flow.  While there is a need for sensors and controllers to move important event data to the higher layers, by far most of the control is performed at the room or equipment room level and will not be migrated north.  I realize the DT noted that P2P communication was not included in the 1st draft and am anxiously awaiting the new and improved version.



My detailed comments are below:

p5: DAGID

"This knowledge is used to identify peer nodes ..."  - The word 'peer' is confusing here since it might be considered only nodes at the same DAG layer.  I believe the meaning meant to be conveyed was all members of the DAG.  Maybe 'member' nodes would be more clearly understood.


p5: DAG Sibling

nit - 'node node'  typo should be 'node'



p6: para7

nit -  "Note that in this document, the terms `node' and `LLN router' are used interchangeably".  There are no references to 'LLN Router' in the ID.  There are many references to 'LLN Node'.  You may want to change the text to read  "Note that in this document, the terms `node' and `LLN node' are used interchangeably".


p7: section 3.2.2

"The use of multiple paths include sending duplicated traffic along diverse paths" - while noted here, I saw no mentioned of duplicating packets across multiple paths anywhere within the draft.


p9: para 3

nit - 'As nodes join the DAG they are able advertise...'  should be  'As nodes join the DAG they are able to advertise...'


p9: para 4

nit - '...is greedy and tries to pick to many DAG parents' should be '...is greedy and tries to pick too many DAG parents'



p13:section 3.3.1.4

nit - 'Note that in such a case traffic may directed along the appropriate constrained ...' should be 'Note that in such a case traffic may be directed along the appropriately constrained ...'


p17:para 8

 "Destination Advertisement Options to a subset of their DAG Parents"   - What defines 'subset'.  Is this a 1-hop multicast to neighbor nodes?  As drafted it sounds like the device randomly selects so paths. This seems completely nondeterministic.

nit - perios (.) missing at end of paragraph.


p19: section 3.3.4.1

"Such a change would require node (56) to detach from the DAG, to defer reattachment until a loop avoidance algorithm has completed ..."   Detaching and reattaching at a lower layer of the DAG seems to leave communication to the LBR nondeterministic with regard to latency.  When a node detaches, it must wait its timeout and a RA from a higher layer before it can reattach.  The higher layers may not even detect the disturbance and not proactively reset their trickle timers.  This could leave a large part of the DAG ungrounded for an inordinate amount of time.  In a real-time system pertinent life-safety alarms could be unable to be migrated northbound for far too long.

nit - '...as it's DAG parents'  should be 'as its DAG parents'

nit - 'There is then little change ...' should be 'There is then little chance...'


p23: section 3.4.1

"Although implementation specific, it is worth noting that a node may decide to implement some local routing decision based on some metrics..."   The interoperability requirement is very strong inside commercial buildings since the equipment is provided by a bevy of manufacturers.  Allowing each manufacturer to select its own metric will lead minimally to suboptimal routing paths and more like to orthogonal operation that may not allow even a single path to be established across nodes.  I understand that the IETF typically leaves routing algorithms to the manufacturers. In this case I believe the IETF must be more prescriptive since the routers are not stand-alone infrastructure devices (Cisco, Alcatel-Lucent), but instead HVAC, lighting and fire controllers developed by application manufacturers that happen to also do routing as a sideline activity.

'These decisions may be local and/or temporary with the objective to maintain the DAG shape while preserving routing stability.' - herein lies what I believe is a philosophical problem (which I alluded to in the previous paragraph) that runs pervasively across this ID.  Unlike many (or all) the protocols supported in the IETF where routers are a special breed of devices distinguished from hosts; in an LLN the hosts typically have a primary function (control the room temperature) and happen to do routing as a secondary task.  As a manufacturer, I want to spend as little time as possible worrying about 'maintaining the DAG shape' and more time solving building control issues.

 
p24: section 4

nit - 'This aim of this section ...' s/b 'The aim of this section ...'


p25: para 4

nit - 'in as antagonistic'  s/b 'in an antagonistic'


p28: DIOIntervalDoublings

nit - 'should be send'  s/b 'should be sent'


p29: DAGID

nit - 'identify'  s/b 'identifies'


p32:para 1

nit - 'an node MAY decide' s/b 'a node MAY decide'  (NOTE: There are many occurrences of this nit throughout the spec).


p35:last para

nit - ' One of these information, ' s/b  'One attribute,'


p36:para 3

nit "it's" s/b "its"
nit "looses" s/b "loses"


p36:para 4

nit "it's" s/b "its"


p36:#5

"Nodes MUST ignore RAs that are received from other routers located deeper within the same DAG".

The above sentence and actually all of paragraph 5 is confusing.  It reads that a node at any lay 'i' must ignore all RAs from all layers 'i+n'.  However, earlier there was a discussion about how a node must first leave the DAG if it wants to move to a lower layer.  How would a node ever decide it might want to connect at a lower layer if it must ignore all RAs from lower layers?  Furthermore a node may want to reconnect at a lower layer of the DAG for application reasons.  That is a room temperature sensor would ideally like to be as close as possible in the DAG hierarchy to is associated room controller.  Hence the DAG composition should be malleable to meet the application layer requirements as well as the routing requirements.

p37:#7

"If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable and refrains from sending Router Advertisement"

If a node is simply awaiting the timeout of a hop timer before it starts its move, it is not yet unstable.  Why would it cease its RAs?  I can believe that once it has gone ungrounded it is unstable and may want to prohibit RAs, but not before it moves.


p37:#8

"If the node was the last DAG parent then the node SHOULD follow that parent."

If for some reason my last DAG parent decides to secede from the DAG and hence I have no path to the LBR, I certainly want to pull the plug from my radical parent and find a new parent that is still grounded.  Why should I have to stay?


p38:para 3

"...use a specific visitor-counter suboption in the DIO."

I don't see the visitor-counter suboption defined in the DIO subheader section.


p38:Section 5.4.2

i) 'For instance,  a node that has limited battery..."

How does a sleeping device operate within the DAG since it's not awake to get RA, DIO and DAO solicitations?


ii) 'In particular, a node might expose a depth which is incremented by more than one from its deepest DAG parent's depth'

While this could be done, I see no utility in doing it.  You mention that it can be done 'in order to fit in its own administrative range'.  I don't get this.  I don't think layer definition can be defined apriori since the number of DAG layers is highly dependent on the job radio configuration.  Please explain.


p40:Section 5.4.3.3

'In order to detect the situation, LLN Nodes time stamp the sending of Router Advertisement'

The use of time stamps indicate at a minimum clock synchronization requirements of the LLN.  It may also be setting a real-time clock requirement on the nodes.  Neither of these are acceptable requirements to be placed on sensor class devices.


p40:Last para

'...the node with lowest extended preference processes the Router Advertisement'

Can you reference where we can find out about 'lowest extended preference'?  This term seems to be an external reference.


p42: sect 5.5

I am very concerned about the approach defined for referencing nodes down the DAG.  The approach described seems very ad hoc and optional. If Node A want to communicate to Node B (even if it's within radio range), it must traverse up the DAG until it finds a 'helper' node that will supply the path back down the DAG to the destination.  I suspect that in WSNs inward DAG nodes will not provide these links unless they themselves coincidentally need to talk to the same node.  There's just no RAM available for these nodes to build expansive router tables to nodes that one-day might need to be traversed.

That said, it is highly likely that the packet will ascend up the DAG all the way to the LBR.  However, there is no mandate that even the LBR has connectivity to all subservient nodes.  So it's quite possible that there is no connectivity defined in the DAG for Node A to talk to Node B even though there is ample radio coverage to access the node.  It is highly undesirable for a packet to traverse through many DAG layers when it might be able to pass the packet P2P or a single hop.  It is unacceptable if there are nodes that simply can't be accessed at all because of the defined DAG map.


p42:

As noted above that it's possible that some nodes may have no communication to other nodes, I wonder how multicasts will work on the DAG.  I support multicasts may not be in the province of the DAG and hence has some orthogonal solution.  However, the ID should clearly state whether the DAG map is used to forward multicast packets across the entire LLN.


p44: DAO Depth

DAO Depth is set to 0 rather than the relative DAG layer address of the node.  Why would that be?  I would think we would want all references within the DAG to be based on the relative position of the node within the DAG..


p44:Prefix

My read of the 6LoWPAN ID indicated that for 6LoWPAN devices using auto-configuration, the prefix was simply the PAN ID and 53 trailing zeros.  This seems to indicate that the prefix is carrying much more topological information.


p44:5.5.2.1

The DAO algorithm as previously noted seems unreliable since it can't guarantee connectivity to all nodes within the DAG.  Reading this section further concerns me that we need to consider data queries from outside the LNN through the LBR onto the DAG.  That is the data flow through the LBR is bidirectional not unidirectional.


p45:para4

nit - 'A no-DAO is a conveyed' s/b 'A no-DAO is conveyed'


p46:para 2

In this way the Reverse Route Stack will come to contain a vector of next hops that must be traversed along the reverse path that the DAO has traveled.

This sentence implies that the metrics used to defined the inward (northbound) DAG structure can be used to deliver outbound (southbound) DAG messages.  Empirical tests show this is not true.  A high percentage of our paths (upwards to 70%) are asymmetrical.  That is the Node A to Node B path is not the same as the Node B to Node A path.  Assuming we can use the DAG paths defined for inbound traffic successfully for outbound traffic may be erroneous.






--=_alternative 006B914B862575F5_=-- From gnawali@gmail.com Thu Jul 16 17:14:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F513A698B for ; Thu, 16 Jul 2009 17:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2reJvEU2OXIt for ; Thu, 16 Jul 2009 17:14:37 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 5BE0D3A6C8D for ; Thu, 16 Jul 2009 17:14:37 -0700 (PDT) Received: by qyk41 with SMTP id 41so480548qyk.29 for ; Thu, 16 Jul 2009 17:15: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=jdgRyKHtRlvt7XCuTAUf0jfcwATGQuATQ6zFI8jsc8A=; b=cZXDKdiQoNMk+UwN/HtQyVQYpta7+KfcAiSBsagiuRbbW2yTvM/XoX7JFe055ORTM4 Hzy7D0216Zul+/wNNjalovPGXQDEW3AA6Z0hfLwJtFYDa176SpDz95vQ8+dfMILUZcgK nREamnYf2xdlcqHwG+w+5nrxPYU3P/2CGLoao= 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=ZpMO38niq+VGxJaNinfEBLTiQIC4CS7u4VtQydKsGM5EuGx65ViEOWvfT2iAzJBZIg sSl5AhgZxnAkn2koxJjq1dTz8UncGKWGnubocPBrC3hN05vpgR5svvTFGk92QoNEBg8a fcrZnxOLLrNzKSTVdhD95Vl7AaAyVUHyScAAw= MIME-Version: 1.0 Received: by 10.224.54.10 with SMTP id o10mr373777qag.36.1247789708006; Thu, 16 Jul 2009 17:15:08 -0700 (PDT) In-Reply-To: <1734253621.2168001247571961278.JavaMail.root@mail02.pantherlink.uwm.edu> References: <807766048.2167711247571801088.JavaMail.root@mail02.pantherlink.uwm.edu> <1734253621.2168001247571961278.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 16 Jul 2009 17:15:07 -0700 Message-ID: From: Omprakash Gnawali To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 00:14:38 -0000 On Tue, Jul 14, 2009 at 4:46 AM, Mukul Goyal wrote: > Hi all > > Here is a simple loop avoidance mechanism that can be used in a P2P routi= ng solution that does not use DAGs. > > Thanks > Mukul > > In DV protocols, the routing loops are triggered when the cost to reach a= destination via the current next hop increases so much that a new next hop= needs to be selected. > > Suppose, a node, B, determines that its current next hop, A, for a destin= ation, X, may no longer be the best ("minimum cost") neighbor to forward pa= ckets to. Such determination could be based on an increase in the link cost= to node A or the receipt of a new advertisement from node A showing an inc= reased cost to reach the destination X. > > In case of such an event, node B should not choose a new next hop immedia= tely. This is because the current cost advertisements by its neighbors, as = well as any new advertisements generated in the immediate aftermath of the = event, may be based on node B's erstwhile cost to reach the destination. Im= mediate selection of a new next hop based on the current or new cost advert= isements by the neighbors may lead to a routing loop and a "count to infini= ty" situation. > > Rather, node B should initiate the propagation of new cost information do= wn the tree (of nodes for whom it currently lies on the route to X)and wait= for some time before calculating its new next hop. The hope is that by the= time the node calculates its new next hop, its increased cost along the cu= rrent next hop is known to all its neighbors and they have generated new ad= vertisements if their previous advertisements were based on the old cost of= node B to reach X. > > So, when node B determines that its current next hop A for destination X = is no longer the best neighbor to forward packets to, it generates a new sp= ecially _marked_ advertisement that lists node B's new cost to reach X via = A, the current next hop. > > The generation of a _marked_ advertizement regarding destination X puts t= he node in the "loop avoidance" state for a time period during which the no= de can neither change its next hop to destination X nor generate a regular = advertisement for the destination X. > > All nodes that receive node B's _marked_ advertisement regarding destinat= ion X update their cost to reach X via B. If a node currently considers nod= e B as its next hop to destination X, it additionally does the following: > 1. it enters the "loop avoidance" state and hence consequently keeps node= B as its next hop to X > 2. =A0originates a _marked_ advertizement listing its new cost to destina= tion X via node B > > Once a node exits the "loop avoidance" state, it is allowed to select a n= ew next hop to X and generate a regular advertisement listing its new cost = to X. > > Here is an example showing the efficacy of this proposal: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 X > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B-C > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 D E > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0F > > X is the destination. > > Suppose all unidirectional link costs are 1 except the following: B->C:5,= B->D:5 and E->B:5 > > Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X > > and node B's perceived cost to reach X via each neighbor is as follows: > via A:2, via C:7, via D:8, via E:6 > > Suppose the cost of link B->A changes to 100. > > In a simple DV protocol, B's cost to reach X via A becomes 101 and hence = it immediately chooses E as the next hop (declaring its new cost to X as 6)= , thereby creating routing loop B->E->F->D->B and a "count to infinity" sit= uation. > > Under the proposed protocol, B would generate a _marked_ advertisement li= sting its cost to X as 101 and enter the "loop avoidance" state. This _mark= ed_ advertisement is received by A, C, D and E. Since D considers B as its = next hop to X, it enters the "loop avoidance" state as well and generates i= ts own _marked_ advertisement listing its cost to X as 102. > > On receiving this advertisement, node F enters the "loop avoidance" state= and generates its own _marked_ advertisement listing its cost to X as 103. > > On receiving this advertisement, node E enters the "loop avoidance" state= and generates its own _marked_ advertisement listing its cost to X as 104. > > If node B comes out of the "loop avoidance" state only after the receipt = of this advertisement from E, B would correctly choose node C as its new ne= xt hop to X and generate a new advertisement listing its cost to X as 7. Wh= en nodes D, F and E come out of the "loop avoidance" state, they would ulti= mately =A0update their cost to X to 8, 9 and 10 respectively without any lo= ops. > > This policy does cause a delay in convergence. Suppose B->C cost is 1 in = the example above. B enters the "loop avoidance" state when cost of link B-= >A changes to 100. Node B would not select C as next hop (and advertize a c= ost 3 to X) until it comes out of the "loop avoidance" state. What kind of packet loss assumptions are necessary to guarantee loop-free routing under this proposal? - om_p From prvs=4421d3a9b=mukul@uwm.edu Thu Jul 16 18:12:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05ACD3A6E03 for ; Thu, 16 Jul 2009 18:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1O1VULjkffI for ; Thu, 16 Jul 2009 18:12:46 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id C7C283A6DFE for ; Thu, 16 Jul 2009 18:12:45 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 16 Jul 2009 20:13:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8EB52C085AB; Thu, 16 Jul 2009 20:13:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyhHcSxQAdeR; Thu, 16 Jul 2009 20:13:15 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 543CDC085AA; Thu, 16 Jul 2009 20:13:15 -0500 (CDT) Date: Thu, 16 Jul 2009 20:13:15 -0500 (CDT) From: Mukul Goyal To: Omprakash Gnawali Message-ID: <1938763792.3199501247793195235.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20799451.3199091247792970479.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 01:13:08 -0000 Om, This proposal does not "guarantee" loop-free routing. It is a loop "avoidan= ce" strategy rather than a loop "prevention" mechanism (RPL's DAG seems to = me as a loop "prevention" mechanism). There is an obvious dependence on the= advertisements not getting lost. This dependence can be lessened by allowi= ng a node to repeat its _marked_ advertisement during its sojourn in the "l= oop avoidance" state. Thanks Mukul =20 ----- Original Message ----- From: "Omprakash Gnawali" To: "Mukul Goyal" Cc: "roll" Sent: Thursday, July 16, 2009 7:15:07 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV ro= uting not using DAGs On Tue, Jul 14, 2009 at 4:46 AM, Mukul Goyal wrote: > Hi all > > Here is a simple loop avoidance mechanism that can be used in a P2P routi= ng solution that does not use DAGs. > > Thanks > Mukul > > In DV protocols, the routing loops are triggered when the cost to reach a= destination via the current next hop increases so much that a new next hop= needs to be selected. > > Suppose, a node, B, determines that its current next hop, A, for a destin= ation, X, may no longer be the best ("minimum cost") neighbor to forward pa= ckets to. Such determination could be based on an increase in the link cost= to node A or the receipt of a new advertisement from node A showing an inc= reased cost to reach the destination X. > > In case of such an event, node B should not choose a new next hop immedia= tely. This is because the current cost advertisements by its neighbors, as = well as any new advertisements generated in the immediate aftermath of the = event, may be based on node B's erstwhile cost to reach the destination. Im= mediate selection of a new next hop based on the current or new cost advert= isements by the neighbors may lead to a routing loop and a "count to infini= ty" situation. > > Rather, node B should initiate the propagation of new cost information do= wn the tree (of nodes for whom it currently lies on the route to X)and wait= for some time before calculating its new next hop. The hope is that by the= time the node calculates its new next hop, its increased cost along the cu= rrent next hop is known to all its neighbors and they have generated new ad= vertisements if their previous advertisements were based on the old cost of= node B to reach X. > > So, when node B determines that its current next hop A for destination X = is no longer the best neighbor to forward packets to, it generates a new sp= ecially _marked_ advertisement that lists node B's new cost to reach X via = A, the current next hop. > > The generation of a _marked_ advertizement regarding destination X puts t= he node in the "loop avoidance" state for a time period during which the no= de can neither change its next hop to destination X nor generate a regular = advertisement for the destination X. > > All nodes that receive node B's _marked_ advertisement regarding destinat= ion X update their cost to reach X via B. If a node currently considers nod= e B as its next hop to destination X, it additionally does the following: > 1. it enters the "loop avoidance" state and hence consequently keeps node= B as its next hop to X > 2. =C2=A0originates a _marked_ advertizement listing its new cost to dest= ination X via node B > > Once a node exits the "loop avoidance" state, it is allowed to select a n= ew next hop to X and generate a regular advertisement listing its new cost = to X. > > Here is an example showing the efficacy of this proposal: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B-C > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / \ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D E > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ / > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F > > X is the destination. > > Suppose all unidirectional link costs are 1 except the following: B->C:5,= B->D:5 and E->B:5 > > Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X > > and node B's perceived cost to reach X via each neighbor is as follows: > via A:2, via C:7, via D:8, via E:6 > > Suppose the cost of link B->A changes to 100. > > In a simple DV protocol, B's cost to reach X via A becomes 101 and hence = it immediately chooses E as the next hop (declaring its new cost to X as 6)= , thereby creating routing loop B->E->F->D->B and a "count to infinity" sit= uation. > > Under the proposed protocol, B would generate a _marked_ advertisement li= sting its cost to X as 101 and enter the "loop avoidance" state. This _mark= ed_ advertisement is received by A, C, D and E. Since D considers B as its = next hop to X, it enters the "loop avoidance" state as well and generates i= ts own _marked_ advertisement listing its cost to X as 102. > > On receiving this advertisement, node F enters the "loop avoidance" state= and generates its own _marked_ advertisement listing its cost to X as 103. > > On receiving this advertisement, node E enters the "loop avoidance" state= and generates its own _marked_ advertisement listing its cost to X as 104. > > If node B comes out of the "loop avoidance" state only after the receipt = of this advertisement from E, B would correctly choose node C as its new ne= xt hop to X and generate a new advertisement listing its cost to X as 7. Wh= en nodes D, F and E come out of the "loop avoidance" state, they would ulti= mately =C2=A0update their cost to X to 8, 9 and 10 respectively without any= loops. > > This policy does cause a delay in convergence. Suppose B->C cost is 1 in = the example above. B enters the "loop avoidance" state when cost of link B-= >A changes to 100. Node B would not select C as next hop (and advertize a c= ost 3 to X) until it comes out of the "loop avoidance" state. What kind of packet loss assumptions are necessary to guarantee loop-free routing under this proposal? - om_p From pal@cs.stanford.edu Thu Jul 16 18:17:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5202328C252 for ; Thu, 16 Jul 2009 18:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZpw1WiIRIs4 for ; Thu, 16 Jul 2009 18:17:18 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A519F3A69DC for ; Thu, 16 Jul 2009 18:17:18 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MRc59-0001T0-O8; Thu, 16 Jul 2009 18:17:51 -0700 In-Reply-To: <1938763792.3199501247793195235.JavaMail.root@mail02.pantherlink.uwm.edu> References: <1938763792.3199501247793195235.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29314C55-B0B4-4CFD-B2B8-096ACC09DFC0@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 16 Jul 2009 18:17:36 -0700 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 01:17:19 -0000 On Jul 16, 2009, at 6:13 PM, Mukul Goyal wrote: > Om, > > This proposal does not "guarantee" loop-free routing. It is a loop > "avoidance" strategy rather than a loop "prevention" mechanism > (RPL's DAG seems to me as a loop "prevention" mechanism). There is > an obvious dependence on the advertisements not getting lost. This > dependence can be lessened by allowing a node to repeat its > _marked_ advertisement during its sojourn in the "loop avoidance" > state. > > Thanks > Mukul I think Om's question is more about what happens to all of the data packets a node is asked to forward while it "waits for some time." Note that these devices have very limited queue sizes. In this scheme, any time a node wants to choose a new parent, it will possibly drop a burst of dropped packets as well as cause a big jump in RTT. Both of these pose issues for TCP. Phil From prvs=4421d3a9b=mukul@uwm.edu Thu Jul 16 19:00:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A203A6BB2 for ; Thu, 16 Jul 2009 19:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 l7aCA1JjzlGL for ; Thu, 16 Jul 2009 19:00:14 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id D938C3A6976 for ; Thu, 16 Jul 2009 19:00:13 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 16 Jul 2009 21:00:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 989DCC085A3; Thu, 16 Jul 2009 21:00:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2C5W4VSj3fX; Thu, 16 Jul 2009 21:00:46 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6003CC085A1; Thu, 16 Jul 2009 21:00:46 -0500 (CDT) Date: Thu, 16 Jul 2009 21:00:46 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <810274274.3208191247796046307.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2043356981.3207431247795596902.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 02:00:14 -0000 Yes. While the node is in the "loop avoidance" state, it does not change its next hop(s). So, the fate of the packets it forwards during this transient state indeed depends on the quality of its current next hop(s). I guess the performance under the transient states may not be good under RPL as well when a node detaches from a DAG and is waiting to reattach at a higher depth or when it wants to jump to a different DAG. Further, reattachment of a node to a DAG may potentially take a long time since the root needs to generate a new sequence number which need to percolate all the way to the waiting node before it can rejoin the DAG. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "Omprakash Gnawali" , "roll" Sent: Thursday, July 16, 2009 8:17:36 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs On Jul 16, 2009, at 6:13 PM, Mukul Goyal wrote: > Om, > > This proposal does not "guarantee" loop-free routing. It is a loop > "avoidance" strategy rather than a loop "prevention" mechanism > (RPL's DAG seems to me as a loop "prevention" mechanism). There is > an obvious dependence on the advertisements not getting lost. This > dependence can be lessened by allowing a node to repeat its > _marked_ advertisement during its sojourn in the "loop avoidance" > state. > > Thanks > Mukul I think Om's question is more about what happens to all of the data packets a node is asked to forward while it "waits for some time." Note that these devices have very limited queue sizes. In this scheme, any time a node wants to choose a new parent, it will possibly drop a burst of dropped packets as well as cause a big jump in RTT. Both of these pose issues for TCP. Phil From prvs=4421d3a9b=mukul@uwm.edu Thu Jul 16 19:56:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65C03A6E1A for ; Thu, 16 Jul 2009 19:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6DWH-ZA-umZ for ; Thu, 16 Jul 2009 19:56:08 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 9420B3A67E7 for ; Thu, 16 Jul 2009 19:56:08 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 16 Jul 2009 21:56:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8EC0FC085A3 for ; Thu, 16 Jul 2009 21:56:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgdwD8y-RJFZ for ; Thu, 16 Jul 2009 21:56:41 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0A37BC085A1 for ; Thu, 16 Jul 2009 21:56:41 -0500 (CDT) Date: Thu, 16 Jul 2009 21:56:40 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <544207020.3220791247799400902.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1794417013.3219121247798877952.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 02:56:10 -0000 Hi All Along the same lines as the loop avoidance mechanism described in an earlier email, here is the outline of a mechanism to correct loops once they have been detected: Periodically, a source node sends a control packet towards the destination X. This packet accumulates the path it travels over. When a node A receives such a packet, it checks the accumulated path. If the node finds itself listed in the accumulated path (i.e. a loop has been detected), it takes the following steps: 1. Identify the nodes involved in the loop and discard the packet. 2. Enter the "loop correction" state, which involves the following actions: 2.1 Reset the cost of all the neighbors to reach destination X as infinity. Note that the cost of all neighbors is reset to infinity and not just the neighbor identified as being involved in a loop. This is done because the currently advertized cost of other neighbors may be tainted by the costs advertized by the nodes in the loop. 2.2 Immediately generate an advertisement listing an infinite cost to reach destination X and including the list of nodes identified to be in the loop. The node may generate additional such advertisements during its sojourn in the "loop correction" state. The sojourn in the "loop correction" state lasts for a certain pre-configured time interval. While in the "loop correction" state, the node can not add any new next hop for destination X. Thus, while a node is in the "loop correction" state, it simply buffers or drops packets going to destination X. A node in the "loop correction" state updates the neighbors cost to reach X based on the received advertisements. But, as mentioned before, it can not choose a next hop and it continues to advertise its own cost to reach X as infinity. When a node B receives an advertisement from node A that identifies it to be involved in a routing loop for destination X, node B notes the IDs of nodes involved in the loop and enters the "loop correction" state taking the actions identified above. Thus, all nodes involved in the loop will enter the "loop correction" state and advertise infinite cost to destination X. The neighbors of these nodes will generate new advertisements for destination X that exclude previously in-loop nodes from consideration. Assuming that: 1. a path, excluding in-loop nodes, does exist from the node to destination X and 2. the "loop correction" state lasts long enough to allow the node to receive new advertisements from all its neighbors based on such a path, the node would select one such out-of-loop neighbor as a next hop for destination X when it comes out of the "loop correction" state. Immediately, the node generates a new advertisement listing its new cost to destination X. Thus, all previously in-loop nodes, when they come out of the "loop correction" state, advertise any paths they may have to destination X that do not include previously in-loop nodes. These advertisements would allow these nodes to determine new optimal, and loop-free, paths to destination X. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "roll" Sent: Tuesday, July 14, 2009 6:46:01 AM GMT -06:00 US/Canada Central Subject: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs Hi all Here is a simple loop avoidance mechanism that can be used in a P2P routing solution that does not use DAGs. Thanks Mukul In DV protocols, the routing loops are triggered when the cost to reach a destination via the current next hop increases so much that a new next hop needs to be selected. Suppose, a node, B, determines that its current next hop, A, for a destination, X, may no longer be the best ("minimum cost") neighbor to forward packets to. Such determination could be based on an increase in the link cost to node A or the receipt of a new advertisement from node A showing an increased cost to reach the destination X. In case of such an event, node B should not choose a new next hop immediately. This is because the current cost advertisements by its neighbors, as well as any new advertisements generated in the immediate aftermath of the event, may be based on node B's erstwhile cost to reach the destination. Immediate selection of a new next hop based on the current or new cost advertisements by the neighbors may lead to a routing loop and a "count to infinity" situation. Rather, node B should initiate the propagation of new cost information down the tree (of nodes for whom it currently lies on the route to X)and wait for some time before calculating its new next hop. The hope is that by the time the node calculates its new next hop, its increased cost along the current next hop is known to all its neighbors and they have generated new advertisements if their previous advertisements were based on the old cost of node B to reach X. So, when node B determines that its current next hop A for destination X is no longer the best neighbor to forward packets to, it generates a new specially _marked_ advertisement that lists node B's new cost to reach X via A, the current next hop. The generation of a _marked_ advertizement regarding destination X puts the node in the "loop avoidance" state for a time period during which the node can neither change its next hop to destination X nor generate a regular advertisement for the destination X. All nodes that receive node B's _marked_ advertisement regarding destination X update their cost to reach X via B. If a node currently considers node B as its next hop to destination X, it additionally does the following: 1. it enters the "loop avoidance" state and hence consequently keeps node B as its next hop to X 2. originates a _marked_ advertizement listing its new cost to destination X via node B Once a node exits the "loop avoidance" state, it is allowed to select a new next hop to X and generate a regular advertisement listing its new cost to X. Here is an example showing the efficacy of this proposal: X | A / \ B-C / \ D E \ / F X is the destination. Suppose all unidirectional link costs are 1 except the following: B->C:5, B->D:5 and E->B:5 Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X and node B's perceived cost to reach X via each neighbor is as follows: via A:2, via C:7, via D:8, via E:6 Suppose the cost of link B->A changes to 100. In a simple DV protocol, B's cost to reach X via A becomes 101 and hence it immediately chooses E as the next hop (declaring its new cost to X as 6), thereby creating routing loop B->E->F->D->B and a "count to infinity" situation. Under the proposed protocol, B would generate a _marked_ advertisement listing its cost to X as 101 and enter the "loop avoidance" state. This _marked_ advertisement is received by A, C, D and E. Since D considers B as its next hop to X, it enters the "loop avoidance" state as well and generates its own _marked_ advertisement listing its cost to X as 102. On receiving this advertisement, node F enters the "loop avoidance" state and generates its own _marked_ advertisement listing its cost to X as 103. On receiving this advertisement, node E enters the "loop avoidance" state and generates its own _marked_ advertisement listing its cost to X as 104. If node B comes out of the "loop avoidance" state only after the receipt of this advertisement from E, B would correctly choose node C as its new next hop to X and generate a new advertisement listing its cost to X as 7. When nodes D, F and E come out of the "loop avoidance" state, they would ultimately update their cost to X to 8, 9 and 10 respectively without any loops. This policy does cause a delay in convergence. Suppose B->C cost is 1 in the example above. B enters the "loop avoidance" state when cost of link B->A changes to 100. Node B would not select C as next hop (and advertize a cost 3 to X) until it comes out of the "loop avoidance" state. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Fri Jul 17 07:12:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1433A6B7C for ; Fri, 17 Jul 2009 07:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBjBRO2kmKqr for ; Fri, 17 Jul 2009 07:12:46 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id 019893A69F6 for ; Fri, 17 Jul 2009 07:12:45 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKSmCG0DFcNVUlNLsZLcWKilGn8aW3dtwi@postini.com; Fri, 17 Jul 2009 07:13:20 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009071709121465-34585 ; Fri, 17 Jul 2009 09:12:14 -0500 MIME-Version: 1.0 To: ROLL WG X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 17 Jul 2009 09:12:08 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/17/2009 09:12:26 AM, Serialize complete at 07/17/2009 09:12:26 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/17/2009 09:12:14 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/17/2009 09:13:06 AM, Serialize complete at 07/17/2009 09:13:06 AM Content-Type: multipart/alternative; boundary="=_alternative 004E074D862575F6_=" Subject: [Roll] draft-dt-roll-rpl-00.txt Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 14:12:49 -0000 This is a multipart message in MIME format. --=_alternative 004E074D862575F6_= Content-Type: text/plain; charset="US-ASCII" Please note the attached comments are in regards to draft-dt-roll-rpl-00.txt. I mistakenly noted on yesterday's email that these comments were in regards to draft-iwao-roll-dadr-00.txt Jerry ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 07/17/2009 08:02 AM ----- Mukul Goyal 07/16/2009 04:38 PM To Jerald P Martocci cc Yusuf Bashir , Ted Humpal Subject draft-dt-roll-rpl-00.txt Comments Jerry You mentioned the wrong draft name. It is draft-dt-roll-rpl-00.txt Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: roll@ietf.org Cc: "Yusuf Bashir" , "Ted Humpal" Sent: Thursday, July 16, 2009 2:34:47 PM GMT -06:00 US/Canada Central Subject: [Roll] I-D Action:draft-iwao-roll-dadr-00.txt Comments Following are comments on the draft-dt-roll-rpl-00. I realize you just sent out a new version Tuesday. I will read that version in the next few days. However, I wanted to get my comments out to the ROLL ML. First, to set perspective, I authored the ROLL Building Requirement ID last year; hence, my comments are slanted toward the commercial building space requirements. As the document notes, we have no more than a few hundred devices in the LLN with a high level of sensor-to-controller, or controller-to-controller messaging. Event based messages such as alarms will be MP2P based. Every message must be application acknowledged to assure it has been properly delivered. This therefore requires bidirectional communication. All messages are timed out and hence long convergence times to repair floating DAGs could be problematic. We also need to discover devices and objects on-line by using broadcast (or multicast) services. There was really no detail in the ID about how multicast would operate on the LNN and the DAG. Installation methods require that all nodes use auto configuration policies hence the IPv6 prefix will be zeros and therefore not usable for routing discrimination. That said, my gut tells me that the approach described in the 00 version of the draft is not yet suitable for commercial building traffic flow. While there is a need for sensors and controllers to move important event data to the higher layers, by far most of the control is performed at the room or equipment room level and will not be migrated north. I realize the DT noted that P2P communication was not included in the 1st draft and am anxiously awaiting the new and improved version. My detailed comments are below: p5: DAGID "This knowledge is used to identify peer nodes ..." - The word 'peer' is confusing here since it might be considered only nodes at the same DAG layer. I believe the meaning meant to be conveyed was all members of the DAG. Maybe 'member' nodes would be more clearly understood. p5: DAG Sibling nit - 'node node' typo should be 'node' p6: para7 nit - "Note that in this document, the terms `node' and `LLN router' are used interchangeably". There are no references to 'LLN Router' in the ID. There are many references to 'LLN Node'. You may want to change the text to read "Note that in this document, the terms `node' and `LLN node' are used interchangeably". p7: section 3.2.2 "The use of multiple paths include sending duplicated traffic along diverse paths" - while noted here, I saw no mentioned of duplicating packets across multiple paths anywhere within the draft. p9: para 3 nit - 'As nodes join the DAG they are able advertise...' should be 'As nodes join the DAG they are able to advertise...' p9: para 4 nit - '...is greedy and tries to pick to many DAG parents' should be '...is greedy and tries to pick too many DAG parents' p13:section 3.3.1.4 nit - 'Note that in such a case traffic may directed along the appropriate constrained ...' should be 'Note that in such a case traffic may be directed along the appropriate ly constrained ...' p17:para 8 "Destination Advertisement Options to a subset of their DAG Parents" - What defines 'subset'. Is this a 1-hop multicast to neighbor nodes? As drafted it sounds like the device randomly selects so paths. This seems completely nondeterministic. nit - perios (.) missing at end of paragraph. p19: section 3.3.4.1 "Such a change would require node (56) to detach from the DAG, to defer reattachment until a loop avoidance algorithm has completed ..." Detaching and reattaching at a lower layer of the DAG seems to leave communication to the LBR nondeterministic with regard to latency. When a node detaches, it must wait its timeout and a RA from a higher layer before it can reattach. The higher layers may not even detect the disturbance and not proactively reset their trickle timers. This could leave a large part of the DAG ungrounded for an inordinate amount of time. In a real-time system pertinent life-safety alarms could be unable to be migrated northbound for far too long. nit - '...as it's DAG parents' should be 'as its DAG parents' nit - 'There is then little change ...' should be 'There is then little chance ...' p23: section 3.4.1 "Although implementation specific, it is worth noting that a node may decide to implement some local routing decision based on some metrics..." The interoperability requirement is very strong inside commercial buildings since the equipment is provided by a bevy of manufacturers. Allowing each manufacturer to select its own metric will lead minimally to suboptimal routing paths and more like to orthogonal operation that may not allow even a single path to be established across nodes. I understand that the IETF typically leaves routing algorithms to the manufacturers. In this case I believe the IETF must be more prescriptive since the routers are not stand-alone infrastructure devices (Cisco, Alcatel-Lucent), but instead HVAC, lighting and fire controllers developed by application manufacturers that happen to also do routing as a sideline activity. 'These decisions may be local and/or temporary with the objective to maintain the DAG shape while preserving routing stability.' - herein lies what I believe is a philosophical problem (which I alluded to in the previous paragraph) that runs pervasively across this ID. Unlike many (or all) the protocols supported in the IETF where routers are a special breed of devices distinguished from hosts; in an LLN the hosts typically have a primary function (control the room temperature) and happen to do routing as a secondary task. As a manufacturer, I want to spend as little time as possible worrying about 'maintaining the DAG shape' and more time solving building control issues. p24: section 4 nit - 'This aim of this section ...' s/b ' The aim of this section ...' p25: para 4 nit - 'in as antagonistic' s/b 'in an antagonistic' p28: DIOIntervalDoublings nit - 'should be send' s/b 'should be sent ' p29: DAGID nit - 'identify' s/b 'identifies' p32:para 1 nit - 'an node MAY decide' s/b ' a node MAY decide' (NOTE: There are many occurrences of this nit throughout the spec). p35:last para nit - ' One of these information, ' s/b 'One attribute,' p36:para 3 nit "it's" s/b "its" nit "looses" s/b "loses" p36:para 4 nit "it's" s/b "its" p36:#5 "Nodes MUST ignore RAs that are received from other routers located deeper within the same DAG". The above sentence and actually all of paragraph 5 is confusing. It reads that a node at any lay 'i' must ignore all RAs from all layers 'i+n'. However, earlier there was a discussion about how a node must first leave the DAG if it wants to move to a lower layer. How would a node ever decide it might want to connect at a lower layer if it must ignore all RAs from lower layers? Furthermore a node may want to reconnect at a lower layer of the DAG for application reasons. That is a room temperature sensor would ideally like to be as close as possible in the DAG hierarchy to is associated room controller. Hence the DAG composition should be malleable to meet the application layer requirements as well as the routing requirements. p37:#7 "If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable and refrains from sending Router Advertisement" If a node is simply awaiting the timeout of a hop timer before it starts its move, it is not yet unstable. Why would it cease its RAs? I can believe that once it has gone ungrounded it is unstable and may want to prohibit RAs, but not before it moves. p37:#8 "If the node was the last DAG parent then the node SHOULD follow that parent." If for some reason my last DAG parent decides to secede from the DAG and hence I have no path to the LBR, I certainly want to pull the plug from my radical parent and find a new parent that is still grounded. Why should I have to stay? p38:para 3 "...use a specific visitor-counter suboption in the DIO." I don't see the visitor-counter suboption defined in the DIO subheader section. p38:Section 5.4.2 i) 'For instance, a node that has limited battery..." How does a sleeping device operate within the DAG since it's not awake to get RA, DIO and DAO solicitations? ii) 'In particular, a node might expose a depth which is incremented by more than one from its deepest DAG parent's depth' While this could be done, I see no utility in doing it. You mention that it can be done 'in order to fit in its own administrative range'. I don't get this. I don't think layer definition can be defined apriori since the number of DAG layers is highly dependent on the job radio configuration. Please explain. p40:Section 5.4.3.3 'In order to detect the situation, LLN Nodes time stamp the sending of Router Advertisement' The use of time stamps indicate at a minimum clock synchronization requirements of the LLN. It may also be setting a real-time clock requirement on the nodes. Neither of these are acceptable requirements to be placed on sensor class devices. p40:Last para '...the node with lowest extended preference processes the Router Advertisement' Can you reference where we can find out about 'lowest extended preference'? This term seems to be an external reference. p42: sect 5.5 I am very concerned about the approach defined for referencing nodes down the DAG. The approach described seems very ad hoc and optional. If Node A want to communicate to Node B (even if it's within radio range), it must traverse up the DAG until it finds a 'helper' node that will supply the path back down the DAG to the destination. I suspect that in WSNs inward DAG nodes will not provide these links unless they themselves coincidentally need to talk to the same node. There's just no RAM available for these nodes to build expansive router tables to nodes that one-day might need to be traversed. That said, it is highly likely that the packet will ascend up the DAG all the way to the LBR. However, there is no mandate that even the LBR has connectivity to all subservient nodes. So it's quite possible that there is no connectivity defined in the DAG for Node A to talk to Node B even though there is ample radio coverage to access the node. It is highly undesirable for a packet to traverse through many DAG layers when it might be able to pass the packet P2P or a single hop. It is unacceptable if there are nodes that simply can't be accessed at all because of the defined DAG map. p42: As noted above that it's possible that some nodes may have no communication to other nodes, I wonder how multicasts will work on the DAG. I support multicasts may not be in the province of the DAG and hence has some orthogonal solution. However, the ID should clearly state whether the DAG map is used to forward multicast packets across the entire LLN. p44: DAO Depth DAO Depth is set to 0 rather than the relative DAG layer address of the node. Why would that be? I would think we would want all references within the DAG to be based on the relative position of the node within the DAG.. p44:Prefix My read of the 6LoWPAN ID indicated that for 6LoWPAN devices using auto-configuration, the prefix was simply the PAN ID and 53 trailing zeros. This seems to indicate that the prefix is carrying much more topological information. p44:5.5.2.1 The DAO algorithm as previously noted seems unreliable since it can't guarantee connectivity to all nodes within the DAG. Reading this section further concerns me that we need to consider data queries from outside the LNN through the LBR onto the DAG. That is the data flow through the LBR is bidirectional not unidirectional. p45:para4 nit - 'A no-DAO is a conveyed' s/b 'A no-DAO is conveyed' p46:para 2 In this way the Reverse Route Stack will come to contain a vector of next hops that must be traversed along the reverse path that the DAO has traveled. This sentence implies that the metrics used to defined the inward (northbound) DAG structure can be used to deliver outbound (southbound) DAG messages. Empirical tests show this is not true. A high percentage of our paths (upwards to 70%) are asymmetrical. That is the Node A to Node B path is not the same as the Node B to Node A path. Assuming we can use the DAG paths defined for inbound traffic successfully for outbound traffic may be erroneous. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 004E074D862575F6_= Content-Type: text/html; charset="US-ASCII"
Please note the attached comments are in regards to draft-dt-roll-rpl-00.txt.  I mistakenly noted on yesterday's email that these comments were in regards to draft-iwao-roll-dadr-00.txt

Jerry


----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 07/17/2009 08:02 AM -----
Mukul Goyal <mukul@uwm.edu>

07/16/2009 04:38 PM

To
Jerald P Martocci <Jerald.P.Martocci@jci.com>
cc
Yusuf Bashir <Yusuf.Bashir@jci.com>, Ted Humpal <Ted.Humpal@jci.com>
Subject
draft-dt-roll-rpl-00.txt  Comments





Jerry

You mentioned the wrong draft name. It is draft-dt-roll-rpl-00.txt

Thanks
Mukul

----- Original Message -----
From: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
To: roll@ietf.org
Cc: "Yusuf Bashir" <Yusuf.Bashir@jci.com>, "Ted Humpal" <Ted.Humpal@jci.com>
Sent: Thursday, July 16, 2009 2:34:47 PM GMT -06:00 US/Canada Central
Subject: [Roll] I-D Action:draft-iwao-roll-dadr-00.txt  Comments




Following are comments on the draft-dt-roll-rpl-00.   I realize you just sent out a new version Tuesday.  I will read that version in the next few days.  However, I wanted to get my comments out to the ROLL ML.

First, to set perspective, I authored the ROLL Building Requirement ID last year; hence, my comments are slanted toward the commercial building space requirements.  As the document notes, we have no more than a few hundred devices in the LLN with a high level of sensor-to-controller, or controller-to-controller messaging.  Event based messages such as alarms will be MP2P based.  Every message must be application acknowledged to assure it has been properly delivered.  This therefore requires bidirectional communication.  All messages are timed out and hence long convergence times to repair floating DAGs could be problematic.

We also need to discover devices and objects on-line by using broadcast (or multicast) services.  There was really no detail in the ID about how multicast would operate on the LNN and the DAG.  Installation methods require that all nodes use auto configuration policies hence the IPv6 prefix will be zeros and therefore not usable for routing discrimination.

That said, my gut tells me that the approach described in the 00 version of the draft is not yet suitable for commercial building traffic flow.  While there is a need for sensors and controllers to move important event data to the higher layers, by far most of the control is performed at the room or equipment room level and will not be migrated north.  I realize the DT noted that P2P communication was not included in the 1st draft and am anxiously awaiting the new and improved version.



My detailed comments are below:

p5: DAGID

"This knowledge is used to identify peer nodes ..."  - The word 'peer' is confusing here since it might be considered only nodes at the same DAG layer.  I believe the meaning meant to be conveyed was all members of the DAG.  Maybe 'member' nodes would be more clearly understood.


p5: DAG Sibling

nit - 'node node'  typo should be 'node'



p6: para7

nit -  "Note that in this document, the terms `node' and `LLN router' are used interchangeably".  There are no references to 'LLN Router' in the ID.  There are many references to 'LLN Node'.  You may want to change the text to read  "Note that in this document, the terms `node' and `LLN node' are used interchangeably".


p7: section 3.2.2

"The use of multiple paths include sending duplicated traffic along diverse paths" - while noted here, I saw no mentioned of duplicating packets across multiple paths anywhere within the draft.


p9: para 3

nit - 'As nodes join the DAG they are able advertise...'  should be  'As nodes join the DAG they are able to advertise...'


p9: para 4

nit - '...is greedy and tries to pick to many DAG parents' should be '...is greedy and tries to pick too many DAG parents'



p13:section 3.3.1.4

nit - 'Note that in such a case traffic may directed along the appropriate constrained ...' should be 'Note that in such a case traffic may be directed along the appropriate ly constrained ...'


p17:para 8

 "Destination Advertisement Options to a subset of their DAG Parents"   - What defines 'subset'.  Is this a 1-hop multicast to neighbor nodes?  As drafted it sounds like the device randomly selects so paths. This seems completely nondeterministic.

nit - perios (.) missing at end of paragraph.


p19: section 3.3.4.1

"Such a change would require node (56) to detach from the DAG, to defer reattachment until a loop avoidance algorithm has completed ..."   Detaching and reattaching at a lower layer of the DAG seems to leave communication to the LBR nondeterministic with regard to latency.  When a node detaches, it must wait its timeout and a RA from a higher layer before it can reattach.  The higher layers may not even detect the disturbance and not proactively reset their trickle timers.  This could leave a large part of the DAG ungrounded for an inordinate amount of time.  In a real-time system pertinent life-safety alarms could be unable to be migrated northbound for far too long.

nit - '...as it's DAG parents'  should be 'as its DAG parents'

nit - 'There is then little change ...' should be 'There is then little chance ...'


p23: section 3.4.1

"Although implementation specific, it is worth noting that a node may decide to implement some local routing decision based on some metrics..."   The interoperability requirement is very strong inside commercial buildings since the equipment is provided by a bevy of manufacturers.  Allowing each manufacturer to select its own metric will lead minimally to suboptimal routing paths and more like to orthogonal operation that may not allow even a single path to be established across nodes.  I understand that the IETF typically leaves routing algorithms to the manufacturers. In this case I believe the IETF must be more prescriptive since the routers are not stand-alone infrastructure devices (Cisco, Alcatel-Lucent), but instead HVAC, lighting and fire controllers developed by application manufacturers that happen to also do routing as a sideline activity.

'These decisions may be local and/or temporary with the objective to maintain the DAG shape while preserving routing stability.' - herein lies what I believe is a philosophical problem (which I alluded to in the previous paragraph) that runs pervasively across this ID.  Unlike many (or all) the protocols supported in the IETF where routers are a special breed of devices distinguished from hosts; in an LLN the hosts typically have a primary function (control the room temperature) and happen to do routing as a secondary task.  As a manufacturer, I want to spend as little time as possible worrying about 'maintaining the DAG shape' and more time solving building control issues.

 
p24: section 4

nit - 'This aim of this section ...' s/b ' The aim of this section ...'


p25: para 4

nit - 'in as antagonistic'  s/b 'in an antagonistic'


p28: DIOIntervalDoublings

nit - 'should be send'  s/b 'should be sent '


p29: DAGID

nit - 'identify'  s/b 'identifies'


p32:para 1

nit - 'an node MAY decide' s/b ' a node MAY decide'  (NOTE: There are many occurrences of this nit throughout the spec).


p35:last para

nit - ' One of these information, ' s/b  'One attribute,'


p36:para 3

nit "it's" s/b "its"
nit "looses" s/b "loses"


p36:para 4

nit "it's" s/b "its"


p36:#5

"Nodes MUST ignore RAs that are received from other routers located deeper within the same DAG".

The above sentence and actually all of paragraph 5 is confusing.  It reads that a node at any lay 'i' must ignore all RAs from all layers 'i+n'.  However, earlier there was a discussion about how a node must first leave the DAG if it wants to move to a lower layer.  How would a node ever decide it might want to connect at a lower layer if it must ignore all RAs from lower layers?  Furthermore a node may want to reconnect at a lower layer of the DAG for application reasons.  That is a room temperature sensor would ideally like to be as close as possible in the DAG hierarchy to is associated room controller.  Hence the DAG composition should be malleable to meet the application layer requirements as well as the routing requirements.

p37:#7

"If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable and refrains from sending Router Advertisement"

If a node is simply awaiting the timeout of a hop timer before it starts its move, it is not yet unstable.  Why would it cease its RAs?  I can believe that once it has gone ungrounded it is unstable and may want to prohibit RAs, but not before it moves.


p37:#8

"If the node was the last DAG parent then the node SHOULD follow that parent."

If for some reason my last DAG parent decides to secede from the DAG and hence I have no path to the LBR, I certainly want to pull the plug from my radical parent and find a new parent that is still grounded.  Why should I have to stay?


p38:para 3

"...use a specific visitor-counter suboption in the DIO."

I don't see the visitor-counter suboption defined in the DIO subheader section.


p38:Section 5.4.2

i) 'For instance,  a node that has limited battery..."

How does a sleeping device operate within the DAG since it's not awake to get RA, DIO and DAO solicitations?


ii) 'In particular, a node might expose a depth which is incremented by more than one from its deepest DAG parent's depth'

While this could be done, I see no utility in doing it.  You mention that it can be done 'in order to fit in its own administrative range'.  I don't get this.  I don't think layer definition can be defined apriori since the number of DAG layers is highly dependent on the job radio configuration.  Please explain.


p40:Section 5.4.3.3

'In order to detect the situation, LLN Nodes time stamp the sending of Router Advertisement'

The use of time stamps indicate at a minimum clock synchronization requirements of the LLN.  It may also be setting a real-time clock requirement on the nodes.  Neither of these are acceptable requirements to be placed on sensor class devices.


p40:Last para

'...the node with lowest extended preference processes the Router Advertisement'

Can you reference where we can find out about 'lowest extended preference'?  This term seems to be an external reference.


p42: sect 5.5

I am very concerned about the approach defined for referencing nodes down the DAG.  The approach described seems very ad hoc and optional. If Node A want to communicate to Node B (even if it's within radio range), it must traverse up the DAG until it finds a 'helper' node that will supply the path back down the DAG to the destination.  I suspect that in WSNs inward DAG nodes will not provide these links unless they themselves coincidentally need to talk to the same node.  There's just no RAM available for these nodes to build expansive router tables to nodes that one-day might need to be traversed.

That said, it is highly likely that the packet will ascend up the DAG all the way to the LBR.  However, there is no mandate that even the LBR has connectivity to all subservient nodes.  So it's quite possible that there is no connectivity defined in the DAG for Node A to talk to Node B even though there is ample radio coverage to access the node.  It is highly undesirable for a packet to traverse through many DAG layers when it might be able to pass the packet P2P or a single hop.  It is unacceptable if there are nodes that simply can't be accessed at all because of the defined DAG map.


p42:

As noted above that it's possible that some nodes may have no communication to other nodes, I wonder how multicasts will work on the DAG.  I support multicasts may not be in the province of the DAG and hence has some orthogonal solution.  However, the ID should clearly state whether the DAG map is used to forward multicast packets across the entire LLN.


p44: DAO Depth

DAO Depth is set to 0 rather than the relative DAG layer address of the node.  Why would that be?  I would think we would want all references within the DAG to be based on the relative position of the node within the DAG..


p44:Prefix

My read of the 6LoWPAN ID indicated that for 6LoWPAN devices using auto-configuration, the prefix was simply the PAN ID and 53 trailing zeros.  This seems to indicate that the prefix is carrying much more topological information.


p44:5.5.2.1

The DAO algorithm as previously noted seems unreliable since it can't guarantee connectivity to all nodes within the DAG.  Reading this section further concerns me that we need to consider data queries from outside the LNN through the LBR onto the DAG.  That is the data flow through the LBR is bidirectional not unidirectional.


p45:para4

nit - 'A no-DAO is a conveyed' s/b 'A no-DAO is conveyed'


p46:para 2

In this way the Reverse Route Stack will come to contain a vector of next hops that must be traversed along the reverse path that the DAO has traveled.

This sentence implies that the metrics used to defined the inward (northbound) DAG structure can be used to deliver outbound (southbound) DAG messages.  Empirical tests show this is not true.  A high percentage of our paths (upwards to 70%) are asymmetrical.  That is the Node A to Node B path is not the same as the Node B to Node A path.  Assuming we can use the DAG paths defined for inbound traffic successfully for outbound traffic may be erroneous.







_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
 --=_alternative 004E074D862575F6_=-- From pal@cs.stanford.edu Fri Jul 17 10:14:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2359F3A6AC5 for ; Fri, 17 Jul 2009 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSZmTh6QYcyc for ; Fri, 17 Jul 2009 10:14:45 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 36F2728C224 for ; Fri, 17 Jul 2009 10:14:36 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MRr1Z-00040r-JG; Fri, 17 Jul 2009 10:15:10 -0700 Message-Id: <1D880EED-1E2F-46D2-9B89-95A9A0E5E6A8@cs.stanford.edu> From: Philip Levis To: Mukul Goyal In-Reply-To: <544207020.3220791247799400902.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 10:15:12 -0700 References: <544207020.3220791247799400902.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 17:14:46 -0000 On Jul 16, 2009, at 7:56 PM, Mukul Goyal wrote: > Hi All > > Along the same lines as the loop avoidance mechanism described in an > earlier email, here is the outline of a mechanism to correct loops > once they have been detected: > > Periodically, a source node sends a control packet towards the > destination X. This packet accumulates the path it travels over. > When a node A receives such a packet, it checks the accumulated > path. If the node finds itself listed in the accumulated path (i.e. > a loop has been detected), it takes the following steps: > 1. Identify the nodes involved in the loop and discard the packet. > 2. Enter the "loop correction" state, which involves the following > actions: > 2.1 Reset the cost of all the neighbors to reach destination X as > infinity. Note that the cost of all neighbors is reset to infinity > and not just the neighbor identified as being involved in a loop. > This is done because the currently advertized cost of other > neighbors may be tainted by the costs advertized by the nodes in the > loop. > 2.2 Immediately generate an advertisement listing an infinite cost > to reach destination X and including the list of nodes identified to > be in the loop. The node may generate additional such advertisements > during its sojourn in the "loop correction" state. > > The sojourn in the "loop correction" state lasts for a certain pre- > configured time interval. While in the "loop correction" state, the > node can not add any new next hop for destination X. Thus, while a > node is in the "loop correction" state, it simply buffers or drops > packets going to destination X. A node in the "loop correction" > state updates the neighbors cost to reach X based on the received > advertisements. But, as mentioned before, it can not choose a next > hop and it continues to advertise its own cost to reach X as infinity. What is the advantage of such an approach rather than detecting loops as soon as their occur and repairing them within a few packet times? One of the key lessons from CTP was that it's a bad idea to make routing failure detection independent of the data rate. Preconfigured time intervals are very difficult for interoperability and lead to high packet losses. Of course, one could say that these periodic control packets are bound to the data rate (e.g., every tenth packet), but in low-power MACs it's usually much more efficient to add a bit of data to an existing packet than source entirely new packets. Phil From prvs=44399eb11=mukul@uwm.edu Fri Jul 17 17:37:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE903A6B11 for ; Fri, 17 Jul 2009 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 fOA1RTk7jYqA for ; Fri, 17 Jul 2009 17:37:16 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 71D983A6A3F for ; Fri, 17 Jul 2009 17:37:16 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 17 Jul 2009 19:37:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E460BC085A6; Fri, 17 Jul 2009 19:37:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6BSp4rBaRui; Fri, 17 Jul 2009 19:37:49 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AB1C6C085A1; Fri, 17 Jul 2009 19:37:49 -0500 (CDT) Date: Fri, 17 Jul 2009 19:37:49 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <467060707.3470351247877469581.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <648981520.3470141247877307368.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 00:37:35 -0000 Phil, The way I understand CTP operation, it seems that it provides no loop correction mechanism other than reducing trickle timers to their smallest value so that any "count to infinity" takes place quickly. So, I am not sure if any claim that loops are repaired "with in a few packet times" is valid. The loop correction times, under CTP, depend on the severity of "count to infinity" situation, the minimum trickle times and the length of the loop. The loop correction strategy I proposed is not impeccable either. It works if an in-loop node stays in the "loop correction" state long enough to allow all neighbors to advertise new costs excluding from consideration all in-loop nodes. Otherwise, it does not work and the in-loop nodes would have to resort to "count to infinity". Whether adding the transmitting node's cost value to each packet, as in CTP, is a more desirable loop detection mechanism than using a separate control packet, that accumulates the route it travels over, is debatable as well. CTP mechanism will certainly result in faster loop detection but requires dedicating bytes in every packet, which would result in reduction in the payload of each packet. If only a fraction of packets carry the transmitting node's cost, CTP's advantage in terms of the loop detection times is lost. Using a separate control packet for loop detection allows the nodes involved in the loop to be explicitly identified (useful if this information can be used to correct loops). There is no need to sacrifice bytes in every packet. The application can generate these control packets based on its loop tolerance characteristics. A source node can choose to originate such a control packet after every 'x' data packets or use a trickle-like strategy to originate them (originate more frequently if loops are likely, e.g. after a upheaval in the topology or routing metrics values, otherwise originate infrequently). One major limitation is if the complete path is too big to be carried in a single control packet. In such cases, I guess, the earliest nodes in the path would have to be forgotten on the assumption that shorter loops are more likely than longer loops. I guess the floor is open for further debate. Thanks, Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Friday, July 17, 2009 12:15:12 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs On Jul 16, 2009, at 7:56 PM, Mukul Goyal wrote: > Hi All > > Along the same lines as the loop avoidance mechanism described in an > earlier email, here is the outline of a mechanism to correct loops > once they have been detected: > > Periodically, a source node sends a control packet towards the > destination X. This packet accumulates the path it travels over. > When a node A receives such a packet, it checks the accumulated > path. If the node finds itself listed in the accumulated path (i.e. > a loop has been detected), it takes the following steps: > 1. Identify the nodes involved in the loop and discard the packet. > 2. Enter the "loop correction" state, which involves the following > actions: > 2.1 Reset the cost of all the neighbors to reach destination X as > infinity. Note that the cost of all neighbors is reset to infinity > and not just the neighbor identified as being involved in a loop. > This is done because the currently advertized cost of other > neighbors may be tainted by the costs advertized by the nodes in the > loop. > 2.2 Immediately generate an advertisement listing an infinite cost > to reach destination X and including the list of nodes identified to > be in the loop. The node may generate additional such advertisements > during its sojourn in the "loop correction" state. > > The sojourn in the "loop correction" state lasts for a certain pre- > configured time interval. While in the "loop correction" state, the > node can not add any new next hop for destination X. Thus, while a > node is in the "loop correction" state, it simply buffers or drops > packets going to destination X. A node in the "loop correction" > state updates the neighbors cost to reach X based on the received > advertisements. But, as mentioned before, it can not choose a next > hop and it continues to advertise its own cost to reach X as infinity. What is the advantage of such an approach rather than detecting loops as soon as their occur and repairing them within a few packet times? One of the key lessons from CTP was that it's a bad idea to make routing failure detection independent of the data rate. Preconfigured time intervals are very difficult for interoperability and lead to high packet losses. Of course, one could say that these periodic control packets are bound to the data rate (e.g., every tenth packet), but in low-power MACs it's usually much more efficient to add a bit of data to an existing packet than source entirely new packets. Phil From jvasseur@cisco.com Mon Jul 20 00:15:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDB73A6C8F for ; Mon, 20 Jul 2009 00:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhE1ly2aaClA for ; Mon, 20 Jul 2009 00:15:59 -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 F09D33A6AF1 for ; Mon, 20 Jul 2009 00:15:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOi1Y0qrR7PD/2dsb2JhbAC2EIgjjiAFhAw X-IronPort-AV: E=Sophos;i="4.43,233,1246838400"; d="scan'208";a="216233391" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2009 07:13:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6K7DwKa025088 for ; Mon, 20 Jul 2009 00:13:58 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6K7Dulp022508 for ; Mon, 20 Jul 2009 07:13:58 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:13:55 +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, 20 Jul 2009 09:13:55 +0200 Message-Id: <468745B5-2031-4395-B8CB-37BC5FCE4249@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 09:13:54 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 Jul 2009 07:13:55.0075 (UTC) FILETIME=[A4626D30:01CA0909] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2; t=1248074038; x=1248938038; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20If=20you=20have=20a=20slot=20in=20Stockholm,=20 thanks=20to=20send=20your=20slides=20by=20July=2024=20-=20no on=20ET.=20Thanks. |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=JVWqRyAXEKGztNB/MLRPHkSbxgt+58u8lP9q6Wt7MAby3BpztzjHwkfLBY dMelG0Wki0KpP2xq5UfRFzyVLpYOnSNWi0gv4wQKrqHMxAPXorj2id6FNTVp mobXEalXWV; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] If you have a slot in Stockholm, thanks to send your slides by July 24 - noon ET. Thanks. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 07:15:59 -0000 From jabeille@cisco.com Mon Jul 20 02:02:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A303A6CA2 for ; Mon, 20 Jul 2009 02:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 J1jPCAW2YoOv for ; Mon, 20 Jul 2009 02:02:33 -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 248733A6AF1 for ; Mon, 20 Jul 2009 02:02:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYAALPOY0qQ/uCKe2dsb2JhbACCJy2XCAEBFiQGnBeII44kBYQM X-IronPort-AV: E=Sophos;i="4.43,233,1246838400"; d="scan'208,217";a="45413887" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2009 09:00: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 n6K90sme018155 for ; Mon, 20 Jul 2009 11:00:54 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6K90s4x006573 for ; Mon, 20 Jul 2009 09:00:54 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:00:55 +0200 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_01CA0918.96B58BD9" Date: Mon, 20 Jul 2009 11:00:54 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86035F7A3B@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL] Grounded flag Thread-Index: AcoFWPcDWHclQnXBSMWMv7umYTVc2QDv5gyA References: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> From: "Julien Abeille (jabeille)" To: "Julien Abeille (jabeille)" , X-OriginalArrivalTime: 20 Jul 2009 09:00:55.0042 (UTC) FILETIME=[96FBA620:01CA0918] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5349; t=1248080454; x=1248944454; 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[Roll]=20[RPL]=20Grounded=20flag |Sender:=20; bh=cMAxVTa05umwglYplSRaMNvHcE2Gv8ywUdveU1HYw2k=; b=VBGAuiOUT40gbmlCs1DWFeX8ajAOc2klQePkHENMzQI/3m9Ye24W0BpW+h vpbqxNka7T7V5AeIMwCNEX2rk/PFWGGGrKwXg9T7Abir4PE7cnEOoVkLHgRg Pi8ZTuMx0t; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] [RPL] Grounded flag X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:02:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0918.96B58BD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable reseding Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: mercredi 15 juillet 2009 16:32 To: roll@ietf.org Subject: [Roll] [RPL] Grounded flag =09 =09 Hi all, =20 - could you clarify how the Grounded flag in DIO interferes with the router lifetime in RAs?=20 a router with a default route usually sets non 0 router lifetime in RA to indicate so, and sets it to 0 if does not want to be considered a default router. Hence the meaning of the grounded flag is similar to the router lifetime being 0 or not. =20 If the idea is to force nodes that receives a RA with router lifetime non 0 not to configure the sender as a default router (to allow nodes to choose which default router they want using parent selection), then it could be precised that routers should set router lifetime to 0 even if they have a default route. =20 - in section 5.1.1.5: =09 "Note that Destination Prefixes specified in this manner inherit the Router Lifetime of their parent RA" if the router has no default route, router lifetime is 0. Hence the prefix will not be added, or will be deleted, simply because the sender has no default route. - what happens if a node receives a DIO with G flag not set and no destination prefix? what is the meaning of such a message? =20 Best, Julien ------_=_NextPart_001_01CA0918.96B58BD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
reseding
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille=20 (jabeille)
Sent: mercredi 15 juillet 2009 = 16:32
To:=20 roll@ietf.org
Subject: [Roll] [RPL] Grounded=20 flag

Hi=20 all,
 
- = could you=20 clarify how the Grounded flag in DIO interferes with the router = lifetime in=20 RAs?
a = router with a=20 default route usually sets non 0 router lifetime in RA to = indicate=20 so, and sets it to 0 if does not want to be considered a default = router. Hence=20 the meaning of the grounded flag is similar to the router lifetime = being 0 or=20 not.
 
If = the idea is to=20 force nodes that receives a RA with router lifetime non 0 not to = configure the=20 sender as a default router (to allow nodes to choose which default = router they=20 want using parent selection), then it could be precised that routers = should=20 set router lifetime to 0 even if they have a default=20 route.
 
- in = section=20 5.1.1.5:
"Note that Destination =
Prefixes specified in this manner inherit the
   Router Lifetime of their parent RA"
if the router has no default route, router lifetime is 0. Hence =
the prefix will not be added, or will be deleted, simply because the sender has no default =
route.
- what=20 happens if a node receives a DIO with G flag not set and no = destination=20 prefix? what is the meaning of such a message?
 
Best,
Julien
------_=_NextPart_001_01CA0918.96B58BD9-- From jhui@archrock.com Mon Jul 20 08:07:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135303A6BD6 for ; Mon, 20 Jul 2009 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pfQcyxf9nlG for ; Mon, 20 Jul 2009 08:07:25 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 12E163A67E5 for ; Mon, 20 Jul 2009 08:07:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 55F61AF915; Mon, 20 Jul 2009 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1jLE6xUBgaF; Mon, 20 Jul 2009 08:07:21 -0700 (PDT) Received: from [192.168.7.71] (69-12-164-133.sfo.archrock.com [69.12.164.133]) by mail.sf.archrock.com (Postfix) with ESMTP id 2D70BAF861; Mon, 20 Jul 2009 08:07:21 -0700 (PDT) Message-Id: <448FD3A0-59D5-4914-8F5B-B459C4202120@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1734253621.2168001247571961278.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 08:07:20 -0700 References: <1734253621.2168001247571961278.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 15:07:26 -0000 Hi Mukul, I think the mechanism you outlined is captured by the "Held-Up" mechanism in Section 5.3.3.1 of the RPL draft. Please clarify if you are thinking of something different. That said, I do think it is good to discuss the "Held-Up" state a bit more. There's a couple of questions that come to mind: 1) How long does a node stay in the Held-Up state? - The RPL draft says that it is a function of the candidate's depth. For deep networks, that can be a fairly long time before a node can successfully find a new feasible successor. 2) What is the effect of packet loss? - If node B is a descendant of A and B misses the advertisement from its parent, then A may attach to B or any of its descendants. In a sufficiently dense network, there's a fairly high probability that some node B will miss the advertisement from A (even with retransmissions). On the flip side, those that properly hear the new cost values are likely not to be involved in any loops. In summary, Count-to-Infinity still exists but arguably with only a subset of nodes. We need to weigh the benefits of utilizing the "Held-Up" state with the potential downsides raised by the two questions above. The answer is not clear to me yet. -- Jonathan Hui On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: > Hi all > > Here is a simple loop avoidance mechanism that can be used in a P2P > routing solution that does not use DAGs. > > Thanks > Mukul > > In DV protocols, the routing loops are triggered when the cost to > reach a destination via the current next hop increases so much that > a new next hop needs to be selected. > > Suppose, a node, B, determines that its current next hop, A, for a > destination, X, may no longer be the best ("minimum cost") neighbor > to forward packets to. Such determination could be based on an > increase in the link cost to node A or the receipt of a new > advertisement from node A showing an increased cost to reach the > destination X. > > In case of such an event, node B should not choose a new next hop > immediately. This is because the current cost advertisements by its > neighbors, as well as any new advertisements generated in the > immediate aftermath of the event, may be based on node B's erstwhile > cost to reach the destination. Immediate selection of a new next hop > based on the current or new cost advertisements by the neighbors may > lead to a routing loop and a "count to infinity" situation. > > Rather, node B should initiate the propagation of new cost > information down the tree (of nodes for whom it currently lies on > the route to X)and wait for some time before calculating its new > next hop. The hope is that by the time the node calculates its new > next hop, its increased cost along the current next hop is known to > all its neighbors and they have generated new advertisements if > their previous advertisements were based on the old cost of node B > to reach X. > > So, when node B determines that its current next hop A for > destination X is no longer the best neighbor to forward packets to, > it generates a new specially _marked_ advertisement that lists node > B's new cost to reach X via A, the current next hop. > > The generation of a _marked_ advertizement regarding destination X > puts the node in the "loop avoidance" state for a time period during > which the node can neither change its next hop to destination X nor > generate a regular advertisement for the destination X. > > All nodes that receive node B's _marked_ advertisement regarding > destination X update their cost to reach X via B. If a node > currently considers node B as its next hop to destination X, it > additionally does the following: > 1. it enters the "loop avoidance" state and hence consequently keeps > node B as its next hop to X > 2. originates a _marked_ advertizement listing its new cost to > destination X via node B > > Once a node exits the "loop avoidance" state, it is allowed to > select a new next hop to X and generate a regular advertisement > listing its new cost to X. > > Here is an example showing the efficacy of this proposal: > > X > | > A > / \ > B-C > / \ > D E > \ / > F > > X is the destination. > > Suppose all unidirectional link costs are 1 except the following: B- > >C:5, B->D:5 and E->B:5 > > Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X > > and node B's perceived cost to reach X via each neighbor is as > follows: > via A:2, via C:7, via D:8, via E:6 > > Suppose the cost of link B->A changes to 100. > > In a simple DV protocol, B's cost to reach X via A becomes 101 and > hence it immediately chooses E as the next hop (declaring its new > cost to X as 6), thereby creating routing loop B->E->F->D->B and a > "count to infinity" situation. > > Under the proposed protocol, B would generate a _marked_ > advertisement listing its cost to X as 101 and enter the "loop > avoidance" state. This _marked_ advertisement is received by A, C, D > and E. Since D considers B as its next hop to X, it enters the "loop > avoidance" state as well and generates its own _marked_ > advertisement listing its cost to X as 102. > > On receiving this advertisement, node F enters the "loop avoidance" > state and generates its own _marked_ advertisement listing its cost > to X as 103. > > On receiving this advertisement, node E enters the "loop avoidance" > state and generates its own _marked_ advertisement listing its cost > to X as 104. > > If node B comes out of the "loop avoidance" state only after the > receipt of this advertisement from E, B would correctly choose node > C as its new next hop to X and generate a new advertisement listing > its cost to X as 7. When nodes D, F and E come out of the "loop > avoidance" state, they would ultimately update their cost to X to > 8, 9 and 10 respectively without any loops. > > This policy does cause a delay in convergence. Suppose B->C cost is > 1 in the example above. B enters the "loop avoidance" state when > cost of link B->A changes to 100. Node B would not select C as next > hop (and advertize a cost 3 to X) until it comes out of the "loop > avoidance" state. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=446f555b9=mukul@uwm.edu Mon Jul 20 18:02:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CA53A69BA for ; Mon, 20 Jul 2009 18:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZAGRLm4XNUu for ; Mon, 20 Jul 2009 18:02:50 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 94CEA3A6C3B for ; Mon, 20 Jul 2009 18:02:50 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 20 Jul 2009 20:02:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 58709C085A1; Mon, 20 Jul 2009 20:02:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06TseH7zbrHe; Mon, 20 Jul 2009 20:02:49 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 62DDBC085A9; Mon, 20 Jul 2009 20:02:49 -0500 (CDT) Date: Mon, 20 Jul 2009 20:02:49 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1732864908.3947031248137887086.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:03:13 -0000 Hi Jonathan, I am not sure how does the "Held-up" mechanism cover the loop avoidance scheme I described. I seem to be missing some thing. Here is my understanding of the "held-up" mechanism described in RPL: Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" state: 1. "Delay the reattachment of a sub-DAG that has been forced to detach. This is not as safe as the use of the sequence, but still covers that when a sub-DAG has detached, the Router Advertisement - DAG Information Option that is initiated by the new DAG root has a chance to spread outward along the sub-DAG so that two different DAGs have formed." I did not understand the text quoted above at all. Please clarify. I did not find any additional text in RPL draft that further describes the use of "held-up" state in this context. 2. The second purpose of the "held-up" state, which I think I understand clearly, is to delay a node's joining of a new DAG to try to ensure that: a) a node joins the new DAG at the minimum possible depth; b) among the neighbor/nearby nodes trying to join the new DAG, the nodes join the new DAG roughly in order of their depth in the new DAG. To achieve these objectives, a node keeps a potential parent in the new DAG in the "held-up' state for a time duration proportional to the potential parent's depth in that DAG. For every new potential parent, the node starts a new "held-up" state timer (the hop timer). The node joins the new DAG via the first potential parent coming out of the "held-up" state. On the other hand, the loop avoidance mechanism I described puts a node in the "loop avoidance" state when the current nexthop/parent is no longer good enough. Rather than immediately choosing a different parent (based on potentially erroneous costs currently being advertised by neighbors), the node advertises (via special _marked_ advertisements) its new cost through the current parent for the duration it is in the "loop avoidance" state. On receiving these _marked_ advertizements, the node's children enter the "loop avoidance" state as well and further propagate the new cost information. The idea is that, by the time the node comes out of the "loop avoidance" state, hopefully all its neighbors would have corrected their cost estimates if the previous estimates were based on the old costs. So, on coming out of the "loop avoidance" state, when the node selects its new parents, it does not cause a routing loop or a "count to infinity" situation. >2) What is the effect of packet loss? >- If node B is a descendant of A and B misses the advertisement from >its parent, then A may attach to B or any of its descendants. In a >sufficiently dense network, there's a fairly high probability that >some node B will miss the advertisement from A (even with >retransmissions). On the flip side, those that properly hear the new >cost values are likely not to be involved in any loops. In summary, >Count-to-Infinity still exists but arguably with only a subset of nodes. I agree. The efficacy of the solution depends on the probability of _neighbor_ descendants (i.e. descendants that are neighbors as well) receiving the new cost information and updating their cost advertisements based on this information. This probability in turn depends on parameters like the probability of advertisement loss, the duration of the "loop avoidance" state, the number of times a node sends out advertisements while in this state, the children tree topology etc. Regards Mukul On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: > Hi all > > Here is a simple loop avoidance mechanism that can be used in a P2P > routing solution that does not use DAGs. > > Thanks > Mukul > > In DV protocols, the routing loops are triggered when the cost to > reach a destination via the current next hop increases so much that > a new next hop needs to be selected. > > Suppose, a node, B, determines that its current next hop, A, for a > destination, X, may no longer be the best ("minimum cost") neighbor > to forward packets to. Such determination could be based on an > increase in the link cost to node A or the receipt of a new > advertisement from node A showing an increased cost to reach the > destination X. > > In case of such an event, node B should not choose a new next hop > immediately. This is because the current cost advertisements by its > neighbors, as well as any new advertisements generated in the > immediate aftermath of the event, may be based on node B's erstwhile > cost to reach the destination. Immediate selection of a new next hop > based on the current or new cost advertisements by the neighbors may > lead to a routing loop and a "count to infinity" situation. > > Rather, node B should initiate the propagation of new cost > information down the tree (of nodes for whom it currently lies on > the route to X)and wait for some time before calculating its new > next hop. The hope is that by the time the node calculates its new > next hop, its increased cost along the current next hop is known to > all its neighbors and they have generated new advertisements if > their previous advertisements were based on the old cost of node B > to reach X. > > So, when node B determines that its current next hop A for > destination X is no longer the best neighbor to forward packets to, > it generates a new specially _marked_ advertisement that lists node > B's new cost to reach X via A, the current next hop. > > The generation of a _marked_ advertizement regarding destination X > puts the node in the "loop avoidance" state for a time period during > which the node can neither change its next hop to destination X nor > generate a regular advertisement for the destination X. > > All nodes that receive node B's _marked_ advertisement regarding > destination X update their cost to reach X via B. If a node > currently considers node B as its next hop to destination X, it > additionally does the following: > 1. it enters the "loop avoidance" state and hence consequently keeps > node B as its next hop to X > 2. originates a _marked_ advertizement listing its new cost to > destination X via node B > > Once a node exits the "loop avoidance" state, it is allowed to > select a new next hop to X and generate a regular advertisement > listing its new cost to X. > > Here is an example showing the efficacy of this proposal: > > X > | > A > / \ > B-C > / \ > D E > \ / > F > > X is the destination. > > Suppose all unidirectional link costs are 1 except the following: B- > >C:5, B->D:5 and E->B:5 > > Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X > > and node B's perceived cost to reach X via each neighbor is as > follows: > via A:2, via C:7, via D:8, via E:6 > > Suppose the cost of link B->A changes to 100. > > In a simple DV protocol, B's cost to reach X via A becomes 101 and > hence it immediately chooses E as the next hop (declaring its new > cost to X as 6), thereby creating routing loop B->E->F->D->B and a > "count to infinity" situation. > > Under the proposed protocol, B would generate a _marked_ > advertisement listing its cost to X as 101 and enter the "loop > avoidance" state. This _marked_ advertisement is received by A, C, D > and E. Since D considers B as its next hop to X, it enters the "loop > avoidance" state as well and generates its own _marked_ > advertisement listing its cost to X as 102. > > On receiving this advertisement, node F enters the "loop avoidance" > state and generates its own _marked_ advertisement listing its cost > to X as 103. > > On receiving this advertisement, node E enters the "loop avoidance" > state and generates its own _marked_ advertisement listing its cost > to X as 104. > > If node B comes out of the "loop avoidance" state only after the > receipt of this advertisement from E, B would correctly choose node > C as its new next hop to X and generate a new advertisement listing > its cost to X as 7. When nodes D, F and E come out of the "loop > avoidance" state, they would ultimately update their cost to X to > 8, 9 and 10 respectively without any loops. > > This policy does cause a delay in convergence. Suppose B->C cost is > 1 in the example above. B enters the "loop avoidance" state when > cost of link B->A changes to 100. Node B would not select C as next > hop (and advertize a cost 3 to X) until it comes out of the "loop > avoidance" state. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Mon Jul 20 19:18:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAD93A6942 for ; Mon, 20 Jul 2009 19:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWqoX6tYA5er for ; Mon, 20 Jul 2009 19:18:57 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AD59728C1A2 for ; Mon, 20 Jul 2009 19:18:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 169F2AF89E; Mon, 20 Jul 2009 19:18:30 -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 5Mi2ADNCKrkH; Mon, 20 Jul 2009 19:18:26 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id 88BA9AF85D; Mon, 20 Jul 2009 19:18:25 -0700 (PDT) Message-Id: <3CAA0720-6C70-4528-A47D-14673536CF7E@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 19:18:23 -0700 References: <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 02:18:58 -0000 Hi Mukul, On Jul 20, 2009, at 6:02 PM, Mukul Goyal wrote: > I am not sure how does the "Held-up" mechanism cover the loop > avoidance scheme I described. I seem to be missing some thing. Here > is my understanding of the "held-up" mechanism described in RPL: > > Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" > state: > > 1. "Delay the reattachment of a sub-DAG that has been forced to > detach. This is not as safe as the use of the sequence, but > still > covers that when a sub-DAG has detached, the Router Advertisement > - DAG Information Option that is initiated by the new DAG root > has > a chance to spread outward along the sub-DAG so that two > different > DAGs have formed." > > I did not understand the text quoted above at all. Please clarify. I > did not find any additional text in RPL draft that further describes > the use of "held-up" state in this context. It's clear that loops may occur if a node needs to increase its cost. In the current draft, a node detaches from the DAG if a node cannot use any neighbor as a feasible successor without increasing its cost. If a node must increase its cost, it must put the candidate successor in the held-up state for a period of time before it becomes a feasible successor. The held-up state is a loop-avoidance mechanism to allow new routing information to propagate to the candidate node. The held- up period is currently specified to approximate the worst-case - a value based on the depth of the candidate node and the expected time to communicate information at each hop. I don't see any real difference between the "held-up" state and your proposed "loop-avoidance" state. A subtle difference is rather than a node placing itself in the "held- up/loop-avoidance" state, RPL places the *candidate* in the "held-up/ loop-avoidance" state. That's why the RPL loop-avoidance mechanism does not require a flag in the advertisement - any joining nodes will wait for the held-up period for new routing information to propagate to the candidate node. Am I missing something else? We'll try to improve the text in the next revision. Among other things, we need to use common terminology (the current draft is a mix of existing drafts and new text). -- Jonathan Hui > 2. The second purpose of the "held-up" state, which I think I > understand clearly, is to delay a node's joining of a new DAG to try > to ensure that: > a) a node joins the new DAG at the minimum possible depth; > b) among the neighbor/nearby nodes trying to join the new DAG, the > nodes join the new DAG roughly in order of their depth in the new DAG. > To achieve these objectives, a node keeps a potential parent in the > new DAG in the "held-up' state for a time duration proportional to > the potential parent's depth in that DAG. For every new potential > parent, the node starts a new "held-up" state timer (the hop timer). > The node joins the new DAG via the first potential parent coming out > of the "held-up" state. > > On the other hand, the loop avoidance mechanism I described puts a > node in the "loop avoidance" state when the current nexthop/parent > is no longer good enough. Rather than immediately choosing a > different parent (based on potentially erroneous costs currently > being advertised by neighbors), the node advertises (via special > _marked_ advertisements) its new cost through the current parent for > the duration it is in the "loop avoidance" state. On receiving these > _marked_ advertizements, the node's children enter the "loop > avoidance" state as well and further propagate the new cost > information. The idea is that, by the time the node comes out of the > "loop avoidance" state, hopefully all its neighbors would have > corrected their cost estimates if the previous estimates were based > on the old costs. So, on coming out of the "loop avoidance" state, > when the node selects its new parents, it does not cause a routing > loop or a "count to infinity" situation. > >> 2) What is the effect of packet loss? >> - If node B is a descendant of A and B misses the advertisement from >> its parent, then A may attach to B or any of its descendants. In a >> sufficiently dense network, there's a fairly high probability that >> some node B will miss the advertisement from A (even with >> retransmissions). On the flip side, those that properly hear the new >> cost values are likely not to be involved in any loops. In summary, >> Count-to-Infinity still exists but arguably with only a subset of >> nodes. > > I agree. The efficacy of the solution depends on the probability of > _neighbor_ descendants (i.e. descendants that are neighbors as well) > receiving the new cost information and updating their cost > advertisements based on this information. This probability in turn > depends on parameters like the probability of advertisement loss, > the duration of the "loop avoidance" state, the number of times a > node sends out advertisements while in this state, the children tree > topology etc. > > Regards > Mukul > > > > On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: > >> Hi all >> >> Here is a simple loop avoidance mechanism that can be used in a P2P >> routing solution that does not use DAGs. >> >> Thanks >> Mukul >> >> In DV protocols, the routing loops are triggered when the cost to >> reach a destination via the current next hop increases so much that >> a new next hop needs to be selected. >> >> Suppose, a node, B, determines that its current next hop, A, for a >> destination, X, may no longer be the best ("minimum cost") neighbor >> to forward packets to. Such determination could be based on an >> increase in the link cost to node A or the receipt of a new >> advertisement from node A showing an increased cost to reach the >> destination X. >> >> In case of such an event, node B should not choose a new next hop >> immediately. This is because the current cost advertisements by its >> neighbors, as well as any new advertisements generated in the >> immediate aftermath of the event, may be based on node B's erstwhile >> cost to reach the destination. Immediate selection of a new next hop >> based on the current or new cost advertisements by the neighbors may >> lead to a routing loop and a "count to infinity" situation. >> >> Rather, node B should initiate the propagation of new cost >> information down the tree (of nodes for whom it currently lies on >> the route to X)and wait for some time before calculating its new >> next hop. The hope is that by the time the node calculates its new >> next hop, its increased cost along the current next hop is known to >> all its neighbors and they have generated new advertisements if >> their previous advertisements were based on the old cost of node B >> to reach X. >> >> So, when node B determines that its current next hop A for >> destination X is no longer the best neighbor to forward packets to, >> it generates a new specially _marked_ advertisement that lists node >> B's new cost to reach X via A, the current next hop. >> >> The generation of a _marked_ advertizement regarding destination X >> puts the node in the "loop avoidance" state for a time period during >> which the node can neither change its next hop to destination X nor >> generate a regular advertisement for the destination X. >> >> All nodes that receive node B's _marked_ advertisement regarding >> destination X update their cost to reach X via B. If a node >> currently considers node B as its next hop to destination X, it >> additionally does the following: >> 1. it enters the "loop avoidance" state and hence consequently keeps >> node B as its next hop to X >> 2. originates a _marked_ advertizement listing its new cost to >> destination X via node B >> >> Once a node exits the "loop avoidance" state, it is allowed to >> select a new next hop to X and generate a regular advertisement >> listing its new cost to X. >> >> Here is an example showing the efficacy of this proposal: >> >> X >> | >> A >> / \ >> B-C >> / \ >> D E >> \ / >> F >> >> X is the destination. >> >> Suppose all unidirectional link costs are 1 except the following: B- >>> C:5, B->D:5 and E->B:5 >> >> Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X >> >> and node B's perceived cost to reach X via each neighbor is as >> follows: >> via A:2, via C:7, via D:8, via E:6 >> >> Suppose the cost of link B->A changes to 100. >> >> In a simple DV protocol, B's cost to reach X via A becomes 101 and >> hence it immediately chooses E as the next hop (declaring its new >> cost to X as 6), thereby creating routing loop B->E->F->D->B and a >> "count to infinity" situation. >> >> Under the proposed protocol, B would generate a _marked_ >> advertisement listing its cost to X as 101 and enter the "loop >> avoidance" state. This _marked_ advertisement is received by A, C, D >> and E. Since D considers B as its next hop to X, it enters the "loop >> avoidance" state as well and generates its own _marked_ >> advertisement listing its cost to X as 102. >> >> On receiving this advertisement, node F enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 103. >> >> On receiving this advertisement, node E enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 104. >> >> If node B comes out of the "loop avoidance" state only after the >> receipt of this advertisement from E, B would correctly choose node >> C as its new next hop to X and generate a new advertisement listing >> its cost to X as 7. When nodes D, F and E come out of the "loop >> avoidance" state, they would ultimately update their cost to X to >> 8, 9 and 10 respectively without any loops. >> >> This policy does cause a delay in convergence. Suppose B->C cost is >> 1 in the example above. B enters the "loop avoidance" state when >> cost of link B->A changes to 100. Node B would not select C as next >> hop (and advertize a cost 3 to X) until it comes out of the "loop >> avoidance" state. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From prvs=446f555b9=mukul@uwm.edu Tue Jul 21 01:55:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EC03A6AF8 for ; Tue, 21 Jul 2009 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMU-sfAjWsHm for ; Tue, 21 Jul 2009 01:55:38 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id AF13C28C1BC for ; Tue, 21 Jul 2009 01:55:38 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 21 Jul 2009 03:55:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6DC92C085A7; Tue, 21 Jul 2009 03:55:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4prrAVvyVYnS; Tue, 21 Jul 2009 03:55:28 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0778CC085A1; Tue, 21 Jul 2009 03:55:28 -0500 (CDT) Date: Tue, 21 Jul 2009 03:55:27 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <121240882.3982791248166527861.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1615651933.3982631248165743072.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:55:40 -0000 Hi Jonathan If we were to compare the loop-avoidance strategy I proposed, when applied = to RPL, with the RPL approach, we can find more subtle differences: 1. Even though you have not mentioned it, one has to assume that a newly de= tached node tells its neighbors (including its erstwhile children) about it= s detachment so that they can update their routing metrics eliminating this= node from consideration. So, in effect, the detached node is advertising a= n infinite cost, which may cause a large number of its descenadants to adve= rtise infinite cost as well (if they also detach from the original DAG). No= w, can we call such nodes, detached from their original DAG, route-less sin= ce such nodes can't forward packets to their old parents and don't have new= parents yet? If so, there may be serious implications for packet forwardin= g. Thus, detaching nodes from the DAG seems an overly-conservative loop-avo= idance strategy. (The "loop correction" strategy I proposed is based on det= ecting explicitly the nodes in-loop and requiring only "in-loop" nodes to a= dvertise infinite cost; still a much milder strategy than what RPL has.) In= comparison, the loop-avoidance strategy I proposed involves nodes maintain= ing their old routes during the "loop avoidance" state. These old routes ma= y not be best but are still better than no routes at all. 2. There are issues with putting neighbors in "held-up" state versus puttin= g the node itself in "loop avoidance" state: a) Need to maintain potentially several per-neighbor timers. b) The "held-up" timer duration for a neighbor depends on the neighbor's de= pth. As you mentioned, if all neighbors have large depths, the "held-up" st= ates of the neighbors can last for a long time during which the node has to= stay detached, i.e. potentially route-less. c) Since the node selects the first neighbor coming out of "held-up" state = as the parent, a node would perhaps select its minimum depth neighbor as it= s only parent. This is not necessarily a good thing. This policy discourage= s multiple parents. On the other hand, if the node were to go to a fixed du= ration "loop-avoidance" state itself, it may have good chances of selecting= multiple parents including the minimum depth one. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "roll" Sent: Monday, July 20, 2009 9:18:23 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV rou= ting not using DAGs Hi Mukul, On Jul 20, 2009, at 6:02 PM, Mukul Goyal wrote: > I am not sure how does the "Held-up" mechanism cover the loop =20 > avoidance scheme I described. I seem to be missing some thing. Here =20 > is my understanding of the "held-up" mechanism described in RPL: > > Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" =20 > state: > > 1. "Delay the reattachment of a sub-DAG that has been forced to > detach. This is not as safe as the use of the sequence, but =20 > still > covers that when a sub-DAG has detached, the Router Advertisement > - DAG Information Option that is initiated by the new DAG root =20 > has > a chance to spread outward along the sub-DAG so that two =20 > different > DAGs have formed." > > I did not understand the text quoted above at all. Please clarify. I =20 > did not find any additional text in RPL draft that further describes =20 > the use of "held-up" state in this context. It's clear that loops may occur if a node needs to increase its cost. =20 In the current draft, a node detaches from the DAG if a node cannot =20 use any neighbor as a feasible successor without increasing its cost. =20 If a node must increase its cost, it must put the candidate successor =20 in the held-up state for a period of time before it becomes a feasible =20 successor. The held-up state is a loop-avoidance mechanism to allow =20 new routing information to propagate to the candidate node. The held-=20 up period is currently specified to approximate the worst-case - a =20 value based on the depth of the candidate node and the expected time =20 to communicate information at each hop. I don't see any real difference between the "held-up" state and your =20 proposed "loop-avoidance" state. A subtle difference is rather than a node placing itself in the "held-=20 up/loop-avoidance" state, RPL places the *candidate* in the "held-up/=20 loop-avoidance" state. That's why the RPL loop-avoidance mechanism =20 does not require a flag in the advertisement - any joining nodes will =20 wait for the held-up period for new routing information to propagate =20 to the candidate node. Am I missing something else? We'll try to improve the text in the next revision. Among other =20 things, we need to use common terminology (the current draft is a mix =20 of existing drafts and new text). -- Jonathan Hui > 2. The second purpose of the "held-up" state, which I think I =20 > understand clearly, is to delay a node's joining of a new DAG to try =20 > to ensure that: > a) a node joins the new DAG at the minimum possible depth; > b) among the neighbor/nearby nodes trying to join the new DAG, the =20 > nodes join the new DAG roughly in order of their depth in the new DAG. > To achieve these objectives, a node keeps a potential parent in the =20 > new DAG in the "held-up' state for a time duration proportional to =20 > the potential parent's depth in that DAG. For every new potential =20 > parent, the node starts a new "held-up" state timer (the hop timer). =20 > The node joins the new DAG via the first potential parent coming out =20 > of the "held-up" state. > > On the other hand, the loop avoidance mechanism I described puts a =20 > node in the "loop avoidance" state when the current nexthop/parent =20 > is no longer good enough. Rather than immediately choosing a =20 > different parent (based on potentially erroneous costs currently =20 > being advertised by neighbors), the node advertises (via special =20 > _marked_ advertisements) its new cost through the current parent for =20 > the duration it is in the "loop avoidance" state. On receiving these =20 > _marked_ advertizements, the node's children enter the "loop =20 > avoidance" state as well and further propagate the new cost =20 > information. The idea is that, by the time the node comes out of the =20 > "loop avoidance" state, hopefully all its neighbors would have =20 > corrected their cost estimates if the previous estimates were based =20 > on the old costs. So, on coming out of the "loop avoidance" state, =20 > when the node selects its new parents, it does not cause a routing =20 > loop or a "count to infinity" situation. > >> 2) What is the effect of packet loss? >> - If node B is a descendant of A and B misses the advertisement from >> its parent, then A may attach to B or any of its descendants. In a >> sufficiently dense network, there's a fairly high probability that >> some node B will miss the advertisement from A (even with >> retransmissions). On the flip side, those that properly hear the new >> cost values are likely not to be involved in any loops. In summary, >> Count-to-Infinity still exists but arguably with only a subset of =20 >> nodes. > > I agree. The efficacy of the solution depends on the probability of =20 > _neighbor_ descendants (i.e. descendants that are neighbors as well) =20 > receiving the new cost information and updating their cost =20 > advertisements based on this information. This probability in turn =20 > depends on parameters like the probability of advertisement loss, =20 > the duration of the "loop avoidance" state, the number of times a =20 > node sends out advertisements while in this state, the children tree =20 > topology etc. > > Regards > Mukul > > > > On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: > >> Hi all >> >> Here is a simple loop avoidance mechanism that can be used in a P2P >> routing solution that does not use DAGs. >> >> Thanks >> Mukul >> >> In DV protocols, the routing loops are triggered when the cost to >> reach a destination via the current next hop increases so much that >> a new next hop needs to be selected. >> >> Suppose, a node, B, determines that its current next hop, A, for a >> destination, X, may no longer be the best ("minimum cost") neighbor >> to forward packets to. Such determination could be based on an >> increase in the link cost to node A or the receipt of a new >> advertisement from node A showing an increased cost to reach the >> destination X. >> >> In case of such an event, node B should not choose a new next hop >> immediately. This is because the current cost advertisements by its >> neighbors, as well as any new advertisements generated in the >> immediate aftermath of the event, may be based on node B's erstwhile >> cost to reach the destination. Immediate selection of a new next hop >> based on the current or new cost advertisements by the neighbors may >> lead to a routing loop and a "count to infinity" situation. >> >> Rather, node B should initiate the propagation of new cost >> information down the tree (of nodes for whom it currently lies on >> the route to X)and wait for some time before calculating its new >> next hop. The hope is that by the time the node calculates its new >> next hop, its increased cost along the current next hop is known to >> all its neighbors and they have generated new advertisements if >> their previous advertisements were based on the old cost of node B >> to reach X. >> >> So, when node B determines that its current next hop A for >> destination X is no longer the best neighbor to forward packets to, >> it generates a new specially _marked_ advertisement that lists node >> B's new cost to reach X via A, the current next hop. >> >> The generation of a _marked_ advertizement regarding destination X >> puts the node in the "loop avoidance" state for a time period during >> which the node can neither change its next hop to destination X nor >> generate a regular advertisement for the destination X. >> >> All nodes that receive node B's _marked_ advertisement regarding >> destination X update their cost to reach X via B. If a node >> currently considers node B as its next hop to destination X, it >> additionally does the following: >> 1. it enters the "loop avoidance" state and hence consequently keeps >> node B as its next hop to X >> 2. originates a _marked_ advertizement listing its new cost to >> destination X via node B >> >> Once a node exits the "loop avoidance" state, it is allowed to >> select a new next hop to X and generate a regular advertisement >> listing its new cost to X. >> >> Here is an example showing the efficacy of this proposal: >> >> X >> | >> A >> / \ >> B-C >> / \ >> D E >> \ / >> F >> >> X is the destination. >> >> Suppose all unidirectional link costs are 1 except the following: B- >>> C:5, B->D:5 and E->B:5 >> >> Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X >> >> and node B's perceived cost to reach X via each neighbor is as >> follows: >> via A:2, via C:7, via D:8, via E:6 >> >> Suppose the cost of link B->A changes to 100. >> >> In a simple DV protocol, B's cost to reach X via A becomes 101 and >> hence it immediately chooses E as the next hop (declaring its new >> cost to X as 6), thereby creating routing loop B->E->F->D->B and a >> "count to infinity" situation. >> >> Under the proposed protocol, B would generate a _marked_ >> advertisement listing its cost to X as 101 and enter the "loop >> avoidance" state. This _marked_ advertisement is received by A, C, D >> and E. Since D considers B as its next hop to X, it enters the "loop >> avoidance" state as well and generates its own _marked_ >> advertisement listing its cost to X as 102. >> >> On receiving this advertisement, node F enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 103. >> >> On receiving this advertisement, node E enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 104. >> >> If node B comes out of the "loop avoidance" state only after the >> receipt of this advertisement from E, B would correctly choose node >> C as its new next hop to X and generate a new advertisement listing >> its cost to X as 7. When nodes D, F and E come out of the "loop >> avoidance" state, they would ultimately update their cost to X to >> 8, 9 and 10 respectively without any loops. >> >> This policy does cause a delay in convergence. Suppose B->C cost is >> 1 in the example above. B enters the "loop avoidance" state when >> cost of link B->A changes to 100. Node B would not select C as next >> hop (and advertize a cost 3 to X) until it comes out of the "loop >> avoidance" state. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From jhui@archrock.com Tue Jul 21 07:55:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F413A6E70 for ; Tue, 21 Jul 2009 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9QPzCNt5hGs for ; Tue, 21 Jul 2009 07:55:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E4E3C3A6B98 for ; Tue, 21 Jul 2009 07:55:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B886DAF914; Tue, 21 Jul 2009 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv1HsgJ5Qmez; Tue, 21 Jul 2009 07:55:21 -0700 (PDT) Received: from [192.168.7.71] (69-12-164-133.sfo.archrock.com [69.12.164.133]) by mail.sf.archrock.com (Postfix) with ESMTP id 8CDBDAF915; Tue, 21 Jul 2009 07:55:21 -0700 (PDT) Message-Id: <7A61CD7A-5B54-43A2-A176-7612004989BC@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <121240882.3982791248166527861.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 07:55:20 -0700 References: <121240882.3982791248166527861.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:55:57 -0000 Hi Mukul, While there are subtle differences, both are based on the same principle - if there's a possibility of a loop, communicate new routing information to children, wait for a while for routing information to propagate before finalizing decisions. The larger issue is the efficacy of such an approach in real-world deployments. There is a level of discomfort in the WG because this (and other) mechanisms haven't yet been widely deployed. As identified by myself, you, and others in this thread, there are still some issues that we need to weigh against the perceived benefits. I'd like to get input from others on the basic mechanism before we get into a deep discussion on the details. Couple quick comments to your email below: On Jul 21, 2009, at 1:55 AM, Mukul Goyal wrote: > If we were to compare the loop-avoidance strategy I proposed, when > applied to RPL, with the RPL approach, we can find more subtle > differences: > > 1. Even though you have not mentioned it, one has to assume that a > newly detached node tells its neighbors (including its erstwhile > children) about its detachment so that they can update their routing > metrics eliminating this node from consideration. So, in effect, the > detached node is advertising an infinite cost, which may cause a > large number of its descenadants to advertise infinite cost as well > (if they also detach from the original DAG). Now, can we call such > nodes, detached from their original DAG, route-less since such nodes > can't forward packets to their old parents and don't have new > parents yet? If so, there may be serious implications for packet > forwarding. Thus, detaching nodes from the DAG Detachment only means that a node advertises itself as being in a floating DAG - the routing structure isn't really dissolved. > seems an overly-conservative loop-avoidance strategy. (The "loop > correction" strategy I proposed is based on detecting explicitly the > nodes in-loop and requiring only "in-loop" nodes to advertise > infinite cost; still a much milder strategy than what RPL has.) In > comparison, the loop-avoidance strategy I proposed involves nodes > maintaining their old routes during the "loop avoidance" state. > These old routes may not be best but are still better than no routes > at all. > > 2. There are issues with putting neighbors in "held-up" state versus > putting the node itself in "loop avoidance" state: > a) Need to maintain potentially several per-neighbor timers. > b) The "held-up" timer duration for a neighbor depends on the > neighbor's depth. As you mentioned, if all neighbors have large > depths, the "held-up" states of the neighbors can last for a long > time during which the node has to stay detached, i.e. potentially > route-less. > c) Since the node selects the first neighbor coming out of "held-up" > state as the parent, a node would perhaps select its minimum depth > neighbor as its only parent. This is not necessarily a good thing. > This policy discourages multiple parents. On the other hand, if the > node were to go to a fixed duration "loop-avoidance" state itself, > it may have good chances of selecting multiple parents including the > minimum depth one. Minimally, the wait time should be the time it takes to propagate routing information from a node to the candidate successor - this can be approximated by the required increase in depth to use the candidate successor. The draft uses depth from the root because it serves the dual purpose of trying to better coordinate the propagation of DV information - with the hope of better convergence times in some cases. Again, these pretty detailed issues in the protocol design. I think we first need to have the larger discussion of whether a broadcast-wait- choose or a different mechanism should be included in the core protocol. -- Jonathan Hui > > Thanks > Mukul > > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "roll" > Sent: Monday, July 20, 2009 9:18:23 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P > DV routing not using DAGs > > > Hi Mukul, > > On Jul 20, 2009, at 6:02 PM, Mukul Goyal wrote: >> I am not sure how does the "Held-up" mechanism cover the loop >> avoidance scheme I described. I seem to be missing some thing. Here >> is my understanding of the "held-up" mechanism described in RPL: >> >> Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" >> state: >> >> 1. "Delay the reattachment of a sub-DAG that has been forced to >> detach. This is not as safe as the use of the sequence, but >> still >> covers that when a sub-DAG has detached, the Router Advertisement >> - DAG Information Option that is initiated by the new DAG root >> has >> a chance to spread outward along the sub-DAG so that two >> different >> DAGs have formed." >> >> I did not understand the text quoted above at all. Please clarify. I >> did not find any additional text in RPL draft that further describes >> the use of "held-up" state in this context. > > It's clear that loops may occur if a node needs to increase its cost. > In the current draft, a node detaches from the DAG if a node cannot > use any neighbor as a feasible successor without increasing its cost. > If a node must increase its cost, it must put the candidate successor > in the held-up state for a period of time before it becomes a feasible > successor. The held-up state is a loop-avoidance mechanism to allow > new routing information to propagate to the candidate node. The held- > up period is currently specified to approximate the worst-case - a > value based on the depth of the candidate node and the expected time > to communicate information at each hop. > > I don't see any real difference between the "held-up" state and your > proposed "loop-avoidance" state. > A subtle difference is rather than a node placing itself in the "held- > up/loop-avoidance" state, RPL places the *candidate* in the "held-up/ > loop-avoidance" state. That's why the RPL loop-avoidance mechanism > does not require a flag in the advertisement - any joining nodes will > wait for the held-up period for new routing information to propagate > to the candidate node. Am I missing something else? > > We'll try to improve the text in the next revision. Among other > things, we need to use common terminology (the current draft is a mix > of existing drafts and new text). > > -- > Jonathan Hui > >> 2. The second purpose of the "held-up" state, which I think I >> understand clearly, is to delay a node's joining of a new DAG to try >> to ensure that: >> a) a node joins the new DAG at the minimum possible depth; >> b) among the neighbor/nearby nodes trying to join the new DAG, the >> nodes join the new DAG roughly in order of their depth in the new >> DAG. >> To achieve these objectives, a node keeps a potential parent in the >> new DAG in the "held-up' state for a time duration proportional to >> the potential parent's depth in that DAG. For every new potential >> parent, the node starts a new "held-up" state timer (the hop timer). >> The node joins the new DAG via the first potential parent coming out >> of the "held-up" state. >> >> On the other hand, the loop avoidance mechanism I described puts a >> node in the "loop avoidance" state when the current nexthop/parent >> is no longer good enough. Rather than immediately choosing a >> different parent (based on potentially erroneous costs currently >> being advertised by neighbors), the node advertises (via special >> _marked_ advertisements) its new cost through the current parent for >> the duration it is in the "loop avoidance" state. On receiving these >> _marked_ advertizements, the node's children enter the "loop >> avoidance" state as well and further propagate the new cost >> information. The idea is that, by the time the node comes out of the >> "loop avoidance" state, hopefully all its neighbors would have >> corrected their cost estimates if the previous estimates were based >> on the old costs. So, on coming out of the "loop avoidance" state, >> when the node selects its new parents, it does not cause a routing >> loop or a "count to infinity" situation. >> >>> 2) What is the effect of packet loss? >>> - If node B is a descendant of A and B misses the advertisement from >>> its parent, then A may attach to B or any of its descendants. In a >>> sufficiently dense network, there's a fairly high probability that >>> some node B will miss the advertisement from A (even with >>> retransmissions). On the flip side, those that properly hear the new >>> cost values are likely not to be involved in any loops. In summary, >>> Count-to-Infinity still exists but arguably with only a subset of >>> nodes. >> >> I agree. The efficacy of the solution depends on the probability of >> _neighbor_ descendants (i.e. descendants that are neighbors as well) >> receiving the new cost information and updating their cost >> advertisements based on this information. This probability in turn >> depends on parameters like the probability of advertisement loss, >> the duration of the "loop avoidance" state, the number of times a >> node sends out advertisements while in this state, the children tree >> topology etc. >> >> Regards >> Mukul >> >> >> >> On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: >> >>> Hi all >>> >>> Here is a simple loop avoidance mechanism that can be used in a P2P >>> routing solution that does not use DAGs. >>> >>> Thanks >>> Mukul >>> >>> In DV protocols, the routing loops are triggered when the cost to >>> reach a destination via the current next hop increases so much that >>> a new next hop needs to be selected. >>> >>> Suppose, a node, B, determines that its current next hop, A, for a >>> destination, X, may no longer be the best ("minimum cost") neighbor >>> to forward packets to. Such determination could be based on an >>> increase in the link cost to node A or the receipt of a new >>> advertisement from node A showing an increased cost to reach the >>> destination X. >>> >>> In case of such an event, node B should not choose a new next hop >>> immediately. This is because the current cost advertisements by its >>> neighbors, as well as any new advertisements generated in the >>> immediate aftermath of the event, may be based on node B's erstwhile >>> cost to reach the destination. Immediate selection of a new next hop >>> based on the current or new cost advertisements by the neighbors may >>> lead to a routing loop and a "count to infinity" situation. >>> >>> Rather, node B should initiate the propagation of new cost >>> information down the tree (of nodes for whom it currently lies on >>> the route to X)and wait for some time before calculating its new >>> next hop. The hope is that by the time the node calculates its new >>> next hop, its increased cost along the current next hop is known to >>> all its neighbors and they have generated new advertisements if >>> their previous advertisements were based on the old cost of node B >>> to reach X. >>> >>> So, when node B determines that its current next hop A for >>> destination X is no longer the best neighbor to forward packets to, >>> it generates a new specially _marked_ advertisement that lists node >>> B's new cost to reach X via A, the current next hop. >>> >>> The generation of a _marked_ advertizement regarding destination X >>> puts the node in the "loop avoidance" state for a time period during >>> which the node can neither change its next hop to destination X nor >>> generate a regular advertisement for the destination X. >>> >>> All nodes that receive node B's _marked_ advertisement regarding >>> destination X update their cost to reach X via B. If a node >>> currently considers node B as its next hop to destination X, it >>> additionally does the following: >>> 1. it enters the "loop avoidance" state and hence consequently keeps >>> node B as its next hop to X >>> 2. originates a _marked_ advertizement listing its new cost to >>> destination X via node B >>> >>> Once a node exits the "loop avoidance" state, it is allowed to >>> select a new next hop to X and generate a regular advertisement >>> listing its new cost to X. >>> >>> Here is an example showing the efficacy of this proposal: >>> >>> X >>> | >>> A >>> / \ >>> B-C >>> / \ >>> D E >>> \ / >>> F >>> >>> X is the destination. >>> >>> Suppose all unidirectional link costs are 1 except the following: B- >>>> C:5, B->D:5 and E->B:5 >>> >>> Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X >>> >>> and node B's perceived cost to reach X via each neighbor is as >>> follows: >>> via A:2, via C:7, via D:8, via E:6 >>> >>> Suppose the cost of link B->A changes to 100. >>> >>> In a simple DV protocol, B's cost to reach X via A becomes 101 and >>> hence it immediately chooses E as the next hop (declaring its new >>> cost to X as 6), thereby creating routing loop B->E->F->D->B and a >>> "count to infinity" situation. >>> >>> Under the proposed protocol, B would generate a _marked_ >>> advertisement listing its cost to X as 101 and enter the "loop >>> avoidance" state. This _marked_ advertisement is received by A, C, D >>> and E. Since D considers B as its next hop to X, it enters the "loop >>> avoidance" state as well and generates its own _marked_ >>> advertisement listing its cost to X as 102. >>> >>> On receiving this advertisement, node F enters the "loop avoidance" >>> state and generates its own _marked_ advertisement listing its cost >>> to X as 103. >>> >>> On receiving this advertisement, node E enters the "loop avoidance" >>> state and generates its own _marked_ advertisement listing its cost >>> to X as 104. >>> >>> If node B comes out of the "loop avoidance" state only after the >>> receipt of this advertisement from E, B would correctly choose node >>> C as its new next hop to X and generate a new advertisement listing >>> its cost to X as 7. When nodes D, F and E come out of the "loop >>> avoidance" state, they would ultimately update their cost to X to >>> 8, 9 and 10 respectively without any loops. >>> >>> This policy does cause a delay in convergence. Suppose B->C cost is >>> 1 in the example above. B enters the "loop avoidance" state when >>> cost of link B->A changes to 100. Node B would not select C as next >>> hop (and advertize a cost 3 to X) until it comes out of the "loop >>> avoidance" state. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > From russ@cisco.com Tue Jul 14 06:44:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315BF3A69D0 for ; Tue, 14 Jul 2009 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUM5S2RXPQS6 for ; Tue, 14 Jul 2009 06:44:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D141E3A6EA3 for ; Tue, 14 Jul 2009 06:44:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50315598" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2009 13:43:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6EDh0wN007121; Tue, 14 Jul 2009 09:43:00 -0400 Received: from [127.0.0.1] (rtp-vpn6-1547.cisco.com [10.82.254.17]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EDh2DH025644; Tue, 14 Jul 2009 13:43:03 GMT Message-ID: <4A5C8B59.3070405@cisco.com> Date: Tue, 14 Jul 2009 09:42:49 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <2009589106.17665911246489666656.JavaMail.root@mail02.pantherlink.uwm.edu> <87y6r7w0cy.fsf@kelsey-ws.hq.ember.com> <69920940-A03D-4A13-8B19-B085FE85BCBD@archrock.com> <87vdmbvvu4.fsf@kelsey-ws.hq.ember.com> <84519635-3386-4EDA-94EF-CDA6D4DC2D86@archrock.com> <87tz1ux6q7.fsf@kelsey-ws.hq.ember.com> <4A4DC7DC.7070100@gmail.com> <4A531314.1080307@gmail.com> <4A546EA8.7000506@gmail.com> <8142BFBB-A593-4AA4-9D20-2D0B788CADD2@gmail.com> <71002404-9343-4A63-8C29-B0D683BC8CF0@cisco.com> In-Reply-To: <71002404-9343-4A63-8C29-B0D683BC8CF0@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1473; t=1247578980; x=1248442980; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=russ@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[Roll]=20RPL=3A=20why=20not=20base=20a= 20DAG=20on=20the=20min=20hop=20distance=20from=20the=0A=20ro ot? |Sender:=20 |To:=20JP=20Vasseur=20; bh=BR7Fi1vQ04RD9n4DCHc4NC60rXWNK2GOO6Do5DfSpNw=; b=WBc7QbWrqvkI/LklFbbIS4H8cm444e+KkWP7POCTyclJojdMjdEa/6/3K2 efjjSu4VPlEmyXkIaaIiEICQzlPEKFSr0J93Zdo7gfkv96WeJwl3eV8VXCNl 91MCTcafAu; Authentication-Results: rtp-dkim-1; header.From=russ@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Tue, 21 Jul 2009 08:30:24 -0700 Cc: roll@ietf.org, Philip Levis Subject: Re: [Roll] RPL: why not base a DAG on the min hop distance from the root? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 13:44:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Case A: Source (3) -> X (2) -> Y (3) -> X (2) -> Y (3) >> >> or >> >> Case B: Source (3) -> X (2) -> Y (2) -> X (2) >> >> These can occur when a node changes its route and updates its gradient >> value but its children have not yet learned the new value. E.g., the >> link between Y and Z breaks, leading to case A, where Y's best choice >> for a next hop is X. > > But the loop is transient. Note that the exact same situation exist with > link state protocol, we call it a micro-loop since it is quickly resolve > but time scale are different and although loop duration may be much > shorter, the number of impacted packets may be much larger. Yes--this isn't what we would call a loop, but a transient loop, because it resolves itself. RIP and BGP do the same thing. In fact, there is only one routing protocol in widespread use that doesn't have microloops, as far as I know. :-) Russ - -- riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone The whole aim of practical politics is to keep the populace alarmed (and hence clamarous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. -H.L. Menkin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpci1kACgkQER27sUhU9OT1SgCgg9Rh63U3QX3dRzad6rVv5GyL Sy0AoO/m73ZKW2V7/Iz/OMMTrQ1nTERl =4EUG -----END PGP SIGNATURE----- From jhui@archrock.com Tue Jul 21 08:49:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545CD28C235 for ; Tue, 21 Jul 2009 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK12Pm56WlGs for ; Tue, 21 Jul 2009 08:49:26 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 914B628C205 for ; Tue, 21 Jul 2009 08:49:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BD394AF914; Tue, 21 Jul 2009 08:49:07 -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 wrUJm4ILNF8E; Tue, 21 Jul 2009 08:49:02 -0700 (PDT) Received: from [192.168.7.71] (69-12-164-133.sfo.archrock.com [69.12.164.133]) by mail.sf.archrock.com (Postfix) with ESMTP id C1CE7AF85C; Tue, 21 Jul 2009 08:49:02 -0700 (PDT) Message-Id: <0B3DF5FC-7FAC-4A24-8E75-DD9053569EF4@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <467060707.3470351247877469581.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 08:49:01 -0700 References: <467060707.3470351247877469581.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:49:27 -0000 Hi Mukul, On Jul 17, 2009, at 5:37 PM, Mukul Goyal wrote: > The way I understand CTP operation, it seems that it provides no > loop correction mechanism other than reducing trickle timers to > their smallest value so that any "count to infinity" takes place > quickly. So, I am not sure if any claim that loops are repaired > "with in a few packet times" is valid. The loop correction times, > under CTP, depend on the severity of "count to infinity" situation, > the minimum trickle times and the length of the loop. I think Phil's "few packet times" claim is for a CTP node that has alternate parents not a part of the loop. > Whether adding the transmitting node's cost value to each packet, as > in CTP, is a more desirable loop detection mechanism than using a > separate control packet, that accumulates the route it travels over, > is debatable as well. It's important to note that generating another datagram is significantly more expensive than adding 1-2 bytes to a packet. For many radio links in use, each packet has the overhead of acquiring the channel, sender/receiver sync, RX-TX turnaround, and acknowledgement. With duty-cycled radios, add the overhead of starting/stopping the radio and any guard times for synchronization and/or preambles for low- power listening. Depending on the link protocol, a new datagram can be 1-3 orders of magnitude more expensive than adding 1-2 bytes to an existing packet. Having these relative costs in mind is helpful in evaluating the tradeoffs between both approaches. -- Jonathan Hui From richard.kelsey@ember.com Tue Jul 21 08:59:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C413A6E88 for ; Tue, 21 Jul 2009 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMcsT3q5z7Lc for ; Tue, 21 Jul 2009 08:59:33 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 847F33A6E6D for ; Tue, 21 Jul 2009 08:59:15 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 11:59:25 -0400 Date: Tue, 21 Jul 2009 11:59:20 -0400 Message-Id: <87my6y81t3.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <7A61CD7A-5B54-43A2-A176-7612004989BC@archrock.com> (message from Jonathan Hui on Tue, 21 Jul 2009 07:55:20 -0700) From: Richard Kelsey References: <121240882.3982791248166527861.JavaMail.root@mail02.pantherlink.uwm.edu> <7A61CD7A-5B54-43A2-A176-7612004989BC@archrock.com> X-OriginalArrivalTime: 21 Jul 2009 15:59:25.0470 (UTC) FILETIME=[3860A3E0:01CA0A1C] Cc: roll@ietf.org Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:59:33 -0000 Hi Jonathan, From: Jonathan Hui Date: Tue, 21 Jul 2009 07:55:20 -0700 While there are subtle differences, both are based on the same principle - if there's a possibility of a loop, communicate new routing information to children, wait for a while for routing information to propagate before finalizing decisions. I think that this approach has a number of weaknesses: - It is resource intensive in that it requires two separate downward information flows. The first to test for a loop and the second to propogate the successful return to a known loop-free state. - The absence of a change is interpreted as a successful result. The presence of a loop is indicated by seeing a change in a prospective parent's RA. No change implies no loop. These networks are lossy. I would be much happier if there were a positive acknowledgement of a loop-free path. - Checking for a loop using broadcasts to propagate information down the DAG is slow and expensive. A loop can be detected by sending information either upward or downward. In an RPL DAG the upward branching factor will usually be significantly less than the downward one. It is likely to be cheaper and faster to detect loops by sending probes upwards. We might even be able to use unicasts instead of broadcasts. -Richard Kelsey From jhui@archrock.com Tue Jul 21 09:09:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD6728C2FF for ; Tue, 21 Jul 2009 09:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIxhaBP9r3k2 for ; Tue, 21 Jul 2009 09:09:11 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5430928C2EB for ; Tue, 21 Jul 2009 09:09:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 74350AF8E9; Tue, 21 Jul 2009 09:08:58 -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 dhHCSQnzW5oQ; Tue, 21 Jul 2009 09:08:53 -0700 (PDT) Received: from [192.168.7.71] (69-12-164-133.sfo.archrock.com [69.12.164.133]) by mail.sf.archrock.com (Postfix) with ESMTP id 8CEE9AF85C; Tue, 21 Jul 2009 09:08:53 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87my6y81t3.fsf@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 v935.3) Date: Tue, 21 Jul 2009 09:08:52 -0700 References: <121240882.3982791248166527861.JavaMail.root@mail02.pantherlink.uwm.edu> <7A61CD7A-5B54-43A2-A176-7612004989BC@archrock.com> <87my6y81t3.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:09:12 -0000 Hi Richard, Your primary concerns are the same as mine, especially (i) relying on information to actually be communicated and (ii) broadcasts. Given the proposals on the table, I'm much more comfortable with loop-detection than loop-avoidance. I am influenced by the fact that I have much more experience with the former than the latter, but I suspect the same goes for others in the WG. -- Jonathan Hui On Jul 21, 2009, at 8:59 AM, Richard Kelsey wrote: > Hi Jonathan, > > From: Jonathan Hui > Date: Tue, 21 Jul 2009 07:55:20 -0700 > > While there are subtle differences, both are based on the same > principle - if there's a possibility of a loop, communicate new > routing information to children, wait for a while for routing > information to propagate before finalizing decisions. > > I think that this approach has a number of weaknesses: > > - It is resource intensive in that it requires two separate > downward information flows. The first to test for a loop > and the second to propogate the successful return to a > known loop-free state. > > - The absence of a change is interpreted as a successful > result. The presence of a loop is indicated by seeing a > change in a prospective parent's RA. No change implies > no loop. These networks are lossy. I would be much > happier if there were a positive acknowledgement of a > loop-free path. > > - Checking for a loop using broadcasts to propagate > information down the DAG is slow and expensive. > > A loop can be detected by sending information either upward > or downward. In an RPL DAG the upward branching factor will > usually be significantly less than the downward one. It is > likely to be cheaper and faster to detect loops by sending > probes upwards. We might even be able to use unicasts > instead of broadcasts. > -Richard Kelsey From wintert@acm.org Tue Jul 21 19:34:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B383A68E2 for ; Tue, 21 Jul 2009 19:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.432 X-Spam-Level: X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd+re6SPbSWN for ; Tue, 21 Jul 2009 19:34:44 -0700 (PDT) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id 427DA3A685A for ; Tue, 21 Jul 2009 19:34:44 -0700 (PDT) Received: (qmail 52428 invoked from network); 22 Jul 2009 02:34:25 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 21 Jul 2009 19:34:25 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: HeuBHF4VM1nOIoAvX0RLwqTytEbsMqS9kDwDwjPrxHourHdxf1QJVOETeNDbmYky9dnQFO4osxQy2NPbNwNsJeYC0cJym3Q0suVJGHAVVPl8jkSMRvFQkc5RSQgdxZ1rsaMqvccPmxIyHhGMl9OCufiJt2iJP.rZNIYxZ5Xyx2Hb719gfqjV4WTcEU8SG7LHY_m1dm2AjNvKpKh.BMVNfV.PkuY3p91b.Q0itBjpF1amyECzC9A8mwIgm0x_xPCODBUGoYXYbCa4kUA_99EPxucIyfWQOwmT6hfI2JFmu5HMTcXMhs6bbjBe4XmWfFi0mJ7ZN7o_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A667AB0.3050100@acm.org> Date: Tue, 21 Jul 2009 22:34:24 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: "Julien Abeille \(jabeille\)" References: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A86035F7A3B@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86035F7A3B@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] [RPL] Grounded flag X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 02:34:45 -0000 Hi Julien, Thanks for your comments, I do think you have caught something here that we need to refine further in the next revision. Julien Abeille (jabeille) wrote: > reseding > Julien > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Julien Abeille (jabeille) > *Sent:* mercredi 15 juillet 2009 16:32 > *To:* roll@ietf.org > *Subject:* [Roll] [RPL] Grounded flag > > Hi all, > > - could you clarify how the Grounded flag in DIO interferes with the > router lifetime in RAs? > a router with a default route usually sets non 0 router lifetime in > RA to indicate so, and sets it to 0 if does not want to be > considered a default router. Hence the meaning of the grounded flag > is similar to the router lifetime being 0 or not. Yes, Alex had made a similar observation as well. But see below: > > If the idea is to force nodes that receives a RA with router > lifetime non 0 not to configure the sender as a default router (to > allow nodes to choose which default router they want using parent > selection), then it could be precised that routers should set router > lifetime to 0 even if they have a default route. > > - in section 5.1.1.5: > > "Note that Destination Prefixes specified in this manner inherit the > Router Lifetime of their parent RA" > > if the router has no default route, router lifetime is 0. Hence the prefix will not be added, or will be deleted, simply because the sender has no default route. Based on these and other comments, I think we may need to open up the definition of Grounded, and we should not overload the router lifetime as in the current draft- There may be application scenarios where a node acts as a MP2P sink but does not want to offer the default route. For example, a node may be some sort of standalone controller that only has an LLN interface and does not / cannot offer the default route. Such a node ought to be grounded for the purposes of DAG discovery, because of its application role, and ought to offer some meaningful prefix to the application (note however that application service discovery is outside the scope of RPL). The lifetime of such prefixes then ought to be defined independently of the router lifetime in the RA. Another example that has been extended on this list is the case where an electric meter may participate in both a utility network and a home network, and may want to offer a prefix for the home network to route certain traffic directly into the utility network, but does not want to provide a default route for the home network (the home network must find another default route through the homeowners ISP for all other traffic). So the determination of Grounded (MP2P sink) may be the result of application provisioning (via configuration API), and does not necessarily imply the default route, and the Destination Prefix suboption ought to be augmented with a lifetime. How does this sound? > > - what happens if a node receives a DIO with G flag not set and no > destination prefix? what is the meaning of such a message? This would most typically be a DIO indicating a floating DAG- generally a transient condition. The members of the floating DAG will be seeking a grounded DAG to re-attach to. I dont know of any example that would suggest a floating DAG should be advertising any other destination prefix. > > Best, > Julien > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Regards, -Tim From prvs=447ddced0=mukul@uwm.edu Tue Jul 21 22:53:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E820B3A68E2 for ; Tue, 21 Jul 2009 22:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.903, 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 eHnxjMsqouny for ; Tue, 21 Jul 2009 22:53:14 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 061763A685B for ; Tue, 21 Jul 2009 22:53:13 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 22 Jul 2009 00:51:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E91EAC085AA; Wed, 22 Jul 2009 00:51:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUGUBQvibVLm; Wed, 22 Jul 2009 00:51:49 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BCEA8C085A3; Wed, 22 Jul 2009 00:51:49 -0500 (CDT) Date: Wed, 22 Jul 2009 00:51:49 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1958032975.4319921248241909657.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1401676027.4319901248241885570.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 06:01:30 -0000 Even if those 1-2 bytes need to be added to every packet?? I know the shrinking payload size in packets is already a major concern. E.g. in IEEE 802.15.4, taking 1-2 bytes off from about 80 bytes of payload is significant. And this number - 80 bytes - is optimistic since other information (IPv6 headers etc.) is going to cause additional shrinking of allowed payload on a packet. Having a special packet for loop-detection purpose allows you control over how frequently you want to originate this packet. Secondly, path accumulation allows explicit loop detection, which in turn may allow better/efficient loop correction. Thanks Mukul > Whether adding the transmitting node's cost value to each packet, as > in CTP, is a more desirable loop detection mechanism than using a > separate control packet, that accumulates the route it travels over, > is debatable as well. It's important to note that generating another datagram is significantly more expensive than adding 1-2 bytes to a packet. For many radio links in use, each packet has the overhead of acquiring the channel, sender/receiver sync, RX-TX turnaround, and acknowledgement. With duty-cycled radios, add the overhead of starting/stopping the radio and any guard times for synchronization and/or preambles for low- power listening. Depending on the link protocol, a new datagram can be 1-3 orders of magnitude more expensive than adding 1-2 bytes to an existing packet. Having these relative costs in mind is helpful in evaluating the tradeoffs between both approaches. -- Jonathan Hui From jhui@archrock.com Wed Jul 22 00:29:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555AD3A6AC8 for ; Wed, 22 Jul 2009 00:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, 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 C7BcbJ0dAgta for ; Wed, 22 Jul 2009 00:29: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 6862828C0E7 for ; Wed, 22 Jul 2009 00:28:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8E3F6AF8D6; Wed, 22 Jul 2009 00:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do2b8PFTM2WL; Wed, 22 Jul 2009 00:26:40 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-195.dsl.pltn13.pacbell.net [71.142.86.195]) by mail.sf.archrock.com (Postfix) with ESMTP id A5BADAF8D5; Wed, 22 Jul 2009 00:26:40 -0700 (PDT) Message-Id: <96F577D2-3872-455F-9A09-7F2D6CEFD9A2@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1958032975.4319921248241909657.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 00:26:39 -0700 References: <1958032975.4319921248241909657.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:29:43 -0000 Hi Mukul, On Jul 21, 2009, at 10:51 PM, Mukul Goyal wrote: > Even if those 1-2 bytes need to be added to every packet?? I know > the shrinking payload size in packets is already a major concern. > E.g. in IEEE 802.15.4, taking 1-2 bytes off from about 80 bytes of > payload is significant. And this number - 80 bytes - is optimistic > since other information (IPv6 headers etc.) is going to cause > additional shrinking of allowed payload on a packet. In many cases, yes, 1-2 bytes in every packet can be much more efficient than sending an explicit control message every X packets. Specific to 802.15.4 250 kbps, 1 byte adds 32us of transmission time - that's it. Compare that to the cost of CCA (order ms), preamble (128 us), RX-TX turnaround (192 us), ack (352 us). If the radio is duty- cycled, then consider radio start/stop times (order ms) and the guard times - around 2 ms total when synchronized or, in the worst-case, hundreds of milliseconds to seconds when completely unsynchronized (e.g. an extended preamble in a low-power listening protocol). Also note that transmitting a large datagram as X fragments is often more efficient than communicating the same information in Y unfragmented datagrams. Fragmented datagrams only carry the L3/L4 headers in the first fragment and there are a number of optimizations that can be applied at the link to reduce the transmission of subsequent fragments (e.g. reduced guard times, reduced/removal of CCA, etc.). Finally, hop-by-hop information doesn't accumulate as you get towards the more burdened nodes closer to the root - the overhead per datagram is fixed. Path accumulation also operates on IPv6 addresses, whereas hop-by-hop only communicates routing cost. To make path accumulation more viable, we'd have to start discussing address compression techniques and/or defining new namespaces. > Having a special packet for loop-detection purpose allows you > control over how frequently you want to originate this packet. > Secondly, path accumulation allows explicit loop detection, which in > turn may allow better/efficient loop correction. Note that I do support sending of path accumulation datagrams - it's used in the RPL drafts for building source-route information at ancestor nodes. The same packets can be helpful for loop detection as well. The difference is that I would not rely solely on path accumulation datagrams for loop-detection. They are significantly more expensive to communicate (compared to hop-by-hop) and, as a result, should be communicated infrequently. When loops exist, they are costly, and I'd want to detect them quickly when datagrams are flowing. -- Jonathan Hui > > Thanks > Mukul > >> Whether adding the transmitting node's cost value to each packet, as >> in CTP, is a more desirable loop detection mechanism than using a >> separate control packet, that accumulates the route it travels over, >> is debatable as well. > > It's important to note that generating another datagram is > significantly more expensive than adding 1-2 bytes to a packet. For > many radio links in use, each packet has the overhead of acquiring the > channel, sender/receiver sync, RX-TX turnaround, and acknowledgement. > With duty-cycled radios, add the overhead of starting/stopping the > radio and any guard times for synchronization and/or preambles for > low- > power listening. Depending on the link protocol, a new datagram can be > 1-3 orders of magnitude more expensive than adding 1-2 bytes to an > existing packet. > > Having these relative costs in mind is helpful in evaluating the > tradeoffs between both approaches. > > -- > Jonathan Hui > From jabeille@cisco.com Wed Jul 22 00:44:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B7028C104 for ; Wed, 22 Jul 2009 00:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.233 X-Spam-Level: X-Spam-Status: No, score=-8.233 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 EuQa5ltdWp5R for ; Wed, 22 Jul 2009 00:44:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5B10F3A6851 for ; Wed, 22 Jul 2009 00:44:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUAAGBgZkqQ/uCLe2dsb2JhbACZZAEBFiQGniuII5BeBYQO X-IronPort-AV: E=Sophos;i="4.43,245,1246838400"; d="scan'208";a="45568274" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2009 07:42:37 +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 n6M7gbkd014620; Wed, 22 Jul 2009 09:42:37 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6M7gbhk008302; Wed, 22 Jul 2009 07:42:37 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 09:42:37 +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, 22 Jul 2009 09:42:34 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86036488C6@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4A667AB0.3050100@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL] Grounded flag Thread-Index: AcoKdQQiGY2M6U4WRima+yUW8282GQAJ425w References: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A86035F7A3B@xmb-ams-33d.emea.cisco.com> <4A667AB0.3050100@acm.org> From: "Julien Abeille (jabeille)" To: "Tim Winter" X-OriginalArrivalTime: 22 Jul 2009 07:42:37.0225 (UTC) FILETIME=[FBB12990:01CA0A9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6090; t=1248248557; x=1249112557; 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[Roll]=20[RPL]=20Grounded=20flag |Sender:=20; bh=zuhOT/0ZWARLzlLqLmF4EJnygPq5CtzjHg/5C6fLvF4=; b=o/5vBNekkiOlUbrfmLHLY6VRrNkTMab//YstJGlvyq+s9Wp/9BtXOJe6ot NWEHZQd34avKfNOYiEfDPpW718SFA88eDRxcM1OHVAHSCXX4Zr7OGLnRMV/b paSEf2hdj/; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] [RPL] Grounded flag X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:44:28 -0000 Hi Tim, Thanks for your answer.=20 The meaning you propose is not that clear to me. Taking the example of the DAG root which is an application controller: saying that calling it a grounded router to allow nodes to connect to this DAG However, the examples you state (smart meter...) make perfect sense. I feel that the Destination prefix suboption allows these application examples to work. (I have no strong opinion yet on whether a separate lifetime should be added to this suboption) I would prefer RPL not to contain application level concepts, but still allow application scenarios we have in mind, at routing level. I feel the destination prefix suboption does this. Best, Julien > -----Original Message----- > From: Tim Winter [mailto:wintert@acm.org]=20 > Sent: mercredi 22 juillet 2009 04:34 > To: Julien Abeille (jabeille) > Cc: ROLL WG > Subject: Re: [Roll] [RPL] Grounded flag >=20 > Hi Julien, >=20 > Thanks for your comments, I do think you have caught=20 > something here that we need to refine further in the next revision. >=20 > Julien Abeille (jabeille) wrote: > > reseding > > Julien > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > Behalf Of *Julien Abeille (jabeille) > > *Sent:* mercredi 15 juillet 2009 16:32 > > *To:* roll@ietf.org > > *Subject:* [Roll] [RPL] Grounded flag > >=20 > > Hi all, > > =20 > > - could you clarify how the Grounded flag in DIO=20 > interferes with the > > router lifetime in RAs? > > a router with a default route usually sets non 0 router=20 > lifetime in > > RA to indicate so, and sets it to 0 if does not want to be > > considered a default router. Hence the meaning of the=20 > grounded flag > > is similar to the router lifetime being 0 or not. > Yes, Alex had made a similar observation as well. But see below: >=20 >=20 > > =20 > > If the idea is to force nodes that receives a RA with router > > lifetime non 0 not to configure the sender as a default=20 > router (to > > allow nodes to choose which default router they want=20 > using parent > > selection), then it could be precised that routers=20 > should set router > > lifetime to 0 even if they have a default route. > > =20 > > - in section 5.1.1.5: > >=20 > > "Note that Destination Prefixes specified in this=20 > manner inherit the > > Router Lifetime of their parent RA" > >=20 > > if the router has no default route, router lifetime is=20 > 0. Hence the prefix will not be added, or will be deleted,=20 > simply because the sender has no default route. I agree with you, a separate lifetime makes sense > Based on these and other comments, I think we may need to=20 > open up the definition of Grounded, and we should not=20 > overload the router lifetime as in the current draft- There=20 > may be application scenarios where a node acts as a MP2P sink=20 > but does not want to offer the default route. For example, a=20 > node may be some sort of standalone controller that only has=20 > an LLN interface and does not / cannot offer the default=20 > route. Such a node ought to be grounded for the purposes of=20 > DAG discovery, because of its application role, and ought to=20 > offer some meaningful prefix to the application (note however=20 > that application service discovery is outside the scope of=20 > RPL).=20 I have the feeling that calling such a node "grounded" is useful only for parent/DAG selection. However, parent/DAG selection can be influenced in RPL by other means already (preference...) hence I would avoid putting an application layer concept in RPL.=20 what we want to achieve in this example (that nodes attach to this controller's DAG) can be done with the current draft. You can e.g. set a very high preference and design the parent seletion algorithm to check mostly the preference. Hence without having application logic in the routing layer, we enable people to deploy a network that make their applications work.=20 I would keep the grounded concept as is but remove the grounded flag, and as you say add a separate lifetime for destination prefix. Best, Julien > The lifetime of such prefixes then ought to be defined=20 > independently of the router lifetime in the RA. Another=20 > example that has been extended on this list is the case where=20 > an electric meter may participate in both a utility network=20 > and a home network, and may want to offer a prefix for the=20 > home network to route certain traffic directly into the=20 > utility network, but does not want to provide a default route=20 > for the home network (the home network must find another=20 > default route through the homeowners ISP for all other traffic). >=20 > So the determination of Grounded (MP2P sink) may be the=20 > result of application provisioning (via configuration API),=20 > and does not necessarily imply the default route, and the=20 > Destination Prefix suboption ought to be augmented with a lifetime. >=20 > How does this sound? >=20 > >=20 > > - what happens if a node receives a DIO with G flag not=20 > set and no > > destination prefix? what is the meaning of such a message? > This would most typically be a DIO indicating a floating DAG-=20 > generally a transient condition. The members of the floating=20 > DAG will be seeking a grounded DAG to re-attach to. I dont=20 > know of any example that would suggest a floating DAG should=20 > be advertising any other destination prefix. >=20 > > =20 > > Best, > > Julien > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > Regards, >=20 > -Tim >=20 From prvs=447ddced0=mukul@uwm.edu Wed Jul 22 00:50:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337FB28C11E for ; Wed, 22 Jul 2009 00:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.602, 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 AHWhxTT3G97g for ; Wed, 22 Jul 2009 00:50:17 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 127C528C10C for ; Wed, 22 Jul 2009 00:50:16 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 22 Jul 2009 02:49:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A973BC085A3; Wed, 22 Jul 2009 02:49:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zikqr93kAE22; Wed, 22 Jul 2009 02:49:13 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 751EAC085A8; Wed, 22 Jul 2009 02:49:13 -0500 (CDT) Date: Wed, 22 Jul 2009 02:49:13 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1868412854.4323241248248953339.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <96F577D2-3872-455F-9A09-7F2D6CEFD9A2@archrock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:50:18 -0000 Very good explanation! Thanks. Cheers Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, July 22, 2009 2:26:39 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs Hi Mukul, On Jul 21, 2009, at 10:51 PM, Mukul Goyal wrote: > Even if those 1-2 bytes need to be added to every packet?? I know > the shrinking payload size in packets is already a major concern. > E.g. in IEEE 802.15.4, taking 1-2 bytes off from about 80 bytes of > payload is significant. And this number - 80 bytes - is optimistic > since other information (IPv6 headers etc.) is going to cause > additional shrinking of allowed payload on a packet. In many cases, yes, 1-2 bytes in every packet can be much more efficient than sending an explicit control message every X packets. Specific to 802.15.4 250 kbps, 1 byte adds 32us of transmission time - that's it. Compare that to the cost of CCA (order ms), preamble (128 us), RX-TX turnaround (192 us), ack (352 us). If the radio is duty- cycled, then consider radio start/stop times (order ms) and the guard times - around 2 ms total when synchronized or, in the worst-case, hundreds of milliseconds to seconds when completely unsynchronized (e.g. an extended preamble in a low-power listening protocol). Also note that transmitting a large datagram as X fragments is often more efficient than communicating the same information in Y unfragmented datagrams. Fragmented datagrams only carry the L3/L4 headers in the first fragment and there are a number of optimizations that can be applied at the link to reduce the transmission of subsequent fragments (e.g. reduced guard times, reduced/removal of CCA, etc.). Finally, hop-by-hop information doesn't accumulate as you get towards the more burdened nodes closer to the root - the overhead per datagram is fixed. Path accumulation also operates on IPv6 addresses, whereas hop-by-hop only communicates routing cost. To make path accumulation more viable, we'd have to start discussing address compression techniques and/or defining new namespaces. > Having a special packet for loop-detection purpose allows you > control over how frequently you want to originate this packet. > Secondly, path accumulation allows explicit loop detection, which in > turn may allow better/efficient loop correction. Note that I do support sending of path accumulation datagrams - it's used in the RPL drafts for building source-route information at ancestor nodes. The same packets can be helpful for loop detection as well. The difference is that I would not rely solely on path accumulation datagrams for loop-detection. They are significantly more expensive to communicate (compared to hop-by-hop) and, as a result, should be communicated infrequently. When loops exist, they are costly, and I'd want to detect them quickly when datagrams are flowing. -- Jonathan Hui > > Thanks > Mukul > >> Whether adding the transmitting node's cost value to each packet, as >> in CTP, is a more desirable loop detection mechanism than using a >> separate control packet, that accumulates the route it travels over, >> is debatable as well. > > It's important to note that generating another datagram is > significantly more expensive than adding 1-2 bytes to a packet. For > many radio links in use, each packet has the overhead of acquiring the > channel, sender/receiver sync, RX-TX turnaround, and acknowledgement. > With duty-cycled radios, add the overhead of starting/stopping the > radio and any guard times for synchronization and/or preambles for > low- > power listening. Depending on the link protocol, a new datagram can be > 1-3 orders of magnitude more expensive than adding 1-2 bytes to an > existing packet. > > Having these relative costs in mind is helpful in evaluating the > tradeoffs between both approaches. > > -- > Jonathan Hui > From prvs=447ddced0=mukul@uwm.edu Wed Jul 22 01:10:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522A03A6A3C for ; Wed, 22 Jul 2009 01:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, 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 z0mvQsTBnptE for ; Wed, 22 Jul 2009 01:10:27 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id E8E373A6851 for ; Wed, 22 Jul 2009 01:10:26 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 22 Jul 2009 03:06:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 04070C085A1; Wed, 22 Jul 2009 03:06:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2KBYgSyXXWJ; Wed, 22 Jul 2009 03:06:07 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D3255C085A0; Wed, 22 Jul 2009 03:06:07 -0500 (CDT) Date: Wed, 22 Jul 2009 03:06:07 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <108685861.4323491248249967723.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2133201242.4323331248249363627.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:10:28 -0000 Richard, > - The absence of a change is interpreted as a successful result. The presence of a loop is indicated by seeing a change in a prospective parent's RA. No change implies no loop. These networks are lossy. I would be much happier if there were a positive acknowledgement of a loop-free path. Please expand your comment. I did not undetstand "The presence of a loop is indicated by seeing a change in....". Also please explain what do you mean by "positive acknowledgement of a loop free path". > A loop can be detected by sending information either upward or downward. In an RPL DAG the upward branching factor will usually be significantly less than the downward one. It is likely to be cheaper and faster to detect loops by sending probes upwards. We might even be able to use unicasts instead of broadcasts. Again, not sure what you mean. Loop detection, whether using RPL approach or path accumulation approach, works by sending probes "upwards". In loop-avoidance approach I mentioned, there is "downwards" flow of information to make sure that "neighbor descendants" update their cost estimates while the node is in "loop avoidance" state. Thanks Mukul From alexandru.petrescu@gmail.com Wed Jul 22 02:21:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7981F28C0ED for ; Wed, 22 Jul 2009 02:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 D0SGm52ivcVk for ; Wed, 22 Jul 2009 02:21:14 -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 ECCFE3A6DC1 for ; Wed, 22 Jul 2009 02:21:13 -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 n6M9KDeo017689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 11:20:13 +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 n6M9KDEP016715; Wed, 22 Jul 2009 11:20:13 +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 n6M9KBLJ013713; Wed, 22 Jul 2009 11:20:13 +0200 Message-ID: <4A66D9CB.1020501@gmail.com> Date: Wed, 22 Jul 2009 11:20:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tim Winter References: <38F26F36EAA981478A49D1F37F474A86035B5142@xmb-ams-33d.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A86035F7A3B@xmb-ams-33d.emea.cisco.com> <4A667AB0.3050100@acm.org> In-Reply-To: <4A667AB0.3050100@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] [RPL] Grounded flag X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:21:15 -0000 Tim Winter a crit : > Hi Julien, > > Thanks for your comments, I do think you have caught something here > that we need to refine further in the next revision. > > Julien Abeille (jabeille) wrote: >> reseding Julien >> >> ------------------------------------------------------------------------ >> *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On >> Behalf Of *Julien Abeille (jabeille) *Sent:* mercredi 15 juillet >> 2009 16:32 *To:* roll@ietf.org *Subject:* [Roll] [RPL] Grounded >> flag >> >> Hi all, >> >> - could you clarify how the Grounded flag in DIO interferes with >> the router lifetime in RAs? a router with a default route usually >> sets non 0 router lifetime in RA to indicate so, and sets it to 0 >> if does not want to be considered a default router. Hence the >> meaning of the grounded flag is similar to the router lifetime >> being 0 or not. > Yes, Alex had made a similar observation as well. But see below: > > >> >> If the idea is to force nodes that receives a RA with router >> lifetime non 0 not to configure the sender as a default router (to >> allow nodes to choose which default router they want using parent >> selection), then it could be precised that routers should set >> router lifetime to 0 even if they have a default route. >> >> - in section 5.1.1.5: >> >> "Note that Destination Prefixes specified in this manner inherit >> the Router Lifetime of their parent RA" >> >> if the router has no default route, router lifetime is 0. Hence the >> prefix will not be added, or will be deleted, simply because the >> sender has no default route. > Based on these and other comments, I think we may need to open up the > definition of Grounded, and we should not overload the router > lifetime as in the current draft- There may be application scenarios > where a node acts as a MP2P sink but does not want to offer the > default route. For example, a node may be some sort of standalone > controller that only has an LLN interface and does not / cannot offer > the default route. Such a node ought to be grounded for the purposes > of DAG discovery, because of its application role, and ought to offer > some meaningful prefix to the application (note however that > application service discovery is outside the scope of RPL). The > lifetime of such prefixes then ought to be defined independently of > the router lifetime in the RA. Another example that has been > extended on this list is the case where an electric meter may > participate in both a utility network and a home network, and may > want to offer a prefix for the home network to route certain traffic > directly into the utility network, but does not want to provide a > default route for the home network (the home network must find > another default route through the homeowners ISP for all other > traffic). > > So the determination of Grounded (MP2P sink) may be the result of > application provisioning (via configuration API), and does not > necessarily imply the default route, and the Destination Prefix > suboption ought to be augmented with a lifetime. > > How does this sound? This explanation sounds good to me, and I agree with a separation of a 'sink' from being the default route. I would also verify later that any notion of default route introduced by RPL does not contradict the existing notion of default route in the RA (lifetime 0), e.g. make sure when both are present and a non-RPL machine receives it makes the right interpretation, and similar. Alex > >> - what happens if a node receives a DIO with G flag not set and no >> destination prefix? what is the meaning of such a message? > This would most typically be a DIO indicating a floating DAG- > generally a transient condition. The members of the floating DAG > will be seeking a grounded DAG to re-attach to. I dont know of any > example that would suggest a floating DAG should be advertising any > other destination prefix. > >> >> Best, Julien >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > Regards, > > -Tim _______________________________________________ Roll mailing > list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From prvs=447ddced0=mukul@uwm.edu Wed Jul 22 06:25:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37683A68A9 for ; Wed, 22 Jul 2009 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 z4yU6GVaG3vY for ; Wed, 22 Jul 2009 06:25:52 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 8E7C63A68B1 for ; Wed, 22 Jul 2009 06:25:52 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 22 Jul 2009 08:25:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9B5D5C085A1; Wed, 22 Jul 2009 08:25:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdBR1BHBNuXl; Wed, 22 Jul 2009 08:25:08 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0B60AC085A0; Wed, 22 Jul 2009 08:25:08 -0500 (CDT) Date: Wed, 22 Jul 2009 08:25:07 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <592863107.4359071248269107876.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1868412854.4323241248248953339.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:25:53 -0000 We had a good discussion about relative merits of hop-by-hop loop detection versus path accumulation approach. There is a sound claim that frequent origination of a special control packet is much more expensive than putting "cost" information in each packet (the hop-by-hop approach). One problem with hop-by-hop approach is that it fails to identify the in-loop nodes explicitly and hence any loop correction mechanism based on the knowledge of in-loop nodes can not be used. So, I am thinking of the following loop detection and correction approach for the alternative (to RPL) routing scheme: 1. Use hop-by-hop approach to detect the possibility of a loop. 2. The node detecting the loop originates the control packet that would do path accumulation and identify the in-loop nodes. This node then initiates loop correction using this knowledge. Now, path accumulation packets are originated when we know there is a problem. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Jonathan Hui" Cc: "roll" Sent: Wednesday, July 22, 2009 2:49:13 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs Very good explanation! Thanks. Cheers Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, July 22, 2009 2:26:39 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] A loop correction mechanism Re: A simple loop avoidance mechanism for use in P2P DV routing not using DAGs Hi Mukul, On Jul 21, 2009, at 10:51 PM, Mukul Goyal wrote: > Even if those 1-2 bytes need to be added to every packet?? I know > the shrinking payload size in packets is already a major concern. > E.g. in IEEE 802.15.4, taking 1-2 bytes off from about 80 bytes of > payload is significant. And this number - 80 bytes - is optimistic > since other information (IPv6 headers etc.) is going to cause > additional shrinking of allowed payload on a packet. In many cases, yes, 1-2 bytes in every packet can be much more efficient than sending an explicit control message every X packets. Specific to 802.15.4 250 kbps, 1 byte adds 32us of transmission time - that's it. Compare that to the cost of CCA (order ms), preamble (128 us), RX-TX turnaround (192 us), ack (352 us). If the radio is duty- cycled, then consider radio start/stop times (order ms) and the guard times - around 2 ms total when synchronized or, in the worst-case, hundreds of milliseconds to seconds when completely unsynchronized (e.g. an extended preamble in a low-power listening protocol). Also note that transmitting a large datagram as X fragments is often more efficient than communicating the same information in Y unfragmented datagrams. Fragmented datagrams only carry the L3/L4 headers in the first fragment and there are a number of optimizations that can be applied at the link to reduce the transmission of subsequent fragments (e.g. reduced guard times, reduced/removal of CCA, etc.). Finally, hop-by-hop information doesn't accumulate as you get towards the more burdened nodes closer to the root - the overhead per datagram is fixed. Path accumulation also operates on IPv6 addresses, whereas hop-by-hop only communicates routing cost. To make path accumulation more viable, we'd have to start discussing address compression techniques and/or defining new namespaces. > Having a special packet for loop-detection purpose allows you > control over how frequently you want to originate this packet. > Secondly, path accumulation allows explicit loop detection, which in > turn may allow better/efficient loop correction. Note that I do support sending of path accumulation datagrams - it's used in the RPL drafts for building source-route information at ancestor nodes. The same packets can be helpful for loop detection as well. The difference is that I would not rely solely on path accumulation datagrams for loop-detection. They are significantly more expensive to communicate (compared to hop-by-hop) and, as a result, should be communicated infrequently. When loops exist, they are costly, and I'd want to detect them quickly when datagrams are flowing. -- Jonathan Hui > > Thanks > Mukul > >> Whether adding the transmitting node's cost value to each packet, as >> in CTP, is a more desirable loop detection mechanism than using a >> separate control packet, that accumulates the route it travels over, >> is debatable as well. > > It's important to note that generating another datagram is > significantly more expensive than adding 1-2 bytes to a packet. For > many radio links in use, each packet has the overhead of acquiring the > channel, sender/receiver sync, RX-TX turnaround, and acknowledgement. > With duty-cycled radios, add the overhead of starting/stopping the > radio and any guard times for synchronization and/or preambles for > low- > power listening. Depending on the link protocol, a new datagram can be > 1-3 orders of magnitude more expensive than adding 1-2 bytes to an > existing packet. > > Having these relative costs in mind is helpful in evaluating the > tradeoffs between both approaches. > > -- > Jonathan Hui > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Jul 22 08:47:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B60E3A6949 for ; Wed, 22 Jul 2009 08:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNZcjB1w0nrY for ; Wed, 22 Jul 2009 08:47:54 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 691C23A6929 for ; Wed, 22 Jul 2009 08:47:54 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:46:24 -0400 Date: Wed, 22 Jul 2009 11:46:20 -0400 Message-Id: <8763dk67qr.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <108685861.4323491248249967723.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 22 Jul 2009 03:06:07 -0500 (CDT)) From: Richard Kelsey References: <108685861.4323491248249967723.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 22 Jul 2009 15:46:24.0812 (UTC) FILETIME=[917B6EC0:01CA0AE3] Cc: roll@ietf.org Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:47:55 -0000 Mukul, Date: Wed, 22 Jul 2009 03:06:07 -0500 (CDT) From: Mukul Goyal RK> The absence of a change is interpreted as a successful RK> result. The presence of a loop is indicated by seeing a RK> change in a prospective parent's RA. No change implies RK> no loop. These networks are lossy. I would be much RK> happier if there were a positive acknowledgement of a RK> loop-free path. Please expand your comment. I did not undetstand "The presence of a loop is indicated by seeing a change in....". In draft-dt-roll-rpl-01 the method for moving down the DAG to a parent with a greater depth is: 1. detach 2. wait while the detached state propagates downward 3. reattach to any grounded node The assumption is that any node still grounded after the waiting period is not a descendent of the moving node and thus can be used as a parent. This depends on the reliable distribution of the detached status. Any communication failure is interpreted as the absence of a loop. Also please explain what do you mean by "positive acknowledgement of a loop free path". Picking a parent with a more recent DAG sequence number would be a positive acknowledgement. Sending a message to the root, or at least far enough up the DAG, and receiving a response would also be a positive acknowledgement of the absence of a loop. RK> A loop can be detected by sending information either upward RK> or downward. In an RPL DAG the upward branching factor will RK> usually be significantly less than the downward one. It is RK> likely to be cheaper and faster to detect loops by sending RK> probes upwards. We might even be able to use unicasts RK> instead of broadcasts. Again, not sure what you mean. Loop detection, whether using RPL approach or path accumulation approach, works by sending probes "upwards". For detached nodes, RPL propagates the detached status down the DAG, not up. The detached status is used for detecting loops. -Richard Kelsey From pthubert@cisco.com Fri Jul 24 07:12:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7999B28C185 for ; Fri, 24 Jul 2009 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE3kX+cPG+-O for ; Fri, 24 Jul 2009 07:12: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 7D69E3A6B49 for ; Fri, 24 Jul 2009 07:12:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANNdaUqrR7O6/2dsb2JhbAC7FYglkFsFhA0 X-IronPort-AV: E=Sophos;i="4.43,264,1246838400"; d="scan'208";a="353223809" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2009 14:09:28 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6OE9S0X018544; Fri, 24 Jul 2009 07:09:28 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6OE9RG3017373; Fri, 24 Jul 2009 14:09:28 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 16:09:27 +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 Jul 2009 16:07:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07D496E9@xmb-ams-337.emea.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF3F9999@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [RPL] multiple roots in a DAG Thread-Index: Acn7/Nb7Fgb7KDlvRKeFZdNIzid3AwAqy9uQATOQf3ACvBOngA== References: <8E09C72DBC577D489F13A71228C0B7BF371391@ftrdmel0.rd.francetelecom.fr> <7892795E1A87F04CADFCCF41FADD00FC07B93DCC@xmb-ams-337.emea.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF3F9999@ftrdmel0.rd.francetelecom.fr> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 24 Jul 2009 14:09:27.0493 (UTC) FILETIME=[5AEA7F50:01CA0C68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2548; t=1248444568; x=1249308568; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20[RPL]=20multiple=20roots=20in= 20a=20DAG |Sender:=20; bh=65e4p3lZvV9tltdiAgcuLtKGUGyWyyBO9Cj62qV1B/M=; b=p6PgbfSF7ciIHbLxxCQKeuny9br+NNGAb2y+HRJO1NhNt7THaK0fbgUfDX LeBokSyiZ4nBxQ+7ETeXLgbC0DSNChsxdrzsSiX3rXwTVRQWj2IJWJIA7NSh 77/9bBsQHz; Authentication-Results: sj-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Roll] [RPL] multiple roots in a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:12:31 -0000 Hi Dominique: Sorry for being late on this >> The only use case for a delta that I have in mind for this is a >6LoWPAN backbone. What's required there is, as you indicate, a sync of >the "roots" so that they used consistent sequence numbers and DAGIDs. >This can be seen as a single root (the backbone itself ) of a single DAG >and the multiple secondary roots advertise depth 1 in that same DAG. >What I'd do there is use one of the root to source the protocol over the >backbone. I think we had good text on that in the fundamentals draft, >maybe we should integrate some of that in RPL. > >The point is that, with the current draft, there is no delta possible. >If I understand correctly, all DIOs with same or earlier sequence >numbers are discarded, so a node hardly ever knows about other roots >than the closest one. Which amounts to watersheds separated by ridges, >not a delta. Am I mistaken here? Same sequence should be accepted because we are doing a DAG, whether we do a delta or not. As you figure, there is a need to coordinate between the multiple sinks of the delta to obtain the sequence and DAGID synchronization. Say we drain a sensor network into a 6LoWPAN backbone. In that case, the backbone is a virtual sink and one edge router would play the role of the root over that backbone, so the edge routers would really advertize a depth of 1 over the LLN even though they act as sinks there. >In an outdoor WSN, I could think of LLNs with multiple exit points that >use different technologies, (cellular on one side, wired on another one, >for example. That would not be a backbone, and synchronizing the roots >would be less obvious. If the exit points belong to different telcos, >they would even advertize different prefixes. Currently, nodes are >prevented from knowing all of these different prefixes. (a quick fix >might seem to propagate DIOs coming from various roots even if seqnum is >older, but that alone wouldn't work : since we don't have root IDs in >the DIOs, there's no way to differentiate an old DIO by the same root >from a new DIO by a different root). In this case they should really form multiple DAGs. They will have different capabilities and security models so they might drain different information. >BTW, adding RootIDs in the DIOs would eliminate the need for >synchronizing the roots, wouldn't it? >Any comment? I think I miss this point. The DAGID is already a unique root ID. Could you please elaborate? All the best, Pascal From jvasseur@cisco.com Sat Jul 25 05:13:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4423A697E for ; Sat, 25 Jul 2009 05:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.055 X-Spam-Level: X-Spam-Status: No, score=-7.055 tagged_above=-999 required=5 tests=[AWL=1.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaDTZjk13Ner for ; Sat, 25 Jul 2009 05:13:22 -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 C4B843A68A8 for ; Sat, 25 Jul 2009 05:13:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAACOUakqQ/uCLe2dsb2JhbACZeQEBFiQGnzWIJo91BYQM X-IronPort-AV: E=Sophos;i="4.43,268,1246838400"; d="scan'208";a="45824398" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2009 12:13:21 +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 n6PCDLcu026133 for ; Sat, 25 Jul 2009 14:13:21 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6PCDL3O020360 for ; Sat, 25 Jul 2009 12:13:21 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 14:13:21 +0200 Received: from [172.18.20.19] ([10.61.94.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Jul 2009 14:13:20 +0200 Message-Id: <8A90971E-7AC9-4837-9E01-FECEFF87BA86@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 25 Jul 2009 14:12:52 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Jul 2009 12:13:20.0885 (UTC) FILETIME=[4CE83A50:01CA0D21] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2; t=1248524001; x=1249388001; 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:=20Agenda=20has=20been=20slightly=20updated=3A=20h ttp=3A//www.ietf.org/proceedings/75/agenda/roll.txt |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=wjQpYkT0IfunWKjEIXMcn39iocCGgMsGJa0QqBFwuSXAQqUqJWbI67jl/z 6zp5ylS4xRjpdBahj4MY2gR2SGY9Wh6R0EfEN2JG+0MJuECOpOmSVmNTX+zV n4u/9ne5no; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Agenda has been slightly updated: http://www.ietf.org/proceedings/75/agenda/roll.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 12:13:23 -0000 From prvs=452c65dfb=mukul@uwm.edu Sun Jul 26 18:54:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A16A3A68D4 for ; Sun, 26 Jul 2009 18:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 j2OZJAARgyFl for ; Sun, 26 Jul 2009 18:54:02 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 848033A68FB for ; Sun, 26 Jul 2009 18:53:53 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 26 Jul 2009 20:53:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 29CC7C085A1 for ; Sun, 26 Jul 2009 20:53:54 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq0bb3hNfM3T for ; Sun, 26 Jul 2009 20:53:54 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 09A79C085A0 for ; Sun, 26 Jul 2009 20:53:54 -0500 (CDT) Date: Sun, 26 Jul 2009 20:53:53 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <973383174.5358341248659633920.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 01:54:23 -0000 Hi all, Please see a new draft describing an alternate routing solution for LLN: http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt This solution allows optimal (or good quality) routes to be achieved to any destination in the LLN (and not just the LBRs as in RPL). Both multipoint-to-point and point-to-point traffic can use this solution. In this solution, only routers in the vicinity of existing routes maintain state about a destination once the route discovery is done. The solution uses the loop correction strategy I described in an earlier email combined with data packet based loop detection. I will submit this draft to IETF repository once it allows me to do so (right now I can't submit a new draft). Thanks Mukul From jvasseur@cisco.com Sun Jul 26 21:43:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7693A68A6 for ; Sun, 26 Jul 2009 21:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Fj88UVw8eW for ; Sun, 26 Jul 2009 21:43:48 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 70C9E3A6898 for ; Sun, 26 Jul 2009 21:43:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/NbEoKS+eh/2dsb2JhbAC3eYgojUYFhA0 X-IronPort-AV: E=Sophos;i="4.43,274,1246838400"; d="scan'208";a="58547733" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-1.cisco.com with ESMTP; 27 Jul 2009 04:43:42 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6R4hg0Q001679 for ; Mon, 27 Jul 2009 12:43:42 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6R4heni003024 for ; Mon, 27 Jul 2009 04:43:42 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 12:42:54 +0800 Received: from [10.43.1.54] ([10.70.231.72]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 12:42:53 +0800 Message-Id: <3DF67F7E-671B-4866-A681-A5AC60C831E1@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 06:42:51 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 27 Jul 2009 04:42:54.0122 (UTC) FILETIME=[B486F8A0:01CA0E74] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=246; t=1248669822; x=1249533822; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Loop=20detection=20between=20sibling |Sender:=20; bh=dcmGTouc++z+b1UfOTBFg/Xbthc+/AggejXZFnpv9Fo=; b=IqDWtnMyd75381AWuTxFYJzBlISj668AUsFNfZJYniIRA2zEtbSyGeP18N nlGrO4XkQyF+JkrJwi1QaTXy00VmJUNHLdz9CXRnNOs48UzZTohcV9OCVvtE v6A0UpYJbgvxPgzerD1vOOjMsf8AHxXx313B1XgOeyZlwrTrBOdy4=; Authentication-Results: hkg-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: [Roll] Loop detection between sibling X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 04:43:50 -0000 Instead of explicit probing when sending to sibling another option is to flag the Flow Label field with a pseudo random number to detect more than 2-hop loops. Simple and efficient with no extra overhead and new mechanisms. Cheers. JP. From cabo@tzi.org Mon Jul 27 02:07:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772F13A6C3A; Mon, 27 Jul 2009 02:07:17 -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=[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 gKmgVUPG6hS3; Mon, 27 Jul 2009 02:07:16 -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 085BF3A6C3C; Mon, 27 Jul 2009 02:07:11 -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.3/8.14.3) with ESMTP id n6R973QK026832; Mon, 27 Jul 2009 11:07:03 +0200 (CEST) Received: from dhcp-161d.meeting.ietf.org (dhcp-161d.meeting.ietf.org [130.129.22.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E9DEEB9B5; Mon, 27 Jul 2009 11:07:02 +0200 (CEST) Message-Id: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> From: Carsten Bormann To: Carsten Bormann 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 v935.3) Date: Mon, 27 Jul 2009 11:06:57 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , 6lowpan@ietf.org, apps-discuss@ietf.org Subject: Re: [Roll] [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:07:17 -0000 The 6LowApp BOF is scheduled for Tue 18:30 at Room 202, see http://u.nu/6jfh I have been asked about the conflict with the social event at Tue evening. The idea is that we will take about an hour for structured discussion. At around 19:30, we will move to a more Bar-BOFy style. Those who want to go to the social will be able to then -- we will find out whether there still will be buses at that time or whether Taxis will be shared. So the Wireless Embedded Internet sub-schedule at IETF 75 for tomorrow, Tue 28, is: 0900-1130 6lowpan INT Cabaret 1520-1810 roll RTG Congresshall C 1830-19xx 6lowapp (APP) Room 202 Gruesse, Carsten From prvs=452c65dfb=mukul@uwm.edu Mon Jul 27 04:01:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178F73A6C1E for ; Mon, 27 Jul 2009 04:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 YjsPj1gtPs4U for ; Mon, 27 Jul 2009 04:01:56 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 441043A67EE for ; Mon, 27 Jul 2009 04:01:56 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 27 Jul 2009 06:01:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CA0AEC085A0; Mon, 27 Jul 2009 06:01:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOU5-230suXL; Mon, 27 Jul 2009 06:01:52 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4C5ABC085AA; Mon, 27 Jul 2009 06:01:52 -0500 (CDT) Date: Mon, 27 Jul 2009 06:01:52 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <3DF67F7E-671B-4866-A681-A5AC60C831E1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Loop detection between sibling X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 11:01:57 -0000 JP, Please give more explanation. I did not understand at all. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Sunday, July 26, 2009 11:42:51 PM GMT -06:00 US/Canada Central Subject: [Roll] Loop detection between sibling Instead of explicit probing when sending to sibling another option is to flag the Flow Label field with a pseudo random number to detect more than 2-hop loops. Simple and efficient with no extra overhead and new mechanisms. Cheers. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Jul 27 06:30:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F046628C245 for ; Mon, 27 Jul 2009 06:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.403 X-Spam-Level: X-Spam-Status: No, score=-7.403 tagged_above=-999 required=5 tests=[AWL=-0.804, 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 Tlw8rNEt1KNi for ; Mon, 27 Jul 2009 06:30:21 -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 0A6DE28C23E for ; Mon, 27 Jul 2009 06:30:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHtIbUqrR7MV/2dsb2JhbAC5Y4gojXwFhA2Jag X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="219531390" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2009 13:30:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6RDUM6i015584; Mon, 27 Jul 2009 06:30:22 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6RDULwe004568; Mon, 27 Jul 2009 13:30:22 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 15:30:21 +0200 Received: from dhcp-1263.meeting.ietf.org ([10.61.101.196]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jul 2009 15:30:20 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 13:50:40 +0200 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 27 Jul 2009 13:30:20.0765 (UTC) FILETIME=[636578D0:01CA0EBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=967; t=1248701422; x=1249565422; c=relaxed/simple; s=sjdkim1004; 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[Roll]=20Loop=20detection=20between=20s ibling |Sender:=20; bh=xQ9q8zul7VRjG7ftmThf4UDbPcgcowLJ960m8lJbHws=; b=gfjAuB8hTJGAkWDWgh2Fm6q5M9z9HOAohchNTgqyoK0HGR9CF2OIl1gZjN VUHPE2iIPh0bQ71O9+8LdoJYZ5+8ByhlTy3Di4SDTZLSp8S1JzHtDTuK0cE4 mK+hku/LLKyeQCkcSjGBqiTsf13OmVh7w8ThjDXjDYfOKA8YYw+fA=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ROLL WG Subject: Re: [Roll] Loop detection between sibling X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:30:22 -0000 Hi, If you know that you are using a sibling and you may have a loop ... you can add a tag in the flow label to detect the loop when the packet circles back. Thanks. JP. On Jul 27, 2009, at 1:01 PM, Mukul Goyal wrote: > JP, > > Please give more explanation. I did not understand at all. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Sunday, July 26, 2009 11:42:51 PM GMT -06:00 US/Canada Central > Subject: [Roll] Loop detection between sibling > > Instead of explicit probing when sending to sibling another option > is to > flag the Flow Label field with a pseudo random number to detect more > than 2-hop loops. Simple and efficient with no extra overhead and new > mechanisms. > > Cheers. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Mon Jul 27 08:27:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0B33A6B0D; Mon, 27 Jul 2009 08:27: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=[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 tfXF4NxU8N7Y; Mon, 27 Jul 2009 08:27:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 80E273A6AD4; Mon, 27 Jul 2009 08:27:06 -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.3/8.14.3) with ESMTP id n6RFQxEL028768; Mon, 27 Jul 2009 17:26:59 +0200 (CEST) Received: from dhcp-52ef.meeting.ietf.org (unknown [130.129.82.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 74E7CBC09; Mon, 27 Jul 2009 17:26:59 +0200 (CEST) Message-Id: <7101F1BF-3003-42B0-BDE6-0502399CF988@tzi.org> From: Carsten Bormann To: ROLL WG , 6lowpan <6lowpan@ietf.org>, apps-discuss@ietf.org In-Reply-To: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 17:26:24 +0200 References: <71C22460-1734-47D6-B7D4-C3A6D272CD42@tzi.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Roll] [6lowpan] 6LowApp: Application protocols for 6LoWPAN and other LLN X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:27:07 -0000 On Jul 27, 2009, at 11:06, Carsten Bormann wrote: > the conflict with the social event Sorry for tricasting once more, but this is *important information*: -- the last bus to the social will leave at 7:30 PM from in front of the Clarion Sign and will wait for us. We are a big enough group that it was OK. (Obviously, not all of us *will* go to the social; happy discussions await the rest.) -- for those who asked what the "Bar" in the "Bar BOF" was about, this seems to be a variant spelling of "beer", and indeed there will be some beer available for the participants of the Bar BOF, sponsored by an entity very interested in progress on the 6lowapp problem. As I said, important information! See you tomorrow at 1830. Gruesse, Carsten From prvs=453fa80d5=mukul@uwm.edu Mon Jul 27 17:54:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47B83A67BD for ; Mon, 27 Jul 2009 17:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 tN0M7WntdGu0 for ; Mon, 27 Jul 2009 17:54:11 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 0D3E03A68BC for ; Mon, 27 Jul 2009 17:54:10 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 27 Jul 2009 19:54:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 20C6DC085A9 for ; Mon, 27 Jul 2009 19:54:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC42PtB+qrnj for ; Mon, 27 Jul 2009 19:54:11 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E021DC085A8 for ; Mon, 27 Jul 2009 19:54:11 -0500 (CDT) Date: Mon, 27 Jul 2009 19:54:11 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1285148470.5706391248742451764.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20090728005255.3A1DC3A6AF9@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-goyal-roll-dv-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 00:54:33 -0000 ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Sent: Monday, July 27, 2009 7:52:55 PM GMT -06:00 US/Canada Central Subject: New Version Notification for draft-goyal-roll-dv-01 A new version of I-D, draft-goyal-roll-dv-01.txt has been successfuly submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-dv Revision: 01 Title: A Distance Vector Protocol for Routing Over Low Power and Lossy Networks Creation_date: 2009-07-27 WG ID: Independent Submission Number_of_pages: 12 Abstract: This draft describes a distance vector protocol for routing over low power and lossy networks (LLN). The IETF Secretariat. From jvasseur@cisco.com Tue Jul 28 00:29:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03FF3A6CF0 for ; Tue, 28 Jul 2009 00:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.459 X-Spam-Level: X-Spam-Status: No, score=-7.459 tagged_above=-999 required=5 tests=[AWL=-0.860, 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 fBOTDdndjikY for ; Tue, 28 Jul 2009 00:29:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EFCF03A6B7A for ; Tue, 28 Jul 2009 00:28:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANdFbkqrR7MV/2dsb2JhbAC5eognjyoFhAw X-IronPort-AV: E=Sophos;i="4.43,281,1246838400"; d="scan'208";a="190194859" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2009 07:28:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6S7SZrF014006 for ; Tue, 28 Jul 2009 00:28:35 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6S7SYtY027553 for ; Tue, 28 Jul 2009 07:28:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:28:34 +0200 Received: from dhcp-1263.meeting.ietf.org ([10.61.103.145]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 09:28:33 +0200 Message-Id: <1D70CEDC-595B-42A7-9081-11448640D829@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 09:28:33 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 Jul 2009 07:28:34.0088 (UTC) FILETIME=[039F2A80:01CA0F55] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=117; t=1248766115; x=1249630115; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Slides=20Uploaded |Sender:=20; bh=3SDY3TaB5BrDDOprIVNCOBWOTbwuUPYtwYDhX1AsO2s=; b=s+sjfqIl7+qymzpxik9y3Dy9PpQttgYdTtjFOuezj+hognGLcQZ5PhCPsj MsxHrpiPnnXhRyjXSE/EwDtpbjambzkwFZVIO7JfGMbnQ1vr1ljNnQfTE2JZ xtE4nw8twXPg+eTyaS4e307JmToRf0apLSse6rJACoYdiDRhN4TmU=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Roll] Slides Uploaded X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:29:02 -0000 Dear all, Slides have been uploaded. https://datatracker.ietf.org/meeting/75/materials.html Thanks. JP. From inzbill26@gmail.com Tue Jul 28 05:21:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDAE3A6EF3 for ; Tue, 28 Jul 2009 05:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLEC18gOXQ9z for ; Tue, 28 Jul 2009 05:21:35 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id E3C103A6EBC for ; Tue, 28 Jul 2009 05:21:34 -0700 (PDT) Received: by fxm12 with SMTP id 12so3332fxm.37 for ; Tue, 28 Jul 2009 05:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+rwprDoPXiYcjZJgY9809BsMzwZrz7F6YjqO3OHjjfw=; b=NqBuxidI/WtjQ/0ilCv1IyXhMkuKobvubUtfxZQbClc8a8gDZq6DHqPb25Qx+QNT3R VmnOGdRbMiZZyQeN5GWFfOCx+teetqTEPZJGJjUED7SaDLMS5LiOPLzCybrg4+tjYCoO QTKyQ5aZlMzlTIglmlmwRU4G+0O2Do59KjzsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HlxU9A3fDQPWp2M8iaZoKNg9Qedn7aB0JMV8Csv0UZfTmanAnh6nfAdcjC/SkQ0xgs AMKZ7LbrO6tWmWEezpyBPhK64ulQcj5EwFi9pTFAMl3GS8mrRNj5LN+IKUNSirAMBSyS wR2nlC3sCtlqkR+8Z9hPs87qV0IMF/t7lDqLY= MIME-Version: 1.0 Received: by 10.103.241.5 with SMTP id t5mr3858202mur.123.1248783690816; Tue, 28 Jul 2009 05:21:30 -0700 (PDT) Date: Tue, 28 Jul 2009 14:21:29 +0200 Message-ID: <2590eb10907280521w67da335es3784c9314f1d9831@mail.gmail.com> From: Inza Bamba To: roll@ietf.org Content-Type: multipart/alternative; boundary=001636b4313d4b1311046fc31c81 Subject: [Roll] An alternative to RPL (Mukul Goyal) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:21:36 -0000 --001636b4313d4b1311046fc31c81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi M. every body, I'm a new comer on this mailing list and also a beginner in LLN. I read the draft describing an alternate solution for LLN it is the interesting however I need some explaination: * what is the interest to disable packet forwarding on host? * In what case a loop could occur? Thank you for your clarification. --001636b4313d4b1311046fc31c81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi M. every body, I'm a new comer on this mailing list and also a begin= ner in LLN. I read the draft describing an alternate solution for LLN it is= the interesting however I need some explaination:

* what is the int= erest to disable packet forwarding on host?
* In what case a loop could occur?=A0

Thank you for your clarificat= ion.
--001636b4313d4b1311046fc31c81-- From prvs=453fa80d5=mukul@uwm.edu Tue Jul 28 05:39:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9A43A6CDE for ; Tue, 28 Jul 2009 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 zWCAd9h4CK6a for ; Tue, 28 Jul 2009 05:39:20 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 901EB3A68DA for ; Tue, 28 Jul 2009 05:39:20 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 28 Jul 2009 07:39:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A846AC085A0; Tue, 28 Jul 2009 07:39:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhdtmXzRhmrp; Tue, 28 Jul 2009 07:39:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 53AECC085A3; Tue, 28 Jul 2009 07:39:21 -0500 (CDT) Date: Tue, 28 Jul 2009 07:39:21 -0500 (CDT) From: Mukul Goyal To: Inza Bamba Message-ID: <1150282537.5757191248784761127.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2094123873.5756691248784625766.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] An alternative to RPL (Mukul Goyal) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:39:21 -0000 Hello, An LLN host may not want to participate in routing for a number of reasons = including the need to save battery. I think it should be OK to allow a node= to alternate between host and router roles. Obviously, when a router switc= hes to the host role, existing routes passing through it would be disrupted= . Perhaps, a router could allow a transition period during which it informs= neighbor nodes of its intention to switch to the host mode but continues t= o act as a router. Loops occur in distance vector routing when the cost to reach the destinati= on via the current next hop deteriorates so much that node A selects a new = next hop, some one whose advertised cost is actually based on the old cost = of node A. This new next hop may end up routing the packets back to node A. Thanks Mukul ----- Original Message ----- From: "Inza Bamba" To: roll@ietf.org Sent: Tuesday, July 28, 2009 7:21:29 AM GMT -06:00 US/Canada Central Subject: [Roll] An alternative to RPL (Mukul Goyal) Hi M. every body, I'm a new comer on this mailing list and also a beginner = in LLN. I read the draft describing an alternate solution for LLN it is the= interesting however I need some explaination:=20 * what is the interest to disable packet forwarding on host?=20 * In what case a loop could occur?=C2=A0=20 Thank you for your clarification.=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jul 28 05:44:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610B03A692C for ; Tue, 28 Jul 2009 05:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u5YPytzZtt7 for ; Tue, 28 Jul 2009 05:44:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9F6FE3A67D8 for ; Tue, 28 Jul 2009 05:44:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALWPbkqQ/uCL/2dsb2JhbAC7Mognj1sFhAyJbA X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="190275968" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2009 12:44:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SCieIp022597; Tue, 28 Jul 2009 14:44:40 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SCieMp000629; Tue, 28 Jul 2009 12:44:40 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 14:44:40 +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: Tue, 28 Jul 2009 14:44:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07DC240E@xmb-ams-337.emea.cisco.com> In-Reply-To: <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs Thread-Index: AcoJnwl7b5dU7TFTTwOTFCDUlx6txQF360KQ References: <1732864908.3947031248137887086.JavaMail.root@mail02.pantherlink.uwm.edu> <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Jonathan Hui" X-OriginalArrivalTime: 28 Jul 2009 12:44:40.0375 (UTC) FILETIME=[2C68E470:01CA0F81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10979; t=1248785080; x=1249649080; 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[Roll]=20A=20simple=20loop=20avoidance= 20mechanism=20for=20use=20in=20P2P=20DV=20routing=20not=20us ing=20DAGs |Sender:=20; bh=qH6GFyy/5GXtAVVdiQiBE2lBAuVWTBC+ZHt0UIdpFCQ=; b=B0zIIxBjQJm1gPnA+HrDGH+XxxdowxAG1nCzV6uLdRYBaLcDolHmE0du5D NXPsyOorgSpxF+ToXmRFDC5RnxXKGVbc/fFI9pdCxfFEGv+oymbeC9dGz950 zt+rWK2QOq; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:44:44 -0000 Hi Mukul: We can certainly improve that text. As you figured, the main goal of the DAG hop timer and associated held up state is to smoothly merge DAGs. Say a floating DAG can be merged back in a grounded DAG. If nodes could attach to the grounded DAG in any order, there would be churn as other nodes joining enable new better positions for nodes that already joined (too quickly). The delay enables nodes that can join higher to join first, so the joining spreads like a ave in the floating DAG. The second "goal" is more like a side effect. If we do not use the sequence to protect completely against loops, then RA loss might actually cause a node that detached from a DAG to reattach to a node in its subDAG that was not aware anything happened, effectively creating a loop. The delay here gives more chances for successive RA waves to propagate to all nodes in the subDAG and avoid that situation.=20 On the side, I'd note that there is a general tendency in this working group to favor approaches that are be less strict at avoiding loops and more clever at detecting them on the data flows (see Phil's mails, the DADR proposal, CTP). Data flow loop detection is also needed to block sibling loops which can happen with the current RPL draft (by design), and the DADR detection would be a nice addition there. If we decide to tweak RPL along those lines, we might decide to remove the sequence totally, or make it optional. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal >Sent: mardi 21 juillet 2009 03:03 >To: Jonathan Hui >Cc: roll >Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs > >Hi Jonathan, > >I am not sure how does the "Held-up" mechanism cover the loop avoidance scheme I described. I seem to be >missing some thing. Here is my understanding of the "held-up" mechanism described in RPL: > >Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" state: > >1. "Delay the reattachment of a sub-DAG that has been forced to > detach. This is not as safe as the use of the sequence, but still > covers that when a sub-DAG has detached, the Router Advertisement > - DAG Information Option that is initiated by the new DAG root has > a chance to spread outward along the sub-DAG so that two different > DAGs have formed." > >I did not understand the text quoted above at all. Please clarify. I did not find any additional text in RPL >draft that further describes the use of "held-up" state in this context. > >2. The second purpose of the "held-up" state, which I think I understand clearly, is to delay a node's joining >of a new DAG to try to ensure that: >a) a node joins the new DAG at the minimum possible depth; >b) among the neighbor/nearby nodes trying to join the new DAG, the nodes join the new DAG roughly in order of >their depth in the new DAG. >To achieve these objectives, a node keeps a potential parent in the new DAG in the "held-up' state for a time >duration proportional to the potential parent's depth in that DAG. For every new potential parent, the node >starts a new "held-up" state timer (the hop timer). The node joins the new DAG via the first potential parent >coming out of the "held-up" state. > >On the other hand, the loop avoidance mechanism I described puts a node in the "loop avoidance" state when the >current nexthop/parent is no longer good enough. Rather than immediately choosing a different parent (based on >potentially erroneous costs currently being advertised by neighbors), the node advertises (via special >_marked_ advertisements) its new cost through the current parent for the duration it is in the "loop >avoidance" state. On receiving these _marked_ advertizements, the node's children enter the "loop avoidance" >state as well and further propagate the new cost information. The idea is that, by the time the node comes out >of the "loop avoidance" state, hopefully all its neighbors would have corrected their cost estimates if the >previous estimates were based on the old costs. So, on coming out of the "loop avoidance" state, when the node >selects its new parents, it does not cause a routing loop or a "count to infinity" situation. > >>2) What is the effect of packet loss? >>- If node B is a descendant of A and B misses the advertisement from >>its parent, then A may attach to B or any of its descendants. In a >>sufficiently dense network, there's a fairly high probability that >>some node B will miss the advertisement from A (even with >>retransmissions). On the flip side, those that properly hear the new >>cost values are likely not to be involved in any loops. In summary, >>Count-to-Infinity still exists but arguably with only a subset of nodes. > >I agree. The efficacy of the solution depends on the probability of _neighbor_ descendants (i.e. descendants >that are neighbors as well) receiving the new cost information and updating their cost advertisements based on >this information. This probability in turn depends on parameters like the probability of advertisement loss, >the duration of the "loop avoidance" state, the number of times a node sends out advertisements while in this >state, the children tree topology etc. > >Regards >Mukul > > > >On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: > >> Hi all >> >> Here is a simple loop avoidance mechanism that can be used in a P2P >> routing solution that does not use DAGs. >> >> Thanks >> Mukul >> >> In DV protocols, the routing loops are triggered when the cost to >> reach a destination via the current next hop increases so much that >> a new next hop needs to be selected. >> >> Suppose, a node, B, determines that its current next hop, A, for a >> destination, X, may no longer be the best ("minimum cost") neighbor >> to forward packets to. Such determination could be based on an >> increase in the link cost to node A or the receipt of a new >> advertisement from node A showing an increased cost to reach the >> destination X. >> >> In case of such an event, node B should not choose a new next hop >> immediately. This is because the current cost advertisements by its >> neighbors, as well as any new advertisements generated in the >> immediate aftermath of the event, may be based on node B's erstwhile >> cost to reach the destination. Immediate selection of a new next hop >> based on the current or new cost advertisements by the neighbors may >> lead to a routing loop and a "count to infinity" situation. >> >> Rather, node B should initiate the propagation of new cost >> information down the tree (of nodes for whom it currently lies on >> the route to X)and wait for some time before calculating its new >> next hop. The hope is that by the time the node calculates its new >> next hop, its increased cost along the current next hop is known to >> all its neighbors and they have generated new advertisements if >> their previous advertisements were based on the old cost of node B >> to reach X. >> >> So, when node B determines that its current next hop A for >> destination X is no longer the best neighbor to forward packets to, >> it generates a new specially _marked_ advertisement that lists node >> B's new cost to reach X via A, the current next hop. >> >> The generation of a _marked_ advertizement regarding destination X >> puts the node in the "loop avoidance" state for a time period during >> which the node can neither change its next hop to destination X nor >> generate a regular advertisement for the destination X. >> >> All nodes that receive node B's _marked_ advertisement regarding >> destination X update their cost to reach X via B. If a node >> currently considers node B as its next hop to destination X, it >> additionally does the following: >> 1. it enters the "loop avoidance" state and hence consequently keeps >> node B as its next hop to X >> 2. originates a _marked_ advertizement listing its new cost to >> destination X via node B >> >> Once a node exits the "loop avoidance" state, it is allowed to >> select a new next hop to X and generate a regular advertisement >> listing its new cost to X. >> >> Here is an example showing the efficacy of this proposal: >> >> X >> | >> A >> / \ >> B-C >> / \ >> D E >> \ / >> F >> >> X is the destination. >> >> Suppose all unidirectional link costs are 1 except the following: B- >> >C:5, B->D:5 and E->B:5 >> >> Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X >> >> and node B's perceived cost to reach X via each neighbor is as >> follows: >> via A:2, via C:7, via D:8, via E:6 >> >> Suppose the cost of link B->A changes to 100. >> >> In a simple DV protocol, B's cost to reach X via A becomes 101 and >> hence it immediately chooses E as the next hop (declaring its new >> cost to X as 6), thereby creating routing loop B->E->F->D->B and a >> "count to infinity" situation. >> >> Under the proposed protocol, B would generate a _marked_ >> advertisement listing its cost to X as 101 and enter the "loop >> avoidance" state. This _marked_ advertisement is received by A, C, D >> and E. Since D considers B as its next hop to X, it enters the "loop >> avoidance" state as well and generates its own _marked_ >> advertisement listing its cost to X as 102. >> >> On receiving this advertisement, node F enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 103. >> >> On receiving this advertisement, node E enters the "loop avoidance" >> state and generates its own _marked_ advertisement listing its cost >> to X as 104. >> >> If node B comes out of the "loop avoidance" state only after the >> receipt of this advertisement from E, B would correctly choose node >> C as its new next hop to X and generate a new advertisement listing >> its cost to X as 7. When nodes D, F and E come out of the "loop >> avoidance" state, they would ultimately update their cost to X to >> 8, 9 and 10 respectively without any loops. >> >> This policy does cause a delay in convergence. Suppose B->C cost is >> 1 in the example above. B enters the "loop avoidance" state when >> cost of link B->A changes to 100. Node B would not select C as next >> hop (and advertize a cost 3 to X) until it comes out of the "loop >> avoidance" state. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Matthew.Anderson@us.elster.com Tue Jul 28 08:45:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FB73A70F3 for ; Tue, 28 Jul 2009 08:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 ZMJ9tu+ah8bX for ; Tue, 28 Jul 2009 08:45:14 -0700 (PDT) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id 738333A7093 for ; Tue, 28 Jul 2009 08:45:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-2.tower-53.messagelabs.com!1248795915!31158878!1 X-StarScan-Version: 6.1.2; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 11485 invoked from network); 28 Jul 2009 15:45:15 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-2.tower-53.messagelabs.com with SMTP; 28 Jul 2009 15:45:15 -0000 X-KeepSent: A92E6ABE:A2302424-85257601:0056034A; type=4; name=$KeepSent To: roll@ietf.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Matthew.Anderson@us.elster.com Date: Tue, 28 Jul 2009 17:44:49 +0200 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5 HF460|May 15, 2009) at 07/28/2009 11:44:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:45:15 -0000 Instead of using the term depth, would the term rank be acceptable? Reflects that each node is searching only for those with a higher rank (well, a lower number, which reflects a higher rank), but doesn't imply a hop count. Matt From jvasseur@cisco.com Tue Jul 28 09:36:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6DC3A687F for ; Tue, 28 Jul 2009 09:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.352 X-Spam-Level: X-Spam-Status: No, score=-9.352 tagged_above=-999 required=5 tests=[AWL=1.247, 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 RxRxBJ-rzc2x for ; Tue, 28 Jul 2009 09:36:21 -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 75FA13A682A for ; Tue, 28 Jul 2009 09:36:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYAAJPFbkqQ/uCLe2dsb2JhbACaBwEBFiQGon2IJ5ADBYQM X-IronPort-AV: E=Sophos;i="4.43,284,1246838400"; d="scan'208";a="46000245" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2009 16:36:21 +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 n6SGaLCl015132 for ; Tue, 28 Jul 2009 18:36:21 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SGaL0G003805 for ; Tue, 28 Jul 2009 16:36:21 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 18:36:21 +0200 Received: from dhcp-1263.meeting.ietf.org ([10.61.102.220]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 18:36:21 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 18:34:24 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 28 Jul 2009 16:36:21.0203 (UTC) FILETIME=[89F2EA30:01CA0FA1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=710; t=1248798981; x=1249662981; 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:=20Moving=20forward=20with=20the=20protocol=20work |Sender:=20; bh=4m2/pOJHBlr37BqCTv2a0O8V5ut+DhjJ5sLZVOLTBYM=; b=drZxSnRCdJPW8e55SVxpy4onEBAoU9L2CV5FAeWX9JjNtJLNOKtzdDpdD1 hhM/HCEgUcnZMrDZNzqYQx4rX25Uqg9iH8MiUjGB7NBdBhMYMkLWPPH28bky rAEPYYd6jn; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:36:22 -0000 Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David From d.sturek@att.net Tue Jul 28 09:59:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176933A6CFD for ; Tue, 28 Jul 2009 09:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmXa9ZGJQNQY for ; Tue, 28 Jul 2009 09:59:42 -0700 (PDT) Received: from smtp103.sbc.mail.re2.yahoo.com (smtp103.sbc.mail.re2.yahoo.com [68.142.229.102]) by core3.amsl.com (Postfix) with SMTP id 2998F3A6AB2 for ; Tue, 28 Jul 2009 09:59:42 -0700 (PDT) Received: (qmail 64635 invoked from network); 28 Jul 2009 16:59:41 -0000 Received: from unknown (HELO Studio) (d.sturek@130.129.21.75 with login) by smtp103.sbc.mail.re2.yahoo.com with SMTP; 28 Jul 2009 16:59:41 -0000 X-YMail-OSG: 8DenU8wVM1mvXbqdxo_xW0ofbgNlfaoQaDz1z8xUqjdZF7j38oI_JR2AqWCfezzVaHKROMbwR6A0JlCmW9U5dR2Tv_VkiNAweP7x5lyZl4Y3hs8HZ2lsYwh1QJ32MCCMCCYV7WL9jTVaosardJ3hEI75RBH3nLKpjHk8cNomN5rDRzAIquhgQZx.Ogg8C32NhNJxlkIWk1qr2UOKvqNQUUnllsSz5lN2nW8QLfGBK2Gyd4uN.mgGX3y5Ag12UifHnTlFOEpQWPw2gJP7LzGXeH3MrsxNtxRKHMs.qJt9XbI2L.c- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: In-Reply-To: Date: Tue, 28 Jul 2009 09:59:36 -0700 Message-ID: <008901ca0fa4$cb12a390$6137eab0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPoY1n6Ntpy4UKRbi3fKxvKcCTuAAAwZZA Content-Language: en-us Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:59:43 -0000 Hi JP, I am in support of adopting the RPL proposal as the foundation for the ROLL routing protocol work. Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, July 28, 2009 9:34 AM To: ROLL WG Subject: [Roll] Moving forward with the protocol work Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Jul 28 10:40:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4A33A6D24; Tue, 28 Jul 2009 10:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D13ga3pQsuCK; Tue, 28 Jul 2009 10:40:44 -0700 (PDT) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by core3.amsl.com (Postfix) with ESMTP id D58E73A682B; Tue, 28 Jul 2009 10:40:43 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKSm84A4h822HUl3xWymougRcHoozFQO/m@postini.com; Tue, 28 Jul 2009 10:40:46 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009072812401284-818937 ; Tue, 28 Jul 2009 12:40:12 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 28 Jul 2009 12:40:00 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/28/2009 12:40:08 PM, Serialize complete at 07/28/2009 12:40:08 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/28/2009 12:40:12 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/28/2009 12:40:50 PM, Serialize complete at 07/28/2009 12:40:50 PM Content-Type: multipart/alternative; boundary="=_alternative 00610B8B86257601_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 17:40:45 -0000 This is a multipart message in MIME format. --=_alternative 00610B8B86257601_= Content-Type: text/plain; charset="US-ASCII" I cannot yet affirm RPL as a working group draft since it hasn't yet stated how P2P communication will operate within the DAG. As I have noted in my review comments, connectivity to every node within the DAG is not assured. The traffic patterns within the LLN are also suspect since most packets must travel upward toward the LBR before finding their intended destination lower in the DAG. This imbalance will create network traffic congestion in the higher layers of the DAG. Hopping many hops up the DAG and back down the DAG to talk to a node that is in direct radio range seems totally inefficient. Latency and convergence time are also a concern. However, I can wait for simulation or implementations to ferret out these issues. Regards, Jerry Martocci JP Vasseur Sent by: roll-bounces@ietf.org 07/28/2009 11:36 AM To ROLL WG cc Subject [Roll] Moving forward with the protocol work Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00610B8B86257601_= Content-Type: text/html; charset="US-ASCII"
I cannot yet affirm RPL as a working group draft since it hasn't yet stated how P2P communication will operate within the DAG.  

As I have noted in my review comments, connectivity to every node within the DAG is not assured.  The traffic patterns within the LLN are also suspect since most packets must travel upward toward the LBR before finding their intended destination lower in the DAG.  This imbalance will create network traffic congestion in the higher layers of the DAG.  Hopping many hops up the DAG and back down the DAG to talk to a node that is in direct radio range seems totally inefficient.

Latency and convergence time are also a concern.  However, I can wait for simulation or implementations to ferret out these issues.

Regards,

Jerry Martocci





JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

07/28/2009 11:36 AM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] Moving forward with the protocol work





Dear WG,

First of all, thanks for all the time and energy you all have devoted  
during the past few weeks on the protocol work. There was excellent  
followup discussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation  
for the ROLL routing protocol work", there was clearly a good  
consensus in the WG meeting. It was also recognized there are still  
several open issues for which we WILL need help from many WG  
contributors, including the authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01  
as a WG document ?

Then we will of course move to the next step.

Thanks,

JP and David


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00610B8B86257601_=-- From mischa.dohler@cttc.es Tue Jul 28 16:42:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F9C3A6D3C for ; Tue, 28 Jul 2009 16:42: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 8+j9x6fi6xMs for ; Tue, 28 Jul 2009 16:42:27 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 084683A68C5 for ; Tue, 28 Jul 2009 16:42:26 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n6SNf1Ai027140; Wed, 29 Jul 2009 01:41:01 +0200 Received: from [127.0.0.1] (111.Red-88-7-108.staticIP.rima-tde.net [88.7.108.111]) by leo (Postfix) with ESMTP id 655C910C31D; Wed, 29 Jul 2009 01:41:00 +0200 (CEST) Message-ID: <4A6F8C8C.1090001@cttc.es> Date: Wed, 29 Jul 2009 01:41:00 +0200 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090728-0, 28/07/2009), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Wed, 29 Jul 2009 01:41:01 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 23:42:28 -0000 Jerry, I am not sure this was already discussed at the meeting in person but I think we are a little in a catch22 situation here since - as far as I remember - none of the requirement docs explicitly required (MUST) p2p situations. I gather that the design team did take these documents as their working basis which is why p2p is not efficiently supported. In our urban requirements draft, we actually did go as far as saying that p2p should not be the main design thrust but rather the highly directional data flows towards a few sinks. Mischa. Jerald.P.Martocci@jci.com wrote: > > I cannot yet affirm RPL as a working group draft since it hasn't yet > stated how P2P communication will operate within the DAG. > > As I have noted in my review comments, connectivity to every node within > the DAG is not assured. The traffic patterns within the LLN are also > suspect since most packets must travel upward toward the LBR before > finding their intended destination lower in the DAG. This imbalance > will create network traffic congestion in the higher layers of the DAG. > Hopping many hops up the DAG and back down the DAG to talk to a node > that is in direct radio range seems totally inefficient. > > Latency and convergence time are also a concern. However, I can wait > for simulation or implementations to ferret out these issues. > > Regards, > > Jerry Martocci > > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 07/28/2009 11:36 AM > > > To > ROLL WG > cc > > Subject > [Roll] Moving forward with the protocol work > > > > > > > > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good > consensus in the WG meeting. It was also recognized there are still > several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=4549da388=mukul@uwm.edu Tue Jul 28 17:14:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB6C3A692D for ; Tue, 28 Jul 2009 17:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 n-KAajIAIk1M for ; Tue, 28 Jul 2009 17:14:08 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id E42353A6A3F for ; Tue, 28 Jul 2009 17:13:45 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 28 Jul 2009 19:13:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 244811958003; Tue, 28 Jul 2009 19:13:47 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPqAR3vp2+rE; Tue, 28 Jul 2009 19:13:46 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id B5BF8195800B; Tue, 28 Jul 2009 19:13:46 -0500 (CDT) Date: Tue, 28 Jul 2009 19:13:46 -0500 (CDT) From: Mukul Goyal To: Mischa Dohler Message-ID: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4A6F8C8C.1090001@cttc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 00:15:01 -0000 Mischa, I am not speaking for Jerry but P2P flows are important in LLN applications I am familiar with (which happen to be in commercial building domain). I will have to go back to all the requirements drafts but I would be surprised if other domains will not benefit from an efficient P2P solution. The main question is why are we insisting on "one solution fits all" approach??? Why can't we recognize that different applications have different requirements and offer multiple solutions (including RPL). Let RPL be used by applications that find it useful but we should not force RPL as the only solution available. In my view, RPL has the following three shortcomings: 1) Does not offer optimal/good P2P routing 2) Does not allow destinations other than LBRs to be advertised. Note that this point and the previous one are independent. 3) Insistence on using DAG as the loop prevention mechanism. RPL is a good MP2P solution but we should not force it down the throats of people who want good P2P routing as well. IETF has a long history of offering multiple solutions for a given routing problem. We has multiple interior gateway protocols, multiple MANET solutions, multiple OSPF-MANET solutions. Why can't, and why should not, we have multiple ROLL solutions?? I asked this question to JP right at the time the ROLL WG got a new charter. The answer I got was - we will work on one solution for now but we do not exclude other solutions. I think ROLL should offer multiple solutions and let an application choose what fits it best. Thanks Mukul ----- Original Message ----- From: "Mischa Dohler" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Jerry, I am not sure this was already discussed at the meeting in person but I think we are a little in a catch22 situation here since - as far as I remember - none of the requirement docs explicitly required (MUST) p2p situations. I gather that the design team did take these documents as their working basis which is why p2p is not efficiently supported. In our urban requirements draft, we actually did go as far as saying that p2p should not be the main design thrust but rather the highly directional data flows towards a few sinks. Mischa. Jerald.P.Martocci@jci.com wrote: > > I cannot yet affirm RPL as a working group draft since it hasn't yet > stated how P2P communication will operate within the DAG. > > As I have noted in my review comments, connectivity to every node within > the DAG is not assured. The traffic patterns within the LLN are also > suspect since most packets must travel upward toward the LBR before > finding their intended destination lower in the DAG. This imbalance > will create network traffic congestion in the higher layers of the DAG. > Hopping many hops up the DAG and back down the DAG to talk to a node > that is in direct radio range seems totally inefficient. > > Latency and convergence time are also a concern. However, I can wait > for simulation or implementations to ferret out these issues. > > Regards, > > Jerry Martocci > > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 07/28/2009 11:36 AM > > > To > ROLL WG > cc > > Subject > [Roll] Moving forward with the protocol work > > > > > > > > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good > consensus in the WG meeting. It was also recognized there are still > several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jul 28 20:25:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F009D3A6D24 for ; Tue, 28 Jul 2009 20:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvPTeJvFBm1z for ; Tue, 28 Jul 2009 20:25:06 -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 9BDD53A6D81 for ; Tue, 28 Jul 2009 20:25:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK9db0qrR7MV/2dsb2JhbAC9B4gnkBsFhBCBTYgg X-IronPort-AV: E=Sophos;i="4.43,286,1246838400"; d="scan'208";a="220495778" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2009 03:25:08 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6T3P8sn023501; Tue, 28 Jul 2009 20:25:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n6T3P8Ma004473; Wed, 29 Jul 2009 03:25:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 20:25:08 -0700 Received: from [10.43.1.15] ([10.21.69.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 20:25:06 -0700 Message-Id: <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 05:25:04 +0200 References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 03:25:07.0300 (UTC) FILETIME=[2BB5F240:01CA0FFC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6458; t=1248837908; x=1249701908; c=relaxed/simple; s=sjdkim1004; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=myN9ezfjBlwtSNpzC4xiTJ3HIIeW9VDOnsC50gslZus=; b=pWtUnSx0sHqHyUxH7Uw9c1yIE6Da/51EklPGviXdOrF+9dNr0R6QJm8SuR GJAUZMyMikxNpKr3qBHxJA4Lp0DVogzVxoe4F2FMTM1D+IXXhFOMKVOx8qBU vscdaWwxWwlI09kIxHnbhQd/xR4pwxAYCFWBFEVKYKcTuXkSeeFnM=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 03:25:14 -0000 Hi Mukul, I would really like to get your answer on whether you support the adoption of RPL as good foundation to move forward, adopting it as a WG ID. Your comments are extremely valid, see in line: On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: > Mischa, > > I am not speaking for Jerry but P2P flows are important in LLN > applications I am familiar with (which happen to be in commercial > building domain). I will have to go back to all the requirements > drafts but I would be surprised if other domains will not benefit > from an efficient P2P solution. > > The main question is why are we insisting on "one solution fits all" > approach??? Why can't we recognize that different applications have > different requirements and offer multiple solutions (including RPL). > > Let RPL be used by applications that find it useful but we should > not force RPL as the only solution available. > > In my view, RPL has the following three shortcomings: > > 1) Does not offer optimal/good P2P routing > 2) Does not allow destinations other than LBRs to be advertised. > Note that this point and the previous one are independent. > 3) Insistence on using DAG as the loop prevention mechanism. > > RPL is a good MP2P solution but we should not force it down the > throats of people who want good P2P routing as well. > > IETF has a long history of offering multiple solutions for a given > routing problem. We has multiple interior gateway protocols, > multiple MANET solutions, multiple OSPF-MANET solutions. Why can't, > and why should not, we have multiple ROLL solutions?? > > I asked this question to JP right at the time the ROLL WG got a new > charter. The answer I got was - we will work on one solution for now > but we do not exclude other solutions. > > I think ROLL should offer multiple solutions and let an application > choose what fits it best. > Few things: 1) The ROLL routing protocol will have to support a good solution for P2P, this is a MUST requirement. For the time being a solution such as RPL is optimized for P2MP and P2MP and does support P2P but that MUST be improved. This was discussed and agreed yesterday during the WG meeting and on the mailing list. Next step is to work on this and your help will be greatly appreciated. 2) The DT will reply but RPL support the advertisements of destination other than LBRs 3) Loop detection: fully agree, I had proposed myself a solution but others may have other ideas. I personally think that this is one of the areas where we can borrow some ideas also from the DADR proposal. Again to be discussed on the list. 4) With regards to having more protocols, we are chartered to design one protocol for the time being. There is still lot of work to do, and the solution will continue to evolve. It is thus premature to think more than one protocol at this stage. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Mischa Dohler" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > Jerry, I am not sure this was already discussed at the meeting in > person > but I think we are a little in a catch22 situation here since - as far > as I remember - none of the requirement docs explicitly required > (MUST) > p2p situations. I gather that the design team did take these documents > as their working basis which is why p2p is not efficiently > supported. In > our urban requirements draft, we actually did go as far as saying that > p2p should not be the main design thrust but rather the highly > directional data flows towards a few sinks. Mischa. > > > Jerald.P.Martocci@jci.com wrote: >> >> I cannot yet affirm RPL as a working group draft since it hasn't yet >> stated how P2P communication will operate within the DAG. >> >> As I have noted in my review comments, connectivity to every node >> within >> the DAG is not assured. The traffic patterns within the LLN are also >> suspect since most packets must travel upward toward the LBR before >> finding their intended destination lower in the DAG. This imbalance >> will create network traffic congestion in the higher layers of the >> DAG. >> Hopping many hops up the DAG and back down the DAG to talk to a node >> that is in direct radio range seems totally inefficient. >> >> Latency and convergence time are also a concern. However, I can wait >> for simulation or implementations to ferret out these issues. >> >> Regards, >> >> Jerry Martocci >> >> >> >> >> >> *JP Vasseur * >> Sent by: roll-bounces@ietf.org >> >> 07/28/2009 11:36 AM >> >> >> To >> ROLL WG >> cc >> >> Subject >> [Roll] Moving forward with the protocol work >> >> >> >> >> >> >> >> >> Dear WG, >> >> First of all, thanks for all the time and energy you all have devoted >> during the past few weeks on the protocol work. There was excellent >> followup discussion at the physical WG meeting. >> >> To the question "Do you think that RPL provides an adequate >> foundation >> for the ROLL routing protocol work", there was clearly a good >> consensus in the WG meeting. It was also recognized there are still >> several open issues for which we WILL need help from many WG >> contributors, including the authors of other documents. >> >> Could you please confirm (or not) the adoption of draft-dt-roll- >> rpl-01 >> as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jul 28 20:59:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D6B3A6A12 for ; Tue, 28 Jul 2009 20:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POf3sgWAsUfc for ; Tue, 28 Jul 2009 20:59:42 -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 727273A67FF for ; Tue, 28 Jul 2009 20:59:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJdmb0qrR7PE/2dsb2JhbAC8bIgnkBcFhBA X-IronPort-AV: E=Sophos;i="4.43,286,1246838400"; d="scan'208";a="356009285" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2009 03:59:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6T3xieB014730; Tue, 28 Jul 2009 20:59:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6T3xibC021636; Wed, 29 Jul 2009 03:59:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 20:59:43 -0700 Received: from [10.43.1.15] ([10.21.69.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 20:59:43 -0700 Message-Id: From: JP Vasseur To: Matthew.Anderson@us.elster.com 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 v935.3) Date: Wed, 29 Jul 2009 05:59:42 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 03:59:43.0523 (UTC) FILETIME=[013C6F30:01CA1001] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=508; t=1248839984; x=1249703984; c=relaxed/simple; s=sjdkim4002; 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[Roll]=20Another=20Term=20Instead=20of= 20Depth |Sender:=20; bh=Fuc/BIr9OAQr0LahphUyf9Ata8ClgIrwmmOUnuXTMHk=; b=r4UcSvbcAAX22ZGt/43UIFgq8LFrZi/HflLS48RSHkcx5NfLKi2/KPbfj9 vplHNQrQJ95lQinJx0juFdxK6zIEtQg3ZxFpvLln2P3INnTUMe87KL6npQca D2moREp9x2; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 03:59:43 -0000 Looks like a very good idea to me. JP. On Jul 28, 2009, at 5:44 PM, Matthew.Anderson@us.elster.com wrote: > > Instead of using the term depth, would the term rank be acceptable? > Reflects that each node is searching only for those with a higher rank > (well, a lower number, which reflects a higher rank), but doesn't > imply a > hop count. > > Matt > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jul 28 23:59:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCE23A6957 for ; Tue, 28 Jul 2009 23:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 0hpT21eFSuJl for ; Tue, 28 Jul 2009 23:59:09 -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 29B993A6907 for ; Tue, 28 Jul 2009 23:59:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIqQb0qrR7PE/2dsb2JhbAC8GIgnkB4FhBA X-IronPort-AV: E=Sophos;i="4.43,287,1246838400"; d="scan'208";a="180173403" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2009 06:59:10 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6T6xAGq012883; Tue, 28 Jul 2009 23:59:10 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n6T6x7ds020281; Wed, 29 Jul 2009 06:59:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 08:59:09 +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, 29 Jul 2009 08:59:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07DC26A2@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Another Term Instead of Depth Thread-Index: AcoQAQuku8Gx++e7TyitRJyXo/hhewAGPa9w References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , X-OriginalArrivalTime: 29 Jul 2009 06:59:09.0667 (UTC) FILETIME=[125BA330:01CA101A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=972; t=1248850750; x=1249714750; c=relaxed/simple; s=sjdkim4002; 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[Roll]=20Another=20Term=20Instead=20of= 20Depth |Sender:=20; bh=nQWg2U0zDbSKD4Y7RA1ZG03tJuvolXQNzGdz96IgYtE=; b=uEnatxEfDcK3EMx6prL2yFVPB6V7AMmNX5L0DsiAPiKeDc85c8bQaCuTG8 O28upehuCYJL74VUE3gV1OExPrVV+e/iCc74kGNPp+yq6TjVpeNCzvdvnO4V XTUDhtzTXK; Authentication-Results: sj-dkim-4; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 06:59:10 -0000 I love it. Thanks Matt. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) >Sent: mercredi 29 juillet 2009 06:00 >To: Matthew.Anderson@us.elster.com >Cc: roll@ietf.org >Subject: Re: [Roll] Another Term Instead of Depth > >Looks like a very good idea to me. > >JP. > >On Jul 28, 2009, at 5:44 PM, Matthew.Anderson@us.elster.com wrote: > >> >> Instead of using the term depth, would the term rank be acceptable? >> Reflects that each node is searching only for those with a higher rank >> (well, a lower number, which reflects a higher rank), but doesn't >> imply a >> hop count. >> >> Matt >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From engineer.umair@yahoo.com Wed Jul 29 00:09:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7DD3A6E8E for ; Wed, 29 Jul 2009 00:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cItRTm2sVjUG for ; Wed, 29 Jul 2009 00:09:40 -0700 (PDT) Received: from n22b.bullet.mail.mud.yahoo.com (n22b.bullet.mail.mud.yahoo.com [68.142.206.159]) by core3.amsl.com (Postfix) with SMTP id 032DB3A6E6C for ; Wed, 29 Jul 2009 00:09:39 -0700 (PDT) Received: from [68.142.200.221] by n22.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 07:09:40 -0000 Received: from [68.142.201.240] by t9.bullet.mud.yahoo.com with NNFMP; 29 Jul 2009 07:09:39 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 29 Jul 2009 07:09:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 979214.87810.bm@omp401.mail.mud.yahoo.com Received: (qmail 95500 invoked by uid 60001); 29 Jul 2009 07:09:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248851379; bh=LYEHhSCaubLSK0mhuD4LfQ4AERfOrHED8sImyLyE1a8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PkAngtPQ+Nqjk7ivdNkudTzZ6wrEU1Jyf257vw201zVbd5QXTzKNdTO9Cy9zeV+cDy6V2yGLasLfGdZE/NpxfZ3JtxJHCt72pUi5EEgF1ZbOUuT5GJBmMYJsfnpH1T57E85L7C1Thy+lt0TC9HKTyWfpUXb4HEW8bdr8ZCtw54E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RwuYrpg0e4s6KGdn8CoE4wnH9FhOLjTBnBvmBLjWoBkxf2VRjiVTKgtcb1cL/5dmtZFce0luFhfAQ16xnwZ59ZD8bgj36xbK6gTEoQwBT6mafHOkn/ZrIQPkAu20P418f2G2IqMn1fRhScaC70aj6pp/rd6qHpZn6RjA5B5B3e0=; Message-ID: <523090.93938.qm@web45516.mail.sp1.yahoo.com> X-YMail-OSG: c87vQdcVM1nrjUZcidRvF7z0slLAIQJe6twNHXDYBhN4.sFKO7E.kKu9YmiaaPpdgaiFdlqaRHZJTyD8P.xm821hzGUsNz48Z59eTlu.GWXD2BJ5ZzdJVGHjV.1G_wmt9_6aRskzz7tOx1WgU0J2DfJCsWO2nLYEQizNV6m5M5zjgnwe61OoSC9RJjfxfiafWt3yjYiRW6LxI9v_Y_ShetgLILPjfcizQpYQQaX5L8y2TOewW1aSHGdu2YerTxuPt.a3Ab73Ya4QoMSb7Vr_yE0UczC95V5LZZ0tBfZNpSs1sxei58TPcGjEQxpK4On9lyOywE7n5QqFUZ9wYMroNA-- Received: from [119.152.11.33] by web45516.mail.sp1.yahoo.com via HTTP; Wed, 29 Jul 2009 00:09:39 PDT X-Mailer: YahooMailClassic/6.0.19 YahooMailWebService/0.7.289.15 Date: Wed, 29 Jul 2009 00:09:39 -0700 (PDT) From: Umair Bussi To: "Pascal Thubert \(pthubert\)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC26A2@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: roll@ietf.org Subject: Re: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 07:09:41 -0000 It looks much better. --Umair --- On Wed, 7/29/09, Pascal Thubert (pthubert) wrote: > From: Pascal Thubert (pthubert) > Subject: Re: [Roll] Another Term Instead of Depth > To: "JP Vasseur (jvasseur)" , Matthew.Anderson@us.elster.com > Cc: roll@ietf.org > Date: Wednesday, July 29, 2009, 6:59 AM > I love it. Thanks Matt. > > Pascal > >-----Original Message----- > >From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] > On Behalf Of > JP Vasseur (jvasseur) > >Sent: mercredi 29 juillet 2009 06:00 > >To: Matthew.Anderson@us.elster.com > >Cc: roll@ietf.org > >Subject: Re: [Roll] Another Term Instead of Depth > > > >Looks like a very good idea to me. > > > >JP. > > > >On Jul 28, 2009, at 5:44 PM, Matthew.Anderson@us.elster.com > wrote: > > > >> > >> Instead of using the term depth, would the term > rank be acceptable? > >> Reflects that each node is searching only for > those with a higher > rank > >> (well, a lower number, which reflects a higher > rank), but doesn't > >> imply a > >> hop count. > >> > >> Matt > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jabeille@cisco.com Wed Jul 29 00:50:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7C93A6E89 for ; Wed, 29 Jul 2009 00:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.383 X-Spam-Level: X-Spam-Status: No, score=-9.383 tagged_above=-999 required=5 tests=[AWL=1.216, 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 lyVmHRTV7or9 for ; Wed, 29 Jul 2009 00:50:10 -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 536DD3A6E73 for ; Wed, 29 Jul 2009 00:50:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQAAEOcb0qQ/uCLe2dsb2JhbACaCgEBFiQGoU6IJ5AnBYQQ X-IronPort-AV: E=Sophos;i="4.43,288,1246838400"; d="scan'208";a="46033417" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 07:50:10 +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 n6T7oAuv024430; Wed, 29 Jul 2009 09:50:10 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6T7oAsi017846; Wed, 29 Jul 2009 07:50:10 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 09:50:10 +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, 29 Jul 2009 09:50:07 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A860369348E@xmb-ams-33d.emea.cisco.com> In-Reply-To: <008901ca0fa4$cb12a390$6137eab0$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoPoY1n6Ntpy4UKRbi3fKxvKcCTuAAAwZZAAB8jJrA= References: <008901ca0fa4$cb12a390$6137eab0$@sturek@att.net> From: "Julien Abeille (jabeille)" To: , "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 29 Jul 2009 07:50:10.0768 (UTC) FILETIME=[32EA9500:01CA1021] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1779; t=1248853810; x=1249717810; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=pxljW5XmTBMeZJPHgJpKaWD4zW4+UuAsZnPeb0CxTwU=; b=Dx2/o0AzeGhz1BT9/b6cLsYh/FWiBoP10L9jCPnmKFe5+P0ZZ+nFF5FuJW 8Ko1YSPx2w4tPLycw7mVREGr60209RFtLH9XgsiPPoFjF1wwvJHoskHQ9J4Q 0ouBckILcp; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 07:50:12 -0000 +1. Best, Julien=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Don Sturek > Sent: mardi 28 juillet 2009 19:00 > To: JP Vasseur (jvasseur); 'ROLL WG' > Subject: Re: [Roll] Moving forward with the protocol work >=20 > Hi JP, >=20 > I am in support of adopting the RPL proposal as the=20 > foundation for the ROLL routing protocol work. >=20 > Best Regards, >=20 > Don Sturek >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of JP Vasseur > Sent: Tuesday, July 28, 2009 9:34 AM > To: ROLL WG > Subject: [Roll] Moving forward with the protocol work >=20 > Dear WG, >=20 > First of all, thanks for all the time and energy you all have=20 > devoted during the past few weeks on the protocol work. There=20 > was excellent followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate=20 > foundation for the ROLL routing protocol work", there was=20 > clearly a good consensus in the WG meeting. It was also=20 > recognized there are still several open issues for which we=20 > WILL need help from many WG contributors, including the=20 > authors of other documents. >=20 > Could you please confirm (or not) the adoption of=20 > draft-dt-roll-rpl-01 as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From dominique.barthel@orange-ftgroup.com Wed Jul 29 00:51:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40523A6E7B for ; Wed, 29 Jul 2009 00:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 4CO3qv3U1Hsq for ; Wed, 29 Jul 2009 00:51:18 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 4193E3A6B99 for ; Wed, 29 Jul 2009 00:51:18 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 09:51:19 +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, 29 Jul 2009 09:47:13 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF49282B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another Term Instead of Depth Thread-Index: AcoPmr/5Ot1z2EVzR4W85wgV7uhWngAg/1FQ References: From: To: X-OriginalArrivalTime: 29 Jul 2009 07:51:19.0219 (UTC) FILETIME=[5BB76030:01CA1021] Subject: Re: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 07:51:19 -0000 Hi all=20 The mechanism makes me think of a trammel hook. A trammel hook allows to adjust the height of a cooking pot over a burning fire. It can easily be moved up, but needs both hands and good control to be moved down. See pictures at http://www.appaltree.net/aba/images/projects/REISIG-trammelhook2_small.j pg=20 http://upload.wikimedia.org/wikipedia/commons/d/da/Goemaer_detail_cremai llere.gif A better-known word for a similar behavior is "ratchet". But the motion is rotation instead of translation; because it cycles around, it is less illustrative of our mechanism. So, tongue in cheek, instead of "height", I suggest "THP" (Trammel Hook Position) ;-) Who wants to carry that idea further? Dominique=20 ------------------------------ Date: Tue, 28 Jul 2009 17:44:49 +0200 From: Matthew.Anderson@us.elster.com Subject: [Roll] Another Term Instead of Depth To: roll@ietf.org Message-ID: =09 =09 Content-Type: text/plain; charset=3DUS-ASCII Instead of using the term depth, would the term rank be acceptable? Reflects that each node is searching only for those with a higher rank (well, a lower number, which reflects a higher rank), but doesn't imply a hop count. Matt ------------------------------ From robert.power@ember.com Wed Jul 29 01:16:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C79B3A6D8F for ; Wed, 29 Jul 2009 01:16:18 -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 2jvvji89d+h2 for ; Wed, 29 Jul 2009 01:16:17 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 98B493A6CA7 for ; Wed, 29 Jul 2009 01:16:17 -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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jul 2009 04:16:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoPoZf+BX5xm4DmQvKdUAH2V0Qt2QAfyC2A References: From: "Robert Power" To: "JP Vasseur" , "ROLL WG" X-Mailman-Approved-At: Wed, 29 Jul 2009 01:17:23 -0700 Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:16:18 -0000 Hello JP & WG, While we all acknowledge that the draft-dt-roll-rpl-01 document is not complete, it is a solid framework and has the main elements that are required from the protocol and presents a solid document from which to move forward. =20 I think we all realize that the current P2P solution is non optimal and we will strive to improve it. In the networks we have deployed, the main traffic pattern is P2MP and I am satisfied that we have a solid solution there and am OK with us moving forward and committing to find a better P2P solution. I do believe that P2P can be improved within RPL and does not require an entirely new protocol.=20 In my opinion, moving this draft forward as a WG document is the best path forward to allow us to focus our efforts and drive toward completion. -regards, Bob > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of JP Vasseur > Sent: Tuesday, July 28, 2009 6:34 PM > To: ROLL WG > Subject: [Roll] Moving forward with the protocol work >=20 > Dear WG, >=20 > First of all, thanks for all the time and energy you all have=20 > devoted =20 > during the past few weeks on the protocol work. There was excellent =20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate=20 > foundation =20 > for the ROLL routing protocol work", there was clearly a good =20 > consensus in the WG meeting. It was also recognized there are still =20 > several open issues for which we WILL need help from many WG =20 > contributors, including the authors of other documents. >=20 > Could you please confirm (or not) the adoption of=20 > draft-dt-roll-rpl-01 =20 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From rcc@jennic.com Wed Jul 29 01:19:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E810B3A6ECF for ; Wed, 29 Jul 2009 01:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r84x3jvAMEIP for ; Wed, 29 Jul 2009 01:19:26 -0700 (PDT) Received: from mailhost.jennic.co.uk (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 8759A3A6EC4 for ; Wed, 29 Jul 2009 01:19:26 -0700 (PDT) Received: from jenpc629.jennic.com ([10.99.96.181]) by jendns02.jennic.com with esmtpa (Exim 4.60) (envelope-from ) id 1MW4Nh-0006Zp-Sy; Wed, 29 Jul 2009 09:19:26 +0100 Message-ID: <4A70060D.7070802@jennic.com> Date: Wed, 29 Jul 2009 09:19:25 +0100 From: Robert Cragie User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: dominique.barthel@orange-ftgroup.com References: <8E09C72DBC577D489F13A71228C0B7BF49282B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF49282B@ftrdmel0.rd.francetelecom.fr> X-Enigmail-Version: 0.96.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Another Term Instead of Depth X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:19:28 -0000 I like the word 'tier' as in ranked layer (not as in someone who ties something :-). It implies rank but adds a depth/height perspective as well and is numerically consistent with the concept of depth in the document.

Robert
Robert Cragie, Principal Engineer

Direct: +44 (0) 114 281 4512
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655   Confidential
_______________________________________________________________


dominique.barthel@orange-ftgroup.com wrote: 
Hi all 

The mechanism makes me think of a trammel hook.
A trammel hook allows to adjust the height of a cooking pot over a
burning fire.
It can easily be moved up, but needs both hands and good control to be
moved down.
See pictures at
http://www.appaltree.net/aba/images/projects/REISIG-trammelhook2_small.j
pg 
http://upload.wikimedia.org/wikipedia/commons/d/da/Goemaer_detail_cremai
llere.gif

A better-known word for a similar behavior is "ratchet". But the motion
is rotation instead of translation; because it cycles around, it is less
illustrative of our mechanism.

So, tongue in cheek, instead of "height", I suggest "THP" (Trammel Hook
Position) ;-)
Who wants to carry that idea further?

Dominique 

------------------------------
Date: Tue, 28 Jul 2009 17:44:49 +0200
From: Matthew.Anderson@us.elster.com
Subject: [Roll] Another Term Instead of Depth
To: roll@ietf.org
Message-ID:
	
<OFA92E6ABE.A2302424-ON85257601.0056034A-C1257601.00567F4B@gb.elster.com
  
	
Content-Type: text/plain; charset=US-ASCII


Instead of using the term depth, would the term rank be acceptable?
Reflects that each node is searching only for those with a higher rank
(well, a lower number, which reflects a higher rank), but doesn't imply
a hop count.

Matt
------------------------------
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
From dominique.barthel@orange-ftgroup.com Wed Jul 29 01:46:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9633A6EF7 for ; Wed, 29 Jul 2009 01:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YCKJ9fVwbsI for ; Wed, 29 Jul 2009 01:46:02 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C8AF13A6F2F for ; Wed, 29 Jul 2009 01:46:00 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 10:46:01 +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, 29 Jul 2009 10:43:33 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF49285F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with the protocol work Thread-Index: AcoPtci5cNnH/HV8SCevRJcbMi4tUgAbg3JA References: From: To: X-OriginalArrivalTime: 29 Jul 2009 08:46:01.0418 (UTC) FILETIME=[000F32A0:01CA1029] Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:46:02 -0000 Hi all, First I want to recognize the work of the Design Team at producing the RPL draft in a short time. I like many ideas in the draft, one of them being the distinction between building a structure, and routing on top of this structure (obviously the structure can advantageously be made to closely match the dominant traffic, such as convergecast). In the current version of the draft, I reckon there are still items that are debatable (how much of loop avoidance vs loop detection, and what algorithms), or even missing. Good P2P routing is certainly a missing one. As a personal opinion, I trust the whole WG, including obviously the DT, to come to a reasonnable and viable solution to this issue, especially in the situation where the spatial density of communicating pairs is limited, which is my understanding of LLN requirements. At this point, I don't see that _not_ adopting the draft as a WG document would accelerate or improve the situation in any way. I therefore support the adoption of the RPL draft as a Working Group document. Dominique ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Jul 2009 18:34:24 +0200 From: JP Vasseur Subject: [Roll] Moving forward with the protocol work To: ROLL WG Message-ID: Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; = delsp=3Dyes Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David ------------------------------ From samitac@ipinfusion.com Wed Jul 29 02:17:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009783A6FD3 for ; Wed, 29 Jul 2009 02:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY+MkG2MD3U4 for ; Wed, 29 Jul 2009 02:17:23 -0700 (PDT) Received: from smtp124.sbc.mail.re3.yahoo.com (smtp124.sbc.mail.re3.yahoo.com [66.196.96.97]) by core3.amsl.com (Postfix) with SMTP id 3FCD43A6FC7 for ; Wed, 29 Jul 2009 02:17:23 -0700 (PDT) Received: (qmail 81442 invoked from network); 29 Jul 2009 09:17:23 -0000 Received: from unknown (HELO samitacD630) (samitac@130.129.82.175 with login) by smtp124.sbc.mail.re3.yahoo.com with SMTP; 29 Jul 2009 09:17:22 -0000 X-YMail-OSG: KFwaj4kVM1kn61Ede4ZqFQoQom9M86XbFweC4.JsHe8OLW0skffrHImO6TqvE2lQ1C4NQl7Gn3ZHrVlhpik7hTNTfja2K0SjWgRNeC3EYFVAbT_eE3EOEfasPjpLmtl_qO0xPVij8qzBXfqvg..VkDmlWcYOzHGZMHJ0K4XnL4N.KmmGfvEMpVY8pLDXoy9zxEKS9Av8loUQWDRs7lJ70dG0.Z9z4Y9.oNJkb3uYPh4gYTD2J9qmyuzwS0o_WB9s635E67fWf4XQlsPJALs.0DXdA64qt_RkCZ7c2_8MSNZfl58- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'JP Vasseur'" , "'Mukul Goyal'" References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> In-Reply-To: <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> Date: Wed, 29 Jul 2009 02:17:19 -0700 Message-ID: <026c01ca102d$602216e0$206644a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoP/CKX/0d6jLuSRvuPxCtEZQw19QAL4/7g Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:17:25 -0000 Hi JP/David, Based on yesterdays presentations, it makes sense to me for RPL draft to move forward and work with DADR team to take advantage of their work on loop-detection and the cost based on historical information on packet forwarding. But, I am not sure if we want to adopt this as standards track wg document, as some of the ideas need more experiments to prove that would work correctly. But, I agree with Mukul that RPL draft has weaknesses and for that matter multiple protocol might be needed in the future. So, is it possible to adopt RPL-draft+some of DADR ideas as an experimental wg draft? Once we have more data on RPL design we can move that to standards track with changes based on test results? That way, we can make sure that the design is solid and the standard documentation will be a mature one. Thanks, -Samita > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Tuesday, July 28, 2009 8:25 PM > To: Mukul Goyal > Cc: ROLL WG > Subject: Re: [Roll] Moving forward with the protocol work > > Hi Mukul, > > I would really like to get your answer on whether you support the adoption > of RPL as good foundation to move forward, adopting it as a WG ID. Your > comments are extremely valid, see in line: > > On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: > > > Mischa, > > > > I am not speaking for Jerry but P2P flows are important in LLN > > applications I am familiar with (which happen to be in commercial > > building domain). I will have to go back to all the requirements > > drafts but I would be surprised if other domains will not benefit from > > an efficient P2P solution. > > > > The main question is why are we insisting on "one solution fits all" > > approach??? Why can't we recognize that different applications have > > different requirements and offer multiple solutions (including RPL). > > > > Let RPL be used by applications that find it useful but we should not > > force RPL as the only solution available. > > > > In my view, RPL has the following three shortcomings: > > > > 1) Does not offer optimal/good P2P routing > > 2) Does not allow destinations other than LBRs to be advertised. > > Note that this point and the previous one are independent. > > 3) Insistence on using DAG as the loop prevention mechanism. > > > > RPL is a good MP2P solution but we should not force it down the > > throats of people who want good P2P routing as well. > > > > IETF has a long history of offering multiple solutions for a given > > routing problem. We has multiple interior gateway protocols, multiple > > MANET solutions, multiple OSPF-MANET solutions. Why can't, and why > > should not, we have multiple ROLL solutions?? > > > > I asked this question to JP right at the time the ROLL WG got a new > > charter. The answer I got was - we will work on one solution for now > > but we do not exclude other solutions. > > > > I think ROLL should offer multiple solutions and let an application > > choose what fits it best. > > > > Few things: > > 1) The ROLL routing protocol will have to support a good solution for > P2P, this is a MUST requirement. For the time being a solution such as > RPL is optimized for P2MP and P2MP and does support P2P but that MUST > be improved. This was discussed and agreed yesterday during the WG > meeting and on the mailing list. Next step is to work on this and your > help will be greatly appreciated. > 2) The DT will reply but RPL support the advertisements of destination > other than LBRs > 3) Loop detection: fully agree, I had proposed myself a solution but > others may have other ideas. I personally think that this is one of > the areas where we can borrow some ideas also from the DADR proposal. > Again to be discussed on the list. > 4) With regards to having more protocols, we are chartered to design > one protocol for the time being. There is still lot of work to do, and > the solution will continue to evolve. It is thus premature to think > more than one protocol at this stage. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "Mischa Dohler" > > To: "Jerald P Martocci" > > Cc: "ROLL WG" > > Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central > > Subject: Re: [Roll] Moving forward with the protocol work > > > > Jerry, I am not sure this was already discussed at the meeting in > > person > > but I think we are a little in a catch22 situation here since - as far > > as I remember - none of the requirement docs explicitly required > > (MUST) > > p2p situations. I gather that the design team did take these documents > > as their working basis which is why p2p is not efficiently > > supported. In > > our urban requirements draft, we actually did go as far as saying that > > p2p should not be the main design thrust but rather the highly > > directional data flows towards a few sinks. Mischa. > > > > > > Jerald.P.Martocci@jci.com wrote: > >> > >> I cannot yet affirm RPL as a working group draft since it hasn't yet > >> stated how P2P communication will operate within the DAG. > >> > >> As I have noted in my review comments, connectivity to every node > >> within > >> the DAG is not assured. The traffic patterns within the LLN are also > >> suspect since most packets must travel upward toward the LBR before > >> finding their intended destination lower in the DAG. This imbalance > >> will create network traffic congestion in the higher layers of the > >> DAG. > >> Hopping many hops up the DAG and back down the DAG to talk to a node > >> that is in direct radio range seems totally inefficient. > >> > >> Latency and convergence time are also a concern. However, I can wait > >> for simulation or implementations to ferret out these issues. > >> > >> Regards, > >> > >> Jerry Martocci > >> > >> > >> > >> > >> > >> *JP Vasseur * > >> Sent by: roll-bounces@ietf.org > >> > >> 07/28/2009 11:36 AM > >> > >> > >> To > >> ROLL WG > >> cc > >> > >> Subject > >> [Roll] Moving forward with the protocol work > >> > >> > >> > >> > >> > >> > >> > >> > >> Dear WG, > >> > >> First of all, thanks for all the time and energy you all have devoted > >> during the past few weeks on the protocol work. There was excellent > >> followup discussion at the physical WG meeting. > >> > >> To the question "Do you think that RPL provides an adequate > >> foundation > >> for the ROLL routing protocol work", there was clearly a good > >> consensus in the WG meeting. It was also recognized there are still > >> several open issues for which we WILL need help from many WG > >> contributors, including the authors of other documents. > >> > >> Could you please confirm (or not) the adoption of draft-dt-roll- > >> rpl-01 > >> as a WG document ? > >> > >> Then we will of course move to the next step. > >> > >> Thanks, > >> > >> JP and David > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Wed Jul 29 02:19:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570E53A67B8 for ; Wed, 29 Jul 2009 02:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 O-AuWouuo1gq for ; Wed, 29 Jul 2009 02:19:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 76D0D3A6FAA for ; Wed, 29 Jul 2009 02:18:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQAAFuxb0qQ/uCLe2dsb2JhbACaCgEBFiQGoCmIJ5AsBYQQ X-IronPort-AV: E=Sophos;i="4.43,288,1246838400"; d="scan'208";a="46046331" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 09:18:55 +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 n6T9IuRs023115 for ; Wed, 29 Jul 2009 11:18:56 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6T9It9s020954 for ; Wed, 29 Jul 2009 09:18:55 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 11:18: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, 29 Jul 2009 11:18:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoPoZFpfnG+Z0v0RGatrx81tkmYAgAhsF3g References: From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 29 Jul 2009 09:18:56.0030 (UTC) FILETIME=[990513E0:01CA102D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2211; t=1248859136; x=1249723136; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdurvy@cisco.com; z=From:=20=22Mathilde=20Durvy=20(mdurvy)=22=20 |Subject:=20RE=3A=20[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=fMsmMtPZ3tDxbZ6vUt84+OVHwDBhvdF3me+hrkv3G8g=; b=C+/danO6onXSj9y5iCHQfcw+TBIVQkLVbWeRAlHuXppGCN6pEhkPQKHt7t bZ03yBdfVyr70OlXj/fv6Uh6i5Q9USytd+neF2y1bebKxD/c41SIa+Keoaj/ rH6ifvnnuI; Authentication-Results: ams-dkim-2; header.From=mdurvy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:19:06 -0000 Hi JP, All, I also support the RPL proposal as the foundation for the ROLL routing protocol work.=20 I think the current RPL proposal is very promising and we should all work towards improving it. Maybe a good start would be to better highlight the key basic mechanisms on which RPL is based in order to propose a simple foundation layer on which to build and solve the remaining issues. I would personally want to see more discussion on 3 topics where I'm still not fully convinced: - the role of siblings: this adds quite some extra complexity to the routing but what does it really bring in practice? - if the choice of possible metrics is specified in the metric draft, why not impose the right conditions on these metrics so that we can base the DAG construction and the loop avoidance on a single metric rather than have a separate hop count or depth? - interaction between timers: I'm thinking in particular of the interaction of the RA timers and the DAG hop timers. In the loop avoidance example given by Jonathan yesterday can we guarantee the right sequencing of RA / DAG Hop timer firing? Best, Mathilde =20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: mardi, 28. juillet 2009 18:34 To: ROLL WG Subject: [Roll] Moving forward with the protocol work Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From laurent.toutain@gmail.com Wed Jul 29 02:27:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5462A3A6F8A for ; Wed, 29 Jul 2009 02:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7U9rAo8GG02 for ; Wed, 29 Jul 2009 02:27:52 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id EF7223A6F65 for ; Wed, 29 Jul 2009 02:27:51 -0700 (PDT) Received: by fxm18 with SMTP id 18so263939fxm.37 for ; Wed, 29 Jul 2009 02:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=B8ODoSjoB5f8we5ugO4gTwWzDU+M9aQzNxb7ixdBQLQ=; b=TSCruaPRDUWtyqWxhjOay5SDyvHwQln0gY3t5L077E24iP73v571rzA22SWNiNiDDs BiN6sGd//NAYo6V+AT6iwBlpRxxkzUTV9E9dVVivESAJin5mKD5V2ddEy2z3H2Ktqmf4 Ok7ciw8rg8sIwCpxMRzXKkn2zuGpfuFnP9vRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=nUlkiNyYrlBxdD4vd5AKFpPysbWtYPKWxOPiFFj7CK17iZgLuOxpajNp79mom06hK0 Iq/WRJSXanzBjxHRKmfhZox4TmGQ8UlS5flf5LEdbGpShnj5j08cNFQEDEQz3qr/nt+w ZhApBXZJS9Jk03uAL+zPI7QglPhX1zM9iJ/Dg= MIME-Version: 1.0 Sender: laurent.toutain@gmail.com Received: by 10.223.105.139 with SMTP id t11mr4004335fao.37.1248859671157; Wed, 29 Jul 2009 02:27:51 -0700 (PDT) In-Reply-To: References: From: Laurent Toutain Date: Wed, 29 Jul 2009 11:27:31 +0200 X-Google-Sender-Auth: 04a3f723105964af Message-ID: <147a29c80907290227m6dc7d36fq252ac43c790b3@mail.gmail.com> To: "Mathilde Durvy (mdurvy)" Content-Type: multipart/alternative; boundary=00504502b07912dbc6046fd4cdc6 Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:27:53 -0000 --00504502b07912dbc6046fd4cdc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I agree, sibling can be viewed as an exception to RPL. P2P routing can be viewed the same way. We need a common protocol to guaranty interoperability between the nodes and RPL can be this protocol. When a group of node wants a different behavior, another routing protocol can be used. I'm also in favor to push RPL as a wg document. Laurent On Wed, Jul 29, 2009 at 11:18, Mathilde Durvy (mdurvy) wrote: > Hi JP, All, > > I also support the RPL proposal as the foundation for the ROLL routing > protocol work. > > I think the current RPL proposal is very promising and we should all > work towards improving it. Maybe a good start would be to better > highlight the key basic mechanisms on which RPL is based in order to > propose a simple foundation layer on which to build and solve the > remaining issues. > > I would personally want to see more discussion on 3 topics where I'm > still not fully convinced: > - the role of siblings: this adds quite some extra complexity to the > routing but what does it really bring in practice? > - if the choice of possible metrics is specified in the metric draft, > why not impose the right conditions on these metrics so that we can base > the DAG construction and the loop avoidance on a single metric rather > than have a separate hop count or depth? > - interaction between timers: I'm thinking in particular of the > interaction of the RA timers and the DAG hop timers. In the loop > avoidance example given by Jonathan yesterday can we guarantee the right > sequencing of RA / DAG Hop timer firing? > > Best, > Mathilde > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur (jvasseur) > Sent: mardi, 28. juillet 2009 18:34 > To: ROLL WG > Subject: [Roll] Moving forward with the protocol work > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --00504502b07912dbc6046fd4cdc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I agree, sibling can be viewed as an exception= to RPL. P2P routing can be viewed the same way. We need a common protocol = to guaranty interoperability between the nodes and RPL can be this protocol= . When a group of node wants a different behavior, another routing protocol= can be used. I'm also in favor to push RPL as a wg document.

Laurent

On Wed, Jul 29, 20= 09 at 11:18, Mathilde Durvy (mdurvy) <mdurvy@cisco.com> wrote:
Hi JP, All,

I also support the RPL proposal as the foundation for the ROLL routing
protocol work.

I think the current RPL proposal is very promising and we should all
work towards improving it. Maybe a good start would be to better
highlight the key basic mechanisms on which RPL is based in order to
propose a simple foundation layer on which to build and solve the
remaining issues.

I would personally want to see more discussion on 3 topics where I'm still not fully convinced:
- the role of siblings: this adds quite some extra complexity to the
routing but what does it really bring in practice?
- if the choice of possible metrics is specified in the metric draft,
why not impose the right conditions on these metrics so that we can base the DAG construction and the loop avoidance on a single metric rather
than have a separate hop count or depth?
- interaction between timers: I'm thinking in particular of the
interaction of the RA timers and the DAG hop timers. In the loop
avoidance example given by Jonathan yesterday can we guarantee the right sequencing of RA / DAG Hop timer firing?

Best,
Mathilde


-----Original Message-----
From: roll-bounces@ietf.org [m= ailto:roll-bounces@ietf.org] O= n Behalf Of
JP Vasseur (jvasseur)
Sent: mardi, 28. juillet 2009 18:34
To: ROLL WG
Subject: [Roll] Moving forward with the protocol work

Dear WG,

First of all, thanks for all the time and energy you all have devoted
during the past few weeks on the protocol work. There was excellent
followup discussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation=
for the ROLL routing protocol work", there was clearly a good consensu= s
in the WG meeting. It was also recognized there are still several open
issues for which we WILL need help from many WG contributors, including
the authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
as a WG document ?

Then we will of course move to the next step.

Thanks,

JP and David


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--00504502b07912dbc6046fd4cdc6-- From teco@inf-net.nl Wed Jul 29 02:57:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAF03A68D7 for ; Wed, 29 Jul 2009 02:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 08ZzAbasW417 for ; Wed, 29 Jul 2009 02:57:09 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 365383A68C6 for ; Wed, 29 Jul 2009 02:57:08 -0700 (PDT) Received: (qmail 29768 invoked from network); 29 Jul 2009 11:57:08 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 29 Jul 2009 11:57:08 +0200 From: "Teco Boot" To: "'JP Vasseur'" , "'ROLL WG'" References: In-Reply-To: Date: Wed, 29 Jul 2009 11:56:36 +0200 Message-ID: <013101ca1032$eec15fa0$cc441ee0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPogz1Vy2X2ruBQ8O128o0u45zhAAjfOOw Content-Language: nl Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:57:10 -0000 Hi JP, WG, I support the adoption of RPL as WG document. I'll sync up with my work on Autoconf, I think I have some improvements, ready for stealing. For example, I suggested multi-path routing based on source address. This brings in address generation and address selection. This is not work for ROLL, but ROLL should provide the routing building blocks for multi-path. As RPL provides a DAG, this is doable. Regards, Teco. |-----Oorspronkelijk bericht----- |Van: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] Namens JP |Vasseur |Verzonden: dinsdag 28 juli 2009 18:34 |Aan: ROLL WG |Onderwerp: [Roll] Moving forward with the protocol work | |Dear WG, | |First of all, thanks for all the time and energy you all have devoted |during the past few weeks on the protocol work. There was excellent |followup discussion at the physical WG meeting. | |To the question "Do you think that RPL provides an adequate foundation |for the ROLL routing protocol work", there was clearly a good |consensus in the WG meeting. It was also recognized there are still |several open issues for which we WILL need help from many WG |contributors, including the authors of other documents. | |Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 |as a WG document ? | |Then we will of course move to the next step. | |Thanks, | |JP and David | | |_______________________________________________ |Roll mailing list |Roll@ietf.org |https://www.ietf.org/mailman/listinfo/roll From tzeta.tsao@ekasystems.com Wed Jul 29 03:06:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106903A6F55 for ; Wed, 29 Jul 2009 03:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzbMyjkyK4D4 for ; Wed, 29 Jul 2009 03:06:49 -0700 (PDT) Received: from web1212.biz.mail.gq1.yahoo.com (web1212.biz.mail.gq1.yahoo.com [67.195.14.59]) by core3.amsl.com (Postfix) with SMTP id 6423E3A6F38 for ; Wed, 29 Jul 2009 03:06:49 -0700 (PDT) Received: (qmail 47281 invoked by uid 60001); 29 Jul 2009 10:06:47 -0000 Message-ID: <865060.45598.qm@web1212.biz.mail.gq1.yahoo.com> X-YMail-OSG: NGw04hcVM1l5dnj1KhS.QH7XEreFIMmju.piZneQ3yyePSXVk74fyzJ8aznuGth78eHNG6T.rH4L66QaergvxiIJ.jeH4pVYrZxHt8d.DWP51Dc7M_LFf8Zvuh3G2_Hk1nL89TOjyb1A518wpLXwewM359fXcnx5m4P.U8C5pc3WYv2360hTjUFFhCobAMKS3JULvgu603z5om0HVIL3rsQtGB6L5FiTaHmTYRJ0lChLSAMpUOOSbELXll.wdfDgPew.0yT0RGy8lKw.OPWeQBHa0crUp3CwzAOEq.IoYdk- Received: from [192.36.80.8] by web1212.biz.mail.gq1.yahoo.com via HTTP; Wed, 29 Jul 2009 03:06:47 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.10 References: Date: Wed, 29 Jul 2009 03:06:47 -0700 (PDT) From: Tzeta Tsao To: JP Vasseur , ROLL WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 10:06:50 -0000 Hi JP, WG, I am in favor of adopting the protocol draft as the WG document. As expressed during the presentation, this move will give incentive for people to start experimenting and provide "real world" experience feedback. Regards, Tzeta ----- Original Message ---- From: JP Vasseur To: ROLL WG Sent: Tuesday, July 28, 2009 12:34:24 PM Subject: [Roll] Moving forward with the protocol work Dear WG, First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ? Then we will of course move to the next step. Thanks, JP and David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From teco@inf-net.nl Wed Jul 29 03:14:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035B53A6EF1 for ; Wed, 29 Jul 2009 03:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvj11O7Imo5R for ; Wed, 29 Jul 2009 03:14:44 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 0626A3A69EC for ; Wed, 29 Jul 2009 03:14:43 -0700 (PDT) Received: (qmail 15485 invoked from network); 29 Jul 2009 12:14:41 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 29 Jul 2009 12:14:41 +0200 From: "Teco Boot" To: "'Pascal Thubert \(pthubert\)'" , "'Mukul Goyal'" , "'Jonathan Hui'" References: <1732864908.3947031248137887086.JavaMail.root@mail02.pantherlink.uwm.edu> <1660661554.3947721248138169244.JavaMail.root@mail02.pantherlink.uwm.edu> <7892795E1A87F04CADFCCF41FADD00FC07DC240E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC240E@xmb-ams-337.emea.cisco.com> Date: Wed, 29 Jul 2009 12:14:08 +0200 Message-ID: <013201ca1035$62a65720$27f30560$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoJnwl7b5dU7TFTTwOTFCDUlx6txQF360KQAC0nDcA= Content-Language: nl Cc: 'roll' Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV routing not using DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 10:14:46 -0000 If in a frozen state, a new RA-DIO (higher sequence number) helps to realign the DAG. One idea is asking the DAG root for it. Of course we need jitter here, or another mechanism for not initiating a RA-DIO requests storm. I can think of a multi-hop RS for the RA-DIO request, with DAG root as destination address. Teco. |-----Oorspronkelijk bericht----- |Van: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] Namens Pascal |Thubert (pthubert) |Verzonden: dinsdag 28 juli 2009 14:44 |Aan: Mukul Goyal; Jonathan Hui |CC: roll |Onderwerp: Re: [Roll] A simple loop avoidance mechanism for use in P2P |DV routing not using DAGs | |Hi Mukul: | |We can certainly improve that text. As you figured, the main goal of the |DAG hop timer and associated held up state is to smoothly merge DAGs. |Say a floating DAG can be merged back in a grounded DAG. If nodes could |attach to the grounded DAG in any order, there would be churn as other |nodes joining enable new better positions for nodes that already joined |(too quickly). The delay enables nodes that can join higher to join |first, so the joining spreads like a ave in the floating DAG. | |The second "goal" is more like a side effect. If we do not use the |sequence to protect completely against loops, then RA loss might |actually cause a node that detached from a DAG to reattach to a node in |its subDAG that was not aware anything happened, effectively creating a |loop. The delay here gives more chances for successive RA waves to |propagate to all nodes in the subDAG and avoid that situation. | |On the side, I'd note that there is a general tendency in this working |group to favor approaches that are be less strict at avoiding loops and |more clever at detecting them on the data flows (see Phil's mails, the |DADR proposal, CTP). Data flow loop detection is also needed to block |sibling loops which can happen with the current RPL draft (by design), |and the DADR detection would be a nice addition there. If we decide to |tweak RPL along those lines, we might decide to remove the sequence |totally, or make it optional. | |Pascal | |>-----Original Message----- |>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of |Mukul Goyal |>Sent: mardi 21 juillet 2009 03:03 |>To: Jonathan Hui |>Cc: roll |>Subject: Re: [Roll] A simple loop avoidance mechanism for use in P2P DV |routing not using DAGs |> |>Hi Jonathan, |> |>I am not sure how does the "Held-up" mechanism cover the loop avoidance |scheme I described. I seem to be |>missing some thing. Here is my understanding of the "held-up" mechanism |described in RPL: |> |>Section 5.3.3.1 in RPL draft states two purposes for the "Held-Up" |state: |> |>1. "Delay the reattachment of a sub-DAG that has been forced to |> detach. This is not as safe as the use of the sequence, but |still |> covers that when a sub-DAG has detached, the Router Advertisement |> - DAG Information Option that is initiated by the new DAG root |has |> a chance to spread outward along the sub-DAG so that two |different |> DAGs have formed." |> |>I did not understand the text quoted above at all. Please clarify. I |did not find any additional text in RPL |>draft that further describes the use of "held-up" state in this |context. |> |>2. The second purpose of the "held-up" state, which I think I |understand clearly, is to delay a node's joining |>of a new DAG to try to ensure that: |>a) a node joins the new DAG at the minimum possible depth; |>b) among the neighbor/nearby nodes trying to join the new DAG, the |nodes join the new DAG roughly in order of |>their depth in the new DAG. |>To achieve these objectives, a node keeps a potential parent in the new |DAG in the "held-up' state for a time |>duration proportional to the potential parent's depth in that DAG. For |every new potential parent, the node |>starts a new "held-up" state timer (the hop timer). The node joins the |new DAG via the first potential parent |>coming out of the "held-up" state. |> |>On the other hand, the loop avoidance mechanism I described puts a node |in the "loop avoidance" state when the |>current nexthop/parent is no longer good enough. Rather than |immediately choosing a different parent (based on |>potentially erroneous costs currently being advertised by neighbors), |the node advertises (via special |>_marked_ advertisements) its new cost through the current parent for |the duration it is in the "loop |>avoidance" state. On receiving these _marked_ advertizements, the |node's children enter the "loop avoidance" |>state as well and further propagate the new cost information. The idea |is that, by the time the node comes out |>of the "loop avoidance" state, hopefully all its neighbors would have |corrected their cost estimates if the |>previous estimates were based on the old costs. So, on coming out of |the "loop avoidance" state, when the node |>selects its new parents, it does not cause a routing loop or a "count |to infinity" situation. |> |>>2) What is the effect of packet loss? |>>- If node B is a descendant of A and B misses the advertisement from |>>its parent, then A may attach to B or any of its descendants. In a |>>sufficiently dense network, there's a fairly high probability that |>>some node B will miss the advertisement from A (even with |>>retransmissions). On the flip side, those that properly hear the new |>>cost values are likely not to be involved in any loops. In summary, |>>Count-to-Infinity still exists but arguably with only a subset of |nodes. |> |>I agree. The efficacy of the solution depends on the probability of |_neighbor_ descendants (i.e. descendants |>that are neighbors as well) receiving the new cost information and |updating their cost advertisements based on |>this information. This probability in turn depends on parameters like |the probability of advertisement loss, |>the duration of the "loop avoidance" state, the number of times a node |sends out advertisements while in this |>state, the children tree topology etc. |> |>Regards |>Mukul |> |> |> |>On Jul 14, 2009, at 4:46 AM, Mukul Goyal wrote: |> |>> Hi all |>> |>> Here is a simple loop avoidance mechanism that can be used in a P2P |>> routing solution that does not use DAGs. |>> |>> Thanks |>> Mukul |>> |>> In DV protocols, the routing loops are triggered when the cost to |>> reach a destination via the current next hop increases so much that |>> a new next hop needs to be selected. |>> |>> Suppose, a node, B, determines that its current next hop, A, for a |>> destination, X, may no longer be the best ("minimum cost") neighbor |>> to forward packets to. Such determination could be based on an |>> increase in the link cost to node A or the receipt of a new |>> advertisement from node A showing an increased cost to reach the |>> destination X. |>> |>> In case of such an event, node B should not choose a new next hop |>> immediately. This is because the current cost advertisements by its |>> neighbors, as well as any new advertisements generated in the |>> immediate aftermath of the event, may be based on node B's erstwhile |>> cost to reach the destination. Immediate selection of a new next hop |>> based on the current or new cost advertisements by the neighbors may |>> lead to a routing loop and a "count to infinity" situation. |>> |>> Rather, node B should initiate the propagation of new cost |>> information down the tree (of nodes for whom it currently lies on |>> the route to X)and wait for some time before calculating its new |>> next hop. The hope is that by the time the node calculates its new |>> next hop, its increased cost along the current next hop is known to |>> all its neighbors and they have generated new advertisements if |>> their previous advertisements were based on the old cost of node B |>> to reach X. |>> |>> So, when node B determines that its current next hop A for |>> destination X is no longer the best neighbor to forward packets to, |>> it generates a new specially _marked_ advertisement that lists node |>> B's new cost to reach X via A, the current next hop. |>> |>> The generation of a _marked_ advertizement regarding destination X |>> puts the node in the "loop avoidance" state for a time period during |>> which the node can neither change its next hop to destination X nor |>> generate a regular advertisement for the destination X. |>> |>> All nodes that receive node B's _marked_ advertisement regarding |>> destination X update their cost to reach X via B. If a node |>> currently considers node B as its next hop to destination X, it |>> additionally does the following: |>> 1. it enters the "loop avoidance" state and hence consequently keeps |>> node B as its next hop to X |>> 2. originates a _marked_ advertizement listing its new cost to |>> destination X via node B |>> |>> Once a node exits the "loop avoidance" state, it is allowed to |>> select a new next hop to X and generate a regular advertisement |>> listing its new cost to X. |>> |>> Here is an example showing the efficacy of this proposal: |>> |>> X |>> | |>> A |>> / \ |>> B-C |>> / \ |>> D E |>> \ / |>> F |>> |>> X is the destination. |>> |>> Suppose all unidirectional link costs are 1 except the following: B- |>> >C:5, B->D:5 and E->B:5 |>> |>> Accordingly, the routes are as follows: C->A->X and E->F->D->B->A->X |>> |>> and node B's perceived cost to reach X via each neighbor is as |>> follows: |>> via A:2, via C:7, via D:8, via E:6 |>> |>> Suppose the cost of link B->A changes to 100. |>> |>> In a simple DV protocol, B's cost to reach X via A becomes 101 and |>> hence it immediately chooses E as the next hop (declaring its new |>> cost to X as 6), thereby creating routing loop B->E->F->D->B and a |>> "count to infinity" situation. |>> |>> Under the proposed protocol, B would generate a _marked_ |>> advertisement listing its cost to X as 101 and enter the "loop |>> avoidance" state. This _marked_ advertisement is received by A, C, D |>> and E. Since D considers B as its next hop to X, it enters the "loop |>> avoidance" state as well and generates its own _marked_ |>> advertisement listing its cost to X as 102. |>> |>> On receiving this advertisement, node F enters the "loop avoidance" |>> state and generates its own _marked_ advertisement listing its cost |>> to X as 103. |>> |>> On receiving this advertisement, node E enters the "loop avoidance" |>> state and generates its own _marked_ advertisement listing its cost |>> to X as 104. |>> |>> If node B comes out of the "loop avoidance" state only after the |>> receipt of this advertisement from E, B would correctly choose node |>> C as its new next hop to X and generate a new advertisement listing |>> its cost to X as 7. When nodes D, F and E come out of the "loop |>> avoidance" state, they would ultimately update their cost to X to |>> 8, 9 and 10 respectively without any loops. |>> |>> This policy does cause a delay in convergence. Suppose B->C cost is |>> 1 in the example above. B enters the "loop avoidance" state when |>> cost of link B->A changes to 100. Node B would not select C as next |>> hop (and advertize a cost 3 to X) until it comes out of the "loop |>> avoidance" state. |>> _______________________________________________ |>> Roll mailing list |>> Roll@ietf.org |>> https://www.ietf.org/mailman/listinfo/roll |> |>_______________________________________________ |>Roll mailing list |>Roll@ietf.org |>https://www.ietf.org/mailman/listinfo/roll |_______________________________________________ |Roll mailing list |Roll@ietf.org |https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Wed Jul 29 04:15:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA2D3A68C9 for ; Wed, 29 Jul 2009 04:15:33 -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 WvPdx+yLtTns for ; Wed, 29 Jul 2009 04:15:32 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 43CA33A6FEE for ; Wed, 29 Jul 2009 04:15:31 -0700 (PDT) Received: from dhcp-54ed.meeting.ietf.org (dhcp-54ed.meeting.ietf.org [130.129.84.237] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n6TBF3hn021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 14:15:13 +0300 Message-ID: <4A702F34.1030303@sensinode.com> Date: Wed, 29 Jul 2009 14:15:00 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:15:33 -0000 I am in favor! JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://www.sensinode.com 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 richard.kelsey@ember.com Wed Jul 29 04:23:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1709B3A6F8D for ; Wed, 29 Jul 2009 04:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 M+Q3uYax+WbQ for ; Wed, 29 Jul 2009 04:23:28 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 56E183A68C9 for ; Wed, 29 Jul 2009 04:23:28 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:23:46 -0400 Date: Wed, 29 Jul 2009 07:23:49 -0400 Message-Id: <87ws5rvika.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Tue, 28 Jul 2009 18:34:24 +0200) From: Richard Kelsey References: X-OriginalArrivalTime: 29 Jul 2009 11:23:46.0785 (UTC) FILETIME=[09DB9510:01CA103F] Cc: roll@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:23:29 -0000 Hi JP, All, I also support the adoption of draft-dt-roll-rpl-01 as a WG document, while acknowledging that there is still a lot of work to do on P2P and loop detection. -Richard Kelsey From ryusuke.masuoka@us.fujitsu.com Wed Jul 29 04:24:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23283A6FEE for ; Wed, 29 Jul 2009 04:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk-kUYvgviak for ; Wed, 29 Jul 2009 04:24:04 -0700 (PDT) Received: from fujitsu1.fujitsu.com (fujitsu1.fujitsu.com [192.240.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E793A6FBD for ; Wed, 29 Jul 2009 04:23:34 -0700 (PDT) Received: from fujitsu1.fujitsu.com (localhost [127.0.0.1]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6TBNYnW006705 for ; Wed, 29 Jul 2009 04:23:34 -0700 (PDT) Received: from mailserv1.fla.fujitsu.com (mailserv1.fla.fujitsu.com [128.8.244.161]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6TBNXum006690 for ; Wed, 29 Jul 2009 04:23:34 -0700 (PDT) Received: from FLACPR8Y053PC (dhcp-10da.meeting.ietf.org [130.129.16.218]) (authenticated bits=0) by mailserv1.fla.fujitsu.com (8.13.8/8.13.8) with ESMTP id n6TBNUZf010665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 29 Jul 2009 07:23:32 -0400 From: "Ryusuke Masuoka" To: References: <8E09C72DBC577D489F13A71228C0B7BF49285F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF49285F@ftrdmel0.rd.francetelecom.fr> Date: Wed, 29 Jul 2009 07:23:28 -0400 Organization: Fujitsu Laboratories of America, Inc. Message-ID: <00e701ca103f$0094db60$01be9220$@masuoka@us.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPtci5cNnH/HV8SCevRJcbMi4tUgAbg3JAAAJs6AA= Content-Language: en-us Subject: [Roll] Data Is NOT Retained at the Node in DADR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryusuke.masuoka@us.fujitsu.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:24:04 -0000 Hi, Thank you very much for letting us present DADR at the ROLL meeting yesterday (7/28). I have to apologize for giving you misinformation about DADR during one of Q&A's and let me provide you the correct information. It is about data retention at a node. The data is retained at the node until it is made sure the data is sent to the next hop (through ACK). However, the data is dropped and will NOT be kept at the node after it is made sure that the data is transmitted to the next hop. Only its packet ID is kept for some period for loop detection and backtracking purposes. When the data returns to the node for some reason (and the node knows it because it keeps packet IDs for some time), the node will use the newly received data to forward to other nodes if necessary. ----- This is probably preaching to the quire, but data reachability is one of the most important requirements for our DADR implementation. Some applications such as a smart metering need a stable operation of the social infrastructure to have customer confidence and there is financial aspect tied directly into data reachability. In such applications, we are typically required to guarantee data reachability from hundreds of nodes to a gateway within a very narrow time window. It may be of Japanese culture, but customers generally give very stringent requirements and expect implementers to take quite large responsibility. ----- Regards, Ryu From roger.alexander@ekasystems.com Wed Jul 29 04:30:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D846D3A6B93 for ; Wed, 29 Jul 2009 04:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IFoe1u19Q9z for ; Wed, 29 Jul 2009 04:30:03 -0700 (PDT) Received: from web1214.biz.mail.gq1.yahoo.com (web1214.biz.mail.gq1.yahoo.com [67.195.14.61]) by core3.amsl.com (Postfix) with SMTP id 1531E3A6A73 for ; Wed, 29 Jul 2009 04:30:03 -0700 (PDT) Received: (qmail 80753 invoked by uid 60001); 29 Jul 2009 11:30:02 -0000 Message-ID: <916640.80101.qm@web1214.biz.mail.gq1.yahoo.com> X-YMail-OSG: 5AaxbFYVM1n_JLjqRh3rUW6yoSU.Bw.sHjIkY98kKjlEOj2a1mSb0zRls3WRbHsCiyHO2SZNO.aGZXvTwaOzctd7p37rT.l445Ia7r7e1Oh_rB6L.xCeBIx_MYIT5CaaiPMGah7pXzKyv8SQcQji76aB_OotS0Ibo9GnFZMbYGiJ_HKiTx16uo9eVtJQfhdlZWDGQiMD5wG4tQ28eNM.q2HeIsgODVzlyaSqUIo4Pk9zhPhq8Ib7q2lbiDp9Tfbi3gMH2pynyoB0F_npsXtVWPfroD01teVwI_9YRJxYsOs5S_vk Received: from [130.129.19.167] by web1214.biz.mail.gq1.yahoo.com via HTTP; Wed, 29 Jul 2009 04:30:02 PDT X-Mailer: YahooMailClassic/6.0.19 YahooMailWebService/0.7.289.10 Date: Wed, 29 Jul 2009 04:30:02 -0700 (PDT) From: Roger Alexander To: ROLL WG , JP Vasseur MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:30:06 -0000 Hi JP, WG, RPL's DAG structure provides a good base for scalable, reliable routing in an urban radio environment. There is a need for further evaluation and refinement of the loop avoidance elements, particularly related to the freezing of the sub-DAG and the associated triggered multicasts of RA-DIO across the sub-DAG. Nonetheless, the protocol provides sufficient, understood core elements to be adopted by the WG for further development towards a standard for L2Ns. I do also believe some attention should be paid to addressing enhanced P2P routing but agree that this should be incorporated within the RPL base. Roger Alexander --- On Tue, 7/28/09, JP Vasseur wrote: > From: JP Vasseur > Subject: [Roll] Moving forward with the protocol work > To: "ROLL WG" > Date: Tuesday, July 28, 2009, 4:34 PM > Dear WG, > > First of all, thanks for all the time and energy you all > have devoted during the past few weeks on the protocol work. > There was excellent followup discussion at the physical WG > meeting. > > To the question "Do you think that RPL provides an adequate > foundation for the ROLL routing protocol work", there was > clearly a good consensus in the WG meeting. It was also > recognized there are still several open issues for which we > WILL need help from many WG contributors, including the > authors of other documents. > > Could you please confirm (or not) the adoption of > draft-dt-roll-rpl-01 as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From hamid.mukhtar@gmail.com Wed Jul 29 04:32:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC533A67B4 for ; Wed, 29 Jul 2009 04:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwMTFYYU0EoK for ; Wed, 29 Jul 2009 04:32:55 -0700 (PDT) Received: from mail-yx0-f183.google.com (mail-yx0-f183.google.com [209.85.210.183]) by core3.amsl.com (Postfix) with ESMTP id 9B6853A6ED2 for ; Wed, 29 Jul 2009 04:32:55 -0700 (PDT) Received: by yxe13 with SMTP id 13so1365978yxe.29 for ; Wed, 29 Jul 2009 04:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=oV0q79hN12mTZQ/Ia+sMOTYTdSpi1oFJxId6CaqpFw0=; b=b5rudb8It7dZdALFdIPwI2BNZlct2GBH9C3AAOrpzXWw5xkdVyA+FuysgcqYLbNYT0 T5iNMxRe5xnc2HIP/Xrz9G4xHRs2XUlN60ave8p4jCikQ5BW75qEOdeUlf0RkhXfTqpI tpbyRO2JNJL4cCl4yBS0dcB1sHc9VQGBsINaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=MzcpkeecOOg7cwXgshmWSGn7TSS3oU1JGItzOT4Q/k393L6Nm5SaCis70fwtSLV5Wo USS+Bz5IKB6LGSmqf6mZq5JcchZHNGYjGwCHJcKPEJjz064oHLD+cTZxooHlaoNAH7fl ZWX+8R/iRLmGWfawGTw3t8gaVxZQlcXESTqRE= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.138.10 with SMTP id l10mr11752390and.61.1248867174738; Wed, 29 Jul 2009 04:32:54 -0700 (PDT) In-Reply-To: <916640.80101.qm@web1214.biz.mail.gq1.yahoo.com> References: <916640.80101.qm@web1214.biz.mail.gq1.yahoo.com> From: Hamid Mukhtar Date: Wed, 29 Jul 2009 20:32:36 +0900 X-Google-Sender-Auth: 2bb7ea6e07a98cf7 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:32:56 -0000 +1. On Wed, Jul 29, 2009 at 8:30 PM, Roger Alexander wrote: > > Hi JP, WG, > > RPL's DAG structure provides a good base for scalable, reliable routing i= n an urban radio environment. There is a need for further evaluation and re= finement of the loop avoidance elements, particularly related to the freezi= ng of the sub-DAG and the associated triggered multicasts of RA-DIO across = the sub-DAG. Nonetheless, the protocol provides sufficient, understood core= elements to be adopted by the WG for further development towards a standar= d for L2Ns. > > I do also believe some attention should be paid to addressing enhanced P2= P routing but agree that this should be incorporated within the RPL base. > > Roger Alexander > > --- On Tue, 7/28/09, JP Vasseur wrote: > >> From: JP Vasseur >> Subject: [Roll] Moving forward with the protocol work >> To: "ROLL WG" >> Date: Tuesday, July 28, 2009, 4:34 PM >> Dear WG, >> >> First of all, thanks for all the time and energy you all >> have devoted during the past few weeks on the protocol work. >> There was excellent followup discussion at the physical WG >> meeting. >> >> To the question "Do you think that RPL provides an adequate >> foundation for the ROLL routing protocol work", there was >> clearly a good consensus in the WG meeting. It was also >> recognized there are still several open issues for which we >> WILL need help from many WG contributors, including the >> authors of other documents. >> >> Could you please confirm (or not) the adoption of >> draft-dt-roll-rpl-01 as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From rcc@jennic.com Wed Jul 29 04:49:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F313A6F13 for ; Wed, 29 Jul 2009 04:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, 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 Rpyg7bhWcBV2 for ; Wed, 29 Jul 2009 04:49:52 -0700 (PDT) Received: from mailhost.jennic.co.uk (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id C1DF33A698B for ; Wed, 29 Jul 2009 04:49:52 -0700 (PDT) Received: from jenpc629.jennic.com ([10.99.96.181]) by jendns02.jennic.com with esmtpa (Exim 4.60) (envelope-from ) id 1MW7fM-00079S-2z; Wed, 29 Jul 2009 12:49:52 +0100 Message-ID: <4A703760.5030103@jennic.com> Date: Wed, 29 Jul 2009 12:49:52 +0100 From: Robert Cragie User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:49:53 -0000 I am in favour of moving forward whilst acknowledging there is work to be done, especially with regard to P2P and security. I also have some concerns regarding subDAG orphaning in certain topologies. Robert Robert Cragie, Principal Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________ JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good > consensus in the WG meeting. It was also recognized there are still > several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Wed Jul 29 05:02:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA933A702D for ; Wed, 29 Jul 2009 05:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.49 X-Spam-Level: X-Spam-Status: No, score=-9.49 tagged_above=-999 required=5 tests=[AWL=1.109, 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 cSP+hUa8BRhx for ; Wed, 29 Jul 2009 05:02: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 62CA13A7011 for ; Wed, 29 Jul 2009 05:02:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAANvWb0qQ/uCKe2dsb2JhbACaDBYkBqAViCeQMQWEEQ X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="scan'208";a="46061345" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 12:02:38 +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 n6TC2c9L022166 for ; Wed, 29 Jul 2009 14:02:38 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TC2cSn006321 for ; Wed, 29 Jul 2009 12:02:38 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:02:38 +0200 Received: from dhcp-1263.meeting.ietf.org ([10.61.81.210]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 14:02:37 +0200 Message-Id: <08E68A5D-9778-4A1F-89C5-9B9A37BE29A4@cisco.com> From: JP Vasseur To: Mathilde Durvy (mdurvy) 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 v935.3) Date: Wed, 29 Jul 2009 14:02:30 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 12:02:38.0165 (UTC) FILETIME=[7777F050:01CA1044] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2575; t=1248868958; x=1249732958; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=9npT5F66ENyR5ixD8G/D+qEkbPYKR1pCVDNiaAeTJ04=; b=N84IJs3g0HLLfaYyOpttgnpFZnwE8nsk1kmnGW0EdNKNUI7rzXXAFo+euR 15EuHH2A+eDOz1/WmdSYdNy9xAv2aDThXIQlHiRLE5voV1/PNxLAk2dDRePx Wbnoqvi889; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:02:39 -0000 Hi Mathilde, On Jul 29, 2009, at 11:18 AM, Mathilde Durvy (mdurvy) wrote: > Hi JP, All, > > I also support the RPL proposal as the foundation for the ROLL routing > protocol work. > I'll strop processing there for now for the sake of the process. What follows is highly relevant and will be answered right after. Thanks. JP. > I think the current RPL proposal is very promising and we should all > work towards improving it. Maybe a good start would be to better > highlight the key basic mechanisms on which RPL is based in order to > propose a simple foundation layer on which to build and solve the > remaining issues. > > I would personally want to see more discussion on 3 topics where I'm > still not fully convinced: > - the role of siblings: this adds quite some extra complexity to the > routing but what does it really bring in practice? > - if the choice of possible metrics is specified in the metric draft, > why not impose the right conditions on these metrics so that we can > base > the DAG construction and the loop avoidance on a single metric rather > than have a separate hop count or depth? > - interaction between timers: I'm thinking in particular of the > interaction of the RA timers and the DAG hop timers. In the loop > avoidance example given by Jonathan yesterday can we guarantee the > right > sequencing of RA / DAG Hop timer firing? > > Best, > Mathilde > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > JP Vasseur (jvasseur) > Sent: mardi, 28. juillet 2009 18:34 > To: ROLL WG > Subject: [Roll] Moving forward with the protocol work > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good > consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, > including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Wed Jul 29 03:23:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1709A3A68B3 for ; Wed, 29 Jul 2009 03:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK4-3Vpc-ZUG for ; Wed, 29 Jul 2009 03:23:02 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 03ED43A6EE9 for ; Wed, 29 Jul 2009 03:23:01 -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_01CA1036.8DCDE30A" Date: Wed, 29 Jul 2009 12:20:58 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EF16C73@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoPoY9stq9r/vMlSoe7xW/EbSxIfQAlLR0s References: From: "Anders Brandt" To: "JP Vasseur" , "ROLL WG" X-Mailman-Approved-At: Wed, 29 Jul 2009 05:27:38 -0700 Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 10:23:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1036.8DCDE30A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In support too. =20 At the same time wishes to support Jerry's comment that it is important = that we end up with a good solution for P2P traffic patterns. These also = apply a lot to home control networks. =20 Cheers, Anders ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af JP Vasseur Sendt: ti 28-07-2009 18:34 Til: ROLL WG Emne: [Roll] Moving forward with the protocol work Dear WG, First of all, thanks for all the time and energy you all have devoted=20 during the past few weeks on the protocol work. There was excellent=20 followup discussion at the physical WG meeting. To the question "Do you think that RPL provides an adequate foundation=20 for the ROLL routing protocol work", there was clearly a good=20 consensus in the WG meeting. It was also recognized there are still=20 several open issues for which we WILL need help from many WG=20 contributors, including the authors of other documents. Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01=20 as a WG document ? Then we will of course move to the next step. Thanks, JP and David _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CA1036.8DCDE30A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Roll] Moving forward with the protocol = work=0A= =0A= =0A= =0A=
=0A=
In support = too.
=0A=
 
=0A=
At the same time wishes to = support Jerry's comment that it is important that we end up with a good = solution for P2P traffic patterns. These also apply a lot to home = control networks.
=0A=
 
=0A=
Cheers,
  = Anders
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af JP Vasseur
Sendt: ti 28-07-2009 18:34
Til: = ROLL WG
Emne: [Roll] Moving forward with the protocol = work

=0A=
=0A=

Dear WG,

First of all, thanks for all the time = and energy you all have devoted 
during the past few weeks on = the protocol work. There was excellent 
followup discussion at = the physical WG meeting.

To the question "Do you think that RPL = provides an adequate foundation 
for the ROLL routing protocol = work", there was clearly a good 
consensus in the WG meeting. It = was also recognized there are still 
several open issues for = which we WILL need help from many WG 
contributors, including = the authors of other documents.

Could you please confirm (or not) = the adoption of draft-dt-roll-rpl-01 
as a WG document = ?

Then we will of course move to the next = step.

Thanks,

JP and = David


_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll

------_=_NextPart_001_01CA1036.8DCDE30A-- From Jerald.P.Martocci@jci.com Wed Jul 29 06:14:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725CB3A703E for ; Wed, 29 Jul 2009 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdW6u13DDjYF for ; Wed, 29 Jul 2009 06:14:50 -0700 (PDT) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 6AE8A3A67F8 for ; Wed, 29 Jul 2009 06:14:49 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSnBLMlIfw3i0zLmKg9CTcN4RKHyLsLwZ@postini.com; Wed, 29 Jul 2009 06:14:51 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009072908142085-889821 ; Wed, 29 Jul 2009 08:14:20 -0500 In-Reply-To: <4A6F8C8C.1090001@cttc.es> MIME-Version: 1.0 To: Mischa Dohler X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 29 Jul 2009 08:14:12 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/29/2009 08:14:14 AM, Serialize complete at 07/29/2009 08:14:14 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/29/2009 08:14:20 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/29/2009 08:14:56 AM, Serialize complete at 07/29/2009 08:14:56 AM Content-Type: multipart/related; boundary="=_related 0048B66586257602_=" Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:14:51 -0000 This is a multipart message in MIME format. --=_related 0048B66586257602_= Content-Type: multipart/alternative; boundary="=_alternative 0048B66586257602_=" --=_alternative 0048B66586257602_= Content-Type: text/plain; charset="US-ASCII" Mischa, Thanks for the comment. I was going to look at the other requirements regarding P2P. I'm very surprised that the other requirements have no need to communicate amongst themselves. The Building Requirements were very clear about p2p. Here's the excerpt from the Building Requirement ID ... 5.2.2. Peer-to-Peer Communication The data domain for commercial FMS systems may sprawl across a vast portion of the physical domain. For example, a chiller may reside in the facility's basement due to its size, yet the associated cooling towers will reside on the roof. The cold-water supply and return pipes serpentine through all the intervening floors. The feedback control loops for these systems require data from across the facility. A network device MUST be able to communicate in a peer-to-peer manner with any other device on the network. Thus, the routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain. Jerry Mischa Dohler 07/28/2009 06:42 PM To Jerald.P.Martocci@jci.com cc JP Vasseur , ROLL WG Subject Re: [Roll] Moving forward with the protocol work Jerry, I am not sure this was already discussed at the meeting in person but I think we are a little in a catch22 situation here since - as far as I remember - none of the requirement docs explicitly required (MUST) p2p situations. I gather that the design team did take these documents as their working basis which is why p2p is not efficiently supported. In our urban requirements draft, we actually did go as far as saying that p2p should not be the main design thrust but rather the highly directional data flows towards a few sinks. Mischa. Jerald.P.Martocci@jci.com wrote: > > I cannot yet affirm RPL as a working group draft since it hasn't yet > stated how P2P communication will operate within the DAG. > > As I have noted in my review comments, connectivity to every node within > the DAG is not assured. The traffic patterns within the LLN are also > suspect since most packets must travel upward toward the LBR before > finding their intended destination lower in the DAG. This imbalance > will create network traffic congestion in the higher layers of the DAG. > Hopping many hops up the DAG and back down the DAG to talk to a node > that is in direct radio range seems totally inefficient. > > Latency and convergence time are also a concern. However, I can wait > for simulation or implementations to ferret out these issues. > > Regards, > > Jerry Martocci > > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 07/28/2009 11:36 AM > > > To > ROLL WG > cc > > Subject > [Roll] Moving forward with the protocol work > > > > > > > > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good > consensus in the WG meeting. It was also recognized there are still > several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=_alternative 0048B66586257602_= Content-Type: text/html; charset="US-ASCII"
Mischa,

Thanks for the comment.  I was going to look at the other requirements regarding P2P.  I'm very surprised that the other requirements have no need to communicate amongst themselves.  The Building Requirements were very clear about p2p.  Here's the excerpt from the Building Requirement ID ...


5.2.2. Peer-to-Peer Communication

   The data domain for commercial FMS systems may sprawl across a vast
   portion of the physical domain.  For example, a chiller may reside in
   the facility's basement due to its size, yet the associated cooling
   towers will reside on the roof.  The cold-water supply and return
   pipes serpentine through all the intervening floors.  The feedback
   control loops for these systems require data from across the
   facility.

   A network device MUST be able to communicate in a peer-to-peer manner
   with any other device on the network. Thus, the routing protocol MUST
   provide routes between arbitrary hosts within the appropriate
   administrative domain.  


Jerry




Mischa Dohler <mischa.dohler@cttc.es>

07/28/2009 06:42 PM

To
Jerald.P.Martocci@jci.com
cc
JP Vasseur <jvasseur@cisco.com>, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protocol work





Jerry, I am not sure this was already discussed at the meeting in person
but I think we are a little in a catch22 situation here since - as far
as I remember - none of the requirement docs explicitly required (MUST)
p2p situations. I gather that the design team did take these documents
as their working basis which is why p2p is not efficiently supported. In
our urban requirements draft, we actually did go as far as saying that
p2p should not be the main design thrust but rather the highly
directional data flows towards a few sinks. Mischa.


Jerald.P.Martocci@jci.com wrote:
>
> I cannot yet affirm RPL as a working group draft since it hasn't yet
> stated how P2P communication will operate within the DAG.  
>
> As I have noted in my review comments, connectivity to every node within
> the DAG is not assured.  The traffic patterns within the LLN are also
> suspect since most packets must travel upward toward the LBR before
> finding their intended destination lower in the DAG.  This imbalance
> will create network traffic congestion in the higher layers of the DAG.
>  Hopping many hops up the DAG and back down the DAG to talk to a node
> that is in direct radio range seems totally inefficient.
>
> Latency and convergence time are also a concern.  However, I can wait
> for simulation or implementations to ferret out these issues.
>
> Regards,
>
> Jerry Martocci
>
>
>
>
>
> *JP Vasseur <jvasseur@cisco.com>*
> Sent by: roll-bounces@ietf.org
>
> 07/28/2009 11:36 AM
>
>                  
> To
>                  ROLL WG <roll@ietf.org>
> cc
>                  
> Subject
>                  [Roll] Moving forward with the protocol work
>
>
>                  
>
>
>
>
>
> Dear WG,
>
> First of all, thanks for all the time and energy you all have devoted  
> during the past few weeks on the protocol work. There was excellent  
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation  
> for the ROLL routing protocol work", there was clearly a good  
> consensus in the WG meeting. It was also recognized there are still  
> several open issues for which we WILL need help from many WG  
> contributors, including the authors of other documents.
>
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01  
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0048B66586257602_=-- --=_related 0048B66586257602_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0B9D76680B9D6FB00048B66586257602> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 0048B66586257602_=-- From pthubert@cisco.com Wed Jul 29 06:37:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385323A708F for ; Wed, 29 Jul 2009 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=2.100, 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 RMfCAZQOFh-N for ; Wed, 29 Jul 2009 06:37:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 05B7C3A6912 for ; Wed, 29 Jul 2009 06:37:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAAB/tb0qQ/uCKe2dsb2JhbACaDBYkBqEOiCeQOwWEEQ X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="scan'208";a="46070103" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 13:37:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6TDbYFq013657 for ; Wed, 29 Jul 2009 15:37:34 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TDbYKE002335 for ; Wed, 29 Jul 2009 13:37:35 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:37:27 +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, 29 Jul 2009 15:37:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoPoZGO/yb/Ap7/QVSLDO37kq0/UQAryK3g References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 29 Jul 2009 13:37:27.0114 (UTC) FILETIME=[B658AAA0:01CA1051] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1676; t=1248874654; x=1249738654; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=z78O90Vi/OXH7IaCMZw8+NKWJgTWt5iD/E83auN4kkY=; b=YDipn2IoN17lZ0iCuL/aSgwwTYHBc4hA4D+TKI23g/bBw7o/KY0kSs1e9w P/TT2hO8KBbYROydTJNW4vBiQuMqMoydSgkM7jB5CDj0yGqf7qOVwRa19Onx s16iLlHv3i; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:37:56 -0000 +1. There are certainly a number of issues on this draft, but they only can be solved properly by the WG if the doc belongs to the WG in the first place. I've sensed a degree of frustration from people outside the design team and it's time to open the door for comments and improvements originated from the WG. It's also time to use the formal process to track issues and get WG consensus on how to deal with them. So I think it's fair to transfer ownership to the WG and apply the appropriate processes to fix what need fixing, add what must be added etc... Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) >Sent: mardi 28 juillet 2009 18:34 >To: ROLL WG >Subject: [Roll] Moving forward with the protocol work > >Dear WG, > >First of all, thanks for all the time and energy you all have devoted >during the past few weeks on the protocol work. There was excellent >followup discussion at the physical WG meeting. > >To the question "Do you think that RPL provides an adequate foundation >for the ROLL routing protocol work", there was clearly a good >consensus in the WG meeting. It was also recognized there are still >several open issues for which we WILL need help from many WG >contributors, including the authors of other documents. > >Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 >as a WG document ? > >Then we will of course move to the next step. > >Thanks, > >JP and David > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jau@ece.drexel.edu Wed Jul 29 06:55:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7397C3A7090 for ; Wed, 29 Jul 2009 06:55:17 -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 zYeyM+bxDY4S for ; Wed, 29 Jul 2009 06:55:16 -0700 (PDT) Received: from mail.ece.drexel.edu (mail.ece.drexel.edu [129.25.60.32]) by core3.amsl.com (Postfix) with ESMTP id AAA613A6F6A for ; Wed, 29 Jul 2009 06:55:16 -0700 (PDT) Received: from [192.168.0.105] (c-71-59-122-229.hsd1.pa.comcast.net [71.59.122.229]) by mail.ece.drexel.edu (Postfix) with ESMTP id 0538433B21; Wed, 29 Jul 2009 09:55:17 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F57A4A5-B1BE-4A31-A0A0-6862973A2DAD@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice de Oliveira Date: Wed, 29 Jul 2009 09:55:15 -0400 To: ROLL WG X-Mailer: Apple Mail (2.753.1) Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:55:17 -0000 I support the adoption of the RPL draft as a WG document... Looking forward to looking into the remaining issues as a WG document... Jau. On Jul 28, 2009, at 12:34 PM, JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have > devoted during the past few weeks on the protocol work. There was > excellent followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate > foundation for the ROLL routing protocol work", there was clearly a > good consensus in the WG meeting. It was also recognized there are > still several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll- > rpl-01 as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From zahariad@teihal.gr Wed Jul 29 07:31:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D2F3A6CCC for ; Wed, 29 Jul 2009 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 IfXOPkMwTkrp for ; Wed, 29 Jul 2009 07:31:09 -0700 (PDT) Received: from kane.otenet.gr (kane.otenet.gr [83.235.67.31]) by core3.amsl.com (Postfix) with ESMTP id 50E903A6BD8 for ; Wed, 29 Jul 2009 07:31:08 -0700 (PDT) Received: from sVAIO (ppp-94-66-25-39.home.otenet.gr [94.66.25.39]) by kane.otenet.gr (8.13.8/8.13.8/Debian-3) with SMTP id n6TEV6WR030542; Wed, 29 Jul 2009 17:31:06 +0300 Message-ID: From: "Theodore Zahariadis" To: "Pascal Thubert \(pthubert\)" , "JP Vasseur \(jvasseur\)" , "ROLL WG" References: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> Date: Wed, 29 Jul 2009 17:30:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 14:31:10 -0000 Dear Pascal, Monitoring externally your discussions, I think it worth adopting the RPL draft as a WG document... Best Regards, Theodore ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" ; "ROLL WG" Sent: Wednesday, July 29, 2009 4:37 PM Subject: Re: [Roll] Moving forward with the protocol work > +1. > > There are certainly a number of issues on this draft, but they only can > be solved properly by the WG if the doc belongs to the WG in the first > place. > > I've sensed a degree of frustration from people outside the design team > and it's time to open the door for comments and improvements originated > from the WG. > > It's also time to use the formal process to track issues and get WG > consensus on how to deal with them. So I think it's fair to transfer > ownership to the WG and apply the appropriate processes to fix what need > fixing, add what must be added etc... > > Pascal > >>-----Original Message----- >>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur (jvasseur) >>Sent: mardi 28 juillet 2009 18:34 >>To: ROLL WG >>Subject: [Roll] Moving forward with the protocol work >> >>Dear WG, >> >>First of all, thanks for all the time and energy you all have devoted >>during the past few weeks on the protocol work. There was excellent >>followup discussion at the physical WG meeting. >> >>To the question "Do you think that RPL provides an adequate foundation >>for the ROLL routing protocol work", there was clearly a good >>consensus in the WG meeting. It was also recognized there are still >>several open issues for which we WILL need help from many WG >>contributors, including the authors of other documents. >> >>Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 >>as a WG document ? >> >>Then we will of course move to the next step. >> >>Thanks, >> >>JP and David >> >> >>_______________________________________________ >>Roll mailing list >>Roll@ietf.org >>https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From wintert@acm.org Wed Jul 29 07:48:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5913A6F01 for ; Wed, 29 Jul 2009 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.515 X-Spam-Level: X-Spam-Status: No, score=-101.515 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCvl8rdXoseC for ; Wed, 29 Jul 2009 07:48:21 -0700 (PDT) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id DD3913A6F29 for ; Wed, 29 Jul 2009 07:48:20 -0700 (PDT) Received: (qmail 9589 invoked from network); 29 Jul 2009 14:48:15 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 29 Jul 2009 07:48:15 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: Rmq3_s4VM1m45UJb6YLMrihjQDAh4aogqDhIgmhQNNo4h9YK2Hf5oVZ8GYbFzFeX0hUD5csnzKcVOalvql.C_1r4vq_XkzjM_6KD6qfI9l8nMDfYbHrM9gIn6BC1YwyDG9uzcRJV6PjpcReJyuPraSFh7twe1e9pvoXPrI5YnNmZKupdkBQmvYYCNTNENoyYuc4qWUemnBa.jyYY5ROmsshN8_0TrXw6t0EiNtHqg_sZvipJXsa409RAd.viP5UNpP78iNyAafbBKk6Qy1nIaxNaVwEKwam.3q.YopudZI3R2cne1CUI0apQv.LHx_fCbrDBjWzBAaCT2ukFi77y9vcB96PHeI_XvzMv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A70612A.4060404@acm.org> Date: Wed, 29 Jul 2009 10:48:10 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG References: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 14:48:22 -0000 +1 Pascal Thubert (pthubert) wrote: > +1. > > There are certainly a number of issues on this draft, but they only can > be solved properly by the WG if the doc belongs to the WG in the first > place. > > I've sensed a degree of frustration from people outside the design team > and it's time to open the door for comments and improvements originated > from the WG. > > It's also time to use the formal process to track issues and get WG > consensus on how to deal with them. So I think it's fair to transfer > ownership to the WG and apply the appropriate processes to fix what need > fixing, add what must be added etc... > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur (jvasseur) >> Sent: mardi 28 juillet 2009 18:34 >> To: ROLL WG >> Subject: [Roll] Moving forward with the protocol work >> >> Dear WG, >> >> First of all, thanks for all the time and energy you all have devoted >> during the past few weeks on the protocol work. There was excellent >> followup discussion at the physical WG meeting. >> >> To the question "Do you think that RPL provides an adequate foundation >> for the ROLL routing protocol work", there was clearly a good >> consensus in the WG meeting. It was also recognized there are still >> several open issues for which we WILL need help from many WG >> contributors, including the authors of other documents. >> >> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 >> as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From engineer.umair@yahoo.com Wed Jul 29 08:37:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E643A6EA3 for ; Wed, 29 Jul 2009 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.310, 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 4K56eDFNknAc for ; Wed, 29 Jul 2009 08:37:42 -0700 (PDT) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by core3.amsl.com (Postfix) with SMTP id 2C3983A696F for ; Wed, 29 Jul 2009 08:37:42 -0700 (PDT) Received: from [216.252.122.217] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 29 Jul 2009 15:36:35 -0000 Received: from [69.147.84.114] by t2.bullet.sp1.yahoo.com with NNFMP; 29 Jul 2009 15:36:35 -0000 Received: from [127.0.0.1] by omp203.mail.sp1.yahoo.com with NNFMP; 29 Jul 2009 15:36:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 697347.43908.bm@omp203.mail.sp1.yahoo.com Received: (qmail 94226 invoked by uid 60001); 29 Jul 2009 15:36:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248881795; bh=S0QHwu+xpf7CUQau4VxNL58Tfq5LZT2wEetJYjBmF8g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1+A77gteKlTWVa3kfH57jRWDuYJAdn6wz6KiKl5aZoQ/Ok4d7YYnK7Ffx2imAHnLLERBrT+vM1M92LDUqyShuUTqiPqp0GdvDW0+v9wNNtrw6phb+HhNTr43YGQHT/dekRhsJqEid14u6hO/e4w3Aog5q76avl1a9iFxEh/nPDY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6Y++4I80f/1uU79HRnte9FXSU1gCLwKhdXSb9YgPcyja5xMWQwVQijK1DqRMmHgIdu8u4rOnUFnMGONJswVwSs0XTtfrqZ3PPEo3nvdEY5gWVn/bjRNP+AGFw4tHW/WVx40BroTGxpcQksVb+SWsiJ5ePhSNjf4EC2lVD2e/vmo=; Message-ID: <559139.94102.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: 1hs7sKoVM1n0.5biP0ckrXsO.vLqsKfCit9sjQatGzjNFQnmfmY1XqwWijV.EeEKzkcgQ6BCLP1H8JbHkQh0pNWhiDU8xI3in4WHkp_V7S.zmu3wM4wK1.0jPeiQt2QW8skV7FGUaGF.vIbO2DsQLBPZMpF6xxd09gujr8EZ17PDf2_YJv3GyHgwzwQ3Z6hQjlKLephTDy2dCmUFEN5_p7bhieSr_V8mKchNY1TkZ8pOm4dlbraq6I0rJhfIu0MSud6uuALXJnsJuFj3Bu.C2GmLdH4g4OJtfxA7dhF8KzmG3Bmj7cBxCm_33.Cq4CuNV3GiZxOnFWiFD9.fMrLg Received: from [119.152.105.146] by web45508.mail.sp1.yahoo.com via HTTP; Wed, 29 Jul 2009 08:36:34 PDT X-Mailer: YahooMailClassic/6.0.19 YahooMailWebService/0.7.289.15 Date: Wed, 29 Jul 2009 08:36:34 -0700 (PDT) From: Umair Bussi To: "JP Vasseur \(jvasseur\)" , ROLL WG In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:37:43 -0000 Plus ONE. Regards, Umair --- On Wed, 7/29/09, Pascal Thubert (pthubert) wrote: > From: Pascal Thubert (pthubert) > Subject: Re: [Roll] Moving forward with the protocol work > To: "JP Vasseur (jvasseur)" , "ROLL WG" > Date: Wednesday, July 29, 2009, 1:37 PM > +1. > > There are certainly a number of issues on this draft, but > they only can > be solved properly by the WG if the doc belongs to the WG > in the first > place. > > I've sensed a degree of frustration from people outside the > design team > and it's time to open the door for comments and > improvements originated > from the WG. > > It's also time to use the formal process to track issues > and get WG > consensus on how to deal with them. So I think it's fair to > transfer > ownership to the WG and apply the appropriate processes to > fix what need > fixing, add what must be added etc... > > Pascal > > >-----Original Message----- > >From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] > On Behalf Of > JP Vasseur (jvasseur) > >Sent: mardi 28 juillet 2009 18:34 > >To: ROLL WG > >Subject: [Roll] Moving forward with the protocol work > > > >Dear WG, > > > >First of all, thanks for all the time and energy you > all have devoted > >during the past few weeks on the protocol work. There > was excellent > >followup discussion at the physical WG meeting. > > > >To the question "Do you think that RPL provides an > adequate foundation > >for the ROLL routing protocol work", there was clearly > a good > >consensus in the WG meeting. It was also recognized > there are still > >several open issues for which we WILL need help from > many WG > >contributors, including the authors of other > documents. > > > >Could you please confirm (or not) the adoption of > draft-dt-roll-rpl-01 > >as a WG document ? > > > >Then we will of course move to the next step. > > > >Thanks, > > > >JP and David > > > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pister@eecs.berkeley.edu Wed Jul 29 08:53:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6993A6FE0 for ; Wed, 29 Jul 2009 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hLvUTDzYhPj for ; Wed, 29 Jul 2009 08:53:13 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 404DC3A6FC7 for ; Wed, 29 Jul 2009 08:53:13 -0700 (PDT) Received: from [10.10.40.28] (cust-67-203-88-62.static.o1.com [67.203.88.62]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n6TFrCcG014645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2009 08:53:13 -0700 (PDT) Message-ID: <4A707067.4060106@eecs.berkeley.edu> Date: Wed, 29 Jul 2009 08:53:11 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 References: <559139.94102.qm@web45508.mail.sp1.yahoo.com> In-Reply-To: <559139.94102.qm@web45508.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:53:14 -0000 -exp(j pi) ksjp Umair Bussi wrote: > Plus ONE. > > Regards, > Umair > > > --- On Wed, 7/29/09, Pascal Thubert (pthubert) wrote: > > >> From: Pascal Thubert (pthubert) >> Subject: Re: [Roll] Moving forward with the protocol work >> To: "JP Vasseur (jvasseur)" , "ROLL WG" >> Date: Wednesday, July 29, 2009, 1:37 PM >> +1. >> >> There are certainly a number of issues on this draft, but >> they only can >> be solved properly by the WG if the doc belongs to the WG >> in the first >> place. >> >> I've sensed a degree of frustration from people outside the >> design team >> and it's time to open the door for comments and >> improvements originated >> from the WG. >> >> It's also time to use the formal process to track issues >> and get WG >> consensus on how to deal with them. So I think it's fair to >> transfer >> ownership to the WG and apply the appropriate processes to >> fix what need >> fixing, add what must be added etc... >> >> Pascal >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org >>> >> [mailto:roll-bounces@ietf.org] >> On Behalf Of >> JP Vasseur (jvasseur) >> >>> Sent: mardi 28 juillet 2009 18:34 >>> To: ROLL WG >>> Subject: [Roll] Moving forward with the protocol work >>> >>> Dear WG, >>> >>> First of all, thanks for all the time and energy you >>> >> all have devoted >> >>> during the past few weeks on the protocol work. There >>> >> was excellent >> >>> followup discussion at the physical WG meeting. >>> >>> To the question "Do you think that RPL provides an >>> >> adequate foundation >> >>> for the ROLL routing protocol work", there was clearly >>> >> a good >> >>> consensus in the WG meeting. It was also recognized >>> >> there are still >> >>> several open issues for which we WILL need help from >>> >> many WG >> >>> contributors, including the authors of other >>> >> documents. >> >>> Could you please confirm (or not) the adoption of >>> >> draft-dt-roll-rpl-01 >> >>> as a WG document ? >>> >>> Then we will of course move to the next step. >>> >>> Thanks, >>> >>> JP and David >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From cjbc@it.uc3m.es Wed Jul 29 08:56:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1081D3A6AF7 for ; Wed, 29 Jul 2009 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.171 X-Spam-Level: X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 WIf5WTt+Tal7 for ; Wed, 29 Jul 2009 08:56:15 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id EE3EF3A6909 for ; Wed, 29 Jul 2009 08:56:14 -0700 (PDT) Received: from [130.129.85.252] (unknown [130.129.85.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 02BF9BA64CA; Wed, 29 Jul 2009 17:56:13 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: JP Vasseur In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-y0Lio/6iNIGPUxVsmVhh" Organization: Universidad Carlos III de Madrid Date: Wed, 29 Jul 2009 17:56:21 +0200 Message-Id: <1248882981.5122.104.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16792.007 Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:56:16 -0000 --=-y0Lio/6iNIGPUxVsmVhh Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable +1 Carlos On Tue, 2009-07-28 at 18:34 +0200, JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted =20 > during the past few weeks on the protocol work. There was excellent =20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation =20 > for the ROLL routing protocol work", there was clearly a good =20 > consensus in the WG meeting. It was also recognized there are still =20 > several open issues for which we WILL need help from many WG =20 > contributors, including the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 =20 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-y0Lio/6iNIGPUxVsmVhh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpwcSUACgkQNdy6TdFwT2c+3wCfTknKBb8henLMGg9aKBiUAp+A pxUAn027Rt8a1Lts7tsoPK5ukZe0lo3B =2/W+ -----END PGP SIGNATURE----- --=-y0Lio/6iNIGPUxVsmVhh-- From alexandru.petrescu@gmail.com Wed Jul 29 09:12:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FF33A6915 for ; Wed, 29 Jul 2009 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.277, 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 1+ki720qP5qn for ; Wed, 29 Jul 2009 09:12:41 -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 253B63A69DD for ; Wed, 29 Jul 2009 09:12: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 n6TGCaj4020649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2009 18:12:36 +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 n6TGCa1r032037; Wed, 29 Jul 2009 18:12:36 +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 n6TGCZLd023012; Wed, 29 Jul 2009 18:12:36 +0200 Message-ID: <4A7074F3.9050304@gmail.com> Date: Wed, 29 Jul 2009 18:12:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Kris Pister References: <559139.94102.qm@web45508.mail.sp1.yahoo.com> <4A707067.4060106@eecs.berkeley.edu> In-Reply-To: <4A707067.4060106@eecs.berkeley.edu> Content-Type: multipart/mixed; boundary="------------080607020205060002080000" Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 16:12:42 -0000 This is a multi-part message in MIME format. --------------080607020205060002080000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit FWIW, that makes for +1, as explained in the attached image. Alex Kris Pister a crit : > -exp(j pi) > > ksjp > > Umair Bussi wrote: >> Plus ONE. >> >> Regards, >> Umair >> >> >> --- On Wed, 7/29/09, Pascal Thubert (pthubert) >> wrote: >> >> >>> From: Pascal Thubert (pthubert) >>> Subject: Re: [Roll] Moving forward with the protocol work >>> To: "JP Vasseur (jvasseur)" , "ROLL WG" >>> >>> Date: Wednesday, July 29, 2009, 1:37 PM >>> +1. >>> >>> There are certainly a number of issues on this draft, but >>> they only can >>> be solved properly by the WG if the doc belongs to the WG >>> in the first >>> place. >>> >>> I've sensed a degree of frustration from people outside the >>> design team >>> and it's time to open the door for comments and >>> improvements originated >>> from the WG. >>> >>> It's also time to use the formal process to track issues >>> and get WG >>> consensus on how to deal with them. So I think it's fair to >>> transfer >>> ownership to the WG and apply the appropriate processes to >>> fix what need >>> fixing, add what must be added etc... >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org >>>> >>> [mailto:roll-bounces@ietf.org] >>> On Behalf Of >>> JP Vasseur (jvasseur) >>> >>>> Sent: mardi 28 juillet 2009 18:34 >>>> To: ROLL WG >>>> Subject: [Roll] Moving forward with the protocol work >>>> >>>> Dear WG, >>>> >>>> First of all, thanks for all the time and energy you >>>> >>> all have devoted >>> >>>> during the past few weeks on the protocol work. There >>>> >>> was excellent >>> >>>> followup discussion at the physical WG meeting. >>>> >>>> To the question "Do you think that RPL provides an >>>> >>> adequate foundation >>> >>>> for the ROLL routing protocol work", there was clearly >>>> >>> a good >>> >>>> consensus in the WG meeting. It was also recognized >>>> >>> there are still >>> >>>> several open issues for which we WILL need help from >>>> >>> many WG >>> >>>> contributors, including the authors of other >>>> >>> documents. >>> >>>> Could you please confirm (or not) the adoption of >>>> >>> draft-dt-roll-rpl-01 >>> >>>> as a WG document ? >>>> >>>> Then we will of course move to the next step. >>>> >>>> Thanks, >>>> >>>> JP and David >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------080607020205060002080000 Content-Type: image/jpeg; name="expjp-explained.JPG" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="expjp-explained.JPG" /9j/4RNoRXhpZgAASUkqAAgAAAALAA8BAgAEAAAASFRDABABAgAKAAAAbAEAABIBAwABAAAA AQAAABoBBQABAAAAXAEAABsBBQABAAAAZAEAACgBAwABAAAAAgAAADEBAgAbAAAAQAEAADIB AgAUAAAAeAEAADsBAgATAAAAjAEAABMCAwABAAAAAQAAAGmHBAABAAAAlAAAAPAAAAAAAAcA AJAHAAQAAAAwMjIwA5ACABQAAACgAQAAAZEHAAQAAAABAgMAAKAHAAQAAAAwMTAwAaADAAEA AAABAAAAAqADAAEAAADgAQAAA6ADAAEAAACAAgAAAAAAAAAABgADAQMAAQAAAAYAAAAaAQUA AQAAALQBAAAbAQUAAQAAALwBAAAoAQMAAQAAAAIAAAABAgQAAQAAAMQBAAACAgQAAQAAAJAR AAAAAAAAAABEaWdpdGFsIFBob3RvIFByb2Zlc3Npb25hbAAAXgEAAAEAAABeAQAAAQAAAEhU Q19QMzQ1MAAAADIwMDk6MDc6MjkgMTg6MDU6MzAAQWxleGFuZHJ1IFBldHJlc2N1AAAyMDA5 OjA3OjI5IDE4OjA1OjMwAID8CgAQJwAAgPwKABAnAAD/2P/bAIQAAwICAwICAwMDAwQDAwQF CAUFBAQFCgcHBggMCgwMCwoLCw0OEhANDhEOCwsQFhARExQVFRUMDxcYFhQYEhQVFAEDBAQF BAUJBQUJFA0LDRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQU/8QBogAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLAQADAQEBAQEBAQEBAAAA AAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+hEAAgECBAQDBAcFBAQAAQJ3AAECAxEE BSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/8AAEQgA qAB+AwEhAAIRAQMRAf/aAAwDAQACEQMRAD8A+25pSxYep7UgJxivlbaux38ySViRNyNkdK0b e7IA46UmhRV2VdX8UHTZbaNIftE0xJ8sHB2qMkj3zgD3Iq7cXImQEA8+1ZWaSCnNTqShH7Nv v3/JoroCcf4UEHOaTZ2KmhdhPTNG080rkyp+QmwnPrTljYdKG+hzuCeqL9lZs53EH8q37W1A Chj3rmm272CKS3RY+xpuJIAH0qveywxGMYUfhXK79Drou3ocW2nSZYFT19KVbBx2Jr6Jx1Z5 sHzJXJBaMvY/lSrAyA56E8VzysdsI9yjfxBrizb+JZeSfTa1W0kDJkHcOmRzWEpaG0YxUnpu SRHPFSMF3Ac4rFvXQ6LWHqBgUoXmlfuG47yx60m0dBVpmU4pkiXDRj5SQD6VOt/IAPmIP1qd DinHsMm1WYjAkP0zVSa6d2yWJpKAk7Mu3t/5U7Bfu54zTY9V4wcflXt1ZtNnPQp3SuS/b0fs P++ahvNSt0hw+Ax6KoyT+ArjlJs7NIK7dkc1d3DTSxhYJkTzB+8wBjt0Jz39KuwxxwIsatgc 7QfTPSuSbt5lUnz1HJpqy6+v6266lmPH41KADjvXO2z0U2WoIPM6cVbSwLYPFO7JloOOmtnj FRSWJjBJqk7epldsri33tgHOasx6VJIpYA/WtEroyqIZLpUoJG38ahfSZxgbT+VWo9Dz5vlZ QvZhMxYLjviq6PxxXXUldnXTikkNknZpPLjOCPvPj7v/ANepUCxKduSzdWPU/WuSTNoQ55c3 bb1/rT7yvct8o/31/wDQhUp2kYPNZPZHTGF6sl0sv1HplcbeQOxqaNg/Q9OvtWR0qKWhft5y gyOlWUvjRdGcoLcnW/x6VHLceYPY0XsYuFncrA7Wq7FfGMYJwK1g7GMo3Jv7UKsO9POubOoz niulTPOrUro5i4g2ru7VQnk8lAF5kY4UHpn3/nQ9WdkXyxulfQIUEKAA5PUt3Jp7Hg96ye+h 204OMbMrTtwPTcv/AKEKnD8ZrJ7G8F+8fov1JY2HWn5w24dR196yN5K5ajkBTPt+dPV8tS13 Je1yTdxUiPn60JmUo6hu605TyMUJ2OecdRrkkk1XuCQV7c1vFs55xuU5r5XUis7zlkvMZBKJ yPTJ/wDrV0tpN3JUeaCSfb/MlLcj+dPYjbWMmenDUwH8Q2d7qlzpEUm6+hAaSPdghcjkEe5A 9an8O6dJYm9aWVpWlnJXe7OyJ/CpJJ6dfxpNckdep5NOvTxuJUqUv4cnF+tpJq3469uhuxgr 2HNSAc5rn63PoESRfIGXt94f5/z1qRetDaRla6aZORgeooGSRWbtuxbslCHoSRSqMDFQn2Mq iEfO1gO46dKgu1IKcZyQOldEGccrdTjLxNtrcmGzSF0B2uyqQevIAz+RxU9vodsmqXF0vmLJ JEikLKwXAJ5Cg4H1r0Jtq+pwwwtOTXucqVrW0fXt0t+epeFijEYaT/v63+NPfTgI8h5P+/jf 41ztnqxoQXV/e/8AMoDSoYGd4t0TSOGcqeWORyfU1cWycZ23U3PJwE/+JqJSJjhowk1CTXXp u277p73d/Vj1sps4F7MP+Ap/8TTzaXQxi9P/AAKNazbXY19jVW1R/NL/ACQjw3SMP9NxweTE OKoGHU9Ra1ntNT8uFZDvJiA3KDg8d844PHr7Fppq7Rw16WJacKda0n5Ly1+XbqdPu+UdqI2J c5rndz2ErsmLnaT0z0pd5Cioi1fQmaVhm/JI7j2rOvpDax2isckyhQfzxW0HqcE0tzHjkBb3 q2E8qVWPSRdufQjJ/qfyr05Wuxx0inFdieCPc57irrQ/6O2awlojpTuZNxwB3+Zf5irGeAO1 YS2uWvjfov1AXABFPE6sKyb1saiuVeVVPTByO1PtoRDwCQuSfzOaq6tYysm3/XRFjPX/ABpY mPUdqho2W+o9nzhR1/lS7jioSSFPS4uMZPftWB4rneFtK6ruv4l+o5q1bqcMlZ6Gfbvub0Na 4AlhAYHb2x6+teq9JAo80bPqh9rPslCyYB6A9m/z6VoTODatgisp7aF0207S3RhXEnyEdPmX +YqV5MLXLLXY1jfnl6L9SASZ4P5UvnbeScAdahltk0DsSXbI3dvQVfhYFfwqfIIO61Hb8Hnt SIQGYDofejzLSJN2Mk09GDde1SOS0D7SguUhJ/eOrOo9lIB/9CFc347mWNtEJJ+bUYl6/WqV 0efV6pGfFMAc5FbUF0pj5PQV6ktzSGiRNHKrAhsYI6HpUjyGO1IjcH/Zc/1rKT6BZ3utzHuL ptpyhxuXoRjqKne5DrgI/wCIrmmroqM2ptNdF+pCJSDhYz9WNOQbmBcg85CjoKnbUcm5aNWN GBfNXAqwY2hCk/dPeosWmPVg6jJ5NATYeRSNRxBIJBq1BA7c7Sc0lqOeiHfZCJA5T5wMA45x /kfpXEfFANA2h5BGLxZB+H/660g9UcFa1ncyfPI5BxVmG8bGc8V3ze5pS2Rajvm/vZPSrAvm ZeW4rmZ0FW+utkHXHzp/6EKtm63AY6ioesTJP99L0X5sFfdk5HrSh++aQ29C9bXuwACrp1Az RbCOB3qGhJp6WIhNjpVhbgyAdPwqNlqbpkgn2YzWpZ6ssKYwMY70lIJR5tCYazH/AHR+Nebf GPXlmk0oKNoiEsn1xsrelbnRwVo2jqYjSZz3qWOUAf1rsnu0bU0rInjk+bjirCzD1rmkjoRD KFvI2jbgE9V9jVoNkdc0nciyvf8Ar+tSWOQ5p/m8eg96mxL2Jo2wOtWI5ccdqlolJ9Cwr7j2 qVWrO50R0F3j1p6yYHUZpXuO66jGlzxnqetecfFWYG8tE64t5f1K/wCFbUtJI4MRZRdxzPya ljfAH512TersVR2Jw+KeJPm44rnOm9iSOQ9cYz2qwr5wKlsQ+GUyMwxwpxn1qUtggZFSTe6u TxsPr9KmjlH4iodmUloTpOFX1NPFxiosaIaLjrS+eSOootbclvsRGUsce9eX/E68I12GPkgW 382P+FbU17x5+Id4Gqz8nmpYnOOtds9JMqnJOxMJDnr0qve3gjjIDMDkZ29cf09M+9YJ3eht VlywbuQy393IpjhjZAFwZWXnp1H+FX4b5hck4doNqqDgnnJ5x6e/tQ4q2hx069RtyktPnfzd uvS3rYnbUBawQElgGYbnHRR3JPpnj8aYNRkvb6W32IscYJ3kndkdMdvf8RUKN3cVSvyxjT78 qd/O9/nYuxatG0TMquxBA2hTkk9hRcaz5EgRYJZGJAOF47EjPqBz+FJQ96zLq4tQp88Ytvpp 11/y+4uPqCQwiQncrdCO/Gf5U63vFuIFlUkIwyNwxxWdup1qtByUF1V/l/TJIrtZ445I/nRx kMOmPWpDJgDkAnpk9aTVgVSM4qUXo9RqklyTXkvxNu8+KMelsn/oTVrS1lqcGIfuM6Ityeal jckda6Zbs0pyskS7/WnK/FY2O1O6uSI/zcEYpVbErdhgDP51Fym9CSLeH4ZfLPO0jkH61JMD ImAVBPBYjkDvj3p3RkoyUWr+n9eRKkSGPZtCrnOF+Xn14qaG0gZSDErAjB385+uaTkyHQpyt df5fdsWpLWN41VlUquNox0ogjWNPLGSuTwefwrJvSxp7OEZKSXl8hps0jWHyz5fkklQOmMYP 8+tVfsV0lzNJFebA7bghjyo6e/t+pqlLueZiMLJxjGjNxs7/AHK1vTbQJJL1LqFyy+RtAkVM deeRnn0ryP4l3B/4S6fkECFAOfqf61tSS5tDCUqlpe18tvRfrc7Mv8x+tSRyYArabu2dVN6I kD5NSFsjjpWT8ztjK+w+J8NTlkDSvgk5I6/0qGac21yVHAx609Jt3KkEeopWuHNYnSTNWrZw T1pNFX6F3cMVF5gBOKxvqKchfNGD/WmtKBT8kc0n1IJpwBjjmvCviNdg+MtQGc7Qg/8AHAf6 100Wkziq/CehJKJBkcqasI3HStaid2OnJNJoeG68CmTCVvuAAHAJ3YOPas1a+ptNycPc3I7K GaGcMxU5UBxuJ9Tn8z/nFWZpjDbRsDj5lDHsBn5s/rVPV+RjGVSlSblukxr3EjXiQI4CHlnR ckHsO45q75ywhtykjdwFBJ6egpPRWNFN8zcnon+n9L5Fg3kcQlDBgI13s2CQB6fWkh1VZbkQ pG5AGGYqVw3BC898En/9dZ8t7lVMUqfKkm23b/P7ld/JlqPURKSFRiqkqzcYBH45qSC9W5RX jIZScHnkcVm00h+3U2lte/4bkplGKiM469qF1QSepWmn3GvA/HUpuPGeskHO3H6Iorphe5x1 XZbnp6kLcOo4Vvm/Hv8A0q3E+B7VtPVsdFq2n9dSQPk1KHAHvXPZ7I6RUYNIwz0xnFSIgDF9 zcj7ueKVxtKROi8EZIz3FOSFGQo6iRT13jOaV3Ypq++xK0MbMWK84xgdCPf1qNYLdSvyjIO4 DJ69OR3o1ZhOFN6y/wCGLEIjjX5YxGMAAgdqSSBWEflvs8ttwGOD65/An86hp9glC8LQ0drL yKtxBPJdtKrrGpXYcE5xzz9eaYi3EMoYz74zjMeAB3yf5d/WtNFp1OWUKvM582nbv/w/59SE RkzvKygEjpnJU14ZrTm88XeJiBny45T9MYFa09ZGMrxTv1dz1Qv/AKT24U/z/wDrVcienK12 XSdm3/WyJlb0p28cVFmdt3bQcjgE9vpVhZB6CoknYqKJY5OPQVMJAQAam1ws0Oa4EcZbBOBn C8k1EbtmeHaoVX5O8YOMZ6f40cpMpvbr+BJ523qRg0nmjk4xj3pqI5bEM12EAyTycAd6atyH QEcqfWhrQ55yWxE82O/FeH6aovvE3jNuDtt7o/8Aj1VDqcz1lY9QV/8ASZfoP61bjPA7Vd9Q i7ImBx3pXkwetF0dMJipJjvUyyc1N7m6aJo5MjOfyqbzMHk0m7ajuP8AMGB/SmNIMg8HHQmk hNp7jWlyOOfxqJp9pznFK5nJ92QSSljkMQR6UqSbVxnAx3qb6HNLV8w151YHHNeQ/DaP+0NX 8ZydQ1vMPzY1LlyxbElzPQ9KiTNzNznBAq6kXHb6VopXehry6EvksORxUUinpiq5rrczSsIv Xp+NTqpx6Vmm2aqXKSxr6nmpcHrTZXPpdkoUlenFMKcA4xS1ByQ1kPPpULKelRzGb13K7jGc Um44xUOVlcm3QgZyiPuGFANcD8A7M3i+KJTzuj25+u41z1Z3py/rqddOnZn/2SAgICAgICAg ICAgIP/iDFRJQ0NfUFJPRklMRQABAQAADERVQ0NNAkAAAG1udHJSR0IgWFlaIAfTAAQABAAA AAAAAGFjc3BNU0ZUAAAAAENBTk9aMDA5AAAAAAAAAAAAAAAAAAD21gABAAAAANMtQ0FOTwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADnJUUkMAAAEs AAAIDGdUUkMAAAEsAAAIDGJUUkMAAAEsAAAIDHJYWVoAAAk4AAAAFGdYWVoAAAlMAAAAFGJY WVoAAAlgAAAAFGNoYWQAAAl0AAAALGNwcnQAAAmgAAAAQGRtbmQAAAngAAAAfGRtZGQAAApc AAAAlHd0cHQAAArwAAAAFHRlY2gAAAsEAAAADGRlc2MAAApcAAAAlHVjbUkAAAsQAAABNGN1 cnYAAAAAAAAEAAAAAAQACQAOABMAGAAdACIAJwAsADEANgA7AEAARQBKAE8AVABZAF4AYwBo AG0AcgB2AHsAgACFAIoAjwCUAJkAngCjAKgArQCyALcAvADBAMYAywDQANUA2gDfAOUA6gDw APUA+wEBAQYBDAESARgBHgEkASsBMQE3AT4BRAFLAVIBWQFfAWYBbQF1AXwBgwGKAZIBmQGh AakBsAG4AcAByAHQAdgB4QHpAfEB+gICAgsCFAIdAiYCLwI4AkECSgJTAl0CZgJwAnoCgwKN ApcCoQKsArYCwALKAtUC4ALqAvUDAAMLAxYDIQMsAzcDQwNOA1oDZgNxA30DiQOVA6EDrQO6 A8YD0wPfA+wD+QQGBBMEIAQtBDoERwRVBGIEcAR+BIwEmgSoBLYExATSBOEE7wT+BQ0FGwUq BTkFSAVYBWcFdgWGBZUFpQW1BcUF1QXlBfUGBQYWBiYGNwZIBlgGaQZ6BosGnQauBr8G0Qbj BvQHBgcYByoHPAdPB2EHcweGB5kHqwe+B9EH5Af4CAsIHggyCEUIWQhtCIEIlQipCL4I0gjm CPsJEAkkCTkJTglkCXkJjgmkCbkJzwnlCfsKEQonCj0KUwpqCoAKlwquCsUK3ArzCwoLIQs5 C1ALaAuAC5gLsAvIC+AL+QwRDCoMQgxbDHQMjQymDMAM2QzyDQwNJg1ADVoNdA2ODagNww3d DfgOEw4uDkkOZA5/DpoOtg7RDu0PCQ8lD0EPXQ95D5YPsg/PD+wQCRAmEEMQYBB9EJsQuRDW EPQREhEwEU4RbRGLEaoRyBHnEgYSJRJEEmQSgxKjEsIS4hMCEyITQhNjE4MTpBPEE+UUBhQn FEgUaRSLFKwUzhTwFREVNBVWFXgVmhW9Fd8WAhYlFkgWaxaPFrIW1Rb5Fx0XQRdlF4kXrRfS F/YYGxhAGGUYihivGNQY+hkfGUUZaxmRGbcZ3RoDGioaUBp3Gp4axRrsGxMbOxtiG4obsRvZ HAEcKRxSHHocoxzLHPQdHR1GHW8dmR3CHeweFh4/Hmkekx6+HugfEx89H2gfkx++H+kgFSBA IGwglyDDIO8hGyFIIXQhoSHNIfoiJyJUIoEiryLcIwojNyNlI5MjwiPwJB4kTSR8JKok2SUI JTglZyWXJcYl9iYmJlYmhia3JucnGCdJJ3knqifcKA0oPihwKKIo1CkGKTgpaimdKc8qAio1 KmgqmyrOKwErNStpK50r0SwFLDksbSyiLNctCy1ALXUtqy3gLhYuSy6BLrcu7S8jL1ovkC/H L/4wNTBsMKMw2jESMUoxgTG5MfEyKjJiMpsy0zMMM0UzfjO3M/E0KjRkNJ402DUSNUw1hzXB Nfw2NzZyNq026DckN183mzfXOBM4TziMOMg5BTlBOX45uzn5OjY6czqxOu87LTtrO6k75zwm PGU8pDzjPSI9YT2gPeA+ID5gPqA+4D8gP2E/oT/iQCNAZEClQOdBKEFqQaxB7kIwQnJCtEL3 QzpDfUPARANERkSKRM1FEUVVRZlF3UYiRmZGq0bwRzVHeke/SAVISkiQSNZJHEliSalJ70o2 Sn1KxEsLS1JLmkvhTClMcUy5TQJNSk2STdtOJE5tTrZPAE9JT5NP3FAmUHBQu1EFUVBRmlHl UjBSfFLHUxJTXlOqU/ZUQlSOVNtVJ1V0VcFWDlZbVqlW9ldEV5JX4FguWHxYy1kaWWhZt1oH WlZapVr1W0VblVvlXDVchVzWXSddd13JXhpea169Xw5fYF+yYARgV2CpYPxhT2GiYfViSGKb Yu9jQ2OXY+tkP2SUZOhlPWWSZedmPGaSZudnPWeTZ+loP2iVaOxpQ2mZafBqSGqfavdrTmum a/5sVmyvbQdtYG25bhFua27Ebx1vd2/RcCtwhXDfcTpxlHHvckpypXMBc1xzuHQTdG90zHUo dYR14XY+dpt2+HdVd7N4EHhueMx5KnmIeed6RXqkewN7YnvBfCF8gXzgfUB9oH4BfmF+wn8j f4R/5YBGgKiBCYFrgc2CL4KRgvSDV4O5hByEgITjhUaFqoYOhnKG1oc6h5+IBIhoiM2JM4mY if6KY4rJiy+LlYv8jGKMyY0wjZeN/o5mjs2PNY+dkAWQbZDWkT+Rp5IQknmS45NMk7aUIJSK lPSVXpXJljOWnpcJl3WX4JhMmLeZI5mPmfuaaJrVm0GbrpwbnImc9p1kndKeQJ6unxyfi5/5 oGig16FGobaiJaKVowWjdaPlpFakxqU3paimGaaLpvynbqfgqFKoxKk2qamqHKqOqwKrdavo rFys0K1ErbiuLK6hrxWviq//sHSw6rFfsdWyS7LBszezrrQktJu1ErWJtgG2eLbwt2i34LhY uNG5SbnCuju6tLstu6e8IbyavRS9j74JvoS+/r95v/TAcMDrwWfB48JfwtvDV8PUxFHEzcVL xcjGRcbDx0HHv8g9yLvJOsm5yjjKt8s2y7XMNcy1zTXNtc41zrbPN8+40DnQutE70b3SP9LB 00PTxdRI1MvVTtXR1lTW2Ndb19/YY9jn2WzZ8Np12vrbf9wE3IrdEN2W3hzeot8o36/gNuC9 4UThy+JT4trjYuPq5HPk++WE5g3mlucf56joMui86Ubp0Opa6uXrb+v67IXtEO2c7ifus+8/ 78vwWPDk8XHx/vKL8xnzpvQ09ML1UPXe9mz2+/eK+Bn4qPk3+cf6V/rn+3f8B/yY/Sj9uf5K /tv/bf//WFlaIAAAAAAAAG+gAAA48gAAA49YWVogAAAAAAAAYpYAALeKAAAY2lhZWiAAAAAA AAAkoAAAD4UAALbEc2YzMgAAAAAAAQw/AAAF3P//8ycAAAeQAAD9kv//+6L///2jAAAD3AAA wHF0ZXh0AAAAAENvcHlyaWdodCAoYykgMjAwMywgQ2Fub24gSW5jLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC4AAAAAZGVzYwAAAAAAAAALQ2Fub24gSW5jLgAAAAAAAAAACgBDAGEAbgBvAG4A IABJAG4AYwAuAAALQ2Fub24gSW5jLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAAE3NSR0IgdjEuMzEgKENh bm9uKQAAAAAAAAAAEgBzAFIARwBCACAAdgAxAC4AMwAxACAAKABDAGEAbgBvAG4AKQAAE3NS R0IgdjEuMzEgKENhbm9uKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYWVogAAAAAAAA9tYAAQAAAADTLXNpZyAAAAAAQ1JUIHVjbUlDU0lH AAABKAEIAAABCAAAAQAAAAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABWSVQg TGFib3JhdG9yeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQ0lOQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPNUAAEAAAABFs8AAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAFAAAAAAAAQABAAAAAAAB/9sAhAADAgIDAgIDAwIDAwMDAwQHBQQE BAQJBgcFBwoJCwsKCQoKDA0RDgwMEAwKCg4UDxAREhMTEwsOFBYUEhYREhMSAQMDAwQEBAgF BQgSDAoMEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhL/xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsBAAMBAQEBAQEBAQEAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq c3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT 1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEG EkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqy s7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/wAARCAKAAeAD ASEAAhEBAxEB/9oADAMBAAIRAxEAPwD7quCQygHBJGDn1qtEzqyls/Nk43fpXytSacNTuppS gmtt0RzM4Zlzt2nJyO3p/Oog+SenTIxUxsoadjapZNXQ9WIDbiVweSvQ0DK8o4Cjr70lVV7t aEzSk0vmPeQqVBwAOflpgw4IwTk/d/Grt/KDklDy1D5lbliCfXpT45HJIYjYT3GKJtMw5F02 JTcMzKWGcctjjNWYn3EBmIwMetKMVFXaGrS91ruWlbenYkYA56VJgn77Z9/6YrOLaV13HFRj LXoTQqElUlsDOPfIHWpw6suFABI4zROf2rajcd7q3/DjWkTAOQD3FNibzQ3QnHHapfMt/wCk XKCSuLH85w7ZB6Adh9aSUB0ITJfHy+gPvTcm3ddhKm1sRbeTkgk478bsdxVKUAKRKQNp5Oe/ FV7V31NKjjDRb7EQcyMQzBQCPmznP1qMDEo8tj8nBFJTjF7EOK1aHEbpMdORuJ70ivmTK4Ax gEiqdZzSRUYrddiRQwbClgee/WmFsNt42AcZ5xSg433CMbweggUIxxwpOQaQLnpgKB65oc29 d7/oU4pyjLyHOCWGQDg9c/lQsgDZOCcEgmojUk9EHs/d0FYYyM4BPA6ZFNR2kGEJXI79Parc 2+pDivkODKfvfNz9eOe1NPEmEw2Rlc9qSbcmn1E6cL6DkJwCCAc80jYkHyg4xg96pztIhwXw 2BUbI25ALHPPNNZf3e4OozyysDn8KU6sVLQiSslpshdjFjg/7wakLgMx3lQTwWPaiNaLew7J 9BpfDhVYEDqQOM07AYkNyByDilJuFmyNGlFdNyTd5g+QfdwQcdjSqxCncwwR8oB9OtYylaVk Woq10tv0E+Utgkg9jT2DKowOMdB9abkuW/cxd3LlRYhiBXOMnJ7VcgPK5AZeCcjB9qzm03fp +pvTilO3YtIisY0C7d5PzZz+FT7Vb7hPHX5cZrPmbja9zWMFzWaADa2EKknqCOlOFuTGxJAL DOQM/SsHK2tuxM6Kd/UT7IpXjJCj5efvU02xKgY3Bjxn+VEpc0rt7XNqVSN2mtCQWhJyTgdS OgqRbMuy5IVvTrUQqKWvzOyMoxvYmltOm8Hr9MVTuLYL0wSB096bnyO/9eZdOadl0OKup3ON 2VO709qjVyrALyqjGAO9e3VpqL5H3POormgntt+DGSHBOec5xkf1pg6YwV7dc4NKau7LqE5J 31sPD/uiG3e+aX5kBI44yBjOahwje1jO7XvPa4qy/vDngcCgZUk5OB0oUbOwNReuwzaSQSQ2 CCRmiSVhgPxgdetbRUZPluZuaJgPnyFBZRwAfzqaF8ghVyQOfeo5nO6YnJc1osspJzyFwD1B 61OLgEhWzg+3X6Gko6X7m6jzN69EOjk3Z+djkZOewqX7Q7rgEbSPlwefpWFnzXmVKXNdCLId rKAM5znHGKbcapHYQvLckRRoNzOxxtA6n6U5RTaRM5NX5noVdE8Uaf4h806XdJO0BAkUdRkZ H9a1DKVUqhySOO9U4uE+WS1M8JiKGLoRnQkpR7kLvvI7SADIC9cY61Xlw2BhcgA4I/zzxUxi tr7m0oSTtbUqybwMkcY49aigJhYgYY7cnHatJ2lBKKLa96/ckY5YK2QTj5gM/jTRJ93g5OcY HOKmMIyk0mVClJ2Hg7GGFxng5HTimOhfCHgdQQOOtKyi7lxlZ+X/AA4sa7SF67iPqaai74+c +ufxpxeraJlFqPNb+kSKdwJfkZB6YwaNmNuQcjPQf0pNy5mmJUk4Xe4hLFgwbkNkcdKaNx3M Dnb60KCWrFKmtExS2774OeOOMUowzZQbcA846fjUzdm7bkOnaNmO3ZZT1x0PUHjpTVwVbO0Z HzHHU01JONrAoqNteofM6kBeQeCKIvnwX+Xb3zSkm05NbGcYrvuhPvNhs46cc8Uc5wFyD39q bj9ldkN02o8z/pC7N2Cvbk5HWkWQgBgTt7LjkHPWk9Y2Mo07Xe6JI+XbaDkjBNNVizgoAo28 ZHapg9eZ7kqDV2PXOQrLhgc5BzjrU0UeCduCB7dM81Ld0VBpK5biVwhyw3Z79B9KsxQnaHIb cR09aylteJvyJNNPcsxK67WznHYGrSIONqgELliOpqJxT1i7Gqh7ib1H28Pzh5B07jqPrVh4 mSMHOCRkqT+FQ5LdIzbj3v0I5IiQDhgF5HGKiw3yRpnJHLYJxU25rtGdNKM1ZliKIlgrqfLB +U9s06HEbnnjHb3rPllGNl10+Z186bfb9SS73JGuEyxPQCs2d2aQgqVbHBzwazjzRSb2NsOk 1ucNKQWY8nc3Y5wKrpIwdQBwB8uR2r6OonJtvZnl0L8iGysS20nIB78UoO9QH4O0ZNZ+ytG6 KldtXFQDdgDGT17ULll+Yj5Rzz/Otra3e7F71rPTQf8AxDIIAFLuD5xye/NTNzuuUiFtNeg6 UMxPAUH5ucUj7SAPvEjg+lQk394RV99gjUr95D8zc8Z7U9M7SV9OBmnLVtvVsOX2jJom3kqS MbuPm5P+c1Ik5I2LtD98nipkk3YtK6cloSqy7wVOWxg+h/Sl80Zzu+VlOf8AClUUnvsaQaso vUUSK244DYOP93ivPvizqrHS7fTYnK/aFLTFRnai9/6/h708PHmqRTWtzxuJKvs8qxLjvytL 1l7q/Mbr0kXhqXSPFelFRCiRwah5WQJ4ZAuG/A4NehrMjRKYiHU8jLZ3Dsea0q81ud+a/Ew4 fhCjiamGXw8sJq3aUXHT5xbfqh7XOJAUXvwexqF5PMJYryR94D8uK5lBxkj6ScZL3u5CzZII 7EcE9f8APNCbVHAwCD1688/jQ97ocObRMcpXqyqCOnOKeo3Hbn7wyD/Ony2kaK/tH5iOQuAh HHPzHtSdHU549jmiS106igm1dre40tgbc7s89MD2pWRV2hsnIxgHH4VCi0rrc0nqk3oKMkjC hc8fep5kVzxkbRnk0Pe73F7OfLb7xAAykkAYOBg5zmm8BTwfUj3pyircplGUpK47GRh+GUDn NM2gMwbafxwadNJ3vuKXMlzC+WWOWO056jj8KVvuFlA2k+nvQ2ophU3TFUgHcQoAG7GMmo2I A5xyeq0KctfMlRkpWXQlCgDgIc9PU+tRKh3ZDEJn1xRF++zJ8zfvbD4QWXKgBieuSTSqVYsW AII6k8j1o5XJuwnGOyBY9i/Mcjnrxn8KUfKGByWfOD6YqW1eyFKO9t7k0Z2nHCn1znFWlgwv Bwo6kGsZJJ6kPVb6l2LkLlV5YdO/qf51JEoHCFSADuI5BOanWFuU2sldItqyrGMpjYezYyKs Aqg3g/MQfvHOazn7y23LT916kkRJ+Z1U5P1z/hUkkYQZbG4KQCT0qKcuWXMiZTd7RY1iGRWU fd6nGadCABkLuI65OOO1KaTvd2FGDlpL/gEiSJHhcbtzdR/hUT/Iu9zlep9M56UlFqVnsbRX LKz2IpJlYDPfjg4x2rOuZwpIQqevFZyvZ6HVSsnqcVcBgcRtkk/MMEcfSovuPtGCT6dBX0FV c2i3vqeVR0pWfl+iGvgkuAcnBOT1HejywVLIecc560SUlaNhqV9OxKiKzHJAHGOOTSCMhCin BI43dKqNS7Jk1zOIJEy4LY3HqfWpPK2FemTwSDmq3en9WHSd07ivGMg5LY6U8ZwMkYx1Wspz c3ZIcW3dMDEQDliOnfNNRPmITPH8qIVHez2Kp26dSZIih+UAqG9evSpUQPEp646EGlKaXXU0 T0cn5ASXJycEHkgUSABVLNgdvas002XJRukloLLlMuxKKoySDwB3NeVaOs/im98Q67qYHkW9 nJHbLIOOVIHHsF5/3q3oWXNP+VfnofOZ43Ur4TCwXxzTfpBczX32+46jwlp6a38OrGzvgWgu bQwnaMFQGIUgn0GDXQ6TYHS9MtLNbl7g2sCoZZAA0mABk4/pUVJWlKLWl3f8ToyHCQnhMJiG /e9mo+qai/waf3l9mOwc/dI560woC2MklefQVjzve27PoaiXw+YwgbgAcE9DjnOM9KVIt3DE 5xjIok+WJrOzkvUeI8gpxtzz7D/9dLGAuAnKYIpRk+Vr5mdOal6/8OKyFR19znp0pEiDrtQg kj+9jFRGo7XZUrNK22wrId2FwSMds1GwznPLE1SfNZsfI+/X+kOVNwUAAc96d5RCA8A4yBjr mpco28y5O3u/1oKIlwMgHnrng0pi+7t+6ONtDqRtzP0EopWGmM5B2nkjHfilcEsOF5XIDHrx UXDksncBGZH5AA7U1oCoA+6FzjnOBmtOeMUluzOMHJLl66imLeSFyQGGR+FIUIA2oMg8nGRV 89k4s55q+ifcUKoA24wCCB+FPYltwBAypIxyc/5NZ25XqzNpxldjfKG5QhPA64x+WaXG3GSc EcLupxUkXVcXqvkOjjVs4yMeuaNqsctuJIwcClaUbpoTly+pZUDzOdpBOetXoEjLEOeFHqP8 +lZNNtryIdr86LIiVgu0FPm6k/SpYyFLEYO5e/8ATmogpSauF05XehKjo4GJOcjPHc+v4U9u ZCSCMZAIpKceZ26XH7K82P8ANIwkJbaDj2qxIQVKllU5+YkVnzKOthSaa93cEQSluSoPoOv4 UblUZAGFPGKyU+a6NGryt2InkCoWbChgOc1AZto54yuRWsKbd5NlRmpJ/wBakEtyFxkMfUg9 ++KyJ33sxQkD0zgk1EbtuL2LlU5I2W5zc+N2CWIYA+tN27cAHLc8bunavoKqtKzPOw7iqS0/ rcc20N8/oMn19qg2cBWJPGCemamMJN6g/it5Eo+YlQnQAn1PrQvC5fOTnrx/k0culk7jtqyV ULMD6etJ+8QMVznGcetEZJPlsF9by6kgACgDJJ+6PSkXBYFQ2D0z2pd2bSkorbt+JIin73QD 39aTYOmMcZPPes4q6aiXyXvYIv8AWhiG5647GpVcFQCD8/ocYpzo80uZb6Fwl+7UbeoZwrBt 2CeDjHtQCycHkYJHtSXLKzZpy3i0ttxPmPMih+5y361ja/EIPDmpLAAg+ySn5QPl+U5OKcbc z5TOtShKPM0r237CeD02eFtLDchrSPvnORn8OtbqOAjFyeM4GMmiolK66XZy5NdZdQ93/l3H 8kIp+YFhuB5we1PLhjjPy4xuznpXPNu1ktz0p01GzkxhYMM4Pccd+PWkjIXnqAvOeq0oxeq6 lRjfYejiRjvJwRk569acWG0sBkngHPWpu9TTkXxCiJjIuwsAFxg8UpKqxMgbgYI65qbq1kE6 atZdBA2wE4ySeSD2qMtvbcGcnqOefT8uaqyk9BUktx753oAxJOec44qRSZFLLx168Y9BVSjH kuTyttWHLiLJQDGexzzTFBHCk+3tUN207Ftu92CtvAGRgsAMd6JUOcsOexC/nS1TJnTjLV7W HDhyCMhsY+bNG8EAPuAwSc96pRvoHNaKshAFX7vKjgjHBpV+Ugg8seB6Ucra1Jair6CEBXOU yOMYNIzBpCVzuAxjFbWvaSZjVhq7oQg9QcsBgZHANPVVU5wV5xxWMYpXX3CnDRtASHyQO4zt 9KSFc9Q3pitZ3jFpnN7y9GWAMKcdj1bAxT/NVVyeRs5x2rGKTV0hy5vhJzdFmG4ZBIxgdqfH dhOTyFHPOMc0nBfC2Di+flZJ9qIUeWSR2zx9acl26hlY8jkgY9aiNJJWZCs01/XQDe7nyxBJ I5zyOKct2WVioCAnnHQClONldbBGKu12H/bSJQAx6DGOR05xUMuplmG4EJwR61nGmmkEqjUl 03I5L8KNxLYHAOfbvTHviw9eODnk/wCc1ra6TfX/ACHC339Cu90GZ/N+7ng5qsX3AkZOOR71 Mo8l10N1a12v6ZlyJt6dzyAMmmLAYyGf5xj0wR1r2a1+fXc82hW/cK6HMMkeaQGyMcDjimrA ABnqBn8aUpOMtNjR2eg7yl2klsEDOPw6UoXygq8jB/u5oV3f1La1tckSHAUqDgHHHX6UGMAK VIIzx+dQlf8AEu0VaNtuo4RZx5ZJAJznoKJosBQgyf4j2okkpWG1eTQ/y8DBJbjkYxmmA7d2 eSBUJXbLvpyvchCv5oUvkHJAAxxU8Z3KVfG+PurZ7cfyqmrO1/M0pQm1e3kSiNd/JYjI98et NIUbfLK5HG49vSsOaW5tKOlv61HNGuAV4wAAvY1jeKGSLw3qxKZP2KUDbz1QgfrRByt2IqSX s20tLEXg3cPC+leaxRltUUqwx045/wA962mwd2CBjgE81daSUm1tdnLky5suw9S32I/khykb 9pYZJw3y46UrLjIGOOhA61yTm7nr2stun5iM3Odx3Bs8/wBKQFZFwrkcdOuOapyaTdjOSvqS q2C25gf7uByeKCcsCzckDBHTjpUpPmuxc142JQp3qerMMUuxV255J6H1/Cspp9BpJX8yNF3N uOAB1ApEAHbLY+bAxgVfM3qEYyHuwDBAOc849PanAEPtQFdx+p+lKSfK5SNNLKKDGTypO5uo 4+tCnzPm5UKBkZ/Oqlo730M4ta3EPytxyaTjaCxLDHCsppuo2loKPL1HKiA7iyjJ+Xnj/PFP VQSvGCScg9feptJxdx8qVrrT9RAqDeFcBc5PPOfrQyqAMg9OpP0pwUrktpjlQSckDLHtQ8B5 xjpjj601PlnowqO87sBlCigZY9/pTc5YDq2MZzVU7XlYxa5laWgKgyVXp64yM0KdhkwTwPTj HtU1E7OO7sKVN8tkv+ADlWcAnDE8fjSjbgby3TkD69K0blGFuqJtPmWmiJPMCrhMgEjrioyS wbLDg5JbvUR0957mDUt2WUZTGHJwT79f8KaJEIT+AOOOMZ9aWq/EmUVyOyDGSp3cD6UiT/I+ 04zx6jrWduZ2FHRNtgJyuF3ZwcjOc5qJ22hdxBDcAZ+h6U4r3HfqOqk1o73I2faxVGVVfBOB n/Pal3ZAOeAOnSmqdnqF+X32RPkAkkPz83FNGZFYOw6fKw60nyyi0uhqpNrQSSEtnZyuQTkc niq8a7SuB04PtXuSpqM3E86jKU6aVtCeSEYAbg8EH1phjXHoWHdsGsk7ts1cW7XHFQrDCqQB yMUC3O1iW3YXnPf/ADmlBSauVJq+i0uKINy4GQc847mjygi/L1B+U55zTlZJpLqbc7kx4h2y BSd/HOe1BG5fl3gEZBFYK7d2aJXXM0NXIJBCsMg7fU0/5W/1Y+bk4z6U5qSle+4Qi0rCEFnU 4Hynn8qUqEX5eCwxwuePepqR0s9jsSstBA2DjCnIPbFRsAqLnoO2MVkoX0Y0+aLbGYD5dRuJ PYc1leI9reHdRTgBoHzlsHp/9enyppxfkZVI3j6qxY0eRVsLXJ+/Cmc9egq4SytvVm4HIHTF J35pX7s5csVsJR0+xH/0lDlLdF4IbKnGQP8A69JJIWyCCf8AePPWsZRSkrI74psTedxA9eKW NhuJXI3LggDA69qc42u+g4eRIp+Ydtx5NPYqyrjHT1xg/nTk5SSS8i0knNSWvQkRjtBbKq3U fhSPIBzkEjr+dYSUr6IG7WXQaW3YAIwxwdoGRSK6hQAGPt7Vbp6XZLdpcjQ/5WGDwSeCB2pW UAfxg9MgZzilZWa7iq6XQqtubnOO428Uu/aQQeR+taezd/zCNmtdxwdi4OcITzimMT/Eyqe2 BmsYyiou4uS9rIdsAcBW7jjApwIjKhRnOT70czkvI1i3JcoquMKerFuRj24pDGB8xbdkD5SO 31q318zK0o38v6/IXcBtIIVT68c0s37pjvHzD0pKKjp3HeSdrbDWK4xnjd0PY4qN5drLgABR yO5q1BJtC5VJ27j8kYwc5bjcMn600NhTuPzKMdK0i0tUZzjZ2YRlQMpgkZySPrQQxiJ6M3I5 rObjdu25mpe4mhol2EK/LDkkjr/nNOHzjBUDnr2p3fxdzmTTVh27AUgsSeuOaI5FKjKk+w5x R3TWxTTtfoOBBIwu1jgkHtSPIwzsII5HvUtO/K1qZRg1LTqRmRcDnntx/ntTGkZzhSMYwQR1 pSScrSWhW65SPHKkncSccdqeHKEDapAzn2q7cyTejCDTuG5UyEwSv8Oc/hUAyMcncvb/AAoV O8XcqL09TdmsDgFfl6Z9qh+w55ZBlhzkHNe5XptVLvY4cPVbppimywwVsMQSMbuxFRNYKNu4 EgDj3/8A1cUOnaTHKpFaepKNPbOEAGCDy2c+lNXTTLyUI3dQDxUKThBtPU0klz3Qq6eFkIbO CeW96HtdgJjTBxwMdelRKi2kjWm9LiNasylXUfKcgj1pBY5iLgDC8gg9s96xm2lvuzRO0bbf 8MNNt8u1yOO5pGtGB9SBn72etZStF2N6adko7sd9myfmGM8ZPQ0yS2KK2QMjt6VTjo0y7toh eDacYHJzgjoP8mq0zKEyeBzgk5xzWXLJu66FQVoJPcY5XGc5Zuo9DWdrUe/SL3JB/cSD1/hN ZJ8rvccYysxdCPmaXZ42kmFQCO/FUZryafxNDbW7lLa3jJmOf9YxHC/h1rVyV3F+Z4qxM6GX 4ez1l7NfLS/3K/3HQEhCR147HvSNgggnB7k9K4Gno/M96M3doECA5Csd3U56U0YBCowYAZJ9 K0Tk/dKcEo+ZMyb1bfgEH7oOcURuNwOBn6dKqEZa2LUbvTdEjoAykndjkkHjpRtCgjIVmPQm oi9BqOlhskYEbFNowegHJo25ww2kAZOWrO737MipBLVjg4HK4btk8Z9acgOCr9AOMN/StIfC 2wqU1bzY8gKgGefX3pEjCAkkE7elUr8l0K15aLyHLECrBjy2CAO/pSbAoP3hxz79c1N+hU2l Gy/r+rD2GTwQpzyaFG0dAQB15BJp9OUiV97+QMAw2tyScYHBoKHJG7C44Of5ULRCqO6b/rqJ 85yd6nPHoKXGFyflYjv/AEqZcq0ZPM7DcHkKRyQc49aQ5BxG6vjOT0NVBKT16icuXVf10FRg cHqVJxzxSGLK/MFJ54z0OaekNwqJu/W4EhGQNgYOWVT0/Gg5dAX4XOeSTz6VHJcm6Ssl5CMF CYyvXkgcn/IpI0QrtGc44B7mtbppaGHs2n7z/r/hyQBVXk8hhnNNUAKdpBJ4GMjPfik3zTcg qW5WgHKg446ZPrSMS2cqAqjsc5od53vuYTvG3KRvEQwIAXDckmoxF13NjPcnqfWqc7+pHMot NimIBdynORnNIQWUDPAOOvFaKokk2iYStsStHtBVx3HBOO461A0QDE5wAMcGsJOKs2zpjzOR 08sfkuG3E7TzgckgVUaTLH58kdB+NfSV6jdTmSPEwdZ+ygnuNacF2DseR0/nTjck53Y3juR+ tc8pQudi97+vvJIrgI+C3JGOvanJPgnBG05we447VbklO5pCy29CY3O4DgBQPzoE7MThsfLj IGcH6VhOXLuzohGPJZ7/APDi+bFG+GPzDg57Uw+WHHBwRnOPvVFSbaTfUqE3CViKFkkYKyjB 4LHt6VKqwhAwbO7nI5qZppW7gqlpOXV/8EVIFwCNx+bIDdPypksCAEuDgenrWdSa0L01b3uU JIUjyFwR3OOlUJ0ygKjtgdvwrKUm432udLfRFOQZ4wQ2c5JzVXUBmwuV7mBgNvuCKybvLQcZ Xsn1M3T9RW00a1SHM00iKqIgyWPTt2oFlJpJ0oysWuJ7vE8gHLM4I69/SuiUlztvr/wT5enU hPD0ZR2pxjL56W/C9zfZFfLElvY9+KVEOC3zEMM4J6HJrjqTVtEfWw0ncQDa2DksWx/+uiNe FK4xt54603LXsU5QUboeEDYMnAY8HrinEYc7vmwO9ZzmmmU3G+iHsg3kZOcjIp2FIIHUDkip 5+XYpSSjZiBCDw7YB4yeKFAUZUnaxxx3p8ztZFtJ2v3HxwDGDxjkYHWnJxEgY7c/KDjr+tS5 p3Rk316DmHy7QN2TwfWnFABubcvHTHWqpyagmC1dlqOWPICxDJHbHSlK4AOSDjk/0octUZqa u1LzBYhgD5utOWFuC7NwOuaJz5XYtySST2CWENtycAHjn2pjxjYG5GMdTz+VEZSUV/XkKU49 vQSRNwOAcHrz1pzKBgknhePanJdF0JaTtfYaY95+XLBT+FN8vaBncvPb61VKfLaLInJaxj/W 49UJLbRnBwTnIpphIU46jrjr1olKN7Mal7uiEdGbAJOFPHb/AD3poG5VUFgADjjpRzWS5hOM OW7Db5kWVXOTwc8flTRlcAgkjoFPr/8AqqrW3MJRUm7itHsXLBgpbHTNLs2YyTjB79AapxUv IwqNK9uuooUIcjknkcUeWsgON5DA5zxU6xkLnul5COm8KZBkr2B5NIqjGQrHPA45FTK6vyMJ aaLqtPnuRTA5B+ctnB/z+NNA8wZYFQvUnvWrqcsVY51Fpu4DJyQCcfdI/Xim7SV+bA46AYx7 1MuWer6Fqbtp5nTaoxVgWbdz17nisYueVYkkjJNe5UlzK6POwsfcSX9X1InlJHTvn7uaRJiA wBGHHc9fWsajVrM7YpxfMidJ1XGwqMk84pUuCYz6nuf0rKVk23udNOm7KXckWfEYYH5s9Rnj H9KfFMfMJLADqWHesW73utyvhafTUR3ALEtlmAzle/pUgImX922Tt4BPBGetOUk6bfYhRafP YaqtnA3cjqelKsoRNshGcZJXtTjJSXM3qVN63aX9MdFcOFIB4J4xxUhkzjPJUY5FZu/M+5tK S5ditO4OSSW6EADNZdw2DkE7TnqO1YOV27odLmaUipK2SpbvwoHU1FImYXXorIe3PSo5ktbG s00mluUvDVrClhbvGkYZvlcjnOD1zWrcWkN0Y0lQsYXDpnsw6Gic5+003PMy7DUnltODja61 +aHyptOOSM8HGKcw52lhiTjA7VktIrl2Z7C91pPcQDysMTu9MCkQqRtbvwam7k7rY0cdNF5E 6ryCpyoI69elDI5LIcEnjOKlNu7e4O6p3ihTwARnkcfX+tOchUII5AOfX60JKRjNWaECbSdx BDfyxTkyFO3YRg9qTkr+RtJ3shRyeM5br7VIEX+IAqB37UcxmqcvhRIFB2jAOeh9qegyvQMA OmP0ocbpdioX5nyjljIZQCOT27VKturIAhORyKIzbXKiJDFjKyggDHTr7UphK9mP1FW9XsTU UtBfK/dZ24JPHHSk2cEKB07DrT5ZWsiVNJO43ySeR074GaRrfI6jBGCpGM1fXXcd/dutv+CO MJMmV+RP7pGaGgc9O49M1TtzXeoSik7sVoQMgbRnuo9qhA5ypHy8nPes729RR5m1powVNxyQ CQckZqMR7RwSDt7jNXfew2uVjlgZsBdwPTNIqBQQGGTjim6l5WXkRJXVh2xWb5W6kYx/OpPs wH3hkY/OnaVr27kzpybs1oJ9nzIQAGyeM9MUi220sSA2O23H0oUrv3tzOakr+TGFDvIJXkjk Aj9Ka6uUyvynbnH94celUqd0c8py3mN8kkncVUA4AI601IwZGC7iqjPA71mou10jOdVLbUTy MHggE/4d6haHYWLN94c1rCTve24Tdro2buQO3RgpPBBzjislSAoXOeOte5W0jv2ObCxvCK6f 5IhkkUyDkgZ4pBIXXbyflz0xXG7t9jqlrFiq6s525ODxz1NOSXJZcgewHU1Mn3OmEVFNLoiQ zKJOCxT+6B1pRKSGZch2GMjnisdEk15lw2ux4lYkAqRz0FEc+XYA8Y+8ATz6VtKMJRauEHK+ w5pjIwLAHj1zQzhlXc3y9hjk+1ZpWWgoWcrrzJEnEfCluw9e1NefbGWBAXqDnFYSclJq5rGK vqYd74rs4JfKgke7n7RW6F8EdckdKy5r/Xb1c2lhBaKw27rmXcw9DtUf1q1TaXNUdvzPGq5v KvUVHAQ5mt3tFP16vyRUfRvEF6Q8+tJbYb5RBaAkH8TUb+GtcJDf8JJOrLnANohBp+1wsZW5 Lv1MIZZndTmlPFKL30jf83+Jc8MRTQ6egEjSojFQGABYg8kYHtW7HO00YZA+WOMMMFRXNVip Sfax6eVudLC04zd7aettCZ2EcYPHXn296bHMrnMbht2SSDWCknoezFwu7ija5OAQoPXvmkY8 Z5zjjvnmhO1oolRlFb66kgYEbhycjPv6U8BVAySSefoO9Uk22hxSklf+tBxYFeCVPGFHak8z 5yMnnvjvWa1TGk1Gw7asgJLbiRnPvTYwzDA4IGfmPSh+6rdFYlxd+Z6akvLFiudp4wTz9RTi GPJyzHoPQUNJ2sjWKlazLke3GMA4FSrEfLBUcdRntRLRakXhHTsPWIByASc85xzUyBeAc8rz kYq4r3bGbaeq3HBAGwA2BxntSrEAxD7uOcEZFK0lC/8AWgm03djliUkhAASeKRIdvGeT0GMV MXZO5m3eSfYVLZCcgYJ/DmgWmA3mABj0xW0pxtZbg01oRtCrYClscbsrSeUTjcucDCg9qSdr XCPTuRMmGPJyOcYqqwIbAJQheQRnI/Chtsc02rR8hpYM5ChcHPG2m7t5LDdnpmpblZPqPnbb RNGu9gFHGehOTmpFgVVyACSOOP1raPSRNRtOyQ4RfOFVGJB7das/Yl2hiOM8k9j/AJJraNPm Vu5Knyp9x7Wiq2SG3MQAB/n3pBAdhAJAAxjpz/k1CSaaZzOcnNSepCbQrsPQcdznNRfZh/GG P/AetO10+hjOPL+Yi22W+YbgeAAPTvSnTjhSFIJ5IA/lRpGWuzMJ25roa1qqYU/MT+n+c1FJ bZAZ0IGOeOlVGLauhRanq+txLvJjYcqG6qeazG+Y7cdMfh6V61ZJN2FQs4xd9rfeVbglAWTB LcAkdOKawYLj7uF7dz9a42kd04xW/wDWpJE27czBeRxjvxTY8nPlkn0/lUJWl5FupF25kPj7 u3XoetSCQ9dvbA296U1c0buuw6PcCM4Y8fh7U1XwpK5OOjGs5q+wm7q/ckUhkJfDHrkL7UDE oIOdy8AA9DUuf8rtY0UUkzMm10mdoNIiNzODhtv3F/Gojo0+oMTq90SuOYIflTr3rRuNNc8t X0R4uIdTHTlRpO0Fo5Lr5L79WaNrZ29pAqWkaRDPIVcZOP1pGclcqeSMjnriuKpO75pdT2sJ gqOFpKnSjyxXT+upGwbCgnuBkjn86FGeDzUxcXLQ6aj9xx6mboQKwyKckrcuAQc8Z9a0lG1Q UHzHpg4rR6SZy4SKjh4rzf5sHUsCrj7vX2qsNPwf3LNC2MEA8fjU3SWpdagqivezuOE09uxE yeagb7ycHHuKnhnErfu3UrjAz1BrOVuVeY6M5xvCrv08ywuS2eeOx45/yKUZUAMFyRnPNLld /Q6+R63fmKSxY5IyDwaVSSCAw3YINTyLqim4KPKhcthSAcdKR8qM/KQR3HaqVlKxVotuTJ0b OO3OKeiEnqGGeeKEmnqTJrlbS1LkAKq27BAzjIqVDs4JyPrWj5ZSdjFyUnsS+WUXLZBzwT6U 9E3KASCpB6mpvpp0MX7z0QvBIbG07eaeDvTO3AHr3pNpyswlGy5h5JU9QMHAP9KFyHbfycYH 9cUNJaig9LjtjbwrEAZ+XGeaRvv4yTxxnpRorWFbuNL7WwM59uM8VHvOS3OQOcnimoaXCm9C vK5IJGME89qrSDcoDKAMf1qm+Wz9C4pPVEeeQRlQMDPU0wHcNwOwsO3FZJtu4Ky0fmTRsEXA +XnjIq3Gd8QIxyBgA5xzXQpJJN7CnFSvqWIhiRcDIz/nirkcoVPnyecgA1uuVK5yc8dn6j1k VzlVj+XA3EZoES7hs+7znPGaLRd+UyU7Tv2/UAAXG0ggd8dPeoxADne5yvPJNU4ppRetiK/K rS6j4rZXPyEHaPf+VSx2ZdDk7toO3DEDn+laKNrXRhdyXYT7IA+CdwJ5HfHrSGx8xCXKgvzj J5GKI2TOacoRS6GBcSL5QAYNux1z1/wrKlHmbSnJI6lu1dNS6kzvwsEoJtaIpz4H8RU9ifWo 87csCQMYUk9vcVjKbTd+p1Rj32/MVZArgDqwByelSA4YEgkk9OmB/kE1Lbb1KUH0FY/uxz6j pwKAQEwBg4xnp9fwrDkNG+WKFDAbWORk8e34ULISGHHrmnON1sVG1kmyK4vEs1866chM4yW6 n+tZqNfa6hwZLK0Yd+HkH9OwpWjfmfwo8zF1KjaoUvilu+y6v9DVtrOOxiWK2RFXPYdKnZQQ NpBPPOazlLeTZ6WHpU6UFCK0RG5J+ZW6np6UwuvG0fM3cGsXZxt/Xc6eVyj7zGDCr7+mf19q QlQ5xncVxyadnFu25NSF3Z7GbogCy6gF/gum6e/NamCTk8kDIwcUTdnZ9kc2XJyw7b7y/wDS mBbLSdTtIGMYNAVSOr8jnjrWTeh6Spy5/IQfeJDgZPuSBSNaozZGBKi8OOM+9O9pXaMp0IzX K2BnaFD5x3ITguozjNTQur7SCTu5/wD1UkuXbYqk3Tk4T3J8KOpH1NNUAEiI/e7kUKOhfIop tAIwAV5OTnk0gkYMcjdk4/CjRy1K5Vrdk6HKgjkDjg1OJAy/N6dzxSeqUl0J05bk8cwVWZ+3 AxxipYpwzqVIyB0qnZq6MJ0mnt2HlwSASfX2o85VAPIHofWnJ3VkyuRSvJEplCHIOOelAl3B sNwevPSnotTJRdm3uPL7gFb7x6e9OSTYTvOQB2qbq2w7e7bqO8xWbvgdOKc0yqCF5O3j3pPm lFeZg+Zu3QjklEZIHXtTN4EZPzMT/CKd7JD5klYrvICw6sCeh7VDMQxbaSOPlIFKUr/Dubxi lBX1RESJOpABPOaA+1CF+XjgetEeZKyMlGztfQkXbIBwRu/j69DUkXCqByG6H1q/e5NetiFP mm3sWlk8sbgeCw78D86kinG7LnhVPANbRd22ZcsJxulrt/XzJjcAtkdH/wA4pUcqBg4YDhSM 4P8AWuiCVtOhNWL0itwaUM6gk4B9OnFIZ2OdxJ4wee3pSi7S1OaUHyJXJ4pEZQy/KRjJbknP Wl+1b+E+Uvg5HIxWqer5mY1Iydk3sK94UI4xk87WzzU0dz8v3iSc8E9PWlFpR5kjmrQVkr6M 4z7WGVSCSCM5Axjiq8khGDgg44GMZraSamrrY9bCq9FRWxWkGA3Gfm4IGe1RmTMY3bjkdCMc 5rHmW3ma25bpbjkdQu1uRn+Hr7UvmBs9Pl/vVnUbUtSo31ASYIClMk56ZNGArbe/Tp/KhpPd alRVle1yZ8KxUEk8Y9Diql9qEGn2rTTlgoGMY5Len51k3LREupTpQcp6Lv5IzrKwk1C4W81e MA5/dQE5Efpn1Nbaj5QPlT5ehPPWqqyS9xK9jmy2nJ81aorSn96XRfdv5j84PysAAeoyc03c Cx+deOMYrCVm3c9KSbd4jN2HJGVHHPvTXKuAY25x6cUSjpFmlLR8ktRuCAA+M9SaH+9uJDED PFTe7Km2rNryM7SHUX2pj5iROGyTnqv/ANetNWVsDncPSrmpNtLsjiy26hKLX2pf+lMcwOBt wCDkk96C275Ccc8gGsOVXuehblW/UUcFgAAMdSaTOxSMcYydvJoUry1NXGN+ZMU7RGRjl/lx ioTB9nYG24Yj51xw3+FNLT3uplUjKqtN1sTwzrIxRsq4HKnqOKkZQ65yQQOaUeZNMKT54Xb1 6jgSQAuSfftQik5YjjOKLJq73NZRstUSAAdiAcZwKfG4YBduflzkihax0IUFpYkT5c7uQTz3 FShth65BHaoScVpuFS7noKZeQT82ep6Y9qdHIMgHGF6d6vlXLqY2tq/P9RfO3sPmOM4Ax1oV 2XdznnByKrZWC1o6kj3G5lzkNnJ9jUiPlMk554HrUVUuQzSfbQRp8EcdxxjOaPNULyMY/DrQ pOyJ5Wna2g5pRl24YnGOeQKhMvB2Z3H9Kq8Yyv2KjFNtIEdRk5HI4OO4qIocEMR0zznFS52k Q47teQjbRId5LKD6VGy7l3Kw+7j6c9apPrbQTi01zaaMeoZSWzyTn1xUkY2qCwwV5xmtHIbh v6j2dZBlQMHp3FPEqjGDg56jpWkJWTRk/aS1fYl85QQOXwRyeOMUqSAsDIw3AduCfei3Jqnq YzlJu9h4uVkyYhux0JHpUXmBkOWUg+1HPJozVNK1xy3ijIGQScBSMDp60q3wC4fHAwOO1W4S ldeljKrB35rDku95YSk5HT3PpTBdhUYfdCjB59/SrbSVmjGpTTXL80c7g7gpXIBIII5JqJiw JZg2QPqRXROd3qdVH3aaCR92cjIyNxHeq54O5MgnqKy0cuVHUr7vcN5DAnaxI5I7U5eEJTJ+ XvwOOlTLmS9SVao/IdkkgKCfp296epKjqQSc5qak/vL95qxFcXcdtCzuWCKdxO7pWTYWsmoy LfaicEj9xD/cHqc9T07VEE4+80cOOpKvOnRvpe8vRbL5yt9xsBQQWznnnPelDbshsrkcH0NK MlJHryTctyUAIQGbGOuKYzb02gkjPPsazm1r8iotyab0GnDOD8wxz1okJ44wPT2qZS2G7qfM upGodAQQPb6UgYqxIkY5HTFO6buzVNy5kjO09T/aupqGIUPGTk/7PatVG2jaT2Az+FE5PZdk cuXSUqVS+/NP/wBKf6CFlz0J9KASx+RePSoV1ZM64xTaTQZxkr19hRjcD5nOfXtTlp6lu7ld 7E4C/MdzbTyCR7U4AEja2SR2rJ3WqGnzaIiltxcMCzOrp9117EUyOdoyIrhsO4+8Bw3+FWve sjmm1CpzdHuWtodlyd2erA+1SbgE2nPy9uOaza1OmpNcthqk8AlvvDr6VJG2TlCckHj8auTl bQjl03/rUm2/L8uVyaUMwJ8xiFYAgU3LQFFvqCMOOoB6+1I25CGz+HpURmluzNpxi2wUbRuY cZxxUiuqkHkDH5mne7auJ2jKLi9CRX5y2R/SguAPm4GeelEL3uHPZ+oRnn5iBg/rSs+3O7PT 1oq1HF2SIVmtegAY5wdvfHNKW5JC/cUkduKmUteZjikm+zGMxVRjLY6jHShZNwAG4Eck038S sjGVuZRQZ3bWOCTwd2DTFTAJYjIGQR2p87iaac1290LvADbc7hycj2pw3LIwkO4fdOBitrxa 13MIRu+UeFJXhs4OBx2pgfjkEDv+NVKavYl6K6HGU7Bu6hvY/rTvOMhw3B7c1TSbumKomnaw ZCxtk/KTg+vNMD4O4E5x6Y/z1qFdt8xMfTyAN8yjnrkD3p2SoOTtJGWGav2rvqY1YOyT6CK5 DKzSAlTwMg4qGRiEcpv3Y5PY1cZvmu1YwrRi0n1M51UqUXLE4zljzTOiKCfmOMjpxXVVcVUN otThF9dLiOwKZj7tyAO31qHadu5snIzWM3b1NlzLcaqgv8559M0qqSmMHg/Nx0qXKWtzV6K2 w8HbJhSOOvOc0FWG7kZbpx1P+cVm5SUbNAo63XkYkjvrWotFGv8Aolu37xweJH9K2VPCnKnq QQPWtJpJrXU48JUdSpVqd3yr0jv97v8AKxJGpI4Ibj86QLk5GOemO1c0Wr2SPVpty09RCVDF SPm7c9Kc3IySDk8AcYrSzirtBe7dmR5JJORhTzxkGmuSy43HgHp3olJNJpGqk4tXQm7e3APP f8KTnhQVBHfFJabf1ozRNOVyhp6N/a2oscNzGevQY/xrSO3Pz9MZz3qJv3rLsjiwCSU+X+aX 5iuRwpbkfnQMAZbkDtUy5ktUdys1fsKibSpXrmlIDjgE4qW25XXQq3NG4BiwIztGegqQFQcZ AI7+lN2aaRTSew9lAfn15qKSFJY2R0LZGPpUp8upDiuS77EcLm3kEMhLZPySZxn0H1q0rEkt kYHSlz83vWMqU1KPLJ3eg8IcZ49fpUoBA+XAUDnHWk3F2RtBWeqHRkhhvwM9OelPkxgHKg9B nvVNp7Ct73u7DCu4Lkk/P24pBzuIJOT0zU8vucrRF29x4lycqeM44pcntg+3pTtF7b7k1k7p /IReM/Nj61JGDwxwcU4y9yxjZLcFBbk9A3GPWkk5JEhI4zS503qipxau/mSBNnTcQMZGSMfW kwWXBbjrilD3pPQHe2w8htuBjcSOSaQIwUZKlcDpRJpPV9SOTlltoIPmbGQMsD6ZprLhFOMq QOvP4e9ZufQXNGLfcd1BYFivse3pR3G3oRxmt02jKNSzug8xhnaM5604KTGRlQTxwenrVNrW 3UUk72GxopYg4wT3J/OpSi9U2gj7oPP86pNoqMXOTTGO/wDEQp3dwahKsTnPKjAB471dKN2y JRtHck3ZJHdDnr3pkKDB43J69OM0RnZv8DKSuvJjXcM7gZdR9ASKikIkibGF6/jVqpcxlTto noROuV+UEAcjHpUSpuUkZYE9K1rQs0ww0JcvvDZG8tlRccsBwenFRu25em3bUu97m19dRm1Q 3zZ6DHNSImFOWyR1NTP4lbsbQdlzDTEc/IwIDZ6Vk6zqDh49P00AXUwyz5z5Kd2/wqk3JpM5 cZWdHDuUd+nq7Jfj+RbsrWOztlhhxiPG49SW7k+v/wBarrKSckgDGMCs5P39S8JSdGhGmnsv vIzkcBs885pzbdmd3AH50pOzuzvpb26r8xgBb7oPHNPV9gHcE8jrT01bCSjLZ6oRgGBOSCTz gY/CmMuMEHIx16Z5rJytY2i3YjxiMhDnueORQh+YZwDj5eKOrY29HFLVlOywNYuyp5OzJPQ8 Gr+SWAIxkYIpzfTyObBRS5n/AHpX9bokI5x6rkUZJQEkYA6VhzXVmd7s20gWQFyCTu7flSYy fmLDjjjvVLcSSS5n5kuFEpJYDb7UvLnjIzyCKiz0bBq2qQ4MAwGDhhyaNoydpGQaTfKh2T1a 1GSoLlcSAYzwe4PqPyplrIysYbg/vEThv7wz1qrtppGNSPLUU++j/QtemGzj17VKpLOdw4xj NTzNR1Oid78z6DicLznGe9OHyKSpBwDjI6U17qMubVoFBZ16AY9PWow+0E9cDJA6Cld81raD WqsupIrAMM9euKUBdxIPX0pqVtES5Xdrj2J3ZBwpNAUAjoBk/wCTS68yMql0wB+Yjgj1FNzt bIwQeuaajaV0xT93YezjadpHDA49adlcsCRnHbnNRzWasrmMbfFcfjKDoMHrTMcnBBOetW1J X1NlL3rdgVWEgyR7nFCrkAkkkjANQ5J7GVWN9v6YCMMuM8nrQE2kbTnAyD71bm1O7Oe7W2g5 tuPmK4z0HTmmlQGJQ5+XI9xVRcuW62GruTQbiSGOQPQDpUzSAqwzwV4/OnNtajm+V8qZEDvY DcQD2ximCQKoRySccHHWq5nf3ehNSDt3EztJ3DOT0BySaOQADgtzx3q1du25KUdEJJkkEEZx wOv1qrLwjg9xgfSqlL3bWMmufRdCaKPag80DnG7nNM4MqFAvfJ557V0TSckwo1OWHurQinix MpIU4HbrmoAmVw68EZHODU810aSScewgxuIkXBHTigMCwwMqR2PPWmmpOxtHls2v62/Uqatq C6batLs3P0RM4LHsKp6PpzWiNNefNdXPzSEnpk9AfQU6bShr1/Q87Ev22Kpwf2FzfPVL9Wap VAGAUBhx7UxlODjcMccDjFYv4uZs9OEfeFKFTlQCM+tJlRnOBk4wabtKLb0Likth4OwjjGem aaEw7bDg471MVzSKVrWW7DeC3zjvhTURyqnjjsT3qGkrXLbjJ27DMNjHTNEZAJzgtjj2paJX 6m11GVynbYXV7rI52p368H/61X1IZierLxmqlrZvscuDfvTX96X5/wCRIYzGOcc8daCck8jg dDxWDfNex3KSSGhgrA7cntzTx87A47fdBqlq7sc5WSsyQgDOOAKVR3BPSld8vMy/aXbY4APy MD3NHOPkPT3qXNKxlzO92NQ/usADOeuKZNA0igggMvQ+lOUryuiai1lF9SSGXzEwfv5wR6VY R9sR4IJ4OTUqGmw4+9BN7smjPygFd3JyTTEB4EmBj+EmiaV/Mtu0mKkhbJYEZPT0pihVBwPX 86cpK1u5m7O7Q9pADj+IHj3pYwScZHPpUuCW7JUVdWX9WuPKkNjg7SOvelwQPmUEkcnPSs4t SgKpZoMkNxjGfwpjbfmJAXHU461snF2ZLcoNpjgoXbwD6E08Abs4zkfw03bnv2FLkcWl1HAK Fw55PSjGB90LkcUm1J2G02mkNGQMnJzzxTl4Cj7oUdMc1E+Vapgm0KSo6kBiTge1NUqhPJKn 0FCnzuxg5bSS6j2ILq6kjaRwo6GmqQyE8fyxV05aNLoZS913HBt5wFGDnrT5MkFXwcrg4Per flsVGyXvIY6HJBIznOcVEqs0bHaQcH+fFDnHUUtvUQhixAXB6kZoA+U+owOK1lFRWj3IlLqx JRvGEG0lsnjOaryw4iyRwRkf1pXVrXMmpK7uWVT90HTOF4x1AHpTwCXbpkDkA4xXRiHdybMq EF7Nr7ipPGSxJOWzz6VVZPMkI3/TnpVQ92PMux0OMZWv5jHZlwUyVUZBPf0qNyzAMcMcc+1N OPKikm9FsZEn/E28QbGJNvpoDYPR5COPy4/WtdeWAAJPTpUVHyxil6/eceApupXrVF/Nb5RV vzuLgso2gjHXNG7jvhRnAPJPrWcXd2aPUcdFIbjEeVY9cU9VJI38gjgelTUine5pu7J6f0wd zJtLnpSMu4ZGcZ796iMlBGsk7g/JOAOO1RtuYbeRz170pRi7PsVyxcWNJY5wTy3Bz1oDNsO4 jjuBTly9hKOlmUoE/wCJtcFieI0/Kr6gtuJJ57etKpNbLojlwCUHNL+aQ4NvJOdxH40NkNn2 9alO7bO6Cu01qM2kHBwTUke8MQOMDpRa1+wSaXQkiyAHzxnn3pWJLEgEZ6nPQVM5JSs9ipNX 0BUxkAEAetKu5VZgTuHaldWskJqNttP+COxtzjHJ5oJwgEfBxz9aS0WqJu5bbETkwyidSfLZ trj39atvuYfdBDdMHPFNxWl2ZUkuZ6ef3kgLYyTgdvyoJ3ctzxzxQoLU6NHohCvz7uA3fnrR jJDKSNwwRilHZORlyWbsCsQy5PHQmpsKRwMZolDRWM6TcbgATgE9KBuAO3jI/KpcY6WZorWu +w7vtLZ54PrSf6ogHJJ9aL3srGcrNvQV2KkbskZ7HrQmVQBDk9snk0PVeomtbtEiFifp3pVL Ic8suMZqW7MEk0rEYVpSQ7ZGaXPygbsEdzVPltddAlHS4rM4wUY8jrnFIqsQFBI3HjmiDSWx z1IpWv1HKSwG4j2zQTlcMQMcgD+dErbocYxXmmOUkfMpAB4+lBBVgMk4HA45q1bmkTbvqICS M/MVUDj880wrtVV6nkqO+M9Kpa3vsHs1Ftti85JcYYde+PSmqp69OM4PQmrgklZGEoN6/wBa DnyzAknBbqe/tVGVd0JLYAIxk1UFoKS5Y3S0LuVwhXb8vGM9aaXwMscZAroqRmqrRjhfgTZX uXBdtp4J5GeaqS/uxkKFbGRzV3taLZ0OCcb/ACIywZjkZzwPXB9agvLhbO1nmc5SONm4PoM1 nGPM7FaxjKb23+4p+HrY2WnB5ggmum81++Sea02cKpwD6A9qJQ95yvoc2UxksNTk92rv56/q JkqMDPQVHtIYAEjAwQT71MU09T0rq6S6Dt4IwcYz+NLkgLj5evHtSlv5DjC1mPKcEjgj0OaY BuwCTg9x61CTkjpUVG/cHYbz1H4daYJAy7u/QGoaaVhQ5b2SIjguCpzg+tOB5OTxRrYafZGH q17caZNd3On2UupzIiYtYGAdx3xnv3xWDN8UJJJY7ODw7rqXkxKpFcQeV2zwf4scZ9ua1p4e VV+60fMZlnn9mylGVKUk22mtVfsyl4b1/X/FWpWWsaNpdkmktIYWmN6uAm/EhIHzFht4GMZr 0tDkAkjHajEU1Cyi7tb+ppwvjcVi6E69Wnywk0463dtn+V/UdszIWGeDSkspyi9axvdpM+mi k3Zj0QjZnoT3qVk5GPxrPq/IvlvFNdRSp5x36Co8MvAKncKUFrdhe6UGG4H+LLE49hTlKA4U gZGSapttabDlBrSwkqKIsP0bII7c0WTO2+N8b4eoPp2NOSUk5Mwqz5akObZ6Fsk9gPfNNb5Q Rkc9M1O3UpQ5VowfDNkANjj/ABpu3GN4PPTNaa2QXurx6j3xIeCQCe3GKk2HjmojPpY55J3t 5jucgjIIHSlVt1S7R1NrSvfy/AFBG05HynrTWOXJGCelTG9/MjkcpNrYduMaErg5H6UikEL8 pOPSos09GPkS16bC7/vEMOOvNSIxfCqy4xk0crer8v6/AmWkn5DEfax28884pQ2F3DIwCfSp afN5f8OErap9AeRyvBUkHkCgygrs3AFsg+9aSd0rbEVYtO/oKoQtjhiSMYPSnq5A9AOGHrzV zkrmbqXV0O3jeeQM85703bsLYPFTFcqcO5nLmbTsJxu7Ep708P5ijcFA24z3Joa0WpUlrZPc gup0t4HlndIo4x87luMZ7mpAC5CggAg9+lbxS5krGbh7qSZG4xkk/jmq1xjYTuwNnHOAfamm ndEqDSv3JWk4QqPlHX3NI0299wyCB0B4/Ku+rGTlzNmGFVqUSOdi2QCTnk9B2qsxOCQDjHWu Z6bmz5n1IfMZiPmGMHPHPtWT4jZ209YIyS1xMkZHqu4Z/QVrHSornJmU3DCVe/K/vsakREKh P7oABFKzZJ8wk56Vk4t3bO6jCFoxXZfkNBJ5J4HU0MQVz054pQXus67tO68hgVzkHB/nUyfL 8wPOMEEUTcbaaolKSaTX/DCl3Bxn5valaTGAMc9RUKPnoa3ba7sjcEuBkjPGKYMYBYAg+lKT V/PUpaS1GZCsBnj6Uu4HO36c1nKMmtHozTVsz0Z111wPm/0de3TnpXN/Emf7FBompF/LOn6m hY4+6jqyMfp8w/KuiEVGcVa7/wCHPnM6j/sGK8ub8EmU/hhqcQ1/xZotu6iGC7jvoY+MxrcA sy/gykV6KGwcAkj+7TrR5ajXb/JC4XrwrZb7vw807ejnJpfJWQ9CWLAdMcUgdohgd65FTvJI +khs0+1h6kxvt+7jqM9afhnHOAe3NE4pSUupUPdSfyFXcTyeh6/hTscHB3EDrUx7lON5CKu1 DznmmYKLuI5IwcHvRC27HzuNyZt4xyAo5OKrXOYbiO4VuMbJOM8E1dPV3OTE/wANuPR3+5mk AXGRgZ6Z71FvBZt2OmOlEVbbobNcy0DeVbj15FIzce+PTrQ4rYXw2sh3zkgKSDkU9FPzDj1+ pprltoKN7ako4jZWHoM0mNqAnJB4PtUtp9RSTi7rUBlvmJ+tIXCbSowi9zWcLSld7kX5ZKK2 sB3yAkHv0x1pr7mQqCeauPutocfhaY9PMAGTjjpjk/jSrhMKvLd81Dlq0CUXZtC4DNj1PJ6Y pWXCtzk/w+9S9UNKaegKjFiASfWkMTfebjnPB6USlYzacpXexIH3KFPG08Duacpwp+YDA4yO tDlaOphKN3rskNfPmdcH0xT5M4DDqCTmtLQe4k2RybnGFxweR9BSgbIxz+FNOKiS42jfqMnP 7iTzSGVUO9SO2OaVGd1yDgbflZQeR1pwkmzOLbSuJJuGdoAJPQcmqlxKV3kZJA444xiumLV7 kyppwTT8yusxdFGGTdgBgelNM+VAAbjqfeuiq7y06Coq8UMeUMSMEHI5Jzg1EZTtIYELjBPS s4q7uzSN27f1sLksM8ZHSsrUgJtS0+IjcAzOxzjoP/11spWnY5cykvq8l6fmjSzkjAbB6gHj in79pGRj1yKx5ud2udlkrOSGupwvG3PbFNPzNhVPHtRFpI3u1HzHA/KxPcU6NgFwM4Hc1inr boWpuy7kiyIpwMbi3HtTJH+bgA5A6U23e+3+RpFc0rroNYEYKjByMDNM2EkEsAvb2qHPS5c9 Tj4fiRpbaw2nams2mXSSBUNwB5cuWKjDdAcg8HH1rUu76XUbn7PpxZIlJWaWNvmYg9FPQD1P 5Vu6PLZPbc+ajxDTxPNSofGpcrXbz/yEisDDcNDb+fFP5e/Pml884wc8HkVW1yxtdYsZtM8Y WcdxZXMTRPJkqAGGDnHKnnqD+VLnjOVr+Zq6TVOcKmsG2pX80blrpFnZT+fa20McrxJE0iAb mRc7QT1OMnH1q8oAA6EjOBXLztux7WGw1KhRVKnFJEilW3cYI60m1W+7/CMnPaojNpnS7WAh kYkAFm6c81IpJXnACjqa1nexrzRcUmCj5iEJIJ5zT2Xcq5yuOuB1qJtNJSI52ncCqjoOhzSy MhXkAq3H1+lG+wOblqwEo4XHBwKdcQJNbuj8hlIIpttWRFWCSfmiOwuWls4y/Lfd6YOQcZx2 qYoUTOf0zRfkdjKjP9ymtuosYA6kZc4pAMhgTz69aG9WzSMoPYerHaMA5B5J705QA2ScmovL 4kOc1fUm3qeGBz256U7Yj5x2HPaoUn1Jin8TIMjnbnrg0pkQ9SSMelaNXkRPmbtbUcp3LngH uOlNdSw6gEnA96hTXO4tBKN4+v8Aw44Hn5+xwaXCk8jOBxnvzVRmkirXuSSoVIZDjdxTsgR/ PnJ6Vk+ZxvEu9oX7DtuwYI5zz70j4cEDOMVKk+b8TndrpeggUxn5sk5GSeKau1F/eMWxxkDr VtyqXSIk3zXiPYbuRxjindQFfkAYzn3yKp6SMpTk9XoMLBcHAKlufehScYYjBHHHSmpJptER k3K7IXhWeMrMG2jGRUsBVItpY8qBwMfQfpWjlKUdAlKKvKwEEElQA3oTiqF6hjicOcEK2ec9 q0TbdkRGVlaxlvcw4xvTjGPnz+NMFxFt++vyjghuf/r12VW72tucuFxCqU1K+o55wrfI6nDc Y5oWUFcPggjk1nOLsvI6YzSYArGOWGDznpz6Vz2namdV10EW8tusCOvz4O8ZGGGOOfSnSlJ3 k+xyZnWlTlShGN3Ka9FZpnQxgBjuDCl3EcKee+KxldNPyPXi1JK248SYb5gKYWCgYzluBg0p Wb02BqKd2h8rgDA6kZ5pV2hCy/jxk/Wob0HTV1ZC7uQytz0we9KzFwcnJ28gDpTk29Ta1nox CQPu55GOTmq07BIWY9gTn0FPlsteoSb3PnXxl4ouHu7qGCztbtbp183zcZG0ttAyOGBY9D3r sfgzY+KNPvz/AGxDPDolzbF2iuF+aOUYCBAeQMdR04r0a0acKD5n5H4JlmMzLE8SQnhYaRn7 z7pt81/RN2PT4mVtdcFST9lBxx13f/rq3fW4ubVlABO04BHH0/GvMkkrJf1qftuHSnGtH+8/ /SUUvDMhuLBhMCDbzPGQTyArYx+HT8K1NgIHGCw7dqeITjNpIrKZy+rQb6K33afoTA5Ixhee McZo8zChio+YckGsHJno3S1JGcdBnOc49KRpBnBGB1zT5bWYQXM7LYerZA3dzggUcdskEY6c 0rO6Vh36f15CltvUdcc0gCqBtxz7UNSaTTC1tRwAGdualjxjBxyOKclJpEt9CrZHyrq5h8va QwYYHHIqyWPBX7pHrxmhxbd2c9CclePTVfj/AMEEBXk9QelIrbs8ZIPX2o3RtrrYcWUAZJJ7 4p69eRwvrUxvKOvcel7SRLvGwnrk0IQxAfjrkU5J8rsZuL1TFIVlHY5puMnHY1mlZtFKSvqI U5IJywx9KcuVyM4yKLa3uKVS6TYKNjg4OR1J5qWA7m6nKj8qh001eJpd2uOZVBBUZx79ajkP RVUj0B7VMN99v+GFJz0SJWYlAVOMen0ppYIuVU+pyc1astjKd7OwnDAEjqc59DShTHyy5D9O QapLfzM9Y7bi7AGzzjPApMBvm5z6mq1S8jKU79NxuQQqjb1HA5pCwKMwUMCACf8A69KOiTtY iMuaPmPZwc7TjJ7/ANKU+Wq5LEHPSrp2s131MpqWlgfY4YEnt05x6/lWdqGwW7l2yoQnn0/K tISs+UiUpRStucgPCWjrFtjsYkAPHX0+tOTwrphIC2yYyOMnA/WvVxGImtzw8Jw1l3JeMNfU D4d0/LAROjDAGGYY+nNMbQ7OJkQTXKSPnannkFj3xzz61m67vytXuaf2Bh0lKMmkvPTUSTRn jgkFtd3RfY2FZt4Y44/nXh1jd+MrTxAI9LWWeRJ22rHDtGAeFbPGOxz71th3CcmpaHx/GVPM 8vpYaeEnKXvddXt026nu32XVkjGL21fOCd0JGPbNLnWkDALYOp6cMpHp3Ncv7iT5XdfifdUo 5rSp8z5ZX17O/W457nV1PFpZOw5IE5/qv1pjXerAn/QYSAPlAuen6UlClzfFv5FyxGZxjedB adpf8Ae1/qTf8wsSHIx/pajHvyPegarqAXnSZvlHJW4TA5+tSqMNU5hHMsdFXjhm/Rr/AIA4 atfOAf7Huc8cCWP0Hv25ofWLyNONGu+SM/vU/wAaJU4qyc1Y2WaYpK7wsrv0/wAxr6zdAqTo 18eccOh57d6rz67JNC8c2j6oqyKQSqqwwfcH0qZUJJJc60M3nc9Yyw818l/mYHh/SND8NTia w0HVILkgZnlt2kbPqCTwSeeMda3P+Ews4yTcQ6jEATlWspM/kBV1YTqtN2djzstxWXZXScKV KcbtttxbfzY1PEemm/8At/2krbiERAvEyktu6cjNW4/GmhyL/wAhOzUnA+Z8ZNZLDzb26fqe jhc/y+Ck51EuZ317WSX5DrXxFoluGS21Gx2hizYmXqef61dOu2EseUvrbaf+mq0nTldXR6VD McBCNoVI2vpqiRdRtWH/AB82xyR/y1U8/nUkc8TfMkkZGOgYVk/dTujphiKMmkpFjz1PyqVc g569qGdUPXjv2rNKTSvsaqrFN6jlOQMZxmnpOuccEnoaaUnexTnF+bANtXLYGCSMdqMZYbGB GKUY3d2KTSVlsO3Y37Tk8HOMYp2SuwZ5A7Va213Ldk7sryShNRjkIIEqFWJ6kDp/OrAG2PAI AxTuowWhx0UueS8/0QvmDdgZGcnOaY8iqBggD2qY6nQ5OOj6nMeJviNYeE9TgttXt75Ld8Zu 44d0QJ6D19OldDpWt2etWwuNMuobqFxw0ThuAe/p06VUqNRQ9qloePhs6wtXG1MHe1SOtn1W 913RoKCWbpg9qlBIxjIP04qG04ntyatcYZcnLHABx92hyc5XIGOtS01axKiubUHIbdubHPJp kbbgQM7h79aSV1tsZNc25Mr7hzkE9SaWOTa5+bB7n1qWlFWOilZ3Hu6ng8gUkbhmywIA7561 C+JyRL5r2JFkCIxwTk+naoVfjJxjHFRy+/qyJRbdydJAQOwOBz7UhDBRu+U5wOa1UUtHvqZy l7qutRDJgjByOtNLALuXC54571cXFR16mc3aW2wMACMDJ7UxfmG0nHHSoUo8zT/qxikt+g9u SN2Bxxmsia5WHxPa2saSM1zaPI7FG2oEIA5xjJL9CRwCe1bRunoZ1Jp3X9bf5mrICW37gfTB z2rN1Y/6JK2dxMZ49etaxXNJyt/W5D5lFqRnlhKqt/CTxjjqKZ3XO5cjtwa7pJtKTFST5bNa iSlVUsxICDO70HfmuIgeTXvHFhfMkgtLYSJbDIA+6cufrxVYeCc3KXn/AF+Z4fEc37Klh4vW c439FJN/jZfM7xUJDfeX/CsuxXzde1LjBVYxkHr8tZJqLdlsexioqXstd5/+2y/4Jr7GzkZ2 n270hLM3JOQO/esVG7unY9BctrPoDcuqn5fXB60rjnC5zSlfobQppLUaVz1AXng05QCSASQD np2q5RUo3HG0VYeIwGyo6n0oZCSF5woqOW7t0LUr2bIpMgMDndnOaap2qABz37AUU1zKzGkk r9Ru4MCGB5pdu0AL1XPFS4NOxouRvVFaP59VmEobPkgZH1q49tFKSZYlYAd1BqG2na559DDU G5c0U3d7q+hBLo1gygyWlsT3zCOP0qNvDWkycyafYsCMY8hRkenFJVJrSLdvUyq5HltR806M X8iBvB+izFv+JdaYf7x8sZ/+tUTeB9EcnOm2445C5X+RreOIq7NnLPhrLLu1O3poN/4QDQyQ 0dgU+YHCXEg/9mpI/h7pKBfK+3JgAALfTD/2anLE1FFq/wCByrhLLoq/vK/aTQxvh7ZoSYbv WIznO4ahJ0xjHWlPgRMDy9X8QRgchP7RYgZ9sVH1qVrtK/oWuF4QTVOtNfO/5if8IVOAB/wk HiAcgAfawcfTK/X86bJ4In8wF/EXiPauRzdAjn6in7dc3Moozhw3iG7LGT09PPcengm4yP8A ipfEB28DM4/w96G8DXWMSeJvEZBUji6AOenXFT9YV0nBMmXDWKaf+2Tvf8BR4SuLNJfN1/Wr h7vEStJNkwn+8h7Hn+VR/wDCC6kSxXxdr6k4wdydfxBqvrCt8Cs/wOd8O4mMuRYyd11731/Q Y3gPUQwMfi/xCCc8+ao756VG/gLVSMx+MvEC8YJ3Ln/9dN4umlZU1fv+Bg+GcwUX/t8/uXUy 9c8JXGk6bLc+JPHOsx2ABDGURjd7Dg7ifT3Nc54M8C3+s+JbHV9G+36VodlKsq3F2U87UAvZ UUAKpPHPb17aU6sVFtJRX5ny+Z8NV6mZ0YfWJVK7ad9FyQV227etke6qxUYwcnoak3Dy8P8A eHp3rzZLmabP2BR25WIV3EHnimNkyAtkKQR04pRnK+/9MtxTdhHZVfC7icelN/h5/Wi7cmhR io6y6k0b8g88noO1TBiWxt6+veplzJplRVtxrFQ2FwOf0pynIAHIHSohs+YStJMJWIXkZGcn FRgnceTyM4J6VcYW2ZCircrHqTgDsOlOY8YPBA4xTe+hE1G1/uEZuAGOQTgE0jMTwu9gBzzV 8uiuzBtW27AzHgjk/nimhSVI+YtjgelTNK6XQmtH3fd2FzsBCkn0yPpWN4hh8hodYja9aTRo 5nSGBziYMhBUqoJbjkccGqjNOOqM1CN0u5sCWQRfvAd5+9zke4/nWPr77dNuWYciBiMHPY1v TfNG99zJrddTntcstWupIG0XUYrER7hOrQBy+QMEZHBGD+dZ1j4a1aDUba4uvEmoTIhBkh8t RHKO4x2Few6tLbluz5/FYLMcTiVKNfkpqzslr5pmxrGhQa5HHHcyXCKhJIhlKbhxwfUcCs23 iii8XwW0KEJZ6YxVccLmRefyJ/OsaVSUrrtf8jox+Aj7eGJWspShFX2SU09PV7nULnIwWwR1 rP0hM3+pAk71dAATjAK5rKDajK56eN5VVoc3Wf8A7ZM1N4VTzj6GmSJ5m3oCFwcdqwjpZs9C 91yryFGWzjJPcelJkq2Dg4HbuafIpPQ2c05XlsPK7lUnoSOMVIgCnqBkU942iwSutdx6rvQD JOD19aV1+UDbyOoFQ/PuWk+axXZNjndgmq7BTnaOg5JNJ/Fe5UXFK8RyggZPUHg4pM4ZiOfY UPmbaKnG25Xt5ANXlJwAI1GCc+v/ANatDAwcE4IzUVNLLyMKEUub1f6CM2H2gZPalK73XJ+X 6dahXdmtjZ6WtuwUBTjAIPTnmnhQQSeOOfep97muTGck9UNTJddoHuSamWPYeowBWlZXlZm0 5PnsloOOcH6cUisp5bLEDnjFYSfKiLSvuKykkMxBPbFIiAHBIIxxk1SSasLVNuIo4PysSpOa VeWBJbHpSs+bQd1JXZW1D7iMMgLIpz+NWAffmnb3dDGg0q0k+yM3WtXi0WxuLu5YARLkL3Y9 lHuTik8OX82saLaXVyiQzXCbiiEkDk46+2K1UXycx59TG/8AChHCrrFyflZpL8yrqvgrR9b1 601fVrQXdzZRGOFZWJRMkHOzpnIroBkNkLgkdhxUe0atF7F4XAU6VepiLe/U3fpol6dfVj1J cAHjHoakUBIzjJxUPlimuh6KWgizjcAeVJxz60j4LZXoBnHrRGFtmKK993Guc4LZznsOoFJC xI5HOcYNNr7y22o3RJC2d2w98fSp3bYBt53Dr6VnJ+9yhC7im+pGB5hUdMnrjpUgAIGODj1r Oct30DZ6iM6s3T2GajBywI9O/wCtUk9LBbexM20AAkAGkLhwc8cdaTk2m0T73LZIj+Xgcnn1 pzEKcKdpHB5601drUwvfUa0u0bmwAPWgODGDGeCecVUYtK5lvJqT6DlO7gcFefwpjoCSrLlW HzA9/anG7enQzlePugwUcL90jnFYPiqQReH7587gLZznbnGAf610U5JmTvb3iPJVPmx26HOO OtMDBW+cnB6Ed67qsuWdo7BRtKF2PDElgOnGOKz4dCSLxDcaqs0jyTWqQeWeiAMWJH14/wC+ ahTtzJrdGVbDe2dO/wBmSl/4CzbjcHODnB71m6cSutamg5yInA+oI/pUKMnzW7BilHnpSf8A N/7bL/M1FfHHYnGaH2uBhgpHXiodlY9GMHa/Vibxkg/hilUBsgMBmjlSZVSTQ6OTCgEcHqae Nu0lB+fFDTer2FDS7ZKMHBK8k8AcClVVwQo6jv2pXbNUkopEEvyvwOhxx3quUDsQcEfzpK0U 2VdczQjnC/MOR+VIJCyhQORWcF1HzWtYq25xqs+AQDGucfjV0/vWCnjAptWd0ZYaz5/KTJSN vy5IHrSk8ckFR0qLrc0inzOQKVLgr1zxTywZuTyvanZ79EU4q6EiQEEvgEHp3oUYx5h5x29a zk3flZrOoryaJixDADOOoNIAGHIwcHk0rOyMorXmXUYxVj8x4HPWgyEH3OcChKyBz2sOVt3B 60uAiqynJA7nNOUNLBFvlSKmoAmHAGDvB+YZFTN8kRIVmKrkqO/tVQbjGxl7Tlqt+SOTEFx4 muEudStJrXT7Q7kt5hhpWxwSO2K3PDpI0i0LnAMYOD3JrrqSj7Ky6HgYD3sZLE1I2lNNL/DF q353+Zqj5/vDJB6U8o2RggDr9K49NV0PeUvcu+hLG2AScE+lKuShycjFTNx5mujsXq4+YpJz jPDdecYNMkJVSMcE9f8A61FvesOzQpxk7Odx5GKaMRyA9iORQ00uUuNrkkJIJBI5NSNlVyxy CKxk+XdauxpeD2BNqsCMYqRpAqnGeR1rF+82+pnKFuhXbBGM8GlDZCqoyB1GM8Vs23ZWIbXL dEpKh8DPDccU4tluoxipiuaV35kVHpqQFv720EnGcdKeFGGCnJ7fSt3KKWmiMZLVtlOOZb6S 4gnhPlxEIWJ4fIzUyRxxBVRcKgwqnpRNTV+R3TMYuNROVtdV910SAbvlA5zk7jS/IAAN2cE4 x71o7xWpPO72QSYyQzg4A4H+feuZ8dYg8M6mwCg/ZXwM47VNJ++ovS5E7WDAAUnA28nFMBUs Qxznr6AV7E2+ewoRul3Hn5V3KOpA61Ip8sBeeOtZVXzK6N6cXqpEgKrggAHPFZ4Bt/Eyspwt 1ZEYx3R85/I1rThadvJ/kzizKT9lB20Uo/8ApSX6mw6BMKhB74xTJCOCOh9q5GpSfvbHr81l awzoHJ6j3pY8Ec43EZx6VeqdkJtNXJ403NjOfoOlSKAEAGTj1pTdlZii7bEg+/7lsgVM8fQg be3FZzUVYqN+vQqSqytwxyx4qs6GVARxxQ5RvzRKinF3GcKQCOCeaNmxj+lZtu9yne9yrbgr qswGGIjQ4B+taCIfmOegpT0+ZlQ051/eY4kq2XPTrTVGSQevOaiSTNotxlZCIhJ2jk56VMhC j5hu47UpSbWmw276iZUN/ez1o4B5JweTT96/vBuTE5AJBXPSmoOmc5x2pRd7roU7xeg11+fg dTyKdtAyCO3AqJ8zuK+txYh6dPelMeM7TjNUp2aT6kyk7so3spMS5PO8Ae+TVlSCqnuB1rWU bRTOeDtXkvJfr/mVNU3fYrkxbmcxsFA78cVFpUZgsLeOYlT5Kqwxg9P0NNe9DY5qtOX1uEra KMtfVx0/A0eI8FmLD2PSpVYEfKfvdPpUK0leR2KEnoiULtxtGAePfFMckyHGSpXn2qE7Oxvq xQDgEc80rDL53YwM4PeiVubQiU2rAW+YleSCOpxT/kwd3bp/Ws2pRsDvzD0wSeBjOKccbOeB 25oqTvburGik0rIWMgYDY602UrgcnLdBjpWC91jlcY3y9ecdgMc4pI5gOX4IHJroTny6E8q5 Uh6uDknkZ4NODK3UjjnnjNLkaZm3bVoazFckA4DcgUZIbcg9MenvVWumRP4rIR3VRmQtg88j pRnKgkZ9c072Ssc/K0nYU5UKrxvhjyQBgU5toGFOGK8EdjQ1K6Jg21dIif8AeDIOTkZwK5H4 l3Cw+ENRL5ZY7c7jjGPxrSME6l0TUmvZvuWS52gHoexGO1PjJ3YzlcDBNelWSj0HQtKCfUXJ blueelOUsqneCS3H4VDa5NjXkWtmWUHIIOSw7jiqWt7raSwvgAGtZgr4/uONp/Dmrou8lfuc uYU4PDTa3Wv3O/6GmG5wQCcA5pnQsfxrLpbod0ZKV59xrA8FfvEDNCKWPBy1TZuI5W2LScj5 uCRjFOBODj0ycnPehQi9ERG8diSFMtlueeD+FWNu44z8209fSs53vZlr3otFWdgAc4OD6VSk TYQAQRjg46VL5VsjSN4xsxu3aPfPSk3Fl2HOCOnrUXbLd5Ip2pP9r3GSP9WhIz0FaK8qSe3T inNpL5HPRjfmd9eZitx1Ocnv7UO5XGCMY7VKT0N7XvcQFkcZxg0B9y4AyfapjJfCxtaEjFgD uGD6CmCQKudxJ9+1Lmd9AdpKw9X3Ec5I6ZFKHDHPQnvUqPLMtNq1yRnKkbMGk3FSQewpptoz u02mAAViCCCwpykMMHGcflUxSS1LWpSvf3ghRQctIMZ4q2uVALbeB2HJrobSRzQlatLvp+o2 RHbAwPSgKFUEgHBqW1ymz0QqgB+ARk5NWV4VuBnFQvh1f9bC8gYsi9QxPSo+WbkDJ5x6U1yW sKala8dyUtkDbwc4JPpUbNu4AxjjFK+76jgldqW4EHBxnqOcUgGXbOG+XqRWbuk2wUbtEytu C47UjFnc4wAewFOMbyuzrSXUkKnCjjjp9KGkCDBIAAyKnkVuWRnKKaIy4IBYZCn9aQABV5wM g0Rcm9XoY2XL5D2KoRz9MClZhuPcAenSnG7XqXPma5gyd5AHUjFBJKYBBIzwOlXLRWSOVR7s acg4blh1wM09Poe5xjBo5WldkRet0gmkOwrGQrEfLkcD3pjkpGGYRlGIDM38OOmKqSe19w2i 0n5gJQ6oVbcHzyD1rh/i0+3wVqnAIaLaAe/IPT61WHj79jmre6nZaM0Gf5cORknggUIdoAYN kdAK9Krbm90jC25FfsPDYbDkbgcD/PerCqzDDZGBiona1/uOtavsi7brgAnGP60l5bi7tJIp UBEqsp7cVkpcr5m9BOMKkJQns1+Zn6Lc7rZre4INzbHy3z1OBw35fyq7tG4MoAwMVpUjZ37n Pga/PhYd1o/VaP8AEFDed83HNLGRIwPIJ71MJWOmCjJlpE2LgjI71MoDEAAbSOlTPSV31uU7 y+EeigSADuRU4BHbAGfxrJ3aXc1Ti5WKc8YY5zgA4NU2Ubtq9Vzz2pSlshxvLcjYhhkcYppX luTn+dJTsrFpa6lCD5tYnA3f6tQeK1F4U9wKme6OfDv4/V/oIx2pjkgHikAB6kn29KiclLc6 FNDmYdznHFRA/NkdBQpJe89i3sxN20FsBST09aTfyT+YpT0ehHNrYkMgB+Xr0BoRipPXgVnK psx3euvQeXKvxwe9D5frgk9jV05q977lc2iRIhB+YMTjqTS53EhduMdKzjPoDetytJ815DGd xKDef8Ktxvkc9u1bSat/XU5aS5qk5vv+n/BFYhwOo9fakCYU8ZqYy5Y+6jVpy6kyDHX8qcxy pKYBPr6U7dnqVKLigUK5x1Jwc0gyFBQDIHfvU+6twV3uKw5+U9elNbAJI+9t/Ond9RON1dMQ KOrNuI9KfAhkU7c4PX6Uvhbci4yvf+upKoPyqoA459aZGMsSrfge1JWTb7msW3qPWUouGGct xUUjF2PGARken0qet0E/du31A5I2qOCeakYBQQw/DFObXLGz1ZlJcqsKDtyzEZHUYoXOCSMc c8UOUOvQykmk1cY4wdzZJJ7dqkT2GQRn6VUr/EnoZTn7zj8hVUA9yTnFCnCgE4x3NTKSa1H0 UX0DOZCOSM8UCMMSp+cdwe9DTT0fYxXKpXZUSx+xXDtbE+U3zGP+HdnJI9K4j4wqh8H3O4ti RkTuc5bp78V0UG4zj3OWV7NmmSrIPLyF9DSRtllOOO4Neg01K73Oih8LuS7mYkjGB29asR42 jkgg8mspxt6lRjami5bthwBnGasl2ZOdykjJpOBolqm+5iakv2G9S/gTeANtwoGMr6/UVoKd 6Aow2MM5X0q6jbhGXXb/ACOCg406tWlLS/vL56P8Vf5jsBvvc56Gnq3l4ZRyOKmCd2d1n7NN bltG3AHHANPUAnHY9KJwalZhzuTSJI1KyZ4JHPFTbNoBOf8AGueVm7o0iteYp3OEB2ZAPc+t Z7vgcHGalK5tZbsiGN+0YwQe9OwD93nA44pSaewmk3uZ8LY1i42n70SDj8a0eGByxGew7U5w 0v3MMKr87/vP9CQhei7sZHNJkAj5iPx61nL3tDqmmpepHK2MsRx2FRF2YZBx9aLxS3JlFsdk gYXrnikZuV6nI7VEm7EbPlY0OC3cj2p8Z+X5zyRSkmtehcbfMQPsIAzk1IGzGNuSeeorNx5X 7vcf2dR6SLjvyakEgK89CMjNaz5rbEvWKZSscXEs9wc4dtq8dgMZq4rEY2k88YrSWjSMaFpQ 5++pKsm0gA8Mc09WGNxAUkVgqaav0/4Js1ZDhuBOAOfXtSHPHbHWtdJK5SaaHZ54PX2xQriJ fmyaJPQhNR07hG/UdDnmlZieBg1nKyZbspWuQTSiAbhzkgEVMrYwVbIxkj2q+bmS5hRdtETM 4znOQe4pizB1BAK89/Wpjqb3YTSbmBJbJ6g9qYODnd2xippuy0Ic76dh+7gbc8nqKcJcD5sL gY561Cg3r1BtN2HE5Q4Ix2pFYqBwcYJPPWmoWS/ryM27XEDgHOAQDnr7VJGMNgn73TNVOPLZ L0MLt69R5cKeGJY9OKiblGyDweeaqKbjzWCUoghLdQdp71Lt2DduBAHPOAKbUbbGKg031TEc gck49vSvOPi4wl0GKNC/726h+7gj74/+vVUlzNIyrO14mqQCmcHLY6HpTQR3INes5XbfmVT0 hd76Eo/dknoWPGanjOMKxwSM4FZykr8xra8dC/B+7AKsOW705nZsgHI6CrU4p2sEdY7gVDKQ wBDHBz0NZ0Cf2PMtvI3+iSnELt/Af7pP8qHNO6aPOxX7qUar+y2n6O35O34mopXYvQ88ilD4 JwAVx09ay0R6fMlFFmHG049eBUyEcE4BNKc0Yp+9p5kka5cZz17U6U5DHIG31rPSzsdVPXTz KF0x+YckDk1SOABkgE9Dio+HQp7jMFTjt7d6Q9CFxz61npKWmwlJJ/iZ8eRrNyNuNsS4PrWk iFgORzRUk42Sd9DPCX/eP+8/0JGfco3Dnp14qL7mecjtis4u2kjeT6dhhcHpyKjV1YHaSPYm nGLasxJ66AHI+93PY9BSY+UZx0HOetVbRor3ebUeFwxAx9KF53cnpxUptIT5W9BMk/gcHPeh WGc5IGOcmnFXWmxDnr7qJeMYJBBPaq2oXZMKKmPMmO1R6epqEk5LUirV9nTbJ7aNLeBEUBUT AwKsKpwoBwetOUkm7mkI2grD0wCSvXr9KkUDGTySDx61Uql07I0km0ToPmAORmkljYA7Tgfn WUZWZMnboRpK24hiTzUh+4elaTStoRG3UaVBO7rzzTwV2KTjpms3NSBU+VNsglQZKyLnd1FM t4sAqsm5M9D+orRO2po4t+8iyqgg4yu3tmmqFViFyQeeKmUrXLW9x/DMVDcU0Lnd1z9aHrp0 KT5VzNa9yWMoMHjGeBTWQIwLkbhzjrWVOTTs9yOo5SAN+T16UpZQUPQc496tyutiKjshfLG4 KAcNz9KdvBAY4HoT2p3TdiG+Z+gjjOOcHpmkRgU+cFg3Ix60l7rv0MlJNNL+upIhCkjt1HPW ld8O3c4wM03pJkXbdkQXkSzYSQFkLYIrzf4n2apZ2KRklJr+EKG7Bc4Ga3oyVlfdHNVaULvc 2EYSAHI59fXAp8ZAYcjHv716dX3XY1oKSgn5ExZW5YDcMYFWIywXuS3WuZ3VkdFla/UtKxKY 455NLHyQMlSQehq4NpWJi2ko23JsjdhipyfmGOhpl1FHcRGOUblPb0oT5bEThzRku6M63lfT HEN2xaI8RTHqPZvetBD8xbGR15rabV7x0OTB1Jfwqi1h+XR/11LsTnaCehqVW+XOO3GK5ZpW Ztez5kiRWy2SD144p7HcDnpWeqjynam1oULgldxBYf7veqMrKSBnp1NRfTQqUrxT6jM4DBsY 9RSB9yEAgAetD8yVPRdiggP9sXHP/LNOAPr3rSLA4UmoqJqyRGFs+fyb/QQ7sn2oLkALxUv3 paG6i+pFM2JOo9MVEAASe/p61KvdOwlorjlGUKkZXP50oIZAAAMdM021smE4+/qKzsn3Cef0 pDtWPDdCCSfShNu7QuawE4ON+QelICTwDRGdk5DcLrUc7iFC5ICjkk9qgsma5kNxIMLjEXGO M9fxppJLn6nJUTlOMPn8kX4yFAz0zT1Ybu/Oazk93Lqdd7KxIOrYPXFSbieM8+9Cl33KTfMi WMlmXa3AOelDZPBHIGKq6WqLilfURySxAXAIpoYqh3YAHGAKFJpESi3qh+TuGTjPBGM5pzKp wFBXvjNRTXLsVzWI5DnOTk59OtMDgcA44596vkWwoTajyokRvmwpOKezhpPnJ574qXGzTRcr voMYlvlxxTwSwxgdMYpNLoKa921xx+QFjtO4/rRu9c5bH0FDblqZ21tuxFLSEAnIJ6jrinK5 43H7vPSp5LtM0mrK3UdlvvMuMelP35TkYzjkUmk0k+hmne5Hv3ScL07+lS54C8A9fx7Vc4v4 Wc0Y2asJ0Ix1Oc8dKfuwcdsZ61L1k7IJJXv1GyljyxOevP0/xrzT4rSBZtDViWaS+5+iqTXT Sa9pE4q0Gk/L/M1Bu8pVY5wR0PenRAswCgZGc8/lXpTlacux1YaF+WCLCcuB8uR1OTxxU6TY GCvXrzWMuhrze5drYsx4LDIzU6f6v5eSAcnNVGyd2Je9Adjg4+Uk5xmozgvkYUjuTSlN7IcF ZJN6CTxrKpWQB1PB96oqZdLXGJZ7RV9SzIM9vUc9O1OnKCjys5sUpQ5a9Pdbry/rU1bO4jli RomWRD0KnPapg5yQCcCplHmLjONSKqLVFlJOhPb0qd3ygyB0z0rGqmrep0vVXRQucFzxyP8A Cs6Q/wAKjJHWpunuN6LUgZgCN3ODinDCZwMjHeok3YIQb/ryKMTkatcqoA3Rpk7s+vatLocH qe9FRNysZ4VXU15v9AEhVMHHv701/XHJ5zUXa2OhuzdmRk5Zjx+NQqCAzgAnkCi1lYW68hwc x9ST0pVbcMDrjrTV3qLTmv0BmxtUn5icjmkc4GG5oSYmuopwMZG3HbsKNwUcfnUvblY3JKJB I51CbyIziCM/vWU/ePp/jV9FGcKMBV4GelKyiuVs56Uuebl02F4DHv6CpFbONvA/i9xSla1m a3vp2EjYBWycfNxVoMzKM457ilNWdzTRrUeh2yfKML9aez5xg9ulHI2tS1G+ob9xbOAeCR61 GGY5wo4OeCatxSumZuDeoKSQSCc5pHfBxu5HWofvOyNIQbdhZJF4wMH60xVAyX+b6dq0tZ3u TorpEqKQeevrSnBb3FQ5N6Gypu90x7YUggY56daaRxkkDHU1nJSuLVpNis5PG3AHSo0lwORx 7U4aaNkNLV+Y/jflR0PIp8TYc/KvHqauUVL3UOT2/rqPeQhDg4GcYqMONgBzilGK5bruZxje T1JFwGJ7Hrg1ytpql5e/E/UbEzTx6fpGiWztGJPkmmuJpuWH95Etxg+kp65GNHHmi2+1/wBP 1OOpHWOu/wDwTrSduNxBKmnkFeZRjPT6VlflbdipxaV1qV5H3gEh854B4ry/4sTkar4fUhcr cSNgt1+Q44rrpqPPHm6XOaopOnc3x0QA7R296RMs+SxAHfOCK7a0rSbNaCempKH2v8xyR39a sRNvdScYPcVk4q9mzonL3Ui9bHPLNnHB471YEvORgnmm0pXG3GMV8gyAQe5AJqNjyduOR+lT rKyQm3JthGozgcAd6fgMpGcEUS31GrXkQHTUDGSymeCUjB2nhvqvQ1GuoPbIP7UAQEgeYnK/ j/d/Hitnaa10Z5qvhtfsP8Ga0D7iNrAr/eB4NWJRjHzHgZx61y3to0em+VxUl1KUuA5wACTy T+lUZJCD/dxkbfSpsm7sb3Uf62GDII55yM9qUAlQCeQOM1hNR3SLT96yRmwNjWbkswBMaAAH ofWtMZ2jryODTm25J+RjhUuWVltJ/oAXqqkHHPFMbkHH92s5yajax0pPm3IZWwcZyTjr1pmc 53biwpxiuW7HdBvVjycepNSAkEeXnGMA1Ts0kjLl1HEF2DEgY6ZqEYOcHkfxHvSi3qOb00JD gjaVKkdapvLJdSCG0b5RnzJOy+31qoJbyOXETcVZby2LtvGtuiogwB+pq2oLKCQcetJ+89Sq dLljYVQoA9zk4pGA+cBic9CPSoVrbbGsWl5ig7vvD5uMVLncoOPu/wA6z3fN+BSl2JQ2V64P qacrkDDYJA6461ab2KSvoh6kZGM49u1NYbhwSB357UnLuEY2uI0QbG1jgcfh702RgC3PHvVO aT21HBO43BkA3kHB6kU1m5CgjAzmnF8zXYl2i33JkBBOSB6EU7lSMkEYqXKPMmW29EhQuH+Y 4/GmiTCjkso4+tSkpu3T+v1L509xWUbcJxu7elJEBwScYGP/AK9W7Xv1Jk7aD8jBz1BpUG4H kYI5qZJ6tDjZJp9SVQQBtHXqMUjn5huOGIwuD3qklZJamEmnLbQNpyCSQB3HpXN+GNGns/En izU7t2J1W9hEUYfcqxwwLGp68EkMSPelzK0orS6M5q7jpt/X+Z0sQ4Yq3B5OadImSCTuZveq lZSSS/qwtegx3CscsBg8YBP615D8WbgnXNGCgnYkrHvzkflWtNXVzhxNV8qsdQuScbgWJ+9n g0K6k528jr7V6NWL5rL+kdGGl+7v0/4BKSBuzndnA96ngIRAAMFh+VTLV26F6K1ti9DId2G6 Ag8HrVlPmTcB8x6gVF1GxrzRafqKhJT1wccmmuw3de2ADVtq7cSed7Cs4OcjnHahPU4GewrN 2eok/fZajJGdpyfYYqvsByGXCmlfqT7vM4kMdg8Uu6wYRgZzHjKn/CrDakLYkajG0BOArfeU /iOn405KM2ktzjhH6rotYfl3CeVXVZEdSDzlTkGqrMuM5HSudxUW0eq5wlHRkDNl8mmo27DN zkcihRtIuPu79SlCc63cquQRChJ9eTWsM7AqgcDisqqba9Ec2Fvyy/xP9AVsgdRjrUbAAZGe RgCsrWkdT1bZDJgHpkjvUYGGIbOfSr95+gpXu49R7RrxnGSQfqKkAG04OOOg7UuiTFzdENEm SMD5cdDUM1zHCg3kL161Stz26kVJKMW5bEEbT3z/ADjyoM8ZGGb8O1XI4fsygR4CnOBVySjo ckIuf7x/ImjOWPGMcj61KGY5XOOOoFQ4XbOxO7t2JFXCHkAZoIUghQMjqc9alO70IfkBHzcd uhpyE7Wx2GaXV3QRi7MFJ68/jUysShwcHHXGaLNpmsVYcjqBxkKOw7U5e27BHTpTnFJJroU5 Ny2Dyzk4JH1FNmjUgh/wNNtbhe2oxUJ3buPQUqQ4XI6n8jSUk1aJCfM2+4+EYU57GlwFOCBu bvUWi5WLjK17A+Ofr+dNcELzjA6HvSglbcrmdhHIc5GDT49qjDrhiOR0Ga1WiuhNu7XmPwFd snnsQetPiXDAsDyPzqZz9y5Kd0Tc5G/lcg9eaR8KAGwAORgUlJSso9TJt3ehEcEA+5zkdqVE jixsCjfknb6mqhH3VcJPW/YfGuMNH196cEBXjByDgg579qUmk9TJP3WVp1LjBOMHJA4zXkHx PcyeNNIUgY+yyAgDBxuHWunDwTeu1mcFZrkR1WAVUD07UIFA3hsHoa9GasjejFKFuxPnfuZg ME9aekgUjHUdAO4zWErO9nsdW9nc0InV1z0Gc4qcOAd3J9cDPek7pak02ua8X/Vv+CTBshQe qmoXbJ59aIwTj5jilrYUn5SB396fHtG3AxjOTROelloZJSTtclDFjn8s07O0DOPc1k4qKTTK Ws7E0bbfmJGQc5ApXIdP3oGDn3pJ21TKT7mLc6ZHFIxsmkt2Y5+VuD+FUw+oRjEiwXAA6qdh /LpVXUl7xxSozoO1Fe729eqG/wBotGCstpMg/A4/Kmx6va52u5jLDgOhX69azalJtX0Ol4yM Lc10R29wkniGVldGUwKAQw9ea2Vdf4f4u2KiSbST7FYWUG52f2n+gpYMSFzjofWo2YZIA575 rL3rHY2tWQSzxRvlmVRweTj8aibUbeJABImM9M+tVGEpJNdTB4mlFtSkQNqqY4SQsxzxGen+ TStcTy8x2xAPRncDn6Cr9krXZzfXdWoRuKsN1LzPOIsHgRp3+pqS2sY4fmTLtjGXYk/rUyaT vYUaXtbSrPbZdC1kAqFwMcUuBhgKW8dOupvytKyJA7Iw4HX6VKJAVwuSR61Li2rJlQvF6ksY CcEcZqTyRjeCPek3ZjulcVVychdwx1oYMOcYz2x71W/U1TsrjA/zen1pUfaxyOQMAVnrG4kr ocjDzGHXJ61MnT5uPQ1Tkl1Llra/QcWD8Nxg4NIzcdRg+3NTJKVmxS2uxjKwbPTacAetAj44 XK9xQ7Wcu5VoWaXURPlCjBDM1Ss3mZz0ptR5rslJp36CemTyDxSIoIzjquOaiK5Ytm0ndXQM mwEYAPqaFXKnI6LjFELWSQ5NpXHqAX6Zzjr2qUYVlBJIHatErq5lVcdE9iRW3M3Yj1FKVDnA GQRxkVnGPLbsZtWvYYYypK4wFOPbFOUoASMBQOuaqKd7mLgo6vcVFwxxnrQqsu50IG3A5q3Z O6M7Jr+vUZOAuCMEk/w9a8U+Ism/x5FkZVLAkDHq4zj8v1rbDwaevmY4nVu21jrN6xoPbHUe tCyDnIJX0Peuyo25X7GuHV4pNEhmDKMBuTToW3dCenWjl5U2zRpNJ9GXVn2qBgdc1NHP3OMH qKiVmrozjBqLRP5yh2Xux9elMEqlzzx/WlGVnqayT5STcCwCgc9D+FLv2nJIGB9amTvL0Kkp XuPWUng5J4xntTvOyMDrjBHpRy2SdyPibRJFKMMuanZwYsN94VjNpTsy6cXe5TnmDvjBDetU 5xk9foPShLlS7iinzlcncCB0zSiJcfOgNJytbuaOnBuzMw20MuuPAY1EQtwyjC/eJ59+lW00 e2fqHyMDhjVOUkvOx5VDCRqzqOWjUmlb5Dm0a13YBmOcDcZWAzj0pRpsCEZ8w8cBnJqVVl06 nR/Z9Pm1b+8k+w26MuIlyT3Gf1oEUaOdqE4HIxSi525TeGHpqTfKOypPygBfTpSxqw7ZU9Kl c1rPqaezUWrBu5wBnmjeBhcA571Kg3FGT21FRx0bkkk5NPEgAIXPWqcXdxRc273WxIPmYbsZ PQVNGVOcgg9vrUaxeg46q7LSNv2g8kVNuUEKRRNczuNrVkuBvIHfHSpjB8ucHAHem7JaiWqs 0U54/nLFfvfzqFyVO7A565qW7o0Ss0LEQc7h1PGKkEuYznqDx71Li3uU+ZWXQC0bEFl3fNki pgUZ+eAO1VZrboOa5nZCsnO5uT9aYw5+UA545PShtaPoRGLsLkKBkcqeD+tNydo2qo/xqHLd y7miT5dWODbcgAZFEZByrEgEdfSmpXWxfL7txzrz82WLEYOOKRVPmHAJ6Dj0ohra2wm0kXEh G4kKSB0qQQZC8DIHSnBMymm4/cS/Z92Cq9BnrQYe/GSc1VXSyM/aO78hrw5Q4+uBTDGojUgs oHajVRbJnFzWo6SBvLyAVUnOM0tujbG3AknGMCnBX3IlDqhLi3Z9rKgQjivB/iCu34kzQqpH l2kXc85JJP5j9K3w75po4sTLkjy9zq/ux857YKtTfM2Yb7xx613yaT917nThfgXoPaXDngjn ipEYrjABB64HaueS3sza6Wm/YlWTcv3jhTzn6VLFMQB8uQoxwaE48rRcou6HJPtJz1PapFm2 NkZyOtTKzdpF8ujk2SCfbg4OAcYoFwGC4J3Y4PpWate6HHVXQ9XEYO4k8cinpcds8D0o5roz UUrEqzhWHJ+Y5NKJBknnNZ82l3ubO6vYhaXcDt+71+lQSHzGDYBAFDVndEwSUmIRtBI9RT1b ehLDGO/rUuSd7Dle/MjGgm/4qyVQuQbMYP8AwIj/AArc8wkYA7fnWlSC5k12OHBayqt/zv8A JCgBV2rk561GpKtgHAB6msnZXZ6FtWOR8ghxznio2YIxOeAO1KM3J36k3dxByMMeVFAJ6MWC 44xxVptNomSvIN4DHAJI6Y70pIJBB6Uop2uQoXTGgnOR68c05WI/1oyGFVpLUm1nqTISzA4w O/tVhFBXnOayd3LmQQjctqykcDGTUqLsIKEknrQpOOjLkm43RZQqTgbhz37VYtwShbGMjkZ6 VM/hbZFrt3ILpDJ1HyjHFZ9wCmQq7toJABopaaFtW27kalu+4HPrkU9B8uFGc+9KpKyTNU27 pDzJzgAnnr2p8b7GK9d3PXp/nFOEnytDs7d7lhMvkvznqaMnGCO1TGK26DcFzb2REVULjGOa MsW4X5R3ptJyu2ON7u2w4/Jj1HU+oqQ8xgjnIxVIp3cfIdHGGGGJG39adEvynAPPY+lUpq1j GLRft48bd4yO5FXraJGYlR8x5qotbLt+plVb1LKWygliBg9u1QvFndgbQR2rN8z32uYKbbDy h1AGT1x1xTJLZckMBh6U5RbuVf7L6jjCWYA5+VvxNTRIFPIHPXjrRHVpsyuloh80JWNiACe4 r5w8dkTfFDUwBt2W8AHOccE/1rfDpK7OWvFSSZvoSYwz5zgcEYxxTHZt6j5Rx616HLaVzrpK yTew5znqfY+9IHbBUHHGR70k48tn1NoyWmmiJy/7vHv0NPhcjOD26VlK0ouTNoq6u9yZSCBz x157UrzFuhBPY+1Ypu9hxJIX2sVLbsYOOtCyBcdAVB+lPa7Rb97Ye0gOSp4GOKcj5QhevvUp JxSW5FrNCiTPzDqPShZN4zkk96G+yNGrC7xkA5yaQlh8q4J7j2rNNxVpdQkg3ljlsgDGcUMw 3HGcjvngfhQ5JIXNKS5TBgbHjeXBx/xL1I46/vG/x/SujWTg5z04rSo9F6HBlzXPVT/nf5Ie XCtn8aZ5g2gtjceuaxTSakdrvK7Ig53kcDmlxlG9/wDGnF3TYSsCv8hLd+BTixHfBHtTVpO/ chxs9AUdWHpx7UxvlJDED0PvS5rK3b/MHZqyHs3K4+XHWmmXftGG3DjJqkrRsQ029CaPccAY bHY1ZjLd+COvNQ2re6F3yE0b78DORmpYpSuSucDsaa8ylJ8mhILrd6cHgmplvMIcnjPao8mO D93Ue0/mHG7FVJiVI2EZPXvxRF9kG0rEbnIznPPagTFACQMexyazceaSVtzSO3N2FBycHkGl GFcEdccmtbu+gJuxOlwAVBGMHjmnmUHlW4I/KlsxpydyJ38zbkU7LqCqkenWlOKukOLtoxys QcNjp+dOL4GCxA9hUtgrpaDxMCuAMn1x0p8cpAHzZYnFOUmn7wr6XL8UpMYOc471bgmCYZm2 n0Bqoyd9FrqYyWrRZF2Nny5wKiMgdMZGT79Kd3e/XT/MyUGh6ShVALZPtR5wABIySM4NTKN2 J/FawouAHU9SegqVZ9oB9s0uWzuRyp6ojub9QGOcjFfNniecXHxJ8QOq8K8Sg9uIwf6124Z/ F2t+phVShBLqdQ+7bknkdDSBlBGNg+UBj3NdNabk7IvDR5KcX5D2YDI6luScYpm/bk8Zx1FZ 2k76nTdaW6f8MLvUkEcEtx71LGTuyTkAc0Nu1ilGyVyTPzZIyB1x6UsTBzwODWSu1oW01Hck WVT90nH160ofaMdeM49Kh3a5X1KtdqS6ixlQMnjFKGwuM5PbNF2m7ku97L+rEiNxnJyTTwRn DEgnqTWbbsNXd0+oZXowBNBYoN3GAOc0TSbstCnP3rCfKxAbOfakRwxIbj3qYu0ml0HJtRab MJGH/CdTRh1G7S1J29V/eHj+vSuhVuACScA8+tbVOZr1X5Hk5fNupX8pv8oiySBo/mGOaQ/d GMj3qVFvVnqylaTQCQKCCcHPWnHAAK4xj1qISkrIybtJJ7MTG48H8aeI8Lkk8/jQp+9yi5HE QqAThiM+1IHI27j8opX20/4cblZaD3PzBhzzTVyfvdR3qoNasTersO81TkLnI68dKlVwgGTk 4pJPoTeTWpKz527MKQe9ODrnknOMECleUokxTbTZKGH8JG09eelCzHBHao5mkDclsSIxyuTx QzjfwBk9Tip5m5Nm93sG9mJyBwcnFIkhDHPGR3oXNJlKfIrCByhwvrS7yT9aJL3rjSstBwCr kdRngEUoJz8h7VXMo7iUr3f9bkigFwSo4p/y7jnIGCcDrUynZ2NYxuxykH5Tnkcg015CvGdw x6VEleSbHGSs7IcsgcAfd56YxS71Q/IBlepPNXfVJkrsWBNkfJnqP5U8TEBAeQO1Tz8srMb+ J3ZOJ9j9R7ZpDdsnQg01JuV12MeWyuxRelOcghvamrcFwSGIP596evJqjCablZj0nKglSOtI +p7lKqST7GhQ5pN9irLlu9ipdX5MMhVxjg4Izmvn6eUT+MvELncp+1Yz64GPWu3DNq6W3U4a 8+tu9vvO1IO7C/Nzyc+1KMhjhsYHOK6q818zTDQvBX7AclSeoB7UwncgKnjuPWojFr3lqdMr JKwsbAAbuOeO9Tq42fe4x1PaonGTa7FNpKxKCTINrY56fhQRzkNtHvzWcbLVdDabVrAhAPyA EA9M09WIPBBBHSlUvB6kxtKdx5LdNpBpW7YBGevPOKTu9S1Gy9bk2SjKq9TSFgGPOc849KVl 95jG7lYb5hZmJIyxzTw2F5PeiSSkjRR5egpIAySM5zUYkHOBUrmjJrsJvmWnU54TLH8RthJJ fSiVHpiTn+ldFNK65MYLZ7Dt61pOd4xcu36nmZdJOriNPtv/ANJiP3lECkcnnJpwmzjdxisG 0lqz1HZPUAB87Nk4PFEbZ9CQOAO3vWtrvbYwc0tXsSFuycDPfvUqO3l7U+bPBrOUVfXqayUi NsMBluM800gDG0c+5zT1VifIkwc8ccdM0nIzzwetLmSTViZxvqhFbc3HXr1pxfBOe/WqdnoS 1e9vMkRiuT1AxUiuGHAxu6mp57WGouIpk56Y/CpE5Hy5P41lL3YuT2BRWqJArDkcvn15pTn7 wJyexp6NcrNJRurhv5GMj0NKAWHHUdyappoLpuzG4bcW+7g0K4HJPygdTTk1YuWt7AGKtkg8 8Y9KljcDA5IJxjNRa6fKX5Eq/uzjgZP5U/eRyuOmD71Gsnd+Y5qPR7j2kCKc/eaoX+UZYkgD nFRe6saU7JtMQv8ANzwCKFYAjc2B6VVlokZyjyvfUlEoJbsAcVKsvKlTgDrmqkk1r5jk02pM GmBfjPXimiRmJx1IIxUP3dCZNfC9gdxkFuo7ZqXzmVSA64I4qlJOCQouNmRrOoG3qQTk56/h TPMLA+VgEjjmrb5W2tjndRW1K1xIEXJLMWwD3rwSwl87WdZlOSr3shJ49u1dmH1d+5xYucUt eh6FwUA64wTx2pNmHJAAwuMDvzXTWakXhE+r6ASS/J+vHXio4uo3cjtntWX2TptdIlHsxweg xx+dOVcqQuct+lF2tgVK9ubdErAhvmPfincsoJ4UdTisrKUtOhtHZpsTG1jjK7unFKuXwABk deOtEm3K5XIrX7EiuCwZMn8M0uN/zRtk46+1LTZ7Dk3e6RIrMw+YdO9Pxu6fe9Kzfvq6YoxU ZX7h905GPwpHBPJyDip5rPV6CjawHgc5AHeowRgbT8pziujmb0expbojmLtmt/iHpBYkC4sr mPj+LaFbmurLEZA9KKiuoL1/M8bBSTxOKa/nX/pEf8xRnYe4zQ+So3YGO3espJRlyo9S6YFF ZxnkZ79qkMgUcHGBgcdazu+bcmMUvdAMcgnnNSB9w2nHIrRRuJzV7DmYqhA6k5xikyMAnPPX HaobX3lTk7Ow8/NkFsgntTWPltgkkdhVQtdp9TGeuohOHG1iM9acrbjwBiiGjfewoq1kShWA ycHPTBpw+aP5sEVmpc116GjldaCIWwxB596njyU+anOyi7bkxXvX7Em7BDLjd057UPJ3x82M Hj3rKCnyLU0505a9B6cAEcrx1FJy5J3HH06VUo2V0UnFPURyNwAzk+lOIKjOcmnutC7vqh6k ltxA56mhAqE5BKnpg4qOaSlbuA4lmUngrnkAUm5hgNyB3qm9bFLWFxwY4wD/AI03fjJHp370 nZaIE0r+YGP5gRgj0pTy2Oc9afKr3E2uw+QZBAHXnilTiPHzce1D+Gz6lTs+g/cCCRk8d6bv KRhiBnt7Um7aIzk3LXqIJGd+R37elDKpbgnpUR9yyREveWpE5MY5K59qVclctw2OOBWzklJr ozmT15kQXrFYyzgjacnPfFeCaJ8yXTsjZa5kLYHXnH9K6MIm5NXsceNXLvuejZKj5wT0yena mKxJKkN8vfNdlZHVRb5EvQcW2ksQSRjn2pqkEbRkn+VYpRsdKbu09CRWzngAHk+1SLz8ueD7 0lTa5mtiY9uo8sxyMjPHH86UMUGCc7RnHXNRJR2NUuVDtxYZ7fXpTTJkhju4HapnZOyewoJJ u5ISO4688DvUiS5BA4POO1RbQvfVD23Acbs5pfm43ZyRyPSock0XGLauwJAHOcimXFx5MTyO eFHU9qaafzMnFW16aiCVXQEjg80B9wG3sDWrVrtbIqD5lrsVbjSYb7UbO8lVxJZs+xg2OWGD /Kr2CFXJ7c1lKq0lpsYLCxpVJzW7a/K3+QscnUc4HJoLDaGIPNNJ7o0WqBH8xsjgZ6U8DcTn tUTtbzKa9+6HE4PIO70NSdDlu4pxMZxSa8xfMATABz60m4bcH0o5bMtp2sgAwQQQc+lICHbn jFNO8/QxUluKrZBBwSOpxT04IPtTSUfmU7bkgzxwRj/apVcg/SsYzc1e2hbVk2h6kKflpADt 3Zx3xVt3ZMuaysSq5YYUfMD+dOYkEbweRz35qWmltqwsnePZj0y+MZwp9aEcAkDIU85NS4O1 kaO2lhRIGYjByO5NOMp34HTFWmlK3UqMddxVBPynIahDjP0qbWWpV9yRGLrkHAHalxkfMB/h RJKLuaU0+gNIC2FBBx16UbRghuuKTWhnG7uIqhRuBJycmkYuR8oznvSjfrsPnciSRthAHIHp So+4bRnOPzqWk1Y1k22m0DZ2tzkjg0x3LR4Veg70NLS29yLcsbMBKVYYHJ/nTElAIEgJyT9a 0UbuRzS1hqCurBuCeeh7cU8uNvTrxirpxsmyY07tL7ylq7kWEr4xhDnJ9q8H8PMfsRc5y7uy n2JPrV4ayUu5yYxOLPScjbliq7eCuOlNQgsCeQg4IGK9Ssr3sa0JKEE32Q35dxyR3FIrLv6E tg4PfmuV8zi1bQ2knKN2PBJG85IHK5HbFPRiX4wdw7mmpc0rpjhdb7D0kAIBBBbsTn/PSlZl IAGBzwKycU5XWxputeo9pFU9MEdPekZsOM9MelRTjzLQSb1RLkEnO4D+dO3IRwATtqWvvNIx 5kAkAGeufWnFicMpOMUnfcq67aDkBHJbjrg1FMoeMoQGBXGAO1OLTZlddu4yJh5K5APAI+lS bt2csCMYA/GnHdp7Ga5otJkmzOCh+UHpTj129iOaSSaSS2N073b/AK7DlxsGDnPAoU8VD0k2 Z2EyA2Rznt6UsbHG1uPfFW3HluC3aFXI5I5HHXNPLHAx160pxaY2x5OwFo+vWmqxYAjsDmpg vdbe6MnJyQIBvPPBIp2ASeRjsTTk3cUY8u/QcqjkA1Ju4w/1GKio9VpsXOS5RzOMgLnr1oB2 nABzVRtyK39dyZXTfmOjJJI5AJxQwOAR260kktB3k7kseBlycYNKmCoAPQcGlLXfWw1q9R8b bCd5OT1A9aTIznIxUztys05HF3sOUAyg5/TFTOoHBOOKW7Un0RUmk0D4ABJ70vBwMYb1qbOU WgjrG7BcjkjODinbgRwCTjrUS95aGsdEmKpCkYJ4700EggDBUDGT1zVQd07kOy3YpOQwUYI4 waTHyZ6kikmrjdk9R68fK3yjNOYjbHjJ3dRnrVu/XqKbir2Wwh6Y96QnnqfmByCOKXNG6JnJ t2GSMTt24z39qQsBwNyjGMmtFCLbT8zCq7WtuEaDzBtGOM4xipCVVc85YZ61Kl0RmrR3RkeI 5NumXTA52xswx7CvDfD7MNMgwcHZzzmurDXbu+h5uMk5LQ9HDBhlsndjjGPxqPOQvQcc4781 3V278qOijJRgokrZGdpU7ieKRjhBjOa5m+Z9jujNcugolYHCnaS2evH1xUiqQucbsdxxTlTs 9x3urCYO7AIznntTto5LEcdTnoaSd9WVJ2SJSNyk7jxTRjGG+U5ycVnFtFxat5kynH32BJPA odgNvOB+Zp6c3MxR5W3y9RTjGcnOabHJ2yBk1DbSs+5uk3DfYlVyWKk5564qG9LC3k8rO8qQ D6ZqVDla5TmlU5oti242oilvmVRipV+Y89cVo0oz8jOK/dpPsiRCQ5AOfbsOKNzMSVxwOQam a5W2a8vu3bHbWzlicdqXcFxnJ4zUuOiHJpuwvBb5V/Wl2kqctkLzwaWi3JdnuPyuCMZ54NBY Iikg56cUQd2HNbUfuI2nuTSAKRjnkZpKNpJjklfyFVMA7sA+lRuWAwSPwHatZP3mZSd9iWLK qd2evT0p5B/2ee9ZJpyvclLmVmOT5iOSDnJ96V23ZDdO4Hr2qpR6o6FK2qQ9cbhzRHk5IIJz 69aiT11IUWiQMcYIyODSKgAPJHGTUwkldX2LtZXJdxOMgc0qpk/eCjqeKhxs7hGo5McFz6ZP Q+lScAcsNp6nPer29CxRjdxgjApEyGxnhuSfSpT2uJPdCjIY4O5geeaVgFUYJHqfemlyxdhS 6IQtyeRz1pGfOCCx+XgClC93pcqS91SX9dBxPy4Y45yOaQMQeWyMdO9TZ3QLVisWyMnJJFLu GB2OOlaJxcR1I2jp/XQGlIUMpwScAYpGlIxvycDr2pez965mrJtpjcAqAGxuI98Um4MvXJPF KPvLTfUzqJStZh5437XyGxjp3oMingZyvQDk/hVOLi7pBF390wvGU3l6DesowRA4H4g143oz Y0+Ag/MYgzetdOFerPJxbirWPSScx/Lg59KgZgWOwDgDPtXXUp3lddDehflQPxkdwcdKOSAQ crisXC7sdOi2JI1AbJA4PH1qVWHlYIwfb/PpUJzd31Nr2STFUDfuHyhvepFO5AB6AjNS3Nry K5YuNr7iL8snTCjH4UuFOAB29aU1Z6DjK8rPoCsBg9Ce1SRsCDs4bHJxQo3ByUWIQRgrgn0p UIbIxnA9cUSvE0TvH3UOywb5VU57ntTxhl4I3DrWT0le1yGkojOTxyMnmnq2clQCT+taP4Uu xLla9h4J3HdgMacpMY56etK90xtdhzsGAz07AUMpGACOuRmp15k+woxXxC9eijGfWnK4zyAe OlTtpccY3fkK2Mn2PTFBZhg7V2kcHrQlZWJ+JOxIq7VwCc56U0gt94AilF2tcT91NCs2S1NV QzZGR6U73k5ISimiQKMYPqKQcZ4BHpkjFOLit/62C1loS7djgsRz6U/JA5HeiVpK62FBX3FQ qDgEkg4/GnZI5AGTWLTTaKTbSbHliCDgGn7Rnnk4yfaj2aWsTSCvr1BWLdAACcVKnyZ4+8MD ntSs9lsNpCgEEbQDk8E9KVvvEMeB6U37y5WUrbgXG4emetHBdhgHOKUY6MV0P9MAAk8jFNHA fgVnqru5TXujd6ggbVHOMd8mjdggcfN0I7Vq1N+hE1yxH528deOPemrJszkcYpWd7rclSbik iQsCpLEBmPJpFfPC8nHXNRGUpLQdRuV7/wBdRjNypIGAe56UgmzweGzge1W1Jx37Dl8VkRiQ CQcAcUwuQhB6Fc/WnaSloc0Unr1EUqDyOB0AFKs4LPsbBGcgHnir3VkyldxvM5jx9cGDwxqb g4ZoGHHGDivKtOJWyiCdAgz+XSt6KV9EeXi2kk2ekgjk5259Tz0/nTUAMgAwcjqBXbO8Z7m9 O3s07dBobaTtHJPHpSBwoHTCj5h+NZqN9ehuprR/1uS42tjIG3kYxT0fgADoOtYvmu7I6V0u PJ2uuSDk8DFKFBzggEdqd5W01uDac7jgT82SDnpk0iEIByNuMAGptzFJP1FGOgAzn86crKFO T74qb7kSp9kKXUIfmyT0BFNByccDHT3od5dCoaNWHH74A6jnFKpwmScDuM+9OVmXfdMdkew9 B0pQVzkj5gPWpSu9GRoviQqkbQd3VutSqAFOeM9Sf0p8tkJNNIeuA+cYGaA4KLvAyO5NY+82 XJ21HA7uhwQaaF+fDcnHanyu2gaLVDicuuSvA4xUhPI3HnHGarSWg009hwc+5564pAS0asvy seobg4oitL2JqQTQjZJAPX1pNpAG7rzThNRbaMVuSKNvQ5zTgcpg4znrU293Upwu/wCvQfHj b1PBqUrwo6A9am2tkWndIRjiTjH3uB6U4HdyuOR0pJXV2NxshwIJwGHWn5yzYYdMVTko6WHG +6EQE/IMdeamw3K7iBjtWL1VynZbji2xgpYcU15Ae4z3NOK69AuruwhkyVVcYPU0B2zxtyPw 4qoJcrbE4p3uPMjOpxgc00sAAGORjnNKWkbIpaAG3A87eaZKd2DnINClZ2aFODcfUlkYbeWz 6VCzHYCzBQcYJGMU+VK1hR95NeY8gZ5O3nvzQh2sNuAzA9OlGySFZu4kjErgnvjI5zUe59vp uHy5pxcWtDGcuYC6kgE/N0PsKa84OeVI6ZHrS9m3ZozvzK/Rix5IIIAJPXGadIwjXjapZc8D npU25ptryFKSikmzividIq+EtQLsM+WB7Dnt+teaWJ22sXQfIM/lXdSno9Dz8Upcyb2PTWPl xgPuPHTOTUat93BbBGORzW9ZrmOmneS0FkbdgE8g4BpASg6+3HU1jyu++hd7Wi90SI2V4zgA Z/GhW4B7tih+62dEVazQ8NgkN95jzmnqQytx9Qe1ZtPnNNOW/UXaAxJPJ5HqKEBbA3E+tJtd C1FctxSdrnBBJOeKkVvlA5GPUVLtZNdCNbXG9flwQCec0BRg9ieBVN31KaSRJuKMAy859agu RLKyFH8vP3gRSirzs2Q4tppbssIVC4PToPelLKRxxkcH0qGmpaDgpWVxdgQ4DZqQOQMHJ4xg CrlJuOwaT06km4ZAVhnsKb97GD82Bj6VK0Kmm1qSDCsQDg54qvd3K2qM5BdsYVR3PYVVK052 kzKvPlhKXZNlfTdNENw15dZa7kABY8hB/dX0FaZOCOD05OKJu87PYxwVB0qFm7yb5n6v/Lb5 EoIGNpBBPOaXC4Bc54PJ9c1lGproddm+hFgnJOM+3agIV+8c5q4y931M3H3m/uHqQBz0A4p4 UBQc8dTUNvogdndoeWyowoGDQDxnOCamflqaRvewqsCSRnGcE+9KZNwIOKThKT30Ffv2/wCA PQg4z1x0pS+71GanVTdzRK6ux24jDYP3u1Pjn+bknBGQRSvfQmN92DPlsvkhjx36UkhDOCOA abTXoCj1kPyBkg5P0poLAqWY5Ix0o91S0/rqRLV27AJA0Yxzg4NBfHcjijkdzoje7SE8z5cE 7hnt2oDkgkk47A1Uk5a+ZE3FRs2OLHGD0U85pgOUGMjFTZxb7Exd1qSEgk7jkjpk0I4UqI2O MZPy03ZaiS3Sd0NZlLsMnPqBQ4DYbGOvTvTUZJJsxlJc3ukIJaXOSf8A69OBBX5fnyOgFU3e OjDl5Fd9F+o5W4XruBxxyOaa8hQAYyecHFLls9DJTU3Znn/xak2eF7gElQzoDjjqf8K84t2+ UDGMAAKOa7YwTjeJwYluzR6oCBwi7QAMmmBlcKAT9WH5104nlck2dWF5lBW7CjIYbTuAHORS AbdoxyVJ59aySVtDZtNq49c5HHU4znvUiZYD2I4rOTu7s0hNxaRKFBIyMtjk57U0L16DtnoT 7mmoWi1/W5q9yQruc5zjgH2H5UA8YCFCw6ZzWCWtl2Er2bExjgqM+hOMVJgbVHVSOoPOaG1y p9yuZLcYwBYkcZoB6rzjB6VVlt8yHGVk2SFlOCOc+9LvU5BGcdSegpXvowTu/QcOMkjgUit+ 8G3AHTBOKzglrY0qNpJruPjZNx7YxUmQSNtV1S6v+v0F15gyVY8dDxT0OTgjkiofR31CS2sP D/OSDwDVDK3mpBJAGS2Xdj/bPT9KdOKauceKbcVDu0jRj+U4PIzT8ZznP+FQk4pt7nW/ed0O 4xgDAPSjLFcdyOOelJTv/XyKlboND7jgZ69xisaHVbi2uVtdaWNWb/VTxghZOTwR2OMd62Ue nU8/GYidFRmleN9fK+zNkYOCRxinCQZOBxWck72k+538ttiQYVSHwXHrTwcBSyjHSodr3Q79 hCwJwRjkc5ppOCQxBPY5qru+mxk5aNIkBGeuCOgFOzn5VGT3puOmpUXa1th28hTk57H1FMJ2 kdhjNJK7YlOy0HiU8LztJ5NIznYCuORxUrVamzWye4omAyHYdhmn78AbsfKCQaq8JSQkr+g1 TtwByCcmgSZJBxgd6TbTfYGktuoA7WwuGNDfIB/s+tUtNO5N3N3YpfdgHbxgn3ozjJbAAGKi TtLlBNXTQr7cjAGc8j0oWTIZBwSpyR29Kh3UG+pTT5bLYMhyWOAR+OaR2PbBOPxpSet2ZNxk 7IYZAp2nb7DPPtTY5AW+RVDYx0rWME4nNUlZ8pNG+CD2PAxTSAPmBXJBAGec04Jx0IU49Uec /GKYroSj5VLzxrwfpmuCiKCEbuSR16110I3OLFPax6g/I3NhR3GM1EX3spO7ae1dVX49Dsoa QWo8yhzwSFPOPbFB6jADcdCcVh7sEipe8/IEkC9OB25qUZK4527cH0o3kkaJ8qHqzLywAJ9O RSgsCSBg4/Sok1c6VZ7ixttGRwc880pIKDnOOnFJxvNom8EvMGcglTwPSl4KYIy2cDFQoNuw 1KLVgXcXBPUjr707POAfmH681eiGpJya6IxtVv7ua/g03SmSK4ceZPOy7hCmcDjuScgVZ0mS 7V57a8ljuJIcESKoXcG9VHcYNDpwUE+u55cMRWljJcr/AHafLa2t7XvfyukapYP936VFLexw sFldIzjgO2M1moXbs9z0qtSMI3qOyMnxVqs+naK76eoe7uZFgt+f43PB/AZNamlrPHYwpfSl 51jAkb+83eqlCMIczetzyqVepPMfZr4FG78227fgvxKnie+ntNOBt5fJmkniRGwCeXAP6ZrZ BwDyxAolHlprlX9dTshXl9eqU38KjFr195Dt/OARwapac3mrPIAAWlI/I4/pU3T0CtBupBer +5GgG+UBgQarapf3VhZiTT7Q30ocZiEojITu2SOo9O9SopuxvXm6cG4q7RbglM0CSOjQswBK N1X61IMZ/rSmlbTr+pcaqnCMtv8AMY7AMOf4ueKhv7ZL62eN1yCOPb0NEbX7GdaMakJR76DN JnaSF4pifNt38t89Tjofyq8p2v8AKeRVVE+Z3M8JJyw8U99vuJlbruxgGm7u/r0rHc6opNiD AB5we5pN42+pPWrXM0kydE7XHiTcdq85PNIz7if73SppQknuU1EcH28MflH6U4SfJuP4Z70/ ZpaNi3RIz5ByPmJzn1psjDaDg59u1O1mVyrca8gccA465pySMcAAHPANRCVlqSmm7IaXOCuW 6YB7mnggnK+gOMUuVuOpo3qLIxMmMAjvnvSEll5BHoKI8riQ2tX1HI7AbTgDPJpCwC9ct157 Cqm0npqTFJWYNuDEkYOacowoJIwOCBUtxjLmuTNvqJuyQQPmHXNR4YkY6jpg4zVprdvYU092 MZh8zDnPt3pqkiIDGcdOefzqV797HOparUnKlm5OVHIJ7cUMQpJkbIYY+lEW+azEo6JHmnxe mxplqjdHuk74riFIEAx1xwK7aMftHDi0rRd/63PT2kXG3PTGM+9JtDMu4gkdjXTWSpz0OuhJ uHM+gzIBPYlvXtSsQORk+ufxrKpGXOUqja2HlccY4zw3rTomH3gfy781F3ax0KK5lLYdGpY5 DDbnFPyTlSeccg8HrWa7l3XKuUViAMnHXqTxSF8gZIA7e9U01qnqXK3LdihgOSBndwBUqlZG Y46jIqNLN9QWj0WomMlc5JB9aQ4fKN6c49qnVO3kE5xjqZejhPtV9dkgmWbbvbsqDAH0zk/j Uukt5z3N3IoVZnHlcdVXj9Tk1tNtRfoeRR95wi9+aTfpd/8AAG3+rSLO1npZR7k8ySN9y3Xu W9/b88VlgaZIsyxxpq1wF/fTyjKKRnOWPAxzwKdKDS5+rtfyOXMKlKvX9nNXirpL+aX/AANP mypotoJrrQ59xILyNGhJIRVU7cZ+ua7gDHH5etKsruyXkRkEZRpuo3e9v/SY2S+TOd8QXElz ewQ2m0+RMm4noHJGB+VbWl332uJi2FljO2VMH5D/APX6ik0vZovDYio8zqKWkZJW9Vzf5S+5 l4Z2Z49qp6SQlknIGdxPJ9TXOnzXtue1O31mK8n+lzRGGI3Nx3rK1bVn0/UdKtYkWRtSnMfz HGxFUliPfpTildpEYzEexpOf9au36mt5mOPQ9+9Y2t6jdNdW+naTJHDcXCtI8jLuESDvj1zw KaTck2Rjq06eFk6XxbL1ei/FmBq+sa1Y3UGlC8jMkrlhdRwAyFQPu7cEZLYGa6bQ4rs6dEdZ YNehMO6gKSM5HA4+tdM6dNQU0tWfOZVicxnmU6VWfNGCs9LXe9/u6E0ebTVZSCoWeNTj3Xj+ VXw+77vDHqfWudp2TZ9NhrJziuj/ADSZKPmwXJ7HrTgAvI6Y7VnfS3Q6lK+qGiTOMY5zzQZA p5GSBQuZyM7p6iqVUbhgnOKw9J8Q+bql5p96QJ4ZD5ZAxuXr+eKtJunJ9UefmGPWGqUW/hnK z+52/FG5wqEnJwc5qR+cLlcds1DnA9SzatYXeIyNxBK/rQWOCODkdPSptuOElFtMaknZsEU5 TjDLwKfLbUWju0CqGAPAyeT6052wxGdpHAJ707Nyt0Q9k11Qu4DpgZ5ANDfJk5JBHHtU8t5D dm3KwpYgAdABg8daXcWUEYwo/Oi2vMQnzKyFVd2No+ozjApAS2SMKOoOc/Soi4y0Ik3bUaVw hIJJJHNNYswByhB9acrXTZMkndDS2TgnJz9OaWPBYBlA28fexWrirmTd3fqTkgEnqpGBzUTy KIzu+bj06/hWVKLer6WE772PLfjBMGh09TtO664yfQVxaSLtGBgMMZ7e1elCNoen/Dnm4lNt I9XZwACnC4AFMU/OOw528VrVumdNKX7tIa5XbuXk54IpfMBAKDBIxnPGa522kXqxyZEgBIAX mplfJwenbBpTSvY64rmix6gAnBAzzn68UdWKt35Gaj3opodNNyuxxO7IboT27YpquqjGMk9R UXRtFfcPyuDnBIxTWZTj5e3GO9C5tUwlKV7RKt1qC2MgMyMINpJlxlUx6+3v7U1tbtlT93IG Yj7salmP4CtfZyml5/0zgqY+lRk41NGvxuc/9rERks9SkksrJ5GkG5f9apbdt3c469K0V1Cb V0W30JGhtgu17p1wFHoinqferlb7S0PncPi5xXLFfvH7sdNrv4m/x+Vinc+GZUu1Mapd2q4Z YJZCAz9Sz9dxJ55q8dHvb6AW129vbWRUBoLU/eAP3SeMDp0oVVSV29tgjlWLpV5xhbllpzO7 aj1t57/eWtQiFo1lc2yDZZMdwUc7Cu04Ht/Skn15Jx5ej4nnkHy/KdqZ7k1m+aULs9aVWGDn Up+S5dN9LJfkTSWaWsNvFkMxuFeR2PLNnNGo2Nw0gu9LZIrpVwSwyso/utz+tCe3Yl4NyjOn f3kk7+abf4tk2k6hfXLNHqdl9mKqPnWQMrnvgdR+NT6WxWCSOMYEcjDHXAzkVk4KMmlt/wAE 6aFarOFKrUjyz966+S/yLFzdpZwtNcK5RRk7ELH8hzXI6n9uku7TX5Y5xb2M+Y7XZhhAwKs5 HXd82f8AgIFbQko3TOTPnOtTVKmtfifpGzt82l9x2FpeQ3MSSWrrLG/RlNYOvzf2bqomjuYI bi9h8qN5sBYUQksfc81nTTdWzW6aLzTGL6j9ag/hal+Kt+LRT0OUnXobkpL5NwrwxSy8tLwr F+egJXj2rs1wCee3Oe1aVm3y3Rjw9UtRq63fNe/VppWfzKN27R6naiMggq7YI9hj9azXk8RX jKY/sFgueRgyNj6kYrOMVJKUlff8zbE1cZzTjhrXb1b6aLobWnJcw2UaajKtzcHl5FXaD+Ha si9k1PXb24ttLuDYWltgS3Cxh3dzn5VGeMAA596mPKrytdb2LxX1uGFpUVJe0lZX+TbfySNP RdJ/srzQbi6uml5ZriTcRj09Kzb577XdTuLSxvJLCyswomkiA8yZzztUkcADFEHduWxz1aVf DYOGGhN883bme66t/cjI1K0vNA1Fr03F9OVdPLkeQsrpjDK/v05rRt9HnurO7vZYzFezXH2i 3HUxgYwOPUDp712c8eW62PmaGGxssTPCTblb3rvu1JK33x+5nQaVqC6nYQz42mQfOndWHBB/ HNXsAoD0UcCvOq+40rn6BgK0q+GjUf2kihrN68aRwWwH2i6kCISM7R1J/AA1ntBcaJe2h+0S z2twWWUTOG2ttyGz25z3rVJcuq3PLxzquu5QdvZ2f3tXv8rlbw9q+palrd211hrAO6RL5YGz acD5upPFdSvzEAjFE4RUlFdh5Ni8TiaU51lpzS5fRbDgeMMcjPQ81DeyNFZzTIm9oo2bZnG7 A6Z7VnF3k7HsznZ7bkWiXv8AaelWt40ao9xGrGMNkKSORmrjryAyY9aH70vS/wCByYTEvEYS nW/mSf3oqWWliwvLq5SW5k+2OHdJX3KpAx8oPQYHSrZY+VnHJHccUm5NJ7lQoSpJq97u+uu7 vYkJB5YHIOQfrS7h6EkdhUez5m5PoarmuNkYl+uRnP0ppcfwA56AY5NKz5VbczvdtsbhS5LA 9hg9PpTl43ZwMYH69a0tfczhUd7EseDlVGWyRytVnYYOzI28HnqaUZN8xLnKL8jyb4tSh59J Rcvmdmxnodv/ANeuSjcJyzDK/nXo0ZS5LW3OGuuadnpuesuqsMEfMOOveowzDouCy9c81dab lK7OmnH3EIc8fw/h1pUcM20Dcuc8dqjlj8LNlD7ZIrccKTz270qkZBwQfbvSlDVyb1NLPddN CRQVJx06E/ypykDGe3J71k3e7N1Gz0FZd24EHk9D0xTV3hsLtGBxxUQtL4uo9VfXQcAWBKEg g9CKaA6pnpg0LqFr7D/YDcAR0FM8sRHKAA9SAOacG03ch04Sd7bCui7hwTntT1OMbflx2x0q d0n2GoQuLgBwCOe/1p27aB8uB0yOKrS2vU3jtZjl24AIxk0xNkJPlogyeAB1pc3RmNWEZNNr bYjvMmW1B5xMCSemcGrKvkENzzwQOKqzVrHMop1Jv0HKSBn8OaqRN9mv2DEgTLuX0yOtEIpt k15tSi2tmaJO7A4I9TTHwflKA5BBzyCKi91ZnbKCkr21M6x8MabZ6h9utrSJLoZ2uM/LkYOB 0BI71bvtNttQ8r7ZFHIIvmXeoPNVezu9zzqWV0PYTo8vuybbX9dBmoaSuo2xiLNC8ZDRSJ1R hyDU1hFcxWiJfz/aJh96XywmR24FLntC3UtYGEMU60H7rSTXpaz+4z76Ka91KeK0maCSOABZ ljDbGJ9+OgpIdD1K5VV1TVpXXncIYljLc+vJFbcyjTS6nl1aGLrV5OlPljzNPTtY3hiNAnOe nA7DrWNpFzFpt9dWkzLHJJK00ZYgCQN7+2MflWUI80Xbdnp46Spyo1JPRNq/qmkaF3rVrYIf tM0SbjgLuBZj7Dqay4L02Nw93Ja3H2G/becIS8bAYyQOgIxVUqbV0tn373OLMsZCMoSguaUP eaXa3K/zf3FmaZtfMUVrDKlskgeSSZNhbHOAP607U9S1K2meDTtIkucFRHMLhVU5HXGM8VL5 VLkk7GM8VVSnjKVJy+FJbX639Lv7kP8AC+nXVjDcvf8AkiS6nMvlxghYgRjA/n+NbOVKYU57 ZFZVNal0ejlFGtRwMI1/jV27eb2+VzH1mG4ivVv4VWRYIDGsWMkMWXL+4xmq1lF/ad2hkdrl Il3PIRhWJ6BR3AH61o+VwvfZHl4inVeJdKT+Nxa87KKf3JP70WNAVbV7y15LW9wWxjHDDOfz zW3Gpbnk8c1nUfMerladPDqCXwtr7mwjUZJXPUdax9d0q41AStHqd1bQLAR5UOAC3ck4OR04 pxdpbGmZUa9XDOFKfLLv2sUPBNnfixtJ2v8AfZmIkW5gC49g319q6kyLGhLNhVVifanUac/d 0ueTw9QxFDLoRqz5traWsklYyvDerzaxbTy3AjxFcMiFVwCvb8cGtcldpxwem0/41FWHLJro j0Mux/1vCxryW9/wbMK48UrZeIY9Mu4vKWePdDMWGGb0rcaRRgF1DP07Z9qbhaz7kYXHRq1a 1N7wlb5WTRBZ6fHprSrbiULLM0jK8hk2sxycZ6D26VZ3g/KQSD+FZR0R0U6Ps0ox2/4FxoO0 YYEnJ6ikSUnpkk8HOcCtNld7f8Ebjqmhw9MZySc5xxUBcdcYDA4XPNK2m5Mp6nkPxbk26vpK iPBUyEH8P/11yoOAucg/3sda76CbSs+/4Hm1k+dJnrRxg5yc8k01SRggnB5PvWlfmTWh14de 6khzDnJPfjB6e3+fWkDDHB+UDoe1Yc1/eOlN8tkOjcjGDgDjpzUgxszk5xgjGPxqZxklrsNT lZscBtJJHLHt0pwkwfmyRjAGeKVSL5tOhvDbQf5uXAI4/nTXdSM4JJ6/nUTg1sO7lFK4bgxX uRyeO1L5m1AD3H40co4uUosF+Uhe+QQMUrFgcEZ9MChalpcq0HCZUU8sTn0ozvYE4+vrQqbt zA7PUAwAyDkZxzmnM4GG6j2pNcz5gdvhY5GxgscEHinBgCQoJ59Kp0pNpLsNVGVZ2/0m3Vic 7iR7cVa5fABAyOPcVNrJGFNP2k36fkg8wdAuCD0zkVFdW5ubbCYWRW3Rtzw2f5URWpnWg5U3 EjsdXS7YW8+IrxD+8ibqfceoq+zAYMZOe4/vVXs0neJnhMU6tJd9mu1hd4JH3htPPNO3L5Y2 hSPeptqdevMrihgX3MM7e1QXepxWFtLNcNtWJSRz+Q/GojFtImdSNGEpy2WvyK2iJJDatNcK Bc3b+bIuc7cjhT7gVo+ZkZOAPWtrK7ZzZY5/V483xSu36t3JfM3MpUjpg46VBc6fbXsOy4jD 4PBPUGs4pxV09jbEUI1IShUV090RW2j2VnMGit1BByCRzxV8gIBuGeO3QCirUqN6nNhMBQw1 PkpKxInzFW4BzznvUpYMc4xgdTWUnskd8YSilYT7vb5Wwcn9aCyhc4YZHIpuFo3XQb0k0xGX aRwSAe1R+X5RKR5VSO3alThqriklzJ2uZ2q6Ct/cLPDdz2kpIDyQHaZE9DWvCqxRIqEkIu3k 8mnUne6/r+tziw2DlCtUq8ztJ7dE+/zsP2/vSxOMEGmyZdGDfdZcHHftWd2mpdDqUWokVhbQ 6XYxWttkRwjau45OKbqenNqdqYXllhjJw4jbBcHt9PpWnXmZyTwreGeHi+VWtfsYWm3Fv4b1 iTSp98Ud/IGsm8skOQvzLwDgjHeukUgYOWAxggVpVSk1Lvb7zz8p5aNOeFSt7NtfJu8fwa+Z x2vSQat4j+xRtsuILWTcTnhsKUI/l+dVrjUbm+uNK1SRNlvp06I5LcOWwsjfQEd/et4w5VGN 9VqfIZrWnUxOJjh/taP/ALhqDbf4o1tX8ZrYXyJBB59nFKI7q4zkRkgnj1x3rT0rxBZa1E5s nbcvLxupVk9Mj0rCVB8lz6LC57Qq4+WG2/lffTX8U18iTWtUGladNcgAsq/uwe7HgfrWCdY1 Pw3En9ryi+We2aSPbFsMcgx8hx2OfrSpwjrzddvluTm+OxOFrRcH7kFzSXdN2S+Wp0NpfS3N pbyzQBJZEUsqtnbkZxTpG/cg8Et3POPapikm1Y9enVnUpxm1ZtJtdtDxv4ssP7f05UJJELnk cDJHf8K5pZAuN4Hyr+Vd1Of7q/mcdWm0/wCu57DIcohXvjAPWmEBZPmHXg9uf84rWs/f5vM9 CheMUuthXUBxnBI746Gk8vEYPRsdPX61zX941c0lZD41U8E4Y80qhucgA57nrVOHO3IfOhyR 7lGOSpzzzzTmBBJwMVL03ZonFp8o7bgghRhfTignepBwOB25P+cVm22i4qK0bHCXAGxsY6nG eKZlWGAV+YZJ9veiztZm/N72uw/JGBuyV4ziljLY+Y5Yd8UONle4Ozi2hd4LEHBBbg44pyqS nIwR/Oom9CISTsRuNy5/unJp4TIHA5FNyt7qNFaTcmP28DIXPp6U4soOWII4GOtTFOVgtFL+ u5WnQ/bYGJDYDEmrBIwAzYyOPerXLZWOON3OXYemcHB78AikL8DBzn0oheUmzola1kVtS0O2 1YD7ZCrmNvkYdVPsaXStHGlK0cc1xMOMefKz7cZ4GfrTVRI5Hl9L6wq8W0+ttn6l5sgjAyr9 T705ckkfKeuBWWy5jufQeCVADHPTpWSdJa7vjLfTeZHGQYYQmFXpyfU8ela05pPY4sXQ9tBQ b92+vp2+802TZjA79u9PVQEweemfaocuZNo7F/MSKmSVXgq3p1oAwzbmB9+alTTlZkzbv6jy DnlvpSxqcjZlhjnNJyikEYvls3qSQ5LAcYHtUhBB+U4yOM+lNO9mtjZ2dl/XceysOSGAHrRs yi1mm07ilZC5Ib5QDnnPrTGHzZ4JxzinzRUb9xNX22uJ1GFAPtTsfKMkHAwfap5otakpe+l6 jtykkj5vQjoaVTuAAVRyeB2p2bj6B7u29wK8kADHGQT0qRdzRgDg84HrUynzQUjKNrjXiU7D wWByM9jUeCA4zlup44H41S91CdneSW+5l6j4a0vVHzeWkTMxyXHDf99DnFTw6Vax2X2ERL9l CkBccdc/zrVSlZpvzPIWV4SnXlWgtZJ3876sjbw9ZS2i2giAhSXftXjkHP5VW1LRZmvLW+0l 4I7mI7JldDtkiJ56dwOQaIStqnc5sRk9FUv3UbNctvKzbX4t39S1qsMMli4vYzMkfzeWueSv IrlLezv/ABTFdXt8siJ5RFnEwPy9OSPw/Wrh8PNfb/h/yPOzqnPEYilhoJ/vE+Z/3Y3aXzkz qdDvft+nxvnDx4SRcEFWA6EVZm3KoU/doklFtWPYwNR1MJCS3aX5Wf43PE/ikS/iy1G4bUt2 JLHoM4rno2YqVbA/u4571003FxfkFRdGz2aQnPzLxnHX2qIKN2fmOOMnj9KORx9DaMVGCt0D AOFIJB9O1KfmPcdB6VL+LXsdC+FPuOUgygDAHQYpwyV6cjj8aaiudJlOejXQkyVwQc7fWnAh eQecAYxXPN+97qN4K8bCfeOWGMnn3pSBswP4s9e1KUHYHZuyWog4b5sjNAUsg6nHIIGKpNXR tdO3oPHB5DfOw+U98CnEnA44Ix/9anJK6sGuiQ3gfeyMHHTml80ryuRgA1Ld1rsKLu9AABOQ MZPPPelVVB5yfTFK19Gi7RT0Jy5UjAyc9SOvtmhlJhGMkgfSojeOo5OMo36lVgftqAYChTwe o5FWChU8EHueMY5pynG6VtTnovkcvX9EKGwT1HOBmgg7zw2cc+hptWvc2TTV0v6ZKT94ncMd eKcH2cjuOCKhK+goy2bFVF7ZHHr1oQryQSc+orSUZPqFo6IUNyQpyxPFCZBBcH61Fkpa7j5n LQUMV3bQSc077pJIOCBzTstH30C32R4O4c5OTkY70udgIHBI6+vNLljrYdm9hZI8S7l7YyOR gU7IIAUAcZ4oS91Ck2nZIkRAXOMlRyOam+5g8nt9aTbeg1q7slXH8QyM9c808fJ0B6dxWfO0 r2LaSWnQQNk7WPOeahkGMA9cYHvVRUFJtPcUtNRCCq4UkA8AigAt14xyMColD7S3/r9DJvmt pYcv3iOcVKxUDLDLEdemKqUE3cUpPZIacbyJP4/fpQy9gzfKc4z71La5LdAjtyvpsDBsfN34 /Cotw8zAJB29AarSLuiZ+fUcwAKcsAOo70w7gCy5BB4FHPd3XzMlCPwseRjnIBzycU3HlHdt yxGN2elP4VYzlBPYM5OG4GeeKjZVZSAQMDnA7ZqVa9upD5U0+3/DGYuk20Or/wBoKJEuWTY2 2QhXHB5XOM1ee6jkDKrBmiUZ/wAf0rZU5zV2zCjQhh3LkW7v87a/5/M8S+JcmfF+AOY7cLk9 8nNc8GOcEHHeuykotPuc1eXvJHtD8YVDtIPA/lUKsu392CA3XI6n1rWr1b6nTh7qmhQ37sEH O5h34H4UoIIJJXpwMc1lzR53odC1TTF2kDLAnng+oqTH7vGBjv2rOpJyduhbpq2g7ezYHGex I4+tObLEbx0HUDrRKzlc1gtRMkuPvAZ5OelBJVFXcBuGc+tTpypdmPWMmkrjlUgZBB54ye1L jK4DHcBxk9qmas7lpqKHLlQeg6ZBPPSjsDgjI7UNcq0KXvPbYbvKg7SXIAJyMfrTUO1VHGR9 4GlHlaaG/dlt0/r7hY+2M5Hqe9TDC8tgD61c6fLpIuUm7uw9GC8EkAHpnmpGKkDdjGPeudwK 9zt/Viln/iYng8Rg/TnvVthuGWIAB6Yp1LKziuxy0tXN/wB79EMTngFWGevSm4Iw24YOD1zV OST8zWSdvdJd4Zhzkgd6FHyDce3UULT3Wi+a9lYlYuQNgUjPNA3MBgjHTPTmnzRT12GoNO6F UkYHcevSnQgqCW3ADoQOKz9pq3HYUqbTWg4FWAK8YPQetOByuSeD0/rT5kooiMW5aoRm2qDn cCegzTg44GCxIJyBwOaFFo1ckraDwxJ3ZwCefelPPCnHHPvzUu9/ISROGYdhjr1p6HCnIznj njmh8vRg4yWq3JC2AecYOcClCswGzoOvNNXbTZblF69B2DIwAxyepPemSKMAg59Dmo5WnqjO UoyVvmRnJBG7APLelABwV7Y6jirppRjy9jJSTdrD0bG4Y545J9qCdr8HPB61nGWtytFqH3u5 x6+lPwMA7jz0qHyxumjNXbuNaXPAOD2GaaQyDABy3PNawtyxXzMZt7tCYOcA8Hnnt+NKh9+q 9CeAKmo4229S46S121G5y3XIPejaxAUMAUGFAqpVIR0sYaJqzGrk7hwpLckc5470ZyDhuTgZ zgGk0m2oozekUmQsMn58dfTp9aikbI+XPHyg7e3etltuOo7HhfxAkMvjW9A+ZYokXAPTqaxh 8wG4lT3zniuyirq6OCs3zXS2PaZcggnbknv6Y6UhI5K9Cc5zx0qqqXPrsmdNNtRjZgThANw+ YjjHApBgJhQRn7pBxWXNzNo2TS166kkZ4+Yghenp0pyHgq2SCf51nNvpsbq73Y4FlP0PZqcJ OSF7dOetTN2sOE2CkqBuAXB5xzikY8NtJYZraMWveW2pUZJ77sFDMCcDgdakjZQSCAPl7Vg3 e5c9IpdUKMgjAyxIH1pjZC4XGcYz604u9r6lJ2Vu4u8nG3BC8GhAPmwgGM4qVHlfN2BXtYds CpwTwetODbs7eQM8dOBVxU3HVdTTmXM2Sh8tnPTH4U70GVIxySc1mnZjUnIzo7SaHWbi6kk3 xTRRokWzG3GST15zkflV44KgA8E8iicqloqPQxw2H5FO+t5N/ggEYdWOM4OBxS4VSrHPPoM9 amMmm09zeS28h7DcODz7UY5GcjIxgdPzqlHRxZmm1YkXPIA4JGMn8KZuI3DoMHt3zScVewU5 8slIcrbiADxkg5pRnJ2tx0JbtRKF1bsXz+83fccZGZCRjbnHWlBGOTnkn8KLNKyIT1HBvlIA BIPWhCwJOVAPHHTNNxco3NHLRdkOZN5HUktng8VIo6hs/KOPes+dyUibWkiYOWIAwC3JwelS puHIG0N2pyilGxrbldybYWBK9FPrSsSOgGfas3dKy6A3poIUCgAHr3/pSei5xkYGKcleKTJ0 s77saSVYr8w2nr2NMYAgADHPA9jTT5TJPlenQeoIABKnaeeaQEmTcxBAHB6cVLtKTIu07Nin IILAHsBmjblQRkccgU78qtbQfLaPudR7kFF3LwDgUwMSPmwMr06Zpv3nr5/iYSd3aIoJYBQS oz1zgU3AxwBx3ByDUu8ZE2u7Mb/FlScdMill+7yRn/69EJP4ZBazshgY88jnjimcscHnsSeK 1UeR8xz8zav0I2CxnapOAB15xVeVz5R7gDvV2bsy01seC+N5WbxnqB28LsVcn/Zz/Ws4/MVz jBHLD/CvQpRUbL1OGru5fI9slIZ+vAPfqfeo43BkGcgjOVzwKis7N2WptSi+S4uBGMkAfjSI fmGegHGD2qIawb8jXlbVh6nc/C4Axx1zTkcIevOR90VnJpaLW5tLRLXyFd8EHjDHjBx+FKHG 48kkjkD681guZqxrHZoMgHB4JPJNKTjg7QR3Azk1pySSSfoDqJaMeCGdsEf4UqscjJOT1z0x UqLa1LU+Z37Eg4KjqVIJ75phY7iSe3pRDTVFcyv6gxCA57nqO1G7g7BtY9eaqUn8XQaTaaF3 K2AeCPXoRRE4JyMEdsU05cr7DXxFhJMPjjJ9s0AqpORjgnk9ai3K9OpSctLoqT3eJhHbr5jk 84OAtWAx2DacE805qUF7xl7VyqSS1t+Yqkup2MBznBOKdGchQQAE7g8UpJvUucnFCq74zkLk 856U7cznb1CjO6lJ3kxKTb8rfmAYgAt/E3Q8UMxYEZC0Ndthp2SsHTJbCkHn06UDkbXp/ZV+ oKpLVND13gfKucc4ApfMzjcADjtQrSV10CTtHRDxKTwOD1OTzT1LNgNg4HXNTycquXFpoIyx +8QPQetS4IwSe3NObWz6ma6xXQnt2xnGG2ngHvUpIXBH3CMjnvWbs2VzKw/ftBzjH9akyvHr jpUzbutNzaLsNf8AdEgEAqeO+R3prYGGUkE8dO1Ltcmo3JJvcQ8HCjgcYxUbYaMbiAw5Az26 UoO+qMFCTW/e4BhtVWA4J6GgZAAUjgY455ptN3CPvU9R+4OwCgfePJoDgYJORnr/AFo5vdZz Xk7pvUMfOSpJPHTFC/dAZhnBwcZpOpLRWN01KV+gKVKg8Eg4znv9KaWK5BIjOMAk5qXLmldf 1qZVL7EbkFlOIwSee2aXG+MtIwOR61pCdlZ7mcpPmdvkN3jK4HA7jt7VFPJuRlXaWx3/AKU1 zJJsqT1aXUa+XJUMD+PNQynNvgna+3AJ71tq9PMx1Uebe58+eKpd3jLVWOPllCkZ6cCqMLbm +Yjg8H0rsjNyilHc5Zvt6nuRYlc5+UsCPpiokdc4QDcOuetZVfjui8ND3FFiu+F+bOOeh/pS gnYFH3jjHNZONkbJuUrDo2zgJkA9qUnaDjJ7kY61UdGnYGr2ix6MrHB656dcUKWjXn5sdDjp zWakm9F/VzonzLS44EZIIGWGQc0ikEfvOSe5NW9Ha5MXZO4vmCQ7WXkkc+tSAfMCpyq9qm7i uXuaRg7rXQVN+7bng9ec5pXQL8ueeRj/AAqXdLQ0krK3cQsBjAwBikUADacg7fWnfSw5rRpO w3aCCD82/wDCpVOAD09hVXlHYG7aIfv3HHGCe3Wory4EEWVJDPwn1PFQ6bclYKlXkp3e24kE Qhj5y2SCznkk1KrEglcgn060VIuT17k0F7JLT+upIpTZksMU1xtbKZ9cDmqU5J2exXNzXil/ W45XOSykk8cUFt/UAeoz3pdkg5tWDSbA5xlvbjNV7C+W7Ql43ikXh4yeR+VHvJcz/q5jOuoy jFre5dUkj5Rx6mlDAEg555x60ltbc2lfoLvDLyclevbFCs5HK4wMbvSiKSVkaNaXJhuUBlO4 Z4weopQ+VwxwSRnBwKT5fsk8ijG/QRG2MFXgnrT8+YAWzg9amytdg42neJOrsCAeACMVOHQH 5uSF6+lS4t2tuXGdk13JBIAAFzyB+Jpwkxkc4x6Vla0rFTla3cQ4PIIyp5xzSFuSSOOgxROb lp1RnHTbYjMg4bDdcZ60wMQvz4UkEjuM1pdpJGc2rprccrZA4B9SB3pBkDBxtPfb70krQSe5 nzOLcF1F3nzPmU/X14o81tpwOM9AKmW1uonK2/QM4IODnP6UgmxhQMjHHNVZ32tYHorrqwdw 2w9wemMUwkgfKufQfSqhK+pP2vvEZWV+ecHqaXOSpGcY/DPrSkrtJGa3sMklYKMEg9MHpVeW aQoGiwGGOcZ7+lNQat8yZ2lpsIku7cHBQsegPSmzOBCSwIbaeSc4q2nz6hOLtp6Hzhrlw1x4 l1ORsjN2wxjGccVFHIQuT27emK64JJXZx1o8r0PcWLg547cDvx2pAyj7g5Kd+vbNbYizndHR QXNTXoOx8vzHJzgEfyoRQxAU9hjPNc0pRtqW3o+XcdtZjnsOhpybnzjay46j1om4xW442aUU P3nAAwQTxmlAU5z97r04rKPuq6N1ZLl6CHg7hnJ/hFLu2AbgMkfKfWmnf3mXOyik+gpA2pyC ydDjvSnLZwPz4zQlG3NLzHBWdugTMyxnyh+86D6mo7cNB8k0nmMy5O4+9XSlGSsZzmuf3f6u Nu7+OyKIUaWRgdsSDcT/AJ9az77xBJDaAW8Mkly52RxOQBu+vpTjSS3ehw4zMlQUrRcml+PY FF7ouiXk17dG8vBG8hdl2qrYyAo9BVnw49zJotlJqLM9w0AaRmAHXnt7YH4Vo2pU3JLXoZ4S piI4mnRm73hJyfndflexq/NuLAd/SqrgzajHGQcRIWw2Op6VlSkl7x6WJheKh0bX5l4/OhAB AHqKj3YjVTkjJ56/571nNxel92dS1jr2Qch8jhTjgDjNIdx+ZQOlNpRSk3oZxa3vqPXOWxwM 9hQQF3cnGKFUS1Q4q0rscOcEgZ/M1DKBDMkwPB+VvcHpWiS0v1Oeo1KMn1RbZnwNp4zz6mms CT97oDjHJPOaiKUXZmyfPexKrYUk4Yd8j0qQOf4jw44FRyc0jRyi5WHgNsBwQOcn1FCjKknn jOMZ57UpcqVjSVOKjqA4UbBgseuOtSgtyqgHK/54pTVrpmTulZdRVcsSDk4/CguFJHQlTyea SlqkjaaVtSVJmLfKoyRwB2pV3OPmbjHTFKTimrCbi1qAYnHTnmmtMyhjnKnnbinywcnZGbTh FLoPR8qd5z6jvTUJbBwB2APtQnZtroTNq6Q9HxkDpnPAxmmqxGcryf4R3rNO0nd6mV/eT7iF iXJ3g49qUZVSS34EYpzac1FdQ0VmxCTgHgHpn+lGGEZGBnHaras9DJybuhr7jgLww6kCkXLF c53DueKHawtEDblbLZHOcd6GfYq7ThsYxjrRGKct9wqfFcjyXbnnGDkdqrJIZeo2EA4Gc1UE 9l0In7qbYkpkR1JPJ52j/Go5twhbcNxCgnI7/wBat2TstWT7ZNKysfN+pyl9a1BiVObuTBB7 A4qG2zvRGJJJrqjolbqrnLUqRbbfke+MxXO8AHgcYxUS4DKCGyfpRWSjK0TWkmkvIccsegBz 3PtToyNoxtIx1POK53FO6NW7IcoKsrYxjkcYqTe20lT8w9+tSnZJla6IcSuNvPGOCc4pNxJw OeCOamzurf15lx91uT7CvJuY55UduP0pythVDDBI/rSqwkoq71RSV5WvoBcKrd9uMkce1OUh 4wByuc5Bqk+ZAvdskRzS+X5eRtBcZ/U5qKS7W1hMspyX4jj3fMx7Yq4JqFvQwrys230syjbF 7i6eFmcTYDXMifw5HyoPTik2mTW0SJMJbR5wDxlv61tFq9n5nlv95TTW7kl+Kb/yHazeteCS xtly+0mc5+4uOB9TVey1SXThax6mF+zzooinUYCn+63+NZ8iaWm5NXFSp46VaPwRVpfr9z/J nRhiQok6e46VWtv3l7dHkE7QO4wM1jC6vbz/AAZ71RxcqbWzf6Fv7y56j1GKp6tavqdn5UM0 9oVYOskLlCCpyM4PI9jQobtdAr0VXpTg3bmVvS5W8P3b3enLM10L1WZgkgXbggkEfmKuXF7N alEhheYvzkEAL9atQTlrsceDxNT6sqkvfdvvK099fq8XywQtNJtXJLc9hWdJd3V9dvbQ3c0k qErKLdAoj+rHjPXj2rSMYp8yR52KxWLtyN8t2rW31/4Br6ZokOmOZYWmklkwrNK5Y4/HpVy+ Ym1kbOSEzz2x3rGU5ylzM9PC4RYWk4Jt7vV3epZik6ZHUevQUocMAFHzEUm3KV0d0HJrQd0y PmHH4U5WHyM469qpO6bRVuWpbsSq+4HAwfTNNBIO7GT7VilFNl1Lxa1AZJyuRgjg/TtUhl+c c7gw7+oppJu3ULaEMN7DcXEiJKjyw8OofJH1FWQx67sADtUTtG0ZbE86bun/AEhRIepGC3Xm lDnA+XBHJzzS5bR3G53d+gK56bD8nIxx+VKSW/hzxnANVJPS25nyuWrdkO3lnJznHXvTWlzk DGAMjA6VjGDejY+ZX90eMFzg7jnqOtGGP3CcdOe1aQldpsmSumv6sG5wOSoHp2oZtygjlfuk etJSg9jOommopibmbggBSfvU04WP5OnHGPSiCu9XqTJJyGu/Pz/L7E/1pA4Ycjoe9bKXLTbR PL71kwyOM5xngFemKa8gOeDkDgYpRTcmkRO9r3I3k2hiCRn7oGBio9+Ey57cU05rUicFYiZm lk+VR+NQ3UrCydjhfl57/pSSuwnNxjc+aPOaW6unY53TyEE/71TadJvvYRuPLjLDk9e1dLnJ RtY5500pOXQ9zW4WeMSwsGRuhH0pV457tx1rrxCW67muHqxqU4yjs0OLYOOPlOcdgakB3+gA HFc8lok+hp7TlVhACmwKATnpUpDbmHy47HPFZe65pXNOaLV7ihQoBOMrx0py/Mp9OuPWlzqU k0itot9hCpyGyMKQAScZpVBfCsMAc5BzUubl8i00khSAuQSMk9+/FRqgQnbzk9Oo/ChbOy0Y kuayQS2xmT5nIyc5U9PemQ6Wsb+bITNJgDdI3bPYdq6HLlS0MquGhWd5PRWK9rpcljLdBHUp PKZC4XDZI6ZpJ9Djudpjmnt3C4Zo3wWHfOamU+Z3R56y+9Bwm7auzXm27lu3sY7S3dLdQCTk nuT6k1DNp8WoaT9luANrx7Rkcjngj+dS5zaUkjqo4KlGHsU7ppr7/wCmXrWAQwRx7mYoigt3 bA60yBHW8myoKyIrD+VTCb5nodCSp06cb7WX4f8AALjIwJI68Z5yMVUvZ/s1tLIxGFTIGep7 AU4JM6Kk3ytv7yh4Ojji8PWkaYAjLbsjvuJP6k/nWyE3tkFWBGeTRVfvtLqcmVTTwdKS7L8j K8QEibTowQS92oUYz0BzUHgshNPmhPFxb3UqzYzySxIJz7EVrH+G7L/hjzpVrZxFSWlrfNxk 1+CZ0LcuQDnvnnior5SLWZm5PlsB27Vh+p79VJQb8iS1+WFDt7DOTnjFUZvEOn2pbzblEIyC SjAfmafJJzcUcv1ijRhGVSVrlnTtZtNTEh064guWiIWQxncVz61dmdYYS85VVUbmZm4AqJU3 TnbqzTD4yjiKftYO8Wt+mm5k6V4og1fU/slvb3ax4ZhcPHtRgOmOc81uSN5amRnCBeck4AHr RVg6clfdmGCzSljYylT+GLa23t19DHsfFem6nqDWun3XmSqpYkIduBgE7sY6kVcOpW2wuLmA KF5PmCtHScbO25lTzbC4qL9nPRNrt6nNaHfNL4pvLuOJhZ38nlJJk4dkQDP6V1mJi3yBCmMD nk81VaClbqebkdeU417fzya803o16kTXdxA8avHH+9fbGP7xwT/IGo11O4kupbWGKJpYlDOC xAAJOP5GspQg42OypjqtOTjKN3p+rIZJ9da5SKKKyWMn5pGc8DPYeuK2SSRyR04Pes6k6cZW RrhKmKcp+3ikulvxZSsbtpLu9hZjiGVdmD0BQfpkH1rQAAXcwAA/Oh3vc3o1VUg2+jkvub/y M+PSNmsNfJe3ZDrhoGkzGDjAIGOK0XHf05/GlKdpXaHg6Ps1O7vdt69NtF5J7CouAVYq3uaY XIk2/wAJGMHv1pSjTk18zV3V2OE2W44GegHSojM7DkY9OfpWUY62kOdm13YCTbhWUNlvzpHG SPlC8Dj8a6bJOy2MvaR5rfcDMxzhgCx7mo3facnAOPXOKpWew7wV0RFj0OCSfTrTSDk8Dj1N XKokm4+n4kKysJG52FiACCTwc5FVNQkT7DK44+Qt9P8AOKhqUJOxjOSlA+Z4nyZWIBBdu/PU 1oaKvmajbBQGYyDBbkdR19a65tRWuxz3UpfM9fu1bSblpVybaVvnUH7h9R7c1oJOJgDH0I+8 O9aVabdn2McB+65qVtN16Eh2shGFyT60iuFQ5x8o4xWCTkuU9BpSV0SBcqxY57ZDVIBk4Jx0 4NZ1FFuzKj8Sdh52ozFSBu5603CgKqH+DJ96Ir3FZlpb3Hyg5z8uScnPbtR2x8ykjnkYrJx5 t2E0opJBk7Nxwc9PY09JCpOMEKOnrT5NGXHR7Dlb5VGcA0gP7vajYC9s1SiuX1B2UmmKWJAB YD603HG7gHHBqUk9/MptL4dmNKlFbcMg8Yz0pbdRJCm5tpKnj3q/ZuM7x3M4xvNSfYmVh5hG RkHkkYqvd/uGinyNsalXPT5Sf/1UX5JWHWjzU9tUWt+8YRuvK+9RyW6yqnnKHMbB+exqW7S5 WW6SnBpbMyYbO/0i4mXSUguLS4k37ZJCvkk8E++f6VrSNI0DrFJtcqQpAzz64q17Oo336nn4 GGIpQlC3u/ZfXXy8jLs9MvbvUILnWzEptQRAsfRierH8O1TXnh/zNSS90+5e0lOPPCcrKBxy PpVVJK9o7Iwjl869GUqz5ajalddGtF+F7+pulVAKk56fxcmqWqSBbBl58yUrGqj1JrHlbat3 PZr1LUG30RaZjbW67MyMB0zjt71mXGq2UW06hbzRAA5Z4S4H4jNUqct46M4cRVpUY2rRvG3r 0J9HvdKulkGjSWxOQZVjXB9sim+KE36DcqmdrIFcDrtzz+lVyNO0lZkwlQlg5zwrXKovb01X 3mhb+S0S+UUCkfKFGAR2qvrVoLrSLu3tyA7wMqj3xWEuanPlffU7Kcf3MfZ2s1+ZV8Nm2uNE tvJjji2IqSx4GVYABgfxH48VzsHhPT18WTW00JltXt/PEZlOEYH0z0PWummmqk7dj5HFZfhc ZluDm1azhdbb2Ul8t/kdTd6fEunGOxAi+zEPDsXG0g8DFXNPvUubSOdWVVkTduz09qyUlr3P oY0VQxCcFaLjp2tHT9UyhrUofUtGhhYb2ui5Gc8Kpyf1p0FwLLxRcRTsqLfWymLPGWXgjP0N KK9yzWrT+84MRO2JnUeqjKmvRO6f3XubDfMwwSfqMYqte2v2mQ7JpY8Lt+VsUOK+GS7nuYmL nDlvY56Gyuf7Xv7ayvpEkjRC0joDvBzjP0xXSWiSxW8cdxIZplXBkwFJPrjFOs1JK+54eV0a 8KlTmqNw5paPvfclW8hW6W3aVElkGdm7lgO4FS5C5Kgc8EVzxfM0mj24VIzbUHto/wA/8hhk XYc8H37VDHqUM1zLawygzRKC6dwDzmtJxbT8iZ1IJx5n8Tt8yZ3ywBIODjr047U07WPDYJ6b hUKEVt6lzUnp3KenapHfCUxRTReTM0bGWMpuI44Hpx1q2UVgWY7iBwenNbNOPqc1GrGrZ+bX 3DJmZWBG1pM9GPUdzVeS+25M8Wwf3h0FKMW3fYJ1JKV1sJHcRkKUkG0Huf5VGkpYszOpVjhM envWk1KOiQ6dSm1zLYlLBRt/hzisrW5B/Zk77sx+W39aIxSfMY83Noj5uilAjPmEZJ4I5zWr 4bZW1myRjtBlUZHbkc11yS5Fcw150/U9vmg8xWWQBlIwQTnNZ+ku1vLJaSLzB9w56gnijEJt NPyBy5Z0pdHo/nsaD5DYUAgH15pQSUJGM8HIJFZ3baudG2hJGGAAGSufmzUgO7p0P51lUVp6 HVJaXHhCAMrkDkYGKdubqRxjgHtWcppq3UmN9X3B2OCeePQ8U1iATtBHHrjNTCLNpNKVluOV huYBe4A+b2pS20b+CCCD9RRHmaC7b0HKCWO9NzIeQD/Wn7N4U7cHvzxVxSSVyFdWfcaOwdWJ HTml+UgbwckE5J9KmCb2NKi5dFsMlOyB8AnIOCPpToy3kqrDGFGSDk0TU2rtkOUedOw7G45P Utzgjp6UjnzFZGzsbjHtTiufVFwfSWu5RluptNYh4pJbXd8rx9V9iKm0zUW1GOV1gkiUSFF8 zguvHzAdvT8KuTVueT1PNpYmpCqsO4u+uvla5dBJfJ+XdjODwPakO5QwO0E4Bye3+eaxVm9O p6cVdLsh0UgmRWiG5GwQQOxFT5GMDoOOlXJ6a7jhZ3t1IpLuGLe0ksS7OoJHFUoGk1i7S4cO lrbjMYY8u3c47CrpqTje2xx4qpGpJUYPRvXyXX/I1WXBJ68eo60ix5BUqcN2Pask+bY7ZRfL qEVnb27u8MCo8mC5CgFsdBn0qSSJJY3jlAYMpBHr7UNy5knqjDD0KVNOEVZO/wCJkW+l3enf Jp1ziANny5Pm2j0FXrGG4jV3url5XbAwMBU9gBV1ZReltThw2GxGHqcrnemtlb7kVbjQ8XDX NnJLbSSYDqhyHPA5qew0pbCRpd0kk0oAkkYgsQO1Qp3WisFLJ1Gu5uXuJ8yXmype6Ndh2bSb 97fLZ8tx5iHOc8dutWNE0V7PS1tLyUTs2TIxG3ljmtLxcbpGFLL6sMWqkql6dpJLte3XtoO0 /wAO2umXjXEfmM5GxTI24IPRfart1psN29u9xF5rWzMyNnkEjHH6cVkpuVpM7KeV0KND2O8X q7lliAxCrzxkk8k0hJViCevbA60nCyi7nbUV53ehQs9P8vWby6ZwVuNiquPugDH86v5CxbpB z0JzilLdI5cNh3ShNN/ak/vZy+q3w/4SOzvYlPk27eS8uTht/FdUGGT3wuT9ar2bUYo87LKv Ni8Ql1cWvutf74jXyZcjBHUc9q5DWI7uHxSLrTBumgtAzpkDeMkEfXB/QVpTkr27oWeQnUwi dH41KNvXmS/U6TT76LUbZZosZHUE8qe4NZ8OoSyeIbiGOQNBHbKQvHDknNTyuKaa1QVMx5qV GrSespR/G9ybVtY/suNWSMzXEjYjiBwWPX8qrw+LbQadBPesbczg/KfnIwcZ4pwoXpqWzvsG Izalh8S6ElpGPM3/AF6mqrrIEkh+dXxhvUe1JJl9w4BIycngVMm07vpoetCUZJPvt89Tn9S+ SO4aJVLmVFU5xt3EDOKavhzzIwJ7idnIP3WIBrZNxV+p8xUwzr15RTaiv83Y1AoiVUG4lABk 85rK8US+VoV9KwGBbvgE9Bg1js7ntpKMVbdI+cwzoqqDkZ5OeOlb3glTJ4gtNhyC/XNdtbWk 2Yxu5XPb5AQPkOeRmsq5zHfWs65APyNj0NVUcnUuwq/wdOjX4amiepLkj296kUfKSuQqjBx1 zWUpO9zujJdBccnnJIyMnvS4JXkZz1Gc/lSmrb9Sl2JkIJLbsDsCelAbPQgg8H5qyu3u/wCt C+b3VZeo5GIPOdrEZOeDSE5dgeh7ilz3lqNK+i6iqrHheGJ+XmlwX4Xrtwam/crbW+pIg2N1 BAbn1FL/AA7FyQR680pt8ySMk3qwm3Ddg4GM4PQ01iwXIXOBge9KLV0axqSaZHcIPLYDIyw4 zUmFAJJ+bAAB9a055OKa6iSSqN9bEqrkEdQfX6UoBHQ89j70K9tByblZsTDEhXCnJBI9MU9V XICg7cf0qL2VhtWeoL8uAfug8E0KoJLE8EAEdqPeXQ0uuj0dyRQpC4IHbANOUcEDPB5A71N3 YyUY2vcj+xxJJvMS+ZnO7Gd1TqVVAMBSBinKc5SYUowpptLdDRvB9Mnt2HapITz95w3cZpRv d22La966HKjYAZlDZwM0rNnAYYA71bn1XYWzvf8A4cVEYE8c5z6YpDwSc846jiqbulfcaSba vuIBuKrngDnHb0pVJToBgc896yqN306k8z5fyFil/ug5p5JICspJ9cinrt3IabWgmAFxznqO TSfaAlyIIyDlcsQPfvSlaxDnb5k5+ckA8nvTAo3qCflPJOetN1G2kaO6asOKl8kZbBxkVFLb G6jKSfMjYyN2KmDte4mudcr6la/0WO90+S0AEauOHX+FuoPvzUekC9i06KPWkQXSfK7xPkMA eDVxndct9zzPqcqOLjUpfDytP8LfqvmPvtWtrA4u5BGQdwyCe3bFYVpPdTXFzqkNuZvOwiRF trsg6EcYzzW1JJxdzizCftKsKVHWUXzNemy+bZBb38s2uGO3sryCK5BFySMKpA4YGtG40SWC aGfRXjilVSsm4ZEgPr71pUklBdTzKWGnjadScY8vLK8b9/dk/le5Paad5Obi7PnXBBG8nkeo FZPhjSQ9tLJdIzCbMcYdcYTJz19az5pO+up1zwHNVoxaunzORo6HvgiltZXbNpIVUE/w9v0r SkmBfy9wJC7iA3OKhu8rnp4B/wCywhf4dPu0/wAjJaA6nbXiruBlkymeuR0P6UzR9XN8himV 0uoV/eo4xz6g9KbUvZu/Q4PbRp4mEktKl19zbX4XNFgR0559cGub8b3Hk+FdTaQtkW7bcHHU Vk9XY9ZNcr1PnmMkZVgTnPH4f/WrpPAS7vE0CSfMC+QVPPQ16FTWFl2OZv8AetRZ7a5wNwOM dTVDUofMs3MZKlAGXrwQadaNpuSextGMXh+Us2ziWKNgS+QCe/1qbZjcGZSQOn0rC8lJq2h0 0VenGK7D1UEDDAFuvNOCqAW4AHU1UoOMTSMW5WQ5QFbllb149acSM7VYMcE9KzqJqztoWovU buO4BvwpzDI5ITbyCanmVmug1DVATvG7OC2Pzp6445IwMjHc1nFK2nQlNyb8hyplxkkDp070 5W2kKuQRQr8yVjZUm1dDNwkJOePX+VPdjGq4A5H3uaqS5XFoys5Ky3/pkMzAyRqxBLSAdfxq fduU7+p9uaG3oluHNao7roh5fcDtwAcAYpUxjDORkdfSp95bGqceWw9pApZWJO7OMUobfyoH qcipcZNXbLlFKNxMr5hHTPbpk4pxTehXgdztpq8lcVlGKTH7d2CPlIIzzilPC8EDjAND1vd6 ilGNvMc209ecdAe9NZSxOR07enFXGLUbk8srW6DkbK5VgCD+VOIUvhicDsOtZqNm30Gqcr2H uB1bJYHI56Z9qGYEcHJUZ59c07NyswjqmmPWQ7vmOSeT/wDWpkhHBkyF7AAn6UnFxk7hLljq MRk3g7lByPwPpUrop4PJHB4rSa92zMk1NppgGQ/KMHngk96b5iKrCQqAegx1rOKaBtJ36Efn yTgm3GzBxvPOfpT7e2itlYINxY5Zu5J96pU5axW//BIjBylzPZf1cmD5YHcFxk9M5oBRQdgx gfnWT5oqxuk3qKJdjZIx3FEcu8LlVOBke+KqMWlv0E4tyTsLG67TtOQTn0xTAc7wSuAMAnnn NFOm+qD2d0RTwwzgF0Dk5PzLnFOYoEA3LjbwFHSm4tJWMFTipua3BFUMScA55J7im52sctjn 8RWq+K3Q0cFa66gASAQwBHTK803cqkdCBwM8fyqOVNtXJbS0sUV0q3j1OS/QkTSp5bgMdpA6 HHrTNS0xbx4mSRonT5Qy9x6GqUWpXv8A0jy6uDXLUpp/E2/Rk0MK2qiFBwB6U5YlCsQCGYYH HWsW5cra6nTGlCFOCttb8BjMCW5CspweO1cj8R3C+D9RbcV3Q498Ej/6wrVOPNeP9IJxSs0t G1+J4AHAXqxGeQVrsPhvGk3iJN7lcqQCBnH1rsr60m1vY5HZzvE9jMg8v5uMjp6DvUNw4eJh gnKEE1NWT52dNLm9nH5jdMlP2CHeRnGM+tWd+doJzwcmsVrJIWHf+zxv2H7v3gI4weBUqybV zls455q51Or3Oq75lbqLD8j5bkH0o3FOd2cD86V3a25cdfeHCUFhwcZoZWI3kk9+vX0oldf1 16lRetmPXkrnHX1H5UFwrAqfc/nWW0kirpwsh4fnjDZPftxUbYUn+Z7U1K3woI3tyvQcsoZP 3YHByMdKdvC8etS1zOxN+W5nzvdDUrFIY8248wzMSBg4G3+taSbVUEnBwf51q5pw31OWi6jr VJSWmi/DUehBbnjJ5PpSA7Rx0xnB71hdps609U0tUSF0GSnTPGfpSq/yKVyTg4HtRJP5F3vF JCBiQwxgZ69c06ObgAdSPShrmTSE5kgbnHQJxwKBId+3JAxkHtQ5W0a1K57paD3fcR93NBJY A8gYx70ObSsyYy5tOn/AHouFx1yelAdSfmJyAR06VKi7u4nO+oqsSTuJKqcnipFcSBskhRz0 60JyWyCzcbjVB3fOGxjg+tPADkAHHHfn8auVR2/EOV3sQyQpKw+RTuP3hwaa0Hyj5pl4/vVL d7WZNSlF37ka2x6+bMOeoftT0iC7m4PUknkmrdrX66GKw0Yu71uTjoQhIweM9PelaRS+CVyF 5GcVN3ey1Z0xfK9RD/t4UjgDrn8aaWYcnHTPSnFtNW6hd8o+Nw+cnn371Gt0U5YNgkgEc4oT tokZVqs47/1ckjmRiQhXLkcClO0KTkemPxo5veTsVB8y0Y1pQ7/u+Octt44pDOI/mGVC8jnF RJP0FF2SE84FV5JJPH5VG7Ljhhj8zVbNiqyto+4ZLAHqM/d6c0FCyncT09uDTvrbsZVHpe5G 5xk7lAU9fQ0xp/M3YZzwedvNKSauL23vt2GO1w7qU8tFJz65pVO3kbsntUrTXsZ87ndSWoPI OmFAwOM5HSuF+K8iL4QvFYAbwgDHPdh2qqWkuZbkXbXL/VzwgOeccANxznIru/hPsm1o+ahk jEbCQegJHNddaovZtdbGNO7dz1pvmYblwO+PpUM7gQSYJO1Tk+lOrB8+5d1y8yIdLIWxiAyR gYPrV1VAAZSAf4qzmuq2Jw1o0Iy8hwYZ3DPFKCQvOPmXgdxTcVb1O6DcY6lgMANoGRjr7Ypu CFGzriuaPMpWexqlaLQ5clsHIyeSKVsnHXLHANauV3v6CUb6CkhBuXnB6ilXIYFw3QYxxipj rJthKdloCACQ/eJPcjpSkA7t3J6dKd27JDgrT5rgW8vPfbwR60E/MM5UY6/jRJNSSK0d33H7 gI8DPHXNIm4ZGGI45FD7MnkfKxQCWUHcCT1NTuAm3POVxx7UTdmrbgKY955AwTgYGMUbT91M j2JrC76m65eaz8wjTGBzndyf5UIFZ12qcjtnpV8za0ehmoKyv/WpIQVTgA5OPenMe23oOpGa Vru5N22n0HMMkE9MkEUoQ4HTIXJpt90VCLurCgZDbTkH07UbflBAweegxRzW32Jbb0BVcg4D evOP6U8EMFLKSB6GlZO+vU0SbSiGMMN/rtWl4CYUdewpsfMkm7bfqOUkAE/Q5POaaWw3zAsP YVHLHqzNve4wDexyTgHr7U4AjOF3DGBVy0hqZ3blb5jJIxKCrb+GGF6cjmnB8cONxI6AdqiC luy7LSw9iVQDBwelNTkZCk/Lirb0uipLReiAqYwefTGR09aag7EEDsf61VP3uumpF23rsN+z LJIWUbTkcjj86aFkSNiGVv72Rijm3TIlBt80fuF3uvyumNxHIpGlkdSRGGOPWlK7mtfInmnG KuhEeRixYA7eRk1Ar5JxgnvzxTTSdvmybOcrE4QtyjYw3Qmmuu0AMSzY/OspNpabkJpaPUCm fvRgZ/n2pJTlsKD7Y9KHdytLcEklo7keMMM8At1/CmGYbV2EjjJp3d0m9CLSSbW4FjsyQOvI bjr7VwHxgmK+FXXAZnnjGM/7QP6dfwqrRctGQrpq+9zxERrkdVxwMV6L8IYc6nKwBOEGcDnB /GrxcrU2mZwjaV1ueoS7S56nDVS1CQJaz4DBQhyfTjHFb1VNySehS/gOXkPsh/ocO3n5R34N WFly/JP0PesmlKTZWGuqaXkOBIY43Y4P0yKlDEKdo3DB/Oqm23fuaxaW+5NGMZLYwOM0Zzgj r9OlQ0lfQ6E7vmHM+VwQoA7E4pGbJXG7CjgCjks1cUIt6sVfvZOBgcUAqwwSQw6jHStFGWo5 ScdyQsMlR2GeetNOQnH3vQVi3roXyWuKWBKggZ9M9abwwAdevYdKajLe5PNJSsx27na2etOV /rtAwPQVXK07DklLVsdvBPyjLA8hqcG5yeh/Gs5a2uaqLitRSVX5+mOBUqvnbuJ5H4VL5mmn uKV73sNB9zx0AH60okBBDZIccketEFaKXQmcboUMGcqSSP4Tj+lPUkDjkgYxjr61Umlohxg7 IVyCeExnt/OnCQKAQzZOMcDt7U2k4ohu+g5XDdeMnjPelUAqxOc4/rU1FJu62/4BSet29ALc AsSOe/Yj0pVl+XBz0xnFKKajZi1UroUPu4O4r6+tKsgYjB+U9B/9eicXZtGiunuI7kNt+ZSD yOOaZJJg5XIAGWzUxSdkDfLcxtZv5buORbRnhhj4eULyxx0FaOmQ/YtPt4GLMUTDMx3Emuhw slG549F1a2MlU+yla3q1qTiTIy27J55qO4txO6uryIw6hW4qeWSkrHp1Y8ySJSWyABnkHOMD FG4YYk4Ofm96XJzK9zXlaj72wocAfdPzfTFIsg2j5ic9ulOMIyTuZNXdxyYcLkkc+lNDqgJb OSOmetTLmW/QGmrNDJJAduD0PAPv1pGkVV2vvVQAORSUWoWLcnyvv/TELhMkEHsMd+KbhtpO QBjoev405+7HmZz8knLXYQttAPIIOQOlLFLtUljkkdCfrVzt7PnIs3o9f8hBJ94ZI55AoMuC fl7YH/1qzaad73RLV3sQlxlwjPn1xnFMVyDjbhiPzoULK7RlNNPcXft27CScenWvOPjJLjw5 GGHzNOMADnjNOKXQlQknueOCRYzhFZQe/XjFem/BhCbuZnJx8oJ64BLVeIg1Rld6lJSb1R6T LjbkgAZrP1ZwlhOSOSoyD35ronrO3mYT5Y0LeRajIESDOPlHB+lSBwCCDjHB96wnGSbsbUYt U0n2HpgheM5HPFSqAM8tx+Naxso2auy0+eWooGAMtk4waeMDd1APBJH61DX2djoUrJL1FQK0 YUA5PWkVivCnGQOT2qXTbTa7lKST1HBPkHBA/nSFcdznbwCKqUlKzXmaJPZjvM3KSSdxbtxk 0E4PJ5HUd6p0nKQpRdvu/ATeEXjGc9e9KShTIB+XtnvWVSLcdOjJUXcFYls5wxOAQP0pyvkc nBI7VrOO6ktQ2kOUk4LMxbPHPWnpISFA6jqWPSsktHpobOTkxwcNn73tnNLglhtz7dv1qJNu 0gjbZgZOTz8xPrQgUMCd2SM8CmouF49UFnJXJQhDDZjOe9JE+GBcknHQd6i3OVo0k9yUuGLD HfuelCbejg/L0700nazZMotPUTAK/MfmJ9MU4N8pAIx0GRkinNcysibpvQVyv3cvgHkE5zTk cqrKfmOO4p1Iu2okmtVsKpKsSMqTjvVPUVlkspVtWdJNvylWwTilHZLdIzq3cHbcxNHuNde7 RbqGNLRm+YySAv09B710DW8k7kF9qr1APWrlCCleP9I8zL/rs6LWIST6ehS1GQQCzttu0SXC qAOMgAn+lafyhRu3EAelJqKSa6/5Ho00vbTiuij+r/QQDKkHHXHuPagBSoOSOCTk0N3uzsg7 K63/AKQBiEy52k8bSaYzAKx+8OxzzUaKPKtiHJOV7gVweM7u/oKaBgKqkZA5FU01uTo1dEqS DzPl3Y6fpULyA5UenPGe9NKTaRjKUn6CE4PG4seoFIZSVAkGQV60RikmnuNu+sShc38cVzHb iRzI/OFXOwe5qOcXNmDLDL5uwElSOopxjzLXZnmV5znKXspfC/8Ahy8k4uUjckgSYPpTwqby zEciplpotjp5ouMZJbiBiQcAkbsD60hYlAACAeO3BqJe8gipqTa8hEKgjBxuIzz3pgHqT9QM 1fxO7MX72pHkmTGScckkYFeZfGycDSLMAqC0/wB3b7c89qUU3NaDik7I8i80NuAzwRyK9d+C sQxOX3Iodct129avGR9xpam1B82/Q7yULjC7j3Az7f8A16y9TANsqkZEjKMn0zzWrdp2scNa 31Vya6GiUG0q5yRjHtxS+XnBULnHYZzUvllNnZCTjTQ8Asy5AGfen7SnBHJPNKXuvvcrmfzF yM8Z4bk+1Shg2SM+wJ60+RR1a3NFUbbYP1ymcZHJPencbcYxj361N7xuzWM1d2QgbvzknkZ7 1IIyQGBJY88+9OSu00Nys9QAVBlm4P8AFTSgPRmJHQHmnUno7bFqST1ECbxlsZHocULgL8mO mQT/AJ701OWmgpcr2HIxyuRkhuvpSoA4GRuDLk98Umle66jUnqSFASTwCDzzzTgdqLuyQQTt zUxe6S1KAE8bs/Kc5PbigEryfuEcYpKXNK5d4yd0P2l/u/Mqng46UiqOWyc/7PFRblfqTzc+ /wDXkSqxA4Vee5pVKgZbGQMdKpJK8Wgi30FRQ/AJwR1z04p2zLYJzheM0LlSSJ+LRrzDhlz3 5BGaaSFCkseep6iq5Yu2mhUH5ErKOueRjGaEVmDAnDYztP8ASsm+ZWDezFAcOM4w3QkimrHu TpnAAOMjFaScVFKOw4aIezYOARufuPb/APXSfMhHXJ54Oc0o6Xf9WIk11MzV7OabUdLmhV2i guCZRntsIB9+cVoNtdSQcgevBonJStJbI4aKqxxFST2lZ/gr/kOYbBnOB9aA3JLHHvUylFrR HoLYrXts16AgkZVVgSFbBPtUu5Qu3GCq4AHehJtLujBR5KnNe90hDIGwVwcH7rH60K5EeAQS R2PtSlNdupbs1oOUgsVIwAfXPNNCKCzgZz0yapt2bX9diE/esuww5VjxjDDjNRzsDEzMdpCk 8HGKVocqa6ETqctpWuVLCySNHlkbLysGLMMk5FSXTLDA7Fiw24AHXnip5vfsupx0YxpUW2td xYkEEKAkFlA96sD5g2NpYj8BV8t48zJoyUUmlsKYwp4AJzjg8mmKDgnkAD1zislUcXeS8je0 XFP+vIiA+TByRkEZok+783JXkfWqvcXuuytZDDkPhjgsep78V5T8bH8u10+MkH52bHTnH69T WlNxbswvFW03/wCCeUpGdxV89RjHFe0/A+3T7MSfmJkG4n/d708ZNOi0n/VxULSa5dOp2kjL 5gZBkg/pWXfvuuLVGxzJkge1au3OrnNX/wB1lFGoTg/Oeg4NNAAx8xXjjBrJ8vM3E6ZJWHog PDE4HvSoV2YDHjg85zVOfO9QfuvQeCAAenoAOop20MfmPTGB2qZSXLuWm2lLuIOCVXJweTmn x4ZR78CtudqKkvmXopsVWU5GRnNKp2Hhi2Oc96mPK2+xqrcqbeoM3IX1z70KBjnJJHPpxWck 3G1zW3LshrHzM7cjJ/pRjGd53cdAeavmvFCjF3fYcG2KODzjqc4pS4A5ySPb603J3ckJJctl oSHB4X1GD60uSxww6DHHeohKzuxrS/MxCF3jOfUjqakLLzn72OgFD0lZlWSQgPf17U9RkDJY n0BzmqUoON7XKpvlkuwqdyTj0/KpFjZh6564HJoekdfIm948yFGQQu3BPK4FOViSQ5wB1IFZ yat6gpbRauCsu/CHC59KCSynO4KvtQrxsNfCkh5YMwJOzPBwcU8JjgZHGOe3pWd01Zv+tSk7 OwMTISrAZHc0yNMKACF2+vNEGrabfoTN+9dIbsX5FwdxbsacQVBGW3A9e2Ku6dn9xDfRgGw4 bO0luQtIJAAyqNx71WqvYbk+gKAw6nBPAqPABG49Knm6W1Qk30FJLMSuFAPbrTTjbkMTk9/r VLuTzK+4SrkgcY3dx1prEx4bdlTjaoOalTVmmtdRa2VxqZ8wgnDA8mldiyDJ5IzjPvSqczs9 ibxUrEYc871GO3emSYKMMbMqR14o0vuKcXa3TUgjkuY/kZN5HAPAzgdaasTuQ85wqjhe2T60 ScW7nBDml7j0LGRjDAqMjk06MAJyCcDH196U5Sd0tjaLtdD2kAGSGDHge9Nyz7sDAIBqX8N2 JaWuxdjAEtx+HWjaGQEgZGecHilay0NJSglci+UZBBPXAFeO/G+UNeadFgthXZjj1xWkW3NI LwTUjy9EwxHLKSef51778Eo9ulRspG0ud2O9ZZgv3WhlTn7239XOgfrtC4I6fSs+5JbUbYOD hVJHtXbUhabXc56tOLoxlft+Zo7iWBAOc9zxQWIXkZO3r64rG1nqdbaUvd6kqsqD5STj8aVQ jLnoe3tVaJp+YcltB6gj2J604K2RzwB0NU401djScZ8w8YHGeMjjHSkdeSrKoB7U5STVlsNq 0736DuMk4yB1xUiMQAAwJHGCKzdNK1jR8qd3uNPzE57HimOwxnGAepqvZqKTNNLDBgHKjODS lsEBvoMelE4x+8fPzWXUeTuf3PTmkVuCR1PI71jB3v5Gs7W0HKzlOxxwMf4VIshOABnI5PpW zjG91p/kJOy1X9WFZ+PlAJ4yccGgudocnKle+c49KUlFxcV/XYqLd02xwl2rgKwycgj6ULlW BZevViMmsubq0DSV/MkjHLZzzTxIQ4YEfKOO9aOEba7EuKdkhyyF2GOoPT1odsYyMdMkCodJ czaehShbUMhgAvPrk9vSlVz/AB544GD1q3dqzDRN2Yu7A+YYI5xnFPK5jyDg9iecUqi5WvMm yfvMcTuI44J5weTTS3LL0wOMnnNZyUSotaBuBVjkEfqcUwkFtrDj+lONNKV4mU7au5FySCAr EA449Kl87OV2kkr82eK0q25U4miTjuIW2hm2EEcZpFcMuCfepavK/XYlR91+QhfaMIvvn1qL zWCkDA96lwjbUNB7SEMxA4Y5FMWTMeSAG29x15pcvNHmRnJU9ewuRzknBIPXtTNxeMbAW/vE 9qr2dlqYSas+w1pTwrLg5602Q7gN3Hrg0lDrcWqdhGYsoOCH/vGmCQMjBh90cMvFDh7l10I0 XTqOyJCAQOD8x9B7U+PGSEzx69x60STT/Mu3MrL1BWGcKucDHSnqQq52nPQc9TQou92/IUox u7Kwgm5AIwe3/wBaozKD1B+9g1Mqdk7DScbDHduDuxg9R3rxf4z3G/VLNQDuSJiVJwM5/wDr VUUtL9dyZL3l8/yPOEzIysmcE4Jx0r6K+D0R/sm3KpulTc23GdwyT09cVlmKSpadCqEVKbXX /M2JSucHhu/tWUSW1iEA8rEe3BOa65NKT6nJUj+6i9ldfmabkA85Df7vSmhGLEqeec5NZyhG +pq1Ll5baIenDfKMAnIGSaeQSPlAB6H61U0+dX2Q/aNLXceGBfdwPX61IhEe4KyktznOcUpX expKSa1HrID2wT0J5FBJUlcjjkmq5L7bkKenvdbgucAAZ/HrQCcMQc46c9KFOya3ZWrWiELq wO3IOOD3qPOcYYHsSKUp3VjROOlhDIDx1wecU7eFGQB05GKhy0sbRvukKsjHGOlPBGz5SSRg 4NDgkr32sU6ieiEDIXG07cdyMDNPEpIBZj93Aqv4mo1JpJAGGRkBf9r0p4JU9SwfhecZ5pVI BF3VxQ+CQWOSOBnpQJQFGxl6Yx60ny/ZCDTWxLvO4Y7NwafvbK4BQ9GpqLcVcPd2QqszMSW2 kdMng07cHXaxI6fMOlFRK6sKVRwTSGhl2naV3se/40pHAwR0OcVm6kr6D5lZi+YTkkng4yKV 5Aow3zfLwV705xcpJMcNE9dRzk8Et82cU3eBnLbiQMj1quVLcV03fqNLANwCB160kj4IJY/N mnzJP9Ryjza2FyEZhyOgG09c01n3KQCSV4x15pxTldvyMlKSd2Ir/Lg92OeelKWwoXcVxzn0 qGppfgaOatdCq6k5+8CckU04GF3DB6k1Dbbk35GV2txpYsnzZ+XnHbP400nAw56D681TaehF 2pe8iNiVxkqe4z3pI5CuQAo+g681UnKSsxSlpdKwjuFYFucnv9O1G7OAvXGaj3ktWTvZhv3Y 3gdMZx6elN2A9cY2+vQ04y5LpE7JNbD1UqR0IxnHTihWIyTjHQDPIqdGrFQUHrcf5qghS2AT yc/41FPOqRttPzHrxnBpQbbt0M5u2u+pHETM33cEdDnrx/8AWoWTkI5G/txV072ku35D1fvf 10HO52tjaobr6Zrwj4xTiXxLGGzhIAAcepp03qpWBOTk3I4mHHmqFJVdw+UH3r6U+FKP/Y8D LgnZvwQfm5PGa5MdHmhsdeFv7Rdy7cKAWO0YDZrKh51vavaHv9e1d/NGUrWOGrFcsU+6NFz5 QG/BPpjPNPCLgnPzfyqeZN3Z0Tgmkug8RYXMeOcH0xT8ZGTjdjt6e9XzQV2lqZwildXEWJip bDMFbrnFSYIGY+SOn09qFKySIUY3aFUbmx0HXpTZARj7vy8+1VGcW+wrxbtHYkjO0gnmgAAg DG0enp9KPZq/MaKSWlxdyqGGAc8EiomOxB6Nz096lt7DcYpJrqGDIT1yDzk4po3EfMMHJPBq W43bki29FbcBzyhyGI5zmnDLEDJJBxgHmpWrsVCCT10JAWPcAe460D5QVyeB+VNWsorzNL8z HJhgee/rT34bbyMjnBzVyfK7PW5ro9QiBJK44J6Y6+1AAUqGUk/j/Ks07OxNk1oPXK4UZGOf 0pSM5AHJGWHrT05rg2tCQKwOF5HoRjmnSPnHG3sR1yamTi53a33/AK+4GlJ+6IT0HCntg85/ /VSADspOBjPfJoSio6Dk1e49kI2jqQTye1OjUqDvzkgnpWkZqcW32E0khVIO8FumBn1pvJDC I1LaSd1oZ7yvLSw3BDLuDcHncaagb5QT2B57VMVHVdDVO60FbeTljkAAc/zoVdi4BB4pyVPl 5Y9TK8k7dgxjgkEY7D9KA24HGOO3pWU+rexaaaTY3yxldpB4+XnpmkJdckDDdNuf1pSlBq5l Gydn0I1O0DauVU9KCmEyR1HTNbNKCdtDOWsuYUZUHB6HuPaoiM8g857Go5tPe8iHpJDWTLDG CR2zScoi7T8wPNRJp6W7jT1EIIyCMNnnryKUJleQDgcVfu3XNsJtu1uo5dytk7hnnHrxQBn5 kTJ28Z61m2pa3skW0tBJCCDkAYORjpVQK5mc7QU7k85HpVpxp6XITU3qiZcqVAbDN/s5zSur HByCzchcc4zVOydzN2vothJ+QvXjrivA/iszSeKplZv9XGgqYrlqo6oRhZ+Vzk7aJHuI8YjJ cDIya+pfhlB5ej2vlEq6RKTnuMc1x5jrCNjfC35/kQyMS+TknI6DrWZbqs2suc7cRD73XHNe i21J3W3+Rx14SVOFu6/K356mqMFcHGSfTpTwFI4ORj+EYrOV3J3L9nrtoh4VWIO0AZxnNLsC Kc43Y5qlKz11CMbNRaJFO0kMRz0oVAOoJz3FNii2m2xp+Vl2tx3B55p0kbHOR245zxWre3cw au/dGjemON3HYYxTom8wfLjPr6mlJuTs1YduWL1GjK8Pnb9OtLkfKX49KiUru5tNLlRFuJOW znJ6jFLGuRlcbsGs3NxVylFNeg8cABgQx6kD2oTkkNgkDHNE6jU9BJe63fr+Q4lRsHXJ7GnL GS52AE44FXTbTuaS0ikIqHkFQRu4JpxyIyFHvnvVSqSl7oc8U72HKCw+XcrBsYzTUYlsIN2T xntU2tp0K5krO49QwHJJwc465qTJGMn5lHpQ7W1JUei6CqcvliSSeuP6UpBDAg52jPpzROkt n0NVZRQu0sVCkbuhz296QfNEcr1A2nvUOS5EuqM0k9b6dhw3AYI+XPfmpEYp8vzbSDx61e6c UO7bSen/AA4oX90Cy7Se2OtIxbB3blIGQR6VCjdP1QS5m2JkO2HGPrQVJJAO1T3xR9n11M/f 5rdhAWBwSCwAyCPzpr8kkgM+Btx0FKTSacepo5vmHA5bPOWwMYximbAAT1YjgZ4yTRGVnK5H tJLcTB34OTn1FRszhNoLbR1AqnBOafSxEZ66goOwttwD1zTMADIbbkZ/GpnJuytoS7c9h7A5 wTnn8KjXPljGDxnnGTSvyoSjZIQ7SCD8p6YJpnQDGOB6VCq+6jRU21YZztyCMDnHpRu3KCDn 3zitOZaJohydrp7jzJkDZ1HU+3ak83y2Od2R1IXofrS5XJNr+txqOi7sGyxLd8YIFMlfailg BgYzUyjdkQjZ3vsNDBGG0jg8YNCHdllwvbOOnrUczU7s1ivd73JCNoxxnHbtXzr8SJyfFV6r jIXAyOewq6Ku7dWaWcW+Xb+v8zD07e95AoGdzYGOlfV3w+g26XCCDwg3exArnx1lGPzN8NG1 SyKdwnzE9ee/SsmzwdZn8znbGoz6EmuqFVtttHn16U4qFttDUZODlQMkc9KWNd6914xk8inU 6v8Arc6UpNtPzHhSDgEgg9RUgjZ8kjHPP4VpD4tWZyTd+Zdhyx+WuBnYx5NKueiYxjv/ADqG pTaXr+RPI9LiCLDgHcxGDuz6Ujs27JDcHjHStL++m9uxMeanpIcPnYDawJ4+tJ9nA6ErjqAa bvfT+kNOy2I135ORuB644pgIKEssgIGOB1oSvbyKUHFO/kDMX+bB+Uf5zQoDxkKSfcjBNZTa jDbcfKru43kEkAt83IA60o3gkAHJ9uRRF83u/wBaCdO0ryJVGSQSxAxjjHNAIXBGee4PSqtZ 3W3+YoqRKGXdzu+XnB6f/WpxIZdyqQxPHpSbls16lK/OpMRY8sccE96WJGxt5Azlver5vdcU TF307lgjgPhgQemcUDO0E9MYwO1ZO9gfPdX1FcbcZ4A53U0KduDywHHvTcm9ToSlypIcPlHH 3nwSTSADb2AHFOcfzMoNrXoLjb8r/ebupz607O/IJZRt545NPkbu0XGEla4/eGALHgYOFGOl AAds7Thh696iXuaEw5nomR8ebz068nilXOBgngdPp/KqcXszRSvpbUOOFIORz1pu3aeFPAAq GnHYmc5X02bHj5iFbeoOPaoirICwBGex5pL3UzJQ9/R7ixpxg8Mxx9KjIIyQRn09anyXSxdn Fu2txWBaMKgK8+9RsCo2EHBA6/SqbfLyr1M1S5k2uomT5nCnn7wzntTAg3BWDc8gk9KauvmX KPu8sdwaM7iFJA+ntSHPUg7Tnis4zUorSw4xbuR4+VuCORyTnPFMDFfl2knjuKptyTuc8YSb bFIYkAqwPXrilUgsSg5I5yenNZzUlBuOn/DGib5or7wMeAWJzz37/WoZQGGcksOgolOWtghe 92Ql/OkQhm2jA+hAqbzVi3FlbAXIOMk1ktF6m6o6avSw9XMkQ2g/Q4FfOvjv994mvmOchzj3 rWi+Zxb66FShJSaRnaLEz6lGrDKls7SMYGK+t/BUXk2MfBDhfqCR2Irjx8o2S7HZhYy9py9/ 8jCkfJYnnpkVkadKJdZvd33lCKVHrjIru9q+ZxRwV7furvRv9GbD72X5VBIxklvWliJWPO3I xnGa0ly3d2aNpqyZI2Efcvzc9u9OHJYtuO4881p7ROKS3M4qKb1HOc4+VcY4/wAKlVFVunGO SeM0/dik35k3UrqLuKrAfMeQeOKcV3MdgBBHJok37R9rGTmpaXERAAD24GR39ajWHeNy59/X NZxm2tyG7K0WNI5xIDweoNRls44GM4yRWr9xP7i5yXMuZjSo3fvehPJ/DihhjCsCvqc5rLma kk9TabjJXbEbYWxHgDdgjPWl+XaDk5Pvyah8yirmaqKU1YeowFGMn86lWP5BgAZHStm1yqSZ PtNGhVG0AMFUNjkH/OKF/eMA43DGfXBpN63l1/Md7pWYsSDcCuC46jPGKGKc7FyxQEc1TaUr dEhe0S0uPRQATkKCeTn0FGA5LFRjHPzVUZvlbS1Cna179SZFwFLEDOAADzj0pm0bMYUBh2PS sm7O/wAi4y1laQ8xqNu3qOoIpAqEEBQMgjGaa1Wu5zqouXRirtC/dxk9D16VIFD7gVzjn/Jp t2vys257q7/roPZAVxJxgimhU3kkYJGAKUUndMq8YtEagF16bug96e21guACwyc/jUrmva5j KaTGs2WH8O5uTnNIpxkSHJHQ1SbTt/XoVJx1XRiFQ6lSBjOSD6059jEkdfTnisvii7/1qVJu DVtgIKkEhcDuD0qF8Z5wecHtg1EFokUpQTvfzBSH4cDIIwcd6jbBI4JJBx6VrD3o6bE8yTvF +Y5WC7jjcwP9KZM4xtI55/z7Vi3Jzv8AcOM9U2yFgC7YOAGHJ+lBIcDAOSMjnGauL91SWuhP tVJ3vuMJZowSCuTxikGVyQOg5GafvOJLbi+UUlVVWGDnjjtTQ+5RhMAc5yOKxdRSi29H/X6F uWzv/wAPqGOGBYbCcUbVwSASQMAdamVRcyh2NIe67pjI13ghRx0BAHNMEZLAPk45zj9Kzt77 5uh1JpwCd1EZAJHYgHoa+b/FMgk168YZ5lJGTitMO/e5ewe0tawvhZEl1y2+U/M4ycZ5Jr67 8HKBYxgKNwUEtz/nNcuPirK73OjCycamp//Z --------------080607020205060002080000-- From samitac@ipinfusion.com Wed Jul 29 13:11:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3B03A6B52 for ; Wed, 29 Jul 2009 13:11:06 -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 5USRZN3y3vcS for ; Wed, 29 Jul 2009 13:11:04 -0700 (PDT) Received: from smtp116.sbc.mail.re3.yahoo.com (smtp116.sbc.mail.re3.yahoo.com [66.196.96.89]) by core3.amsl.com (Postfix) with SMTP id 92ED03A6407 for ; Wed, 29 Jul 2009 13:11:04 -0700 (PDT) Received: (qmail 94971 invoked from network); 29 Jul 2009 20:10:59 -0000 Received: from unknown (HELO samitacD630) (samitac@130.129.82.175 with login) by smtp116.sbc.mail.re3.yahoo.com with SMTP; 29 Jul 2009 20:10:58 -0000 X-YMail-OSG: zw9v67wVM1lvuq7yBt0PKj_L9k4k9UT1.fOavCD_BGX1AeEnVhCrSR0uyTYjqPiGlxeIUwbXcG6XpffgfTwckgYzHWNDUQU.DeV9WZUZf0S7V0qzeKkFHHtYosLcY95bDIxFQ1F6vQVoHTAEbrOmU74__zO08VOQ54WZfPA2vO1vNs6SYOrcc.p11WZsuwLWC71nE797KTlmtQyf3272GN2vIEiRhtUFDOss5wKl.uqTi7iSi1phdCP4sOoQyH_HRepV_Qr4eo1k0KWvV_AGT.87WZG3repf49a474ATEbZlLbc- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Pascal Thubert \(pthubert\)'" References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu><48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> <026c01ca102d$602216e0$206644a0$@com> <7892795E1A87F04CADFCCF41FADD00FC07DC2A9F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2A9F@xmb-ams-337.emea.cisco.com> Date: Wed, 29 Jul 2009 13:10:55 -0700 Message-ID: <033e01ca1088$aeaf9660$0c0ec320$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoP/CKX/0d6jLuSRvuPxCtEZQw19QAL4/7gAA+xvoAAB0p1kA== Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 20:11:06 -0000 Hi Pascal, I am forwarding this mail to Roll. Your point is taken; I did not think of Industrial usage dependency on this RFC. In that case, I certainly think that IETF should help deploy its own protocol by speeding it up with a slight risk. I assume we are going to be careful on the reviews and will have some implementations plus interop testing before standardization in that case. In case, we find a major issue later, we can always produce another RFC. So here is a complete +1 :-) Thanks for pointing it out. -Samita > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, July 29, 2009 9:42 AM > To: Samita Chakrabarti > Subject: RE: [Roll] Moving forward with the protocol work > > Hi Samita :) > > You must understand that the industrial constraints do not leave us the > years that would be needed to make an experimental protocol, play with it, > and then make a standard track. So we'll have accept some risk, manage it > and a utilize a conservative solution with well understood techniques. > > As you figured, the main risk in this draft is the new assembly of those > well known components. Also being conservative in the methods employed (for > instance detach the Dag rather than risk a meltdown) yields temporary > unreachabilities that could be avoided on some research floors > - at what risk? > > Considering that there is no way to make it experimental, your vote is an > abstain right now. Would you please reconsider? > > Pascal > > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Samita Chakrabarti > >Sent: mercredi 29 juillet 2009 11:17 > >To: JP Vasseur (jvasseur); 'Mukul Goyal' > >Cc: 'ROLL WG' > >Subject: Re: [Roll] Moving forward with the protocol work > > > >Hi JP/David, > > > >Based on yesterdays presentations, it makes sense to me for RPL draft > to > >move forward and work with DADR team to take advantage of their work on > >loop-detection and the cost based on historical information on packet > >forwarding. > >But, I am not sure if we want to adopt this as standards track wg > document, > >as some of the ideas need more experiments to prove that would work > >correctly. > > > >But, I agree with Mukul that RPL draft has weaknesses and for that > matter > >multiple protocol might be needed in the future. So, is it possible to > adopt > >RPL-draft+some of DADR ideas as an experimental wg draft? Once we have > more > >data on RPL design we can move that to standards track with changes > based on > >test results? > >That way, we can make sure that the design is solid and the standard > >documentation will be a mature one. > > > >Thanks, > >-Samita > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP > >> Vasseur > >> Sent: Tuesday, July 28, 2009 8:25 PM > >> To: Mukul Goyal > >> Cc: ROLL WG > >> Subject: Re: [Roll] Moving forward with the protocol work > >> > >> Hi Mukul, > >> > >> I would really like to get your answer on whether you support the > adoption > >> of RPL as good foundation to move forward, adopting it as a WG ID. > Your > >> comments are extremely valid, see in line: > >> > >> On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: > >> > >> > Mischa, > >> > > >> > I am not speaking for Jerry but P2P flows are important in LLN > >> > applications I am familiar with (which happen to be in commercial > >> > building domain). I will have to go back to all the requirements > >> > drafts but I would be surprised if other domains will not benefit > from > >> > an efficient P2P solution. > >> > > >> > The main question is why are we insisting on "one solution fits > all" > >> > approach??? Why can't we recognize that different applications have > >> > different requirements and offer multiple solutions (including > RPL). > >> > > >> > Let RPL be used by applications that find it useful but we should > not > >> > force RPL as the only solution available. > >> > > >> > In my view, RPL has the following three shortcomings: > >> > > >> > 1) Does not offer optimal/good P2P routing > >> > 2) Does not allow destinations other than LBRs to be advertised. > >> > Note that this point and the previous one are independent. > >> > 3) Insistence on using DAG as the loop prevention mechanism. > >> > > >> > RPL is a good MP2P solution but we should not force it down the > >> > throats of people who want good P2P routing as well. > >> > > >> > IETF has a long history of offering multiple solutions for a given > >> > routing problem. We has multiple interior gateway protocols, > multiple > >> > MANET solutions, multiple OSPF-MANET solutions. Why can't, and why > >> > should not, we have multiple ROLL solutions?? > >> > > >> > I asked this question to JP right at the time the ROLL WG got a new > >> > charter. The answer I got was - we will work on one solution for > now > >> > but we do not exclude other solutions. > >> > > >> > I think ROLL should offer multiple solutions and let an application > >> > choose what fits it best. > >> > > >> > >> Few things: > >> > >> 1) The ROLL routing protocol will have to support a good solution for > >> P2P, this is a MUST requirement. For the time being a solution such > as > >> RPL is optimized for P2MP and P2MP and does support P2P but that MUST > >> be improved. This was discussed and agreed yesterday during the WG > >> meeting and on the mailing list. Next step is to work on this and > your > >> help will be greatly appreciated. > >> 2) The DT will reply but RPL support the advertisements of > destination > >> other than LBRs > >> 3) Loop detection: fully agree, I had proposed myself a solution but > >> others may have other ideas. I personally think that this is one of > >> the areas where we can borrow some ideas also from the DADR proposal. > >> Again to be discussed on the list. > >> 4) With regards to having more protocols, we are chartered to design > >> one protocol for the time being. There is still lot of work to do, > and > >> the solution will continue to evolve. It is thus premature to think > >> more than one protocol at this stage. > >> > >> Thanks. > >> > >> JP. > >> > >> > Thanks > >> > Mukul > >> > > >> > ----- Original Message ----- > >> > From: "Mischa Dohler" > >> > To: "Jerald P Martocci" > >> > Cc: "ROLL WG" > >> > Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada > Central > >> > Subject: Re: [Roll] Moving forward with the protocol work > >> > > >> > Jerry, I am not sure this was already discussed at the meeting in > >> > person but I think we are a little in a catch22 situation here > >> > since - as > far > >> > as I remember - none of the requirement docs explicitly required > >> > (MUST) > >> > p2p situations. I gather that the design team did take these > documents > >> > as their working basis which is why p2p is not efficiently > >> > supported. In our urban requirements draft, we actually did go as > >> > far as saying > that > >> > p2p should not be the main design thrust but rather the highly > >> > directional data flows towards a few sinks. Mischa. > >> > > >> > > >> > Jerald.P.Martocci@jci.com wrote: > >> >> > >> >> I cannot yet affirm RPL as a working group draft since it hasn't > yet > >> >> stated how P2P communication will operate within the DAG. > >> >> > >> >> As I have noted in my review comments, connectivity to every node > >> >> within the DAG is not assured. The traffic patterns within the > >> >> LLN are > also > >> >> suspect since most packets must travel upward toward the LBR > before > >> >> finding their intended destination lower in the DAG. This > imbalance > >> >> will create network traffic congestion in the higher layers of the > >> >> DAG. > >> >> Hopping many hops up the DAG and back down the DAG to talk to a > node > >> >> that is in direct radio range seems totally inefficient. > >> >> > >> >> Latency and convergence time are also a concern. However, I can > wait > >> >> for simulation or implementations to ferret out these issues. > >> >> > >> >> Regards, > >> >> > >> >> Jerry Martocci > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> *JP Vasseur * > >> >> Sent by: roll-bounces@ietf.org > >> >> > >> >> 07/28/2009 11:36 AM > >> >> > >> >> > >> >> To > >> >> ROLL WG > >> >> cc > >> >> > >> >> Subject > >> >> [Roll] Moving forward with the protocol work > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Dear WG, > >> >> > >> >> First of all, thanks for all the time and energy you all have > devoted > >> >> during the past few weeks on the protocol work. There was > excellent > >> >> followup discussion at the physical WG meeting. > >> >> > >> >> To the question "Do you think that RPL provides an adequate > >> >> foundation for the ROLL routing protocol work", there was clearly > >> >> a good consensus in the WG meeting. It was also recognized there > >> >> are > still > >> >> several open issues for which we WILL need help from many WG > >> >> contributors, including the authors of other documents. > >> >> > >> >> Could you please confirm (or not) the adoption of draft-dt-roll- > >> >> rpl-01 > >> >> as a WG document ? > >> >> > >> >> Then we will of course move to the next step. > >> >> > >> >> Thanks, > >> >> > >> >> JP and David > >> >> > >> >> > >> >> _______________________________________________ > >> >> Roll mailing list > >> >> Roll@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/roll > >> >> > >> >> > >> >> > >----------------------------------------------------------------------- > - > >> >> > >> >> _______________________________________________ > >> >> Roll mailing list > >> >> Roll@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/roll > >> > _______________________________________________ > >> > Roll mailing list > >> > Roll@ietf.org > >> > https://www.ietf.org/mailman/listinfo/roll > >> > _______________________________________________ > >> > Roll mailing list > >> > Roll@ietf.org > >> > https://www.ietf.org/mailman/listinfo/roll > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll From mischa.dohler@cttc.es Wed Jul 29 14:17:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB2E3A6952 for ; Wed, 29 Jul 2009 14:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-2kQUdP+2f8 for ; Wed, 29 Jul 2009 14:17:57 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 3DB6E3A6933 for ; Wed, 29 Jul 2009 14:17:57 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n6TLGgqm024100; Wed, 29 Jul 2009 23:16:42 +0200 Received: from [127.0.0.1] (175.Red-88-3-147.dynamicIP.rima-tde.net [88.3.147.175]) by leo (Postfix) with ESMTP id 3879E10C31E; Wed, 29 Jul 2009 23:16:40 +0200 (CEST) Message-ID: <4A70BC3A.7000704@cttc.es> Date: Wed, 29 Jul 2009 23:16:42 +0200 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090729-0, 29/07/2009), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Wed, 29 Jul 2009 23:16:42 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:17:58 -0000 JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Wed Jul 29 14:42:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C989C3A659A; Wed, 29 Jul 2009 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTZmGZWyq7bR; Wed, 29 Jul 2009 14:42:45 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 854653A68C2; Wed, 29 Jul 2009 14:42:40 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSnDCUgXlv46Ixcm3r6UpmWy7anX0GThd@postini.com; Wed, 29 Jul 2009 14:42:45 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009072916430130-945576 ; Wed, 29 Jul 2009 16:43:01 -0500 In-Reply-To: <973383174.5358341248659633920.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 To: Mukul Goyal X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 29 Jul 2009 16:42:33 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/29/2009 04:42:36 PM, Serialize complete at 07/29/2009 04:42:36 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/29/2009 04:43:01 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/29/2009 04:43:10 PM, Serialize complete at 07/29/2009 04:43:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0077407686257602_=" Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:42:53 -0000 This is a multipart message in MIME format. --=_alternative 0077407686257602_= Content-Type: text/plain; charset="US-ASCII" Mukal, Attached are my comments on your submission. In total, I like the approach. The idea of monitoring and repairing loops rather than architecturally disallowing loops is simple and seems effective. I can't say I completely understood the entire draft. I think a few well placed examples would help. Also there seems to be cases (see p7) where you temporally eliminate route discovery requests. Not sure why this is needed. Following are my detailed comments. p4: Routing domains I am not sure why we would want to define routing domains. This is extra configuration effort that doesn't necessarily add any value. I wouldn't know a priori how to define the logical entities. p5:#4:Routing Table The neighbor discovery process is different than 6LoWPANs. Can't we build the neighbor lists using 6LoWPAN ND algorithms? p7:bullet 6 I don't understand why we would build a list of all unreachable destinations. Mukul Goyal Sent by: roll-bounces@ietf.org 07/26/2009 08:54 PM To roll cc Subject [Roll] An alternative to RPL Hi all, Please see a new draft describing an alternate routing solution for LLN: http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt This solution allows optimal (or good quality) routes to be achieved to any destination in the LLN (and not just the LBRs as in RPL). Both multipoint-to-point and point-to-point traffic can use this solution. In this solution, only routers in the vicinity of existing routes maintain state about a destination once the route discovery is done. The solution uses the loop correction strategy I described in an earlier email combined with data packet based loop detection. I will submit this draft to IETF repository once it allows me to do so (right now I can't submit a new draft). Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0077407686257602_= Content-Type: text/html; charset="US-ASCII"

Mukal,

Attached are my comments on your submission.  In total, I like the approach.  The idea of monitoring and repairing loops rather than architecturally disallowing loops is simple and seems effective.  

I can't say I completely understood the entire draft.  I think a few well placed examples would help.  Also there seems to be cases (see p7) where you temporally eliminate route discovery requests.  Not sure why this is needed.  


Following are my detailed comments.


p4: Routing domains

I am not sure why we would want to define routing domains.  This is extra configuration effort that doesn't necessarily add any value.  I wouldn't know a priori how to define the logical entities.


p5:#4:Routing Table

The neighbor discovery process is different than 6LoWPANs.  Can't we build the neighbor lists using 6LoWPAN ND algorithms?


p7:bullet 6

I don't understand why we would build a list of all unreachable destinations.







Mukul Goyal <mukul@uwm.edu>
Sent by: roll-bounces@ietf.org

07/26/2009 08:54 PM

To
roll <roll@ietf.org>
cc
Subject
[Roll] An alternative to RPL





Hi all,

Please see a new draft describing an alternate routing solution for LLN:

http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt

This solution allows optimal (or good quality) routes to be achieved to any destination in the LLN (and not just the LBRs as in RPL). Both multipoint-to-point and point-to-point traffic can use this solution.

In this solution, only routers in the vicinity of existing routes maintain state about a destination once the route discovery is done.

The solution uses the loop correction strategy I described in an earlier email combined with data packet based loop detection.

I will submit this draft to IETF repository once it allows me to do so (right now I can't submit a new draft).

Thanks
Mukul
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0077407686257602_=-- From jvasseur@cisco.com Wed Jul 29 15:04:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1728B3A6BEF for ; Wed, 29 Jul 2009 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQUGTS-yV1ZZ for ; Wed, 29 Jul 2009 15:04:24 -0700 (PDT) Received: from syd-iport-2.cisco.com (syd-iport-2.cisco.com [64.104.193.197]) by core3.amsl.com (Postfix) with ESMTP id 81E0F3A6BE4 for ; Wed, 29 Jul 2009 15:04:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKdkcEoKS+eh/2dsb2JhbACCVbhliCeQLgWEEYFOYg X-IronPort-AV: E=Sophos;i="4.43,290,1246838400"; d="scan'208,217";a="55918896" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-2.cisco.com with ESMTP; 29 Jul 2009 22:04:12 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6TM46Jx027658; Thu, 30 Jul 2009 06:04:06 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TM46rT019964; Wed, 29 Jul 2009 22:04:06 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 06:04:06 +0800 Received: from [10.43.1.15] ([10.66.254.63]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 06:04:03 +0800 Message-Id: <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> From: JP Vasseur To: Samita Chakrabarti In-Reply-To: <026c01ca102d$602216e0$206644a0$@com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-14900028 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 00:03:59 +0200 References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> <026c01ca102d$602216e0$206644a0$@com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 22:04:04.0395 (UTC) FILETIME=[7C89A7B0:01CA1098] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=37559; t=1248905048; x=1249769048; c=relaxed/simple; s=hkgdkim1002; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=Bn75dt9zNdsVEworyWK0Sv16fqPy+ZgHzNMp9KW6ln8=; b=aZfhGTl8M2R4utxAxVl752JgfjI9K6Q/UBTQNlCUGwFkyyoUbA0GJmeAJD ECHPZ7aQ1h/uUi8yX7EwjJELq5LY43LO4BA0xAjHkxL1VrWjtidnGNfr12Qf jpFr2L3bXpDlD2Lf6GVqJslsv2p72Xp5Q6AMmQEPBjA+fpLgTzBJQ=; Authentication-Results: hkg-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 22:04:26 -0000 --Apple-Mail-6-14900028 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Samita, There are three parts in your email. On Jul 29, 2009, at 11:17 AM, Samita Chakrabarti wrote: > Hi JP/David, > Part 1. > Based on yesterdays presentations, it makes sense to me for RPL > draft to > move forward and work with DADR team to take advantage of their work > on > loop-detection and the cost based on historical information on packet > forwarding. OK. Part 2 > But, I am not sure if we want to adopt this as standards track wg > document, > as some of the ideas need more experiments to prove that would work > correctly. > Bear in mind that WG document adoption is the first step and we are far from being done. We will definitely need to work on various open issues as a WG and considering the amount of energy and willingness to work, I am highly confident that we will be able to quickly move forward as a group. We will of course take the time to build confidence on the protocol before publication submission and (according to our charter) we will follow the Std track. Part 3 > But, I agree with Mukul that RPL draft has weaknesses and for that > matter > multiple protocol might be needed in the future. As mentioned in my reply to Mukul this morning let's wait until we know what the final protocol potential weaknesses are. Thanks. JP. > So, is it possible to adopt > RPL-draft+some of DADR ideas as an experimental wg draft? Once we > have more > data on RPL design we can move that to standards track with changes > based on > test results? > That way, we can make sure that the design is solid and the standard > documentation will be a mature one. > > Thanks, > -Samita > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of JP >> Vasseur >> Sent: Tuesday, July 28, 2009 8:25 PM >> To: Mukul Goyal >> Cc: ROLL WG >> Subject: Re: [Roll] Moving forward with the protocol work >> >> Hi Mukul, >> >> I would really like to get your answer on whether you support the >> adoption >> of RPL as good foundation to move forward, adopting it as a WG ID. >> Your >> comments are extremely valid, see in line: >> >> On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: >> >>> Mischa, >>> >>> I am not speaking for Jerry but P2P flows are important in LLN >>> applications I am familiar with (which happen to be in commercial >>> building domain). I will have to go back to all the requirements >>> drafts but I would be surprised if other domains will not benefit >>> from >>> an efficient P2P solution. >>> >>> The main question is why are we insisting on "one solution fits all" >>> approach??? Why can't we recognize that different applications have >>> different requirements and offer multiple solutions (including RPL). >>> >>> Let RPL be used by applications that find it useful but we should >>> not >>> force RPL as the only solution available. >>> >>> In my view, RPL has the following three shortcomings: >>> >>> 1) Does not offer optimal/good P2P routing >>> 2) Does not allow destinations other than LBRs to be advertised. >>> Note that this point and the previous one are independent. >>> 3) Insistence on using DAG as the loop prevention mechanism. >>> >>> RPL is a good MP2P solution but we should not force it down the >>> throats of people who want good P2P routing as well. >>> >>> IETF has a long history of offering multiple solutions for a given >>> routing problem. We has multiple interior gateway protocols, >>> multiple >>> MANET solutions, multiple OSPF-MANET solutions. Why can't, and why >>> should not, we have multiple ROLL solutions?? >>> >>> I asked this question to JP right at the time the ROLL WG got a new >>> charter. The answer I got was - we will work on one solution for now >>> but we do not exclude other solutions. >>> >>> I think ROLL should offer multiple solutions and let an application >>> choose what fits it best. >>> >> >> Few things: >> >> 1) The ROLL routing protocol will have to support a good solution for >> P2P, this is a MUST requirement. For the time being a solution such >> as >> RPL is optimized for P2MP and P2MP and does support P2P but that MUST >> be improved. This was discussed and agreed yesterday during the WG >> meeting and on the mailing list. Next step is to work on this and >> your >> help will be greatly appreciated. >> 2) The DT will reply but RPL support the advertisements of >> destination >> other than LBRs >> 3) Loop detection: fully agree, I had proposed myself a solution but >> others may have other ideas. I personally think that this is one of >> the areas where we can borrow some ideas also from the DADR proposal. >> Again to be discussed on the list. >> 4) With regards to having more protocols, we are chartered to design >> one protocol for the time being. There is still lot of work to do, >> and >> the solution will continue to evolve. It is thus premature to think >> more than one protocol at this stage. >> >> Thanks. >> >> JP. >> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Mischa Dohler" >>> To: "Jerald P Martocci" >>> Cc: "ROLL WG" >>> Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central >>> Subject: Re: [Roll] Moving forward with the protocol work >>> >>> Jerry, I am not sure this was already discussed at the meeting in >>> person >>> but I think we are a little in a catch22 situation here since - as >>> far >>> as I remember - none of the requirement docs explicitly required >>> (MUST) >>> p2p situations. I gather that the design team did take these >>> documents >>> as their working basis which is why p2p is not efficiently >>> supported. In >>> our urban requirements draft, we actually did go as far as saying >>> that >>> p2p should not be the main design thrust but rather the highly >>> directional data flows towards a few sinks. Mischa. >>> >>> >>> Jerald.P.Martocci@jci.com wrote: >>>> >>>> I cannot yet affirm RPL as a working group draft since it hasn't >>>> yet >>>> stated how P2P communication will operate within the DAG. >>>> >>>> As I have noted in my review comments, connectivity to every node >>>> within >>>> the DAG is not assured. The traffic patterns within the LLN are >>>> also >>>> suspect since most packets must travel upward toward the LBR before >>>> finding their intended destination lower in the DAG. This >>>> imbalance >>>> will create network traffic congestion in the higher layers of the >>>> DAG. >>>> Hopping many hops up the DAG and back down the DAG to talk to a >>>> node >>>> that is in direct radio range seems totally inefficient. >>>> >>>> Latency and convergence time are also a concern. However, I can >>>> wait >>>> for simulation or implementations to ferret out these issues. >>>> >>>> Regards, >>>> >>>> Jerry Martocci >>>> >>>> >>>> >>>> >>>> >>>> *JP Vasseur * >>>> Sent by: roll-bounces@ietf.org >>>> >>>> 07/28/2009 11:36 AM >>>> >>>> >>>> To >>>> ROLL WG >>>> cc >>>> >>>> Subject >>>> [Roll] Moving forward with the protocol work >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Dear WG, >>>> >>>> First of all, thanks for all the time and energy you all have >>>> devoted >>>> during the past few weeks on the protocol work. There was excellent >>>> followup discussion at the physical WG meeting. >>>> >>>> To the question "Do you think that RPL provides an adequate >>>> foundation >>>> for the ROLL routing protocol work", there was clearly a good >>>> consensus in the WG meeting. It was also recognized there are still >>>> several open issues for which we WILL need help from many WG >>>> contributors, including the authors of other documents. >>>> >>>> Could you please confirm (or not) the adoption of draft-dt-roll- >>>> rpl-01 >>>> as a WG document ? >>>> >>>> Then we will of course move to the next step. >>>> >>>> Thanks, >>>> >>>> JP and David >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>>> > ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > --Apple-Mail-6-14900028 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Samita,

There are three parts in your = email.

On Jul 29, 2009, at 11:17 AM, Samita = Chakrabarti wrote:

Hi = JP/David,


Part = 1.

Based on yesterdays = presentations, it makes sense to me for RPL draft to
move forward and = work with DADR team to take advantage of their work on
loop-detection = and the cost based on historical information on = packet
forwarding.

OK.
<= div>
Part 2

But, I = am not sure if we want to adopt this as standards track wg = document,
as some of the ideas need more experiments to prove that = would = work
correctly.


Bear in = mind that WG document adoption is the first step and we are far from = being done.
We will definitely need to work on various open = issues as a WG and considering the amount
of energy and = willingness to work, I am highly confident that we will be able to = quickly move
forward as a group. We will of course take the = time to build confidence on the = protocol 
before 
But, I agree with Mukul that = RPL draft has weaknesses and for that matter
multiple protocol might = be needed in the future.

As = mentioned in my reply to Mukul this morning let's wait until we know = what the final protocol
potential weaknesses = are.

Thanks.

JP.
So, is it possible to = adopt
RPL-draft+some of DADR ideas as an experimental wg draft? Once = we have more
data on RPL design we can move that to standards track = with changes based on
test results?
That way, we can make sure = that the design is solid and the standard
documentation will be a = mature one.

Thanks,
-Samita

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of JP
Vasseur
Sent: = Tuesday, July 28, 2009 8:25 PM
To: Mukul Goyal
Cc: ROLL WG
Subject: Re: [Roll] Moving forward with the protocol = work

Hi = Mukul,

I would really = like to get your answer on whether you support the = adoption
of RPL as good = foundation to move forward, adopting it as a WG ID. = Your
comments are extremely = valid, see in line:

On Jul 29, = 2009, at 2:13 AM, Mukul Goyal wrote:

Mischa,

I am not speaking for Jerry but = P2P flows are important in LLN
applications I am familiar with = (which happen to be in = commercial
building domain). I will have to = go back to all the requirements
drafts but I would be surprised = if other domains will not benefit = from
an efficient P2P = solution.

The main question is why are we = insisting on "one solution fits = all"
approach??? Why can't we recognize that different = applications have
different requirements and offer = multiple solutions (including = RPL).

Let RPL be used by applications = that find it useful but we should = not
force RPL as the only solution = available.

In my view, RPL has the = following three shortcomings:

1) Does not offer optimal/good = P2P routing
2) Does not allow destinations = other than LBRs to be = advertised.
Note that this point and the = previous one are independent.
3) Insistence on using DAG as = the loop prevention mechanism.

RPL is a good MP2P solution but = we should not force it down the
throats of people who want good = P2P routing as well.

IETF has a long history of = offering multiple solutions for a = given
routing problem. We has multiple interior gateway = protocols, multiple
MANET solutions, multiple = OSPF-MANET solutions. Why can't, and = why
should not, we have multiple ROLL = solutions??

I asked this question to JP = right at the time the ROLL WG got a = new
charter. The answer I got was - we will work on one = solution for now
but we do not exclude other = solutions.

I think ROLL should offer = multiple solutions and let an = application
choose what fits it = best.


Few = things:

1) The ROLL = routing protocol will have to support a good solution = for
P2P, this is a MUST = requirement. For the time being a solution such = as
RPL is optimized for P2MP = and P2MP and does support P2P but that MUST
be improved. This was discussed and agreed yesterday = during the WG
meeting and on = the mailing list. Next step is to work on this and = your
help will be greatly = appreciated.
2) The DT will = reply but RPL support the advertisements of = destination
other than = LBRs
3) Loop detection: fully = agree, I had proposed myself a solution but
others may have other ideas. I personally think that this = is one of
the areas where we = can borrow some ideas also from the DADR = proposal.
Again to be = discussed on the list.
4) With = regards to having more protocols, we are chartered to = design
one protocol for the = time being. There is still lot of work to do, = and
the solution will continue = to evolve. It is thus premature to think
more than one protocol at this = stage.

Thanks.

JP.

Thanks
Mukul

----- Original Message = -----
From: "Mischa Dohler" <mischa.dohler@cttc.es>
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>= ;
Cc: "ROLL WG" <roll@ietf.org>
Sent: = Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada = Central
Subject: Re: [Roll] Moving forward with the protocol = work

Jerry, I am not sure this was = already discussed at the meeting = in
person
but I think we are a little in a = catch22 situation here since - as = far
as I remember - none of the requirement docs explicitly = required
(MUST)
p2p situations. I gather that = the design team did take these = documents
as their working basis which is = why p2p is not efficiently
supported. = In
our urban requirements draft, we actually did go as far as = saying that
p2p should not be the main = design thrust but rather the = highly
directional data flows towards a few sinks. = Mischa.


Jerald.P.Martocci@jci.com = wrote:

I = cannot yet affirm RPL as a working group draft since it hasn't = yet
stated = how P2P communication will operate within the = DAG.

As I = have noted in my review comments, connectivity to every = node
within
the = DAG is not assured.  The traffic patterns within the LLN are = also
suspect = since most packets must travel upward toward the LBR = before
finding = their intended destination lower in the DAG.  This = imbalance
will = create network traffic congestion in the higher layers of = the
DAG.
Hopping = many hops up the DAG and back down the DAG to talk to a = node
that = is in direct radio range seems totally = inefficient.

Latency = and convergence time are also a concern.  However, I can = wait
for = simulation or implementations to ferret out these = issues.

Regards,

Jerry = Martocci





*JP = Vasseur <jvasseur@cisco.com>*
Sent by: roll-bounces@ietf.org

07/28/2009 11:36 = AM


To
ROLL WG = <roll@ietf.org>
cc

Subject
[Roll] = Moving forward with the protocol = work








Dear = WG,

First = of all, thanks for all the time and energy you all have = devoted
during = the past few weeks on the protocol work. There was = excellent
followup= discussion at the physical WG = meeting.

To the = question "Do you think that RPL provides an = adequate
foundation
for= the ROLL routing protocol work", there was clearly a = good
consensus in the WG meeting. It was also recognized there = are still
several = open issues for which we WILL need help from many = WG
contributors, including the authors of other = documents.

Could = you please confirm (or not) the adoption of = draft-dt-roll-
rpl-01
as a = WG document ?

Then = we will of course move to the next = step.

Thanks,

JP and = David


_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



-----------------= -------------------------------------------------------

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll




= --Apple-Mail-6-14900028-- From sakane@tanu.org Wed Jul 29 23:24:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4673A6B55 for ; Wed, 29 Jul 2009 23:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X7yfNUD6cCI for ; Wed, 29 Jul 2009 23:24:23 -0700 (PDT) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id 74A343A6938 for ; Wed, 29 Jul 2009 23:24:23 -0700 (PDT) Received: from [10.43.1.45] (static-195.22.91.6.addr.tdcsong.se [195.22.91.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 50C4516B0C for ; Thu, 30 Jul 2009 15:24:22 +0900 (JST) Message-ID: <4A713C8E.1010403@tanu.org> Date: Thu, 30 Jul 2009 15:24:14 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: 'ROLL WG' References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> <026c01ca102d$602216e0$206644a0$@com> <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> In-Reply-To: <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 06:24:24 -0000 +1. we really need a base draft to move forward. it doesn't matter to choose one among some protocols. it means current original RPL may not be a final roll protocol as is. we have a time to improve it till WGLC. I take JP's comment. > Bear in mind that WG document adoption is the first step and we are far > from being done. > We will definitely need to work on various open issues as a WG and > considering the amount > of energy and willingness to work, I am highly confident that we will be > able to quickly move > forward as a group. We will of course *take the time to build confidence > on the protocol * > *before *publication submission* and (according to our charter) we will > follow the Std track.* From samitac@ipinfusion.com Thu Jul 30 00:24:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EE828C10A for ; Thu, 30 Jul 2009 00:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 J3aRnt1sFLFk for ; Thu, 30 Jul 2009 00:24:27 -0700 (PDT) Received: from smtp102.sbc.mail.re2.yahoo.com (smtp102.sbc.mail.re2.yahoo.com [68.142.229.103]) by core3.amsl.com (Postfix) with SMTP id 08F5D3A6E9C for ; Thu, 30 Jul 2009 00:24:26 -0700 (PDT) Received: (qmail 97805 invoked from network); 30 Jul 2009 07:24:28 -0000 Received: from unknown (HELO samitacD630) (samitac@130.129.82.175 with login) by smtp102.sbc.mail.re2.yahoo.com with SMTP; 30 Jul 2009 07:24:28 -0000 X-YMail-OSG: SOyLGskVM1k4vnqdIehuZV7DHz3B5VfMRyXr5IFjjO6anIikAwLinUKxaz44uMWfHa2PEdb4Ifde_VeJG1ptjQ2J9hviYc35qju7Vix9oKZVQc52J9Z7b6GWiYKWiH0tbP0BWAB6aI12NbGxbGFMGf9fIX7c2v.haczOgy14OBYkuxQ_2hoiF0jg.Owk2wBpgjfH.QxDbjVf3DyAIOL1HikIxzR5oYA2g9CYL203G6VHt2MrQ1EoQClf9c57hB7QpF2.vh7u5CbcZrcl X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'JP Vasseur'" References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> <026c01ca102d$602216e0$206644a0$@com> <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> In-Reply-To: <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> Date: Thu, 30 Jul 2009 00:24:24 -0700 Message-ID: <038701ca10e6$c4ae24f0$4e0a6ed0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0388_01CA10AC.184F4CF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQmHqDKDvOPuWzRoebkn0gmQRX1wATevrw Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:24:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0388_01CA10AC.184F4CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, Bear in mind that WG document adoption is the first step and we are far from being done. We will definitely need to work on various open issues as a WG and considering the amount of energy and willingness to work, I am highly confident that we will be able to quickly move forward as a group. We will of course take the time to build confidence on the protocol before publication submission and (according to our charter) we will follow the Std track. Part 3 Thanks for the explanation. I agree with your viewpoint. Regards, -Samita ------=_NextPart_000_0388_01CA10AC.184F4CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

 =

Bear in mind that WG document adoption is the first = step and we are far from being done.

We will definitely need to work on various open = issues as a WG and considering the amount

of energy and willingness to work, I am highly = confident that we will be able to quickly move

forward as a group. We will of course take the = time to build confidence on the protocol 

before publication submission and (according to = our charter) we will follow the Std track.

 

Part 3





 Thanks for the explanation. I agree with your = viewpoint.

 =

Regards,

-Samita=

------=_NextPart_000_0388_01CA10AC.184F4CF0-- From jvasseur@cisco.com Thu Jul 30 01:54:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB7C3A71A3 for ; Thu, 30 Jul 2009 01:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ujjPw7OkBMxo for ; Thu, 30 Jul 2009 01:54:58 -0700 (PDT) Received: from smtp-wifi.orange.fr (smtp-wifi-out.orange.fr [80.12.242.163]) by core3.amsl.com (Postfix) with ESMTP id 17AE63A71A4 for ; Thu, 30 Jul 2009 01:54:51 -0700 (PDT) Received: from [172.18.20.6] (unknown [81.253.35.63]) by mwinf5908 (SMTP Server) with ESMTP id 2A4F71C00215; Thu, 30 Jul 2009 10:54:35 +0200 (CEST) X-ME-UUID: 20090730085441173.2A4F71C00215@mwinf5908 Message-Id: <5D5F590D-D794-4402-A1DB-41EDB26CCC4B@cisco.com> From: JP Vasseur To: Samita Chakrabarti In-Reply-To: <038701ca10e6$c4ae24f0$4e0a6ed0$@com> Content-Type: multipart/alternative; boundary=Apple-Mail-3-53935165 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 10:54:34 +0200 References: <578654547.6035111248826426641.JavaMail.root@mail02.pantherlink.uwm.edu> <48BE288E-BF93-4D27-95FB-1DD3D8FAA764@cisco.com> <026c01ca102d$602216e0$206644a0$@com> <60B1E7B6-8564-4556-85C0-431C489BB039@cisco.com> <038701ca10e6$c4ae24f0$4e0a6ed0$@com> X-Mailer: Apple Mail (2.935.3) Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:54:58 -0000 --Apple-Mail-3-53935165 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit You are most welcome. Thanks. JP. On Jul 30, 2009, at 9:24 AM, Samita Chakrabarti wrote: > Hi JP, > > Bear in mind that WG document adoption is the first step and we are > far from being done. > We will definitely need to work on various open issues as a WG and > considering the amount > of energy and willingness to work, I am highly confident that we > will be able to quickly move > forward as a group. We will of course take the time to build > confidence on the protocol > before publication submission and (according to our charter) we will > follow the Std track. > > Part 3 > > > > > Thanks for the explanation. I agree with your viewpoint. > > Regards, > -Samita > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-3-53935165 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable You are most = welcome.

Thanks.

JP.

On Jul 30, 2009, at 9:24 AM, Samita Chakrabarti = wrote:

Hi JP,
 
Bear in mind that WG = document adoption is the first step and we are far from being = done.
We will definitely need = to work on various open issues as a WG and considering the = amount
of energy and willingness = to work, I am highly confident that we will be able to quickly = move
forward as a group. We = will of course take = the time to build confidence on the = protocol 
publication = submission and (according to our = charter) we will follow the Std = track.
Part = 3




 Thanks for the = explanation. I agree with your viewpoint.
 
Regards,
-SamitaRoll@ietf.org
Robert Cragie wrote: > > I am in favour of moving forward whilst acknowledging there is work to > be done, especially with regard to P2P and security. I also have some > concerns regarding subDAG orphaning in certain topologies. That's almost precisely what I'd have written. In addition to the subDAG orphaning (e.g. when a DAG detaches but the RA-DIO isn't heard by all children), the Objective Function also has some security considerations that haven't yet been discussed or addressed. In particular, in a non-homogenous network, a misbehaved node could either become a black hole or violate the rules and deliberately route through a battery powered node. Ed Beroset --=_alternative 0034061A85257603_= Content-Type: text/html; charset="US-ASCII"
> Robert Cragie wrote:
>
> I am in favour of moving forward whilst acknowledging there is work to
> be done, especially with regard to P2P and security. I also have some
> concerns regarding subDAG orphaning in certain topologies.

That's almost precisely what I'd have written.  In addition to the subDAG orphaning (e.g. when a DAG detaches but the RA-DIO isn't heard by all children), the Objective Function also has some security considerations that haven't yet been discussed or addressed.  In particular, in a non-homogenous network, a misbehaved node could either become a black hole or violate the rules and deliberately route through a battery powered node.  

Ed Beroset --=_alternative 0034061A85257603_=-- From prvs=45531a805=mukul@uwm.edu Thu Jul 30 04:25:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CEAC3A6C60 for ; Thu, 30 Jul 2009 04:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERabKuaW-oVy for ; Thu, 30 Jul 2009 04:25:40 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 1E1BA3A6B72 for ; Thu, 30 Jul 2009 04:25:40 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 30 Jul 2009 06:25:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 435CBC085A8; Thu, 30 Jul 2009 06:25:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pncn+F+sNFhK; Thu, 30 Jul 2009 06:25:40 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CC466C085A1; Thu, 30 Jul 2009 06:25:40 -0500 (CDT) Date: Thu, 30 Jul 2009 06:25:40 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1344414827.6388331248953140552.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <918287861.6388211248952986220.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:28:00 -0000 Hi JP As a _protocol_, RPL is not yet complete. It needs addition of a good P2P solution at the least. I imagine it is possible to incorporate in RPL the route discovery and maintenance mechanisms discussed in draft-goyal-roll-dv-01 to achieve better P2P routing (basically building a DAG rooted at the destination during route discovery; pruning it afterwards and using this pruned DAG, limited to the the neighborhood of discovered routes, for route maintenance). I guess other mechanisms may also be possible. As a _framework_ for all future ROLL work, RPL has a serious deficiency. RPL is too tightly interweaved with one particular loop prevention mechanism - the one based on DAGs. At present, it does not seem possible to use RPL with a different loop prevention/avoidance/detection+correction mechanism. Hence, RPL is not ready to serve as a general framework for future ROLL work. I think that RPL needs to be modified so that the use of DAGs becomes optional. Then, it will be possible to use RPL as a framework. Right now, it is not a framework. Thus, it seems that more work is required before RPL is ready for WG status either as a protocol or as a framework. I am not sure glossing over known deficiencies and rushing with WG status for RPL would serve any useful purpose. Rather than granting it a WG status now and trying to solve the problems later on, I would suggest the reverse route. Regards Mukul To: "Mukul Goyal" Cc: "Mischa Dohler" , "ROLL WG" Sent: Tuesday, July 28, 2009 10:25:04 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Hi Mukul, I would really like to get your answer on whether you support the adoption of RPL as good foundation to move forward, adopting it as a WG ID. Your comments are extremely valid, see in line: On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: > Mischa, > > I am not speaking for Jerry but P2P flows are important in LLN > applications I am familiar with (which happen to be in commercial > building domain). I will have to go back to all the requirements > drafts but I would be surprised if other domains will not benefit > from an efficient P2P solution. > > The main question is why are we insisting on "one solution fits all" > approach??? Why can't we recognize that different applications have > different requirements and offer multiple solutions (including RPL). > > Let RPL be used by applications that find it useful but we should > not force RPL as the only solution available. > > In my view, RPL has the following three shortcomings: > > 1) Does not offer optimal/good P2P routing > 2) Does not allow destinations other than LBRs to be advertised. > Note that this point and the previous one are independent. > 3) Insistence on using DAG as the loop prevention mechanism. > > RPL is a good MP2P solution but we should not force it down the > throats of people who want good P2P routing as well. > > IETF has a long history of offering multiple solutions for a given > routing problem. We has multiple interior gateway protocols, > multiple MANET solutions, multiple OSPF-MANET solutions. Why can't, > and why should not, we have multiple ROLL solutions?? > > I asked this question to JP right at the time the ROLL WG got a new > charter. The answer I got was - we will work on one solution for now > but we do not exclude other solutions. > > I think ROLL should offer multiple solutions and let an application > choose what fits it best. > Few things: 1) The ROLL routing protocol will have to support a good solution for P2P, this is a MUST requirement. For the time being a solution such as RPL is optimized for P2MP and P2MP and does support P2P but that MUST be improved. This was discussed and agreed yesterday during the WG meeting and on the mailing list. Next step is to work on this and your help will be greatly appreciated. 2) The DT will reply but RPL support the advertisements of destination other than LBRs 3) Loop detection: fully agree, I had proposed myself a solution but others may have other ideas. I personally think that this is one of the areas where we can borrow some ideas also from the DADR proposal. Again to be discussed on the list. 4) With regards to having more protocols, we are chartered to design one protocol for the time being. There is still lot of work to do, and the solution will continue to evolve. It is thus premature to think more than one protocol at this stage. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Mischa Dohler" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > Jerry, I am not sure this was already discussed at the meeting in > person > but I think we are a little in a catch22 situation here since - as far > as I remember - none of the requirement docs explicitly required > (MUST) > p2p situations. I gather that the design team did take these documents > as their working basis which is why p2p is not efficiently > supported. In > our urban requirements draft, we actually did go as far as saying that > p2p should not be the main design thrust but rather the highly > directional data flows towards a few sinks. Mischa. > > > Jerald.P.Martocci@jci.com wrote: >> >> I cannot yet affirm RPL as a working group draft since it hasn't yet >> stated how P2P communication will operate within the DAG. >> >> As I have noted in my review comments, connectivity to every node >> within >> the DAG is not assured. The traffic patterns within the LLN are also >> suspect since most packets must travel upward toward the LBR before >> finding their intended destination lower in the DAG. This imbalance >> will create network traffic congestion in the higher layers of the >> DAG. >> Hopping many hops up the DAG and back down the DAG to talk to a node >> that is in direct radio range seems totally inefficient. >> >> Latency and convergence time are also a concern. However, I can wait >> for simulation or implementations to ferret out these issues. >> >> Regards, >> >> Jerry Martocci >> >> >> >> >> >> *JP Vasseur * >> Sent by: roll-bounces@ietf.org >> >> 07/28/2009 11:36 AM >> >> >> To >> ROLL WG >> cc >> >> Subject >> [Roll] Moving forward with the protocol work >> >> >> >> >> >> >> >> >> Dear WG, >> >> First of all, thanks for all the time and energy you all have devoted >> during the past few weeks on the protocol work. There was excellent >> followup discussion at the physical WG meeting. >> >> To the question "Do you think that RPL provides an adequate >> foundation >> for the ROLL routing protocol work", there was clearly a good >> consensus in the WG meeting. It was also recognized there are still >> several open issues for which we WILL need help from many WG >> contributors, including the authors of other documents. >> >> Could you please confirm (or not) the adoption of draft-dt-roll- >> rpl-01 >> as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Thu Jul 30 05:13:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C9928C1D7 for ; Thu, 30 Jul 2009 05:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aDA6sCm4o4p for ; Thu, 30 Jul 2009 05:13:10 -0700 (PDT) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by core3.amsl.com (Postfix) with ESMTP id E310D3A686D for ; Thu, 30 Jul 2009 05:13:09 -0700 (PDT) Received: by fxm7 with SMTP id 7so630878fxm.34 for ; Thu, 30 Jul 2009 05:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=5YrcrYyLivpX0q83zD7wuqF+YPRrcKEXPN8wTBVe/5w=; b=BUgdKPH6f8x6juMHLBxQQvvC55Xj6Yrl8SvMJNeGERFiaPhwiKTEDt8r58wQwbP3yY GnFj7bBMNERNkjXg//y8qggXEs7WtWl0s3wF3ZuqN8lOrqd0J0A3MnB8SJwgF057ZQg6 7K2VXjANTBV5GNnFgtj5XoMYI2wjWqM32EVtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=ccZY1hlfd9pEroacyZlA2SGyDjXzNP6VRvdWwirqeKgIpB0PGeefo5KyRmMRisRgw9 s4ZYaPrN2JDNTTic3KXNtCI21PuG8Y5YqBE1dtFRohWbKOY2noS142J1YLuFA1mEIhD2 zIvz63TnB1qd6uIZuHfOxFx/zlUicOCrXqRKA= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.193.12 with SMTP id v12mr667336mup.2.1248955988936; Thu, 30 Jul 2009 05:13:08 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Thu, 30 Jul 2009 14:12:35 +0200 X-Google-Sender-Auth: aa1046627b40fdf3 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=0016e652f9f40f8a74046feb3af4 Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:13:11 -0000 --0016e652f9f40f8a74046feb3af4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi JP, Hi David, RPL is indeed an interesting approach. Other approaches that were put forward are also interesting, such as draft-goyal-roll-dv, and draft-iwao-roll-dadr. However, we all agree: neither is mature. The first priority is indeed *protocol work*. It is paramount to develop these different approaches further, to identify if and how they could work/benefit from one another. Therefore at this point, I do not understand the urgency regarding changing the status of RPL to working group document. It may rightfully become such, down the road, once it's trade-offs are better understood and the document is more fleshed out -- possibly incorporating some ideas from other approaches. But for now it seems a tad too early to be fully justified. Changing the status of RPL to working group document in a hurry has nothing to do with speeding up the actual technical progress, so defering a little is not likely to slow down in any way the top priority: I mean protocol work. In a nutshell: 1- defering change to WG status will not slow down protocol development, which is priority number 1, 2- some concerns were expressed regarding RPL, in its current premature state, 3- there's nothing to lose yet with a more conservative attitude, instead of a rush, concerning official procedures. What do you think? Regards, Emmanuel On Tue, Jul 28, 2009 at 6:34 PM, JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent followup > discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation for > the ROLL routing protocol work", there was clearly a good consensus in the > WG meeting. It was also recognized there are still several open issues for > which we WILL need help from many WG contributors, including the authors of > other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a > WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0016e652f9f40f8a74046feb3af4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP, Hi David,

RPL is indeed an interesting approach. = Other approaches that were put forward are also interesting, such as draft-= goyal-roll-dv, and draft-iwao-roll-dadr.

However, = we all agree: neither is mature. The first priority is indeed *protocol wor= k*. It is paramount to develop these different approaches further, to ident= ify if and how they could work/benefit from one another.

Therefore=A0at this point, I do not understand the urge= ncy regarding changing the status of RPL to working group document. It may = rightfully become such, down the road, once it's trade-offs are better = understood and the document is more fleshed out -- possibly incorporating s= ome ideas from other approaches. But for now it seems a tad too early to be= fully justified.

Changing the status of RPL to working group document in= a hurry has nothing to do with speeding up the actual=A0technical progress= , so defering a little is not likely to slow down in any way the top priori= ty: I mean=A0protocol work.

In a nutshell:

1- defering cha= nge to WG status will not slow down protocol development, which is priority= number 1,
2- some concerns were expressed regarding RPL, in its = current premature state,
3- there's nothing to lose yet with a more conservative attitude, = instead of a rush, concerning official procedures.

What do you think?


Emmanuel



On Tue, Jul 28, 2009 at 6:34 PM, JP Vasseur <jvasseur@cisco.com> wrote:<= br>
Dear WG,

First of all, thanks for all the time and energy you all have devoted durin= g the past few weeks on the protocol work. There was excellent followup dis= cussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation= for the ROLL routing protocol work", there was clearly a good consens= us in the WG meeting. It was also recognized there are still several open i= ssues for which we WILL need help from many WG contributors, including the = authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a= WG document ?

Then we will of course move to the next step.

Thanks,

JP and David


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0016e652f9f40f8a74046feb3af4-- From prvs=45531a805=mukul@uwm.edu Thu Jul 30 05:50:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319913A6BB6; Thu, 30 Jul 2009 05:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, 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 kSm45v2qBPL0; Thu, 30 Jul 2009 05:50:34 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 2790D3A6B8B; Thu, 30 Jul 2009 05:50:34 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 30 Jul 2009 07:50:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EB2AFC085A7; Thu, 30 Jul 2009 07:50:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GQo8kLMtJd2; Thu, 30 Jul 2009 07:50:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BEF96C085A1; Thu, 30 Jul 2009 07:50:32 -0500 (CDT) Date: Thu, 30 Jul 2009 07:50:32 -0500 (CDT) From: Mukul Goyal To: Jerald P Martocci Message-ID: <1497174814.6399451248958232653.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <935286666.6399231248958181431.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:50:35 -0000 Hi Jerry, Thanks for your comments. Please see the response inline. >Attached are my comments on your submission. =C2=A0In total, I like the ap= proach. =C2=A0The idea of monitoring and repairing loops rather than archit= ecturally disallowing loops is simple and seems effective. =C2=A0=20 >I can't say I completely understood the entire draft. =C2=A0I think a few = well placed examples would help. I will add examples to the draft. >Also there seems to be cases (see p7) where you temporally eliminate route= discovery requests. =C2=A0Not sure why this is needed. =C2=A0=20 Not sure what you mean. There seems to be some misunderstanding. The route = discovery requests are never eliminated. =20 >Following are my detailed comments.=20 >p4: Routing domains=20 >I am not sure why we would want to define routing domains. =C2=A0This is e= xtra configuration effort that doesn't necessarily add any value. =C2=A0I w= ouldn't know a priori how to define the logical entities.=20 The routing domains are required to limit the scope of route discovery. We = do not want all 10K nodes in the network to know that A wants to find a rou= te to B. The idea is that if we could define routing domains such that most= source-destination pairs lie in the same domain, route discovery can be re= stricted to nodes within the domain. Ofcourse, some destinations can be uni= versal, i.e. route discovery for these destinations have network-wide scope= . Also, for small networks, it may be OK to not have routing domains at all= . My hope is that, most of the times, routing domains can be defined using = natural divisions in the network. >p5:#4:Routing Table=20 >The neighbor discovery process is different than 6LoWPANs. =C2=A0Can't we = build the neighbor lists using 6LoWPAN ND algorithms?=20 Yes, we should be able to do that. >p7:bullet 6=20 >I don't understand why we would build a list of all unreachable destinatio= ns.=20 When a router sends an RA listing a bunch of destinations for which route d= iscovery is desired, the receiving router should enter the destinations, fo= r which it does not yet know the routes, to its route discovery and mainten= ance tables so that it can advertise the need to find routes to these desti= nations further in its own RAs. Ofcourse, the local policy can always be en= forced to decide whether to create new entries in the route discovery and m= aintenance tables or not. Thanks Mukul From prvs=45531a805=mukul@uwm.edu Thu Jul 30 06:17:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6B028C199 for ; Thu, 30 Jul 2009 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 ytMKg6quF78c for ; Thu, 30 Jul 2009 06:17:44 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id DEE3728C17B for ; Thu, 30 Jul 2009 06:17:43 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 30 Jul 2009 08:17:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8901DC085A3; Thu, 30 Jul 2009 08:17:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slOUS8o4-WqW; Thu, 30 Jul 2009 08:17:45 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 330DBC085A1; Thu, 30 Jul 2009 08:17:45 -0500 (CDT) Date: Thu, 30 Jul 2009 08:17:45 -0500 (CDT) From: Mukul Goyal To: Mischa Dohler Message-ID: <1435187642.6407451248959865082.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <739450438.6404891248959338493.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:17:45 -0000 Mischa, >We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as P2P routing). But, the implication of giving it the WG status seems to be that RPL would be the _framework_ on which all future ROLL work would be based. I am not in support of the use of RPL as a framework unless it eliminates its current tight coupling with DAGs (a, rather heavy duty, loop prevention mechanism). >I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. I agree. I was surprised to see such heavy emphasis in RPL on loop prevention. It should be possible for an LLN application to use a simple mechanism to deal with loops or decide not to deal with loops at all. RPL does not allow that. With RPL, you have to use DAGs, which is a very restrictive and very heavy duty loop prevention mechanism. >P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Absolutely, P2P routing requirement is well within 95 percentile domain. I guess other folks will affirm this. Meeting this requirement is not as difficult as it may seem (even within RPL). >Security is an important issue. >Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I agree there is a concern if the overhead of running IP is worth the benefits. > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Unfortunately, I can not support such a move at present. Thanks Mukul JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From engineer.umair@yahoo.com Thu Jul 30 06:42:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1833A692A for ; Thu, 30 Jul 2009 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldvDRInpctgB for ; Thu, 30 Jul 2009 06:42:28 -0700 (PDT) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by core3.amsl.com (Postfix) with SMTP id 8FD343A68E6 for ; Thu, 30 Jul 2009 06:42:28 -0700 (PDT) Received: from [216.252.122.219] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jul 2009 13:42:28 -0000 Received: from [69.147.65.168] by t4.bullet.sp1.yahoo.com with NNFMP; 30 Jul 2009 13:42:28 -0000 Received: from [127.0.0.1] by omp503.mail.sp1.yahoo.com with NNFMP; 30 Jul 2009 13:42:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 655066.44194.bm@omp503.mail.sp1.yahoo.com Received: (qmail 37701 invoked by uid 60001); 30 Jul 2009 13:42:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248961348; bh=kLlUPxgz8FgVuj+ycq8oB5v3XLL0UQquic4kEhikkHA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZkGJa0fwjnFx3riBYOXe7Azsv+hsIr/YhneieUxgEURZrBdr8BaLPYoXj5x/zDdrTj29nQMESL/VdKpOM26IIZCQgFPa4eE9Ej6ZYQcNRk5oq3iBZJf1l1wvg7SLIbmHj3Yf/tGr075d4jATKFrXQBs6jf0Jx1xR53Pa0TFprNI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hdcTFzsCTyaH0JrhZokpW2+b9fImSLYVmrgNOok+/j3fZaSweaA4klXwMLobWAHfUI4/CHnyYGR2uXeetih2w49hUyiHJ1ueLbpHueTvmPHZFzsKyMQT4fGDifoq8X1419ya42ipm1aF+fQQ9pUBrmG7rC9yunmILyx224txGhw=; Message-ID: <534063.36621.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: NtF2NgAVM1ndGcGOZdjdK2qvOwmY.CzBrKRTfURjsrYuZ9p9NWi1vze5HtjJ0vC3Tiaaac_4bmwQyDXr5_ei6S8jfFAZsTwCBGcC5gf0CJP._bkXkpw05KebVJsGeF_9arLu_UbLMMe.YsXtvhA761XoOFGCHTAETePbt_ecKv_HOMr3MmEgnpKrqoU3k13L9Rq6gGhhGxTI84FKfZkmZvoudTCaUnnkHu8NpgAiZiRmhpmPCjitiK0RaZe9ZH0nDzBQES1G0fbCyBAsdeFE7r.mFYMyHc4T_pM2SbaAF0sO_eovdXUK5K2lgd5dSZmM7Td2mziBR_X5YD5Xhbw- Received: from [116.71.182.227] by web45502.mail.sp1.yahoo.com via HTTP; Thu, 30 Jul 2009 06:42:28 PDT X-Mailer: YahooMailClassic/6.0.19 YahooMailWebService/0.7.289.15 Date: Thu, 30 Jul 2009 06:42:28 -0700 (PDT) From: Umair Bussi To: Mukul Goyal In-Reply-To: <1497174814.6399451248958232653.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:42:29 -0000 Regards, Umair --- On Thu, 7/30/09, Mukul Goyal wrote: > From: Mukul Goyal > Subject: Re: [Roll] An alternative to RPL > To: "Jerald P Martocci" > Cc: "roll" , roll-bounces@ietf.org > Date: Thursday, July 30, 2009, 12:50 PM > Hi Jerry, >=20 > Thanks for your comments. Please see the response inline. >=20 > >Attached are my comments on your submission. =A0In > total, I like the approach. =A0The idea of monitoring and > repairing loops rather than architecturally disallowing > loops is simple and seems effective. =A0=20 >=20 > >I can't say I completely understood the entire draft. > =A0I think a few well placed examples would help. >=20 > I will add examples to the draft. >=20 > >Also there seems to be cases (see p7) where you > temporally eliminate route discovery requests. =A0Not sure > why this is needed. =A0=20 >=20 > Not sure what you mean. There seems to be some > misunderstanding. The route discovery requests are never > eliminated. > =A0=20 > >Following are my detailed comments.=20 >=20 >=20 > >p4: Routing domains=20 >=20 > >I am not sure why we would want to define routing > domains. =A0This is extra configuration effort that doesn't > necessarily add any value. =A0I wouldn't know a priori how to > define the logical entities.=20 >=20 > The routing domains are required to limit the scope of > route discovery. We do not want all 10K nodes in the network > to know that A wants to find a route to B. The idea is that > if we could define routing domains such that most > source-destination pairs lie in the same domain, route > discovery can be restricted to nodes within the domain. > Ofcourse, some destinations can be universal, i.e. route > discovery for these destinations have network-wide scope. > Also, for small networks, it may be OK to not have routing > domains at all. My hope is that, most of the times, routing > domains can be defined using natural divisions in the > network. I am unable to realize the idea. What logic is going to be used. Will it be= dependent on physical arrangemnet and going to be configured after deploym= ent. >=20 > >p5:#4:Routing Table=20 >=20 > >The neighbor discovery process is different than > 6LoWPANs. =A0Can't we build the neighbor lists using 6LoWPAN > ND algorithms?=20 >=20 > Yes, we should be able to do that. >=20 > >p7:bullet 6=20 >=20 > >I don't understand why we would build a list of all > unreachable destinations.=20 >=20 > When a router sends an RA listing a bunch of destinations > for which route discovery is desired, the receiving router > should enter the destinations, for which it does not yet > know the routes, to its route discovery and maintenance > tables so that it can advertise the need to find routes to > these destinations further in its own RAs. Ofcourse, the > local policy can always be enforced to decide whether to > create new entries in the route discovery and maintenance > tables or not. >=20 > Thanks > Mukul >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =0A=0A=0A From prvs=45531a805=mukul@uwm.edu Thu Jul 30 07:39:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744B43A70B5 for ; Thu, 30 Jul 2009 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 DV8dx8ply6zD for ; Thu, 30 Jul 2009 07:39:50 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 774CF3A6B1D for ; Thu, 30 Jul 2009 07:39:50 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 30 Jul 2009 09:39:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 07224C085A6; Thu, 30 Jul 2009 09:39:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89H+7xJ+GxMN; Thu, 30 Jul 2009 09:39:51 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D134BC085A1; Thu, 30 Jul 2009 09:39:51 -0500 (CDT) Date: Thu, 30 Jul 2009 09:39:51 -0500 (CDT) From: Mukul Goyal To: Umair Bussi Message-ID: <1502201474.6443831248964791707.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <625440093.6437901248963950808.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 14:39:51 -0000 Hi Umair, The basic idea is to limit the scope of route discovery.=20 It may be possible to identify natural physical or logical partitions in th= e network such that good routes among the nodes in a partition can be found= within the partition itself. Such partitions, if they exist, are natural r= outing domains. Also, consider the case where we have multiple independent, small LLNs and = there is a need to integrate them to allow cross-LLN communication among se= lected nodes. Thus, most communication still takes place within the old LLN= boundaries but there is a desire to allow further communication across bou= ndaries. Such small LLN units may be configured as separate routing domains= with nodes involved in cross-unit communication marked as "universal" dest= inations. Ofcourse, separation of LLN nodes in routing domains may result i= n sacrifice of route redundancy if the domain boundaries have significant p= hysical overlap. There is a clear need for scalability in ROLL protocols since LLNs may have= 1000's of nodes. Routing domains is one way of achieving this. Thanks Mukul=20 >=20 > >p4: Routing domains=20 >=20 > >I am not sure why we would want to define routing > domains. =C2=A0This is extra configuration effort that doesn't > necessarily add any value. =C2=A0I wouldn't know a priori how to > define the logical entities.=20 >=20 > The routing domains are required to limit the scope of > route discovery. We do not want all 10K nodes in the network > to know that A wants to find a route to B. The idea is that > if we could define routing domains such that most > source-destination pairs lie in the same domain, route > discovery can be restricted to nodes within the domain. > Ofcourse, some destinations can be universal, i.e. route > discovery for these destinations have network-wide scope. > Also, for small networks, it may be OK to not have routing > domains at all. My hope is that, most of the times, routing > domains can be defined using natural divisions in the > network. I am unable to realize the idea. What logic is going to be used. Will it be= dependent on physical arrangemnet and going to be configured after deploym= ent. From Jerald.P.Martocci@jci.com Thu Jul 30 07:42:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C7F3A71C9; Thu, 30 Jul 2009 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooDsTOkB-MOA; Thu, 30 Jul 2009 07:42:33 -0700 (PDT) Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by core3.amsl.com (Postfix) with ESMTP id A2DF53A71C2; Thu, 30 Jul 2009 07:42:32 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKSnGxWpjj9NEYo3OXw2eJnsKcs0NV4Djr@postini.com; Thu, 30 Jul 2009 07:42:35 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009073009423906-1002266 ; Thu, 30 Jul 2009 09:42:39 -0500 In-Reply-To: <1497174814.6399451248958232653.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 To: Mukul Goyal X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 30 Jul 2009 09:42:22 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/30/2009 09:42:30 AM, Serialize complete at 07/30/2009 09:42:30 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 09:42:39 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 09:42:41 AM, Serialize complete at 07/30/2009 09:42:41 AM Content-Type: multipart/alternative; boundary="=_alternative 0050C81D86257603_=" Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 14:42:34 -0000 This is a multipart message in MIME format. --=_alternative 0050C81D86257603_= Content-Type: text/plain; charset="US-ASCII" Comments on comments below... Mukul Goyal 07/30/2009 07:50 AM To Jerald P Martocci cc roll , roll-bounces@ietf.org Subject Re: [Roll] An alternative to RPL Hi Jerry, Thanks for your comments. Please see the response inline. >Attached are my comments on your submission. In total, I like the approach. The idea of monitoring and repairing loops rather than architecturally disallowing loops is simple and seems effective. >I can't say I completely understood the entire draft. I think a few well placed examples would help. I will add examples to the draft. >Also there seems to be cases (see p7) where you temporally eliminate route discovery requests. Not sure why this is needed. Not sure what you mean. There seems to be some misunderstanding. The route discovery requests are never eliminated. I'm probably misreading the text. Here's the paragraph... o An existing route discovery table entry is refreshed, i.e. allowed to exist for a certain additional time duration, if it was created in response to an RA from this router and the current RA includes in its route discovery list the destination corresponding to this entry. The phrase "allowed to exist for a certain additional time duration" implies to me that route discovery entries are temporal. I would think that as long as the route is valid, it would be kept. >Following are my detailed comments. >p4: Routing domains >I am not sure why we would want to define routing domains. This is extra configuration effort that doesn't necessarily add any value. I wouldn't know a priori how to define the logical entities. The routing domains are required to limit the scope of route discovery. We do not want all 10K nodes in the network to know that A wants to find a route to B. The idea is that if we could define routing domains such that most source-destination pairs lie in the same domain, route discovery can be restricted to nodes within the domain. Ofcourse, some destinations can be universal, i.e. route discovery for these destinations have network-wide scope. Also, for small networks, it may be OK to not have routing domains at all. My hope is that, most of the times, routing domains can be defined using natural divisions in the network. Ah!!! ok. I wasn't thinking about 10K LLN deployments. In the building market we have maybe 250 nodes in the LLN. I'm fine with defining domains so that the default is the entire LLN. This way for small LLNs, there would be no additional work. >p5:#4:Routing Table >The neighbor discovery process is different than 6LoWPANs. Can't we build the neighbor lists using 6LoWPAN ND algorithms? Yes, we should be able to do that. Good. We should leverage other work whenever possible. >p7:bullet 6 >I don't understand why we would build a list of all unreachable destinations. When a router sends an RA listing a bunch of destinations for which route discovery is desired, the receiving router should enter the destinations, for which it does not yet know the routes, to its route discovery and maintenance tables so that it can advertise the need to find routes to these destinations further in its own RAs. Ofcourse, the local policy can always be enforced to decide whether to create new entries in the route discovery and maintenance tables or not. ok. Makes sense now. Thanks Mukul --=_alternative 0050C81D86257603_= Content-Type: text/html; charset="US-ASCII"

Comments on comments below...




Mukul Goyal <mukul@uwm.edu>

07/30/2009 07:50 AM

To
Jerald P Martocci <Jerald.P.Martocci@jci.com>
cc
roll <roll@ietf.org>, roll-bounces@ietf.org
Subject
Re: [Roll] An alternative to RPL





Hi Jerry,

Thanks for your comments. Please see the response inline.

>Attached are my comments on your submission.  In total, I like the approach.  The idea of monitoring and repairing loops rather than architecturally disallowing loops is simple and seems effective.  

>I can't say I completely understood the entire draft.  I think a few well placed examples would help.

I will add examples to the draft.

>Also there seems to be cases (see p7) where you temporally eliminate route discovery requests.  Not sure why this is needed.  

Not sure what you mean. There seems to be some misunderstanding. The route discovery requests are never eliminated.

I'm probably misreading the text.  Here's the paragraph...


   o  An existing route discovery table entry is refreshed, i.e. allowed
      to exist for a certain additional time duration, if it was created
      in response to an RA from this router and the current RA includes
      in its route discovery list the destination corresponding to this
      entry.
 
The phrase "allowed to exist for a certain additional time duration" implies to me that route discovery entries are temporal.  I would think that as long as the route is valid, it would be kept.



>Following are my detailed comments.


>p4: Routing domains

>I am not sure why we would want to define routing domains.  This is extra configuration effort that doesn't necessarily add any value.  I wouldn't know a priori how to define the logical entities.

The routing domains are required to limit the scope of route discovery. We do not want all 10K nodes in the network to know that A wants to find a route to B. The idea is that if we could define routing domains such that most source-destination pairs lie in the same domain, route discovery can be restricted to nodes within the domain. Ofcourse, some destinations can be universal, i.e. route discovery for these destinations have network-wide scope. Also, for small networks, it may be OK to not have routing domains at all. My hope is that, most of the times, routing domains can be defined using natural divisions in the network.

Ah!!!  ok.  I wasn't thinking about 10K LLN deployments.  In the building market we have maybe 250 nodes in the LLN.  I'm fine with defining domains so that the default is the entire LLN.  This way for small LLNs, there would be no additional work.

>p5:#4:Routing Table

>The neighbor discovery process is different than 6LoWPANs.  Can't we build the neighbor lists using 6LoWPAN ND algorithms?

Yes, we should be able to do that.

Good.  We should leverage other work whenever possible.

>p7:bullet 6

>I don't understand why we would build a list of all unreachable destinations.

When a router sends an RA listing a bunch of destinations for which route discovery is desired, the receiving router should enter the destinations, for which it does not yet know the routes, to its route discovery and maintenance tables so that it can advertise the need to find routes to these destinations further in its own RAs. Ofcourse, the local policy can always be enforced to decide whether to create new entries in the route discovery and maintenance tables or not.

ok.  Makes sense now.

Thanks
Mukul
--=_alternative 0050C81D86257603_=-- From zach@sensinode.com Thu Jul 30 08:02:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3962E3A71C3 for ; Thu, 30 Jul 2009 08:02:46 -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 kImqkZhLsq2V for ; Thu, 30 Jul 2009 08:02:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0A0A13A6A63 for ; Thu, 30 Jul 2009 08:02:44 -0700 (PDT) Received: from snl-zach.local ([192.165.126.74]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n6UF2fKU007060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 18:02:41 +0300 Message-ID: <4A71B613.7000504@sensinode.com> Date: Thu, 30 Jul 2009 18:02:43 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Mukul Goyal References: <1435187642.6407451248959865082.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1435187642.6407451248959865082.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:02:46 -0000 Hi, Mukul Goyal wrote: > Mischa, > >> We should use this early design stage to come up with one solution - one > solution which is not necessarily optimum for all cases but for the > (e.g.) 95% quantile. The PHY guys learned to live with such an approach. > The MAC folks are getting there and we should take our chance now. 95% > means clearly to concentrate on the core issues, of which loop > detection/avoidance, p2p and security are somehow still open. > > When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as P2P routing). But, the implication of giving it the WG status seems to be that RPL would be the _framework_ on which all future ROLL work would be based. I am not in support of the use of RPL as a framework unless it eliminates its current tight coupling with DAGs (a, rather heavy duty, loop prevention mechanism). The goal of the WG from my understanding, is to produce *one* protocol in the current charter. RPL is definitely suitable as a starting point for that protocol (JP said foundation, not framework). I completely support this approach. From the industry point of view we need a single solution, which fulfills application requirements sufficiently and thus can be widely deployed commercially. Regarding loop prevention, so what if RPL does a better job than is necessary? Does it break some requirement doing that? If so, we should fix it. There are other reasons for using DAGs than just loop prevention. Zach -- http://www.sensinode.com 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 From prvs=45531a805=mukul@uwm.edu Thu Jul 30 08:04:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798B83A71AB; Thu, 30 Jul 2009 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 di1skfLmFRhD; Thu, 30 Jul 2009 08:04:44 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 7AA5D3A713E; Thu, 30 Jul 2009 08:04:44 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 30 Jul 2009 10:04:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1AAABC085A3; Thu, 30 Jul 2009 10:04:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVwx2GXpiSWG; Thu, 30 Jul 2009 10:04:45 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E8DD6C085A1; Thu, 30 Jul 2009 10:04:45 -0500 (CDT) Date: Thu, 30 Jul 2009 10:04:45 -0500 (CDT) From: Mukul Goyal To: Jerald P Martocci Message-ID: <636492027.6455131248966285866.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1329367113.6453271248966037856.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] An alternative to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:04:45 -0000 Hi Jerry, >>>Also there seems to be cases (see p7) where you temporally eliminate rou= te discovery requests. =C2=A0Not sure why this is needed. =C2=A0=20 >>Not sure what you mean. There seems to be some misunderstanding. The rout= e discovery requests are never eliminated.=20 >I'm probably misreading the text. =C2=A0Here's the paragraph...=20 >=C2=A0 =C2=A0o =C2=A0An existing route discovery table entry is refreshed,= i.e. allowed=20 =C2=A0 =C2=A0 =C2=A0 to exist for a certain additional time duration, if it= was created=20 =C2=A0 =C2=A0 =C2=A0 in response to an RA from this router and the current = RA includes=20 =C2=A0 =C2=A0 =C2=A0 in its route discovery list the destination correspond= ing to this=20 =C2=A0 =C2=A0 =C2=A0 entry.=20 =C2=A0=20 >The phrase "allowed to exist for a certain additional time duration" impli= es to me that route discovery entries are temporal. =C2=A0I would think tha= t as long as the route is valid, it would be kept.=20 The route discovery table entries are meant to exist only while route disco= very is going on. Once the routes have been discovered, the routers on the = routes, and the routers in their "vicinity", maintain state about the desti= nation in their "Route Maintenance" tables. Hope this clarifies your doubt. Thanks Mukul From prvs=45531a805=mukul@uwm.edu Thu Jul 30 08:29:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327793A68EF for ; Thu, 30 Jul 2009 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 Djt90ta7wY2q for ; Thu, 30 Jul 2009 08:29:22 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 1F4273A6C30 for ; Thu, 30 Jul 2009 08:29:01 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 30 Jul 2009 10:29:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8E76AC085AD; Thu, 30 Jul 2009 10:29:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2cR+r0FfrSy; Thu, 30 Jul 2009 10:29:03 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 42C55C085A7; Thu, 30 Jul 2009 10:29:03 -0500 (CDT) Date: Thu, 30 Jul 2009 10:29:03 -0500 (CDT) From: Mukul Goyal To: Zach Shelby Message-ID: <678440223.6467601248967743123.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1301317185.6465211248967505752.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:29:23 -0000 Zach Nothing wrong in RPL doing the loop prevention the way it does it. But, sho= uld every LLN application be forced to deal with the loops this way only?? = The foundation, or the framework, needs to be broad enough to allow differe= nt ways of doing things (e.g. dealing with loops) or not doing some things = at all. One protocol should not mean only one way of doing non-essential things suc= h as dealing with loops.=20 RPL is heavily coupled with DAGs, which I think is basically a heavy duty l= oop prevention mechanism. Please explain the other essential tasks that DAG= s perform?? Thanks Mukul ----- Original Message ----- From: "Zach Shelby" To: "Mukul Goyal" Cc: "ROLL WG" Sent: Thursday, July 30, 2009 10:02:43 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Hi, Mukul Goyal wrote: > Mischa, >=20 >> We should use this early design stage to come up with one solution - one= =20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an approach.= =20 > The MAC folks are getting there and we should take our chance now. 95%=20 > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open. >=20 > When you say a solution, it seems that you want one particular protocol. = I am OK with RPL as a protocol even though it has deficiencies (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would=20 be based. I am not in support of the use of RPL as a framework unless it=20 eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism). The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach. From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially. Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop prevention. Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog =E2=80=9COn the Internet of Things=E2=80=9D Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND From Jerald.P.Martocci@jci.com Thu Jul 30 08:57:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2A328C248; Thu, 30 Jul 2009 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GrbzXdE8N2R; Thu, 30 Jul 2009 08:57:56 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by core3.amsl.com (Postfix) with ESMTP id A8FA83A6BE0; Thu, 30 Jul 2009 08:57:55 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKSnHDBb5WqwYs6kHxtVsih1Yg557gArw/@postini.com; Thu, 30 Jul 2009 08:57:58 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009073010580250-1012098 ; Thu, 30 Jul 2009 10:58:02 -0500 In-Reply-To: <4A70BC3A.7000704@cttc.es> MIME-Version: 1.0 To: Mischa Dohler X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 30 Jul 2009 10:57:48 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/30/2009 10:57:54 AM, Serialize complete at 07/30/2009 10:57:54 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 10:58:02 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 10:58:05 AM, Serialize complete at 07/30/2009 10:58:05 AM Content-Type: multipart/alternative; boundary="=_alternative 0057B06186257603_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:57:57 -0000 This is a multipart message in MIME format. --=_alternative 0057B06186257603_= Content-Type: text/plain; charset="US-ASCII" Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0057B06186257603_= Content-Type: text/html; charset="US-ASCII"

Hi Mischa,

Nearly all communication in a commercial building facility management system is point to point.  I'm surprised the other three requirements don't also have a strong p2p requirement.  Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer.  This centralized model was not scalable nor fault tolerant.  That is if the minicomputer 'blew a gasket', the entire building went out of control.

As soon as it was economically viable, we decentralized control by moving it down into the rooms.  Now each room was controlled independently with an array of room sensors and room controllers.  Now if a controller failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destined to other nodes on the LLN.  They all require application ACKs.  About 20% of the packets are destined to the LBR and onwards.  These are event packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.


Jerry




Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

To
JP Vasseur <jvasseur@cisco.com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protocol work





JP, all,

We should use this early design stage to come up with one solution - one
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach.
The MAC folks are getting there and we should take our chance now. 95%
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were
worried about too much. Unless somebody provides me with a convincing
study, I propose to merely adopt some simple and possibly sub-optimum
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about?
Any node truly to any node? Are we back to pure ad hoc then? I guess if
IETF couldn't provide us with a magic ultra low power solution for ad
hoc networks in past years, then chances are slim that this will work
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency
of the 95% quantile applications, I propose to adopt some simple and
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an
 M2M event in Paris a few months ago organized by Orange where we met
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would
never let IP run over their ROLL-type networks. The sheer majority did
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have devoted
> during the past few weeks on the protocol work. There was excellent
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several open
> issues for which we WILL need help from many WG contributors, including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0057B06186257603_=-- From d.sturek@att.net Thu Jul 30 09:02:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00DD3A6C30 for ; Thu, 30 Jul 2009 09:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+QVRArMi01i for ; Thu, 30 Jul 2009 09:02:12 -0700 (PDT) Received: from smtp122.sbc.mail.re3.yahoo.com (smtp122.sbc.mail.re3.yahoo.com [66.196.96.95]) by core3.amsl.com (Postfix) with SMTP id 4812F3A6BA7 for ; Thu, 30 Jul 2009 09:02:12 -0700 (PDT) Received: (qmail 33332 invoked from network); 30 Jul 2009 16:02:11 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp122.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 16:02:10 -0000 X-YMail-OSG: xs7DgTAVM1mLn_VGvkGFGKAwhxN0ZKHkphxQ_Aq7mgyLmpL9znYRtTfbgKH6_5_lzLSGmVF8XDVDicVdAltuGAWKDr3u.yd1E9uPF9KnDsvIV7O1lb8v_8JZ5vEraTsIuE6iablEiKZ4E8KEOmFQbf_KyRHs0sQ0ciyGUUIwB0YgrntCBTnwecbYEGd4wIxAfuClhYbdH4AYWtV3dG0SiOBnAKszKZMZV7jHYCvM4bVfDzpIIH.KxHC5lY8xrLXOuAA8lCmDPBpu_Uy4U7nvCQ6Y2sCUZDVpKIdyGWUzi2I- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" , "'JP Vasseur'" References: <918287861.6388211248952986220.JavaMail.root@mail02.pantherlink.uwm.edu> <1344414827.6388331248953140552.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1344414827.6388331248953140552.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 30 Jul 2009 09:02:02 -0700 Message-ID: <010001ca112f$158ba990$40a2fcb0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRCM7GQm5JVERIQ7atDzXC4Su+sQAGPzIw Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:02:13 -0000 Hi Mukul, I think RPL is a good candidate for the types of applications we see for Smart Metering (which admittedly don't require optimized P2P). The options I have seen for distance vector routing with optimized P2P support either require flooding (like AODV for example) or maintenance of large state information within routing devices. I read the various notes on concerns on loop prevention in RPL. I don't really see those mechanisms as being that heavy (I think you are referring to the issuance of RAs and the text around frozen DAGs). Could you elaborate a bit more on why you see the loop avoidance mechanism in RPL as being heavy and what the tradeoffs are in the alternative proposal, not around loop avoidance, but the added maintenance and state information required to rely on optimized P2P as the basis for ROLL. Also, it seems to me that an optimized P2P solution could be built with the DAG. Assuming some changes were also made to loop avoidance wouldn't this make more sense that trying to use an optimized P2P solution (which has historically never scaled for all application spaces, hence the plethora of MANET protocols). Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Thursday, July 30, 2009 4:26 AM To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work Hi JP As a _protocol_, RPL is not yet complete. It needs addition of a good P2P solution at the least. I imagine it is possible to incorporate in RPL the route discovery and maintenance mechanisms discussed in draft-goyal-roll-dv-01 to achieve better P2P routing (basically building a DAG rooted at the destination during route discovery; pruning it afterwards and using this pruned DAG, limited to the the neighborhood of discovered routes, for route maintenance). I guess other mechanisms may also be possible. As a _framework_ for all future ROLL work, RPL has a serious deficiency. RPL is too tightly interweaved with one particular loop prevention mechanism - the one based on DAGs. At present, it does not seem possible to use RPL with a different loop prevention/avoidance/detection+correction mechanism. Hence, RPL is not ready to serve as a general framework for future ROLL work. I think that RPL needs to be modified so that the use of DAGs becomes optional. Then, it will be possible to use RPL as a framework. Right now, it is not a framework. Thus, it seems that more work is required before RPL is ready for WG status either as a protocol or as a framework. I am not sure glossing over known deficiencies and rushing with WG status for RPL would serve any useful purpose. Rather than granting it a WG status now and trying to solve the problems later on, I would suggest the reverse route. Regards Mukul To: "Mukul Goyal" Cc: "Mischa Dohler" , "ROLL WG" Sent: Tuesday, July 28, 2009 10:25:04 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Hi Mukul, I would really like to get your answer on whether you support the adoption of RPL as good foundation to move forward, adopting it as a WG ID. Your comments are extremely valid, see in line: On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote: > Mischa, > > I am not speaking for Jerry but P2P flows are important in LLN > applications I am familiar with (which happen to be in commercial > building domain). I will have to go back to all the requirements > drafts but I would be surprised if other domains will not benefit > from an efficient P2P solution. > > The main question is why are we insisting on "one solution fits all" > approach??? Why can't we recognize that different applications have > different requirements and offer multiple solutions (including RPL). > > Let RPL be used by applications that find it useful but we should > not force RPL as the only solution available. > > In my view, RPL has the following three shortcomings: > > 1) Does not offer optimal/good P2P routing > 2) Does not allow destinations other than LBRs to be advertised. > Note that this point and the previous one are independent. > 3) Insistence on using DAG as the loop prevention mechanism. > > RPL is a good MP2P solution but we should not force it down the > throats of people who want good P2P routing as well. > > IETF has a long history of offering multiple solutions for a given > routing problem. We has multiple interior gateway protocols, > multiple MANET solutions, multiple OSPF-MANET solutions. Why can't, > and why should not, we have multiple ROLL solutions?? > > I asked this question to JP right at the time the ROLL WG got a new > charter. The answer I got was - we will work on one solution for now > but we do not exclude other solutions. > > I think ROLL should offer multiple solutions and let an application > choose what fits it best. > Few things: 1) The ROLL routing protocol will have to support a good solution for P2P, this is a MUST requirement. For the time being a solution such as RPL is optimized for P2MP and P2MP and does support P2P but that MUST be improved. This was discussed and agreed yesterday during the WG meeting and on the mailing list. Next step is to work on this and your help will be greatly appreciated. 2) The DT will reply but RPL support the advertisements of destination other than LBRs 3) Loop detection: fully agree, I had proposed myself a solution but others may have other ideas. I personally think that this is one of the areas where we can borrow some ideas also from the DADR proposal. Again to be discussed on the list. 4) With regards to having more protocols, we are chartered to design one protocol for the time being. There is still lot of work to do, and the solution will continue to evolve. It is thus premature to think more than one protocol at this stage. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Mischa Dohler" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > Jerry, I am not sure this was already discussed at the meeting in > person > but I think we are a little in a catch22 situation here since - as far > as I remember - none of the requirement docs explicitly required > (MUST) > p2p situations. I gather that the design team did take these documents > as their working basis which is why p2p is not efficiently > supported. In > our urban requirements draft, we actually did go as far as saying that > p2p should not be the main design thrust but rather the highly > directional data flows towards a few sinks. Mischa. > > > Jerald.P.Martocci@jci.com wrote: >> >> I cannot yet affirm RPL as a working group draft since it hasn't yet >> stated how P2P communication will operate within the DAG. >> >> As I have noted in my review comments, connectivity to every node >> within >> the DAG is not assured. The traffic patterns within the LLN are also >> suspect since most packets must travel upward toward the LBR before >> finding their intended destination lower in the DAG. This imbalance >> will create network traffic congestion in the higher layers of the >> DAG. >> Hopping many hops up the DAG and back down the DAG to talk to a node >> that is in direct radio range seems totally inefficient. >> >> Latency and convergence time are also a concern. However, I can wait >> for simulation or implementations to ferret out these issues. >> >> Regards, >> >> Jerry Martocci >> >> >> >> >> >> *JP Vasseur * >> Sent by: roll-bounces@ietf.org >> >> 07/28/2009 11:36 AM >> >> >> To >> ROLL WG >> cc >> >> Subject >> [Roll] Moving forward with the protocol work >> >> >> >> >> >> >> >> >> Dear WG, >> >> First of all, thanks for all the time and energy you all have devoted >> during the past few weeks on the protocol work. There was excellent >> followup discussion at the physical WG meeting. >> >> To the question "Do you think that RPL provides an adequate >> foundation >> for the ROLL routing protocol work", there was clearly a good >> consensus in the WG meeting. It was also recognized there are still >> several open issues for which we WILL need help from many WG >> contributors, including the authors of other documents. >> >> Could you please confirm (or not) the adoption of draft-dt-roll- >> rpl-01 >> as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Jul 30 09:03:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860133A6C30; Thu, 30 Jul 2009 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.601 X-Spam-Level: X-Spam-Status: No, score=-7.601 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGHNkbTw3aNa; Thu, 30 Jul 2009 09:03:15 -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 C2BB93A6C1E; Thu, 30 Jul 2009 09:03:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE9hcUqrR7O6/2dsb2JhbACCJTAhuEmIJ5AtBYQR X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="221389895" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 30 Jul 2009 16:03:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6UG3HiJ000425; Thu, 30 Jul 2009 09:03:17 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6UG2mxY019366; Thu, 30 Jul 2009 16:03:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 18:03:01 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 18:02:59 +0200 Message-Id: <638157F6-2E86-407E-9E7F-1034E85E9D8F@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-18-79639230 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 18:02:58 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jul 2009 16:02:59.0808 (UTC) FILETIME=[35D9C600:01CA112F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14328; t=1248969797; x=1249833797; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=vsjWyW+kSHZjG9R79NV5ZkUNn+sXrcOBO2EIugyF7pk=; b=CLZC4f5OZgPjFwCxhfyFjqGvng80Jj5XBks/4EbcyC/at5mFtdApjkXUgO ffzvj2u0+QaeXcIcybCZerX+xcX6DX7kb8ThfGfx0l+s1nVJNy/gx/8eIO5f m+NJ4VJMgF; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:03:17 -0000 --Apple-Mail-18-79639230 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, Just jumping to the point. On Jul 30, 2009, at 5:57 PM, Jerald.P.Martocci@jci.com wrote: > > > Hi Mischa, > > Nearly all communication in a commercial building facility > management system is point to point. I'm surprised the other three > requirements don't also have a strong p2p requirement. Back in the > early 80's prior to processor based sensors, we deployed 'dumb > sensors' that would simply upload their current environmental > information to a centralized minicomputer. This centralized model > was not scalable nor fault tolerant. That is if the minicomputer > 'blew a gasket', the entire building went out of control. > > As soon as it was economically viable, we decentralized control by > moving it down into the rooms. Now each room was controlled > independently with an array of room sensors and room controllers. > Now if a controller failed, only the room might lose control, not > the entire complex. The room controllers were then further > controlled by higher level controllers. This distributed > architecture has been in place for 25 years and is the mainstay of > building control. > > My point is that is the Commercial Market the LLN is not just a path > for moving data nortbound. Most of the packets sent on the LLN are > destined to other nodes on the LLN. They all require application > ACKs. About 20% of the packets are destined to the LBR and > onwards. These are event packets being sent to the higher layers > for further analysis. > > If we don't support a robust p2p protocol option in ROLL, we will > knock out the Building Market in its entirety which means at best > you will only solve 75% of the need. > There NO question about this. P2P is a MUST and our solution will have to support it in an efficient way. Cheers. JP. > > Jerry > > > > > Mischa Dohler > Sent by: roll-bounces@ietf.org > 07/29/2009 04:18 PM > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] Moving forward with the protocol work > > > > > > JP, all, > > We should use this early design stage to come up with one solution - > one > solution which is not necessarily optimum for all cases but for the > (e.g.) 95% quantile. The PHY guys learned to live with such an > approach. > The MAC folks are getting there and we should take our chance now. 95% > means clearly to concentrate on the core issues, of which loop > detection/avoidance, p2p and security are somehow still open. > > I do understand the concept of loops arising. I have doubts that with > the dynamics of typical ROLL networks, these will give us headaches > within this 95% application quantile. I have read tons of papers > produced in the last decade on routing in ROLL-type networks. Loop > detection and avoidance was clearly not something people (including > those doing practical rollouts and running their companies today) were > worried about too much. Unless somebody provides me with a convincing > study, I propose to merely adopt some simple and possibly sub-optimum > heuristics and then forget about it. > > P2P seems to worry some of us (sorry, Jerry, for having forgotten > about > the p2p paragraph). However, again, are we talking about the 95% > quantile here? Furthermore, how much p2p exactly are you talking > about? > Any node truly to any node? Are we back to pure ad hoc then? I guess > if > IETF couldn't provide us with a magic ultra low power solution for ad > hoc networks in past years, then chances are slim that this will work > out now. Unless somebody provides me with a convincing study that > adopting a general p2p ROLL protocol will not jeopardize the > efficiency > of the 95% quantile applications, I propose to adopt some simple and > possibly sub-optimum heuristics and then forget about it. > > Security is an important issue. > > Now that we are at it, I sampled quite a large number of companies > at an > M2M event in Paris a few months ago organized by Orange where we met > with JP and others. The large majority of companies present there > explicitly told me that - for a very varying set of reasons - they > would > never let IP run over their ROLL-type networks. The sheer majority did > suprise me. We still have a lot of work ahead. > > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. > > Mischa. > > > > > > > JP Vasseur wrote: > > Dear WG, > > > > First of all, thanks for all the time and energy you all have > devoted > > during the past few weeks on the protocol work. There was excellent > > followup discussion at the physical WG meeting. > > > > To the question "Do you think that RPL provides an adequate > foundation > > for the ROLL routing protocol work", there was clearly a good > consensus > > in the WG meeting. It was also recognized there are still several > open > > issues for which we WILL need help from many WG contributors, > including > > the authors of other documents. > > > > Could you please confirm (or not) the adoption of draft-dt-roll- > rpl-01 > > as a WG document ? > > > > Then we will of course move to the next step. > > > > Thanks, > > > > JP and David > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-18-79639230 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Jerry,

Just jumping to the = point.

On Jul 30, 2009, at 5:57 PM, Jerald.P.Martocci@jci.com = wrote:



Hi = Mischa,

Nearly all = communication in a commercial building facility management system is = point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior = to processor based sensors, we deployed 'dumb sensors' that would simply = upload their current environmental information to a centralized = minicomputer.  This centralized model was not scalable nor fault = tolerant.  That is if the minicomputer 'blew a gasket', the entire = building went out of control.

As soon as it was economically viable, we = decentralized control by moving it down into the rooms.  Now each = room was controlled independently with an array of room sensors and room = controllers.  Now if a controller failed, only the room might lose = control, not the entire complex.  The room controllers were then = further controlled by higher level controllers.  This distributed = architecture has been in place for 25 years and is the mainstay of = building control.  

My point is that is the Commercial Market the LLN is = not just a path for moving data nortbound.  Most of the packets = sent on the LLN are destined to other nodes on the LLN.  They all = require application ACKs.  About 20% of the packets are destined to = the LBR and onwards.  These are event packets being sent to the = higher layers for further analysis.

If we don't support a robust p2p protocol option in = ROLL, we will knock out the Building Market in its entirety which means = at best you will only solve 75% of the need.
=

There NO question about this. P2P = is a MUST and our solution will have to support it in an efficient = way.

Cheers.

JP.

Jerry




Mischa Dohler <mischa.dohler@cttc.es> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">07/29/2009 04:18 PM =

To
JP Vasseur <jvasseur@cisco.com> =
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protocol = work

=



JP, = all,

We should use this early design stage to come up with one = solution - one
solution which is not necessarily optimum for all = cases but for the
(e.g.) 95% quantile. The PHY guys learned to live = with such an approach.
The MAC folks are getting there and we = should take our chance now. 95%
means clearly to concentrate on the = core issues, of which loop
detection/avoidance, p2p and security = are somehow still open.

I do understand the concept of loops = arising. I have doubts that with
the dynamics of typical ROLL = networks, these will give us headaches
within this 95% application = quantile. I have read tons of papers
produced in the last decade on = routing in ROLL-type networks. Loop
detection and avoidance was = clearly not something people (including
those doing practical = rollouts and running their companies today) were
worried about too = much. Unless somebody provides me with a convincing
study, I = propose to merely adopt some simple and possibly sub-optimum
= heuristics and then forget about it.

P2P seems to worry some of = us (sorry, Jerry, for having forgotten about
the p2p paragraph). = However, again, are we talking about the 95%
quantile here? = Furthermore, how much p2p exactly are you talking about?
Any node = truly to any node? Are we back to pure ad hoc then? I guess if
IETF = couldn't provide us with a magic ultra low power solution for ad
= hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that =
adopting a general p2p ROLL protocol will not jeopardize the = efficiency
of the 95% quantile applications, I propose to adopt = some simple and
possibly sub-optimum heuristics and then forget = about it.

Security is an important issue.

Now that we = are at it, I sampled quite a large number of companies at an
=  M2M event in Paris a few months ago organized by Orange where we = met
with JP and others. The large majority of companies present = there
explicitly told me that - for a very varying set of reasons - = they would
never let IP run over their ROLL-type networks. The = sheer majority did
suprise me. We still have a lot of work = ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG = document.

Mischa.






JP Vasseur = wrote:
> Dear WG,
>
> First of all, thanks for all = the time and energy you all have devoted
> during the past few = weeks on the protocol work. There was excellent
> followup = discussion at the physical WG meeting.
>
> To the = question "Do you think that RPL provides an adequate foundation
= > for the ROLL routing protocol work", there was clearly a good = consensus
> in the WG meeting. It was also recognized there are = still several open
> issues for which we WILL need help from = many WG contributors, including
> the authors of other = documents.
>
> Could you please confirm (or not) the = adoption of draft-dt-roll-rpl-01
> as a WG document ?
> =
> Then we will of course move to the next step.
>
= > Thanks,
>
> JP and David
>
>
= > _______________________________________________
> Roll = mailing list
> Roll@ietf.org
> https://www.ietf.org/m= ailman/listinfo/roll
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-18-79639230-- From jabeille@cisco.com Thu Jul 30 09:07:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C3D3A688B; Thu, 30 Jul 2009 09:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.686 X-Spam-Level: X-Spam-Status: No, score=-9.686 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Pwdb0F2AWNc5; Thu, 30 Jul 2009 09:07:49 -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 4B55B3A6823; Thu, 30 Jul 2009 09:07:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUAAMdhcUqQ/uCKe2dsb2JhbACCJTAhlxYWJAagY4gnkC4FhBE X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="46156236" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 16:07:48 +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 n6UG7m1H020818; Thu, 30 Jul 2009 18:07:48 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UG7m3g013205; Thu, 30 Jul 2009 16:07:48 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 18:07:49 +0200 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_01CA112F.E1DB07E7" Date: Thu, 30 Jul 2009 18:07:46 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86036E750B@xmb-ams-33d.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoRLoXzgLhRH4dmQRCNwgmVxGO1jAAAPb1A References: <4A70BC3A.7000704@cttc.es> From: "Julien Abeille (jabeille)" To: , "Mischa Dohler" X-OriginalArrivalTime: 30 Jul 2009 16:07:49.0078 (UTC) FILETIME=[E244DF60:01CA112F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15708; t=1248970068; x=1249834068; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=9fkdTv89KK7ahRFnvznoCp1kLVXajDWIJR2ev0IvtkA=; b=U7FwEpzzv0jL63GDrNVdSj4Q4e6beTrg+P3wVnf5imGL/eri09CrryU/OT RQKbAbvbmW/popeL/tHPjpnEOngaFIxCnZitxceGyvtaB6AepSf6udDdIw5u r7hRxHlNQq; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:07:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA112F.E1DB07E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerald, =20 just to understand better the setup in commercial buildings: in a typical scenario, which devices / how many are present in a room, what is the layer 2 topology and the p2p application flows? =20 Thank you, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: jeudi 30 juillet 2009 17:58 To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work =09 =09 =09 Hi Mischa,=20 =09 Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control.=20 =09 As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. =20 =09 My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis.=20 =09 If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.=20 =09 =09 Jerry=20 =09 =09 =09 =09 =09 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =09 JP, all, =09 We should use this early design stage to come up with one solution - one=20 solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach.=20 The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. =09 I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. =09 P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. =09 Security is an important issue. =09 Now that we are at it, I sampled quite a large number of companies at an=20 M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would=20 never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. =09 I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. =09 Mischa. =09 =09 =09 =09 =09 =09 JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation=20 > for the ROLL routing protocol work", there was clearly a good consensus=20 > in the WG meeting. It was also recognized there are still several open=20 > issues for which we WILL need help from many WG contributors, including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01=20 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 =09 ------_=_NextPart_001_01CA112F.E1DB07E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jerald,
 
just to understand better the setup in = commercial=20 buildings: in a typical scenario,  which devices / how many = are=20 present in a room, what is the layer 2 topology and the p2p = application=20 flows?
 
Thank you,
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com
Sent: jeudi 30 juillet 2009=20 17:58
To: Mischa Dohler
Cc: ROLL WG;=20 roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward = with the=20 protocol work



Hi Mischa,=20

Nearly all communication in a = commercial=20 building facility management system is point to point.  I'm = surprised the=20 other three requirements don't also have a strong p2p requirement. =  Back=20 in the early 80's prior to processor based sensors, we deployed 'dumb = sensors'=20 that would simply upload their current environmental information to a=20 centralized minicomputer.  This centralized model was not = scalable nor=20 fault tolerant.  That is if the minicomputer 'blew a gasket', the = entire=20 building went out of control.

As=20 soon as it was economically viable, we decentralized control by moving = it down=20 into the rooms.  Now each room was controlled independently with = an array=20 of room sensors and room controllers.  Now if a controller = failed, only=20 the room might lose control, not the entire complex.  The room=20 controllers were then further controlled by higher level controllers.=20  This distributed architecture has been in place for 25 years and = is the=20 mainstay of building control.  

My point is that is the Commercial Market the LLN is not just = a path=20 for moving data nortbound.  Most of the packets sent on the LLN = are=20 destined to other nodes on the LLN.  They all require application = ACKs.=20  About 20% of the packets are destined to the LBR and onwards.=20  These are event packets being sent to the higher layers for = further=20 analysis.

If we don't = support a=20 robust p2p protocol option in ROLL, we will knock out the Building = Market in=20 its entirety which means at best you will only solve 75% of the = need.=20


Jerry =




Mischa = Dohler=20 <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org=20

07/29/2009 04:18 PM =

To
JP Vasseur=20 <jvasseur@cisco.com>=20
cc
ROLL WG=20 <roll@ietf.org>=20
Subject
Re: [Roll] Moving = forward with=20 the protocol work

=




JP, all,

We should use this early design stage to = come up=20 with one solution - one
solution which is not necessarily optimum = for all=20 cases but for the
(e.g.) 95% quantile. The PHY guys learned to = live with=20 such an approach.
The MAC folks are getting there and we should = take our=20 chance now. 95%
means clearly to concentrate on the core issues, = of which=20 loop
detection/avoidance, p2p and security are somehow still=20 open.

I do understand the concept of loops arising. I have = doubts that=20 with
the dynamics of typical ROLL networks, these will give us = headaches=20
within this 95% application quantile. I have read tons of papers=20
produced in the last decade on routing in ROLL-type networks. Loop =
detection and avoidance was clearly not something people = (including=20
those doing practical rollouts and running their companies today) = were=20
worried about too much. Unless somebody provides me with a = convincing=20
study, I propose to merely adopt some simple and possibly = sub-optimum=20
heuristics and then forget about it.

P2P seems to worry = some of us=20 (sorry, Jerry, for having forgotten about
the p2p paragraph). = However,=20 again, are we talking about the 95%
quantile here? Furthermore, = how much=20 p2p exactly are you talking about?
Any node truly to any node? Are = we back=20 to pure ad hoc then? I guess if
IETF couldn't provide us with a = magic=20 ultra low power solution for ad
hoc networks in past years, then = chances=20 are slim that this will work
out now. Unless somebody provides me = with a=20 convincing study that
adopting a general p2p ROLL protocol will = not=20 jeopardize the efficiency
of the 95% quantile applications, I = propose to=20 adopt some simple and
possibly sub-optimum heuristics and then = forget=20 about it.

Security is an important issue.

Now that we = are at it,=20 I sampled quite a large number of companies at an
 M2M event = in Paris=20 a few months ago organized by Orange where we met
with JP and = others. The=20 large majority of companies present there
explicitly told me that = - for a=20 very varying set of reasons - they would
never let IP run over = their=20 ROLL-type networks. The sheer majority did
suprise me. We still = have a lot=20 of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 = as a WG=20 document.

Mischa.






JP Vasseur = wrote:
>=20 Dear WG,
>
> First of all, thanks for all the time and = energy you=20 all have devoted
> during the past few weeks on the protocol = work.=20 There was excellent
> followup discussion at the physical WG=20 meeting.
>
> To the question "Do you think that RPL = provides an=20 adequate foundation
> for the ROLL routing protocol work", = there was=20 clearly a good consensus
> in the WG meeting. It was also = recognized=20 there are still several open
> issues for which we WILL need = help from=20 many WG contributors, including
> the authors of other=20 documents.
>
> Could you please confirm (or not) the = adoption of=20 draft-dt-roll-rpl-01
> as a WG document ?
>
> Then = we will=20 of course move to the next step.
>
> Thanks,
> =
> JP=20 and David
>
>
>=20 _______________________________________________
> Roll mailing=20 list
> Roll@ietf.org
>=20 = https://www.ietf.org/mailman/listinfo/roll
___________________________= ____________________
Roll=20 mailing=20 = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CA112F.E1DB07E7-- From d.sturek@att.net Thu Jul 30 09:12:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8E228C2E2 for ; Thu, 30 Jul 2009 09:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn34mW2mYxWj for ; Thu, 30 Jul 2009 09:12:44 -0700 (PDT) Received: from smtp117.sbc.mail.re3.yahoo.com (smtp117.sbc.mail.re3.yahoo.com [66.196.96.90]) by core3.amsl.com (Postfix) with SMTP id 65C6228C2F4 for ; Thu, 30 Jul 2009 09:12:40 -0700 (PDT) Received: (qmail 20983 invoked from network); 30 Jul 2009 16:12:40 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp117.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 16:12:40 -0000 X-YMail-OSG: 5sLGgtUVM1mx59iAqTrfyxRwX0wqflugZzS.XBZCKcBzA.l8m84tQc_evRBz9ESnCJWVX4Fs9On5nJEtjnxh3YSWyMS1Ttm5KnAW8cWG1HqZXSyYh9Fl5acQaZ8B5758xz0UTnclBXbej7jqlLhcYmLjonD_FRBSrZ4ZMs1aKdhQY_V9Ubjhcb38H3Y7cxpQMhGD2C7ChDfPFLdW5n7DY.e.CV6.XO5VsowHlCF9J3xsmwC3i3WAKLcoiiTj.vXd9aatcomSMTVFfjOsnqiLSra34tBoa.NiSxCkOhmc4.A- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: , "'Mischa Dohler'" References: <4A70BC3A.7000704@cttc.es> In-Reply-To: Date: Thu, 30 Jul 2009 09:12:31 -0700 Message-ID: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0145_01CA10F5.E01DC600" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRLpbSfRz7w2JpQDO+Mev0wUAMFwAAMWKQ Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:12:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0145_01CA10F5.E01DC600 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Jerry, I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0145_01CA10F5.E01DC600 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Jerry,

 

I think RPL does support P2P but does not optimize the = number of hops. I think that is the central issue you and Mukul are bringing = up.

 

I do question whether optimizing hops is really = necessary.  I think most applications (including building controls) can take = advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also = without nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose). 

 

I really don’t see that trying (once again as they = have in MANET for some time) to find a single protocol that efficiently = implements P2P and scales while addressing the various data transmission patterns will = result in anything other than the same set of solutions we have today (distance = vector with flooding, link state routing and its derivatives, source routing = and its derivatives). 

 

Don

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol = work

 



Hi Mischa,

Nearly = all communication in a commercial building facility management system is = point to point.  I'm surprised the other three requirements don't also have = a strong p2p requirement.  Back in the early 80's prior to processor = based sensors, we deployed 'dumb sensors' that would simply upload their = current environmental information to a centralized minicomputer.  This = centralized model was not scalable nor fault tolerant.  That is if the = minicomputer 'blew a gasket', the entire building went out of control.

As = soon as it was economically viable, we decentralized control by moving it down into = the rooms.  Now each room was controlled independently with an array of = room sensors and room controllers.  Now if a controller failed, only the = room might lose control, not the entire complex.  The room controllers = were then further controlled by higher level controllers.  This = distributed architecture has been in place for 25 years and is the mainstay of = building control.  

My = point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destined to = other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we = don't support a robust p2p protocol option in ROLL, we will knock out the = Building Market in its entirety which means at best you will only solve 75% of = the need.


Jerry =



Mischa Dohler <mischa.dohler@cttc.es>
Sent = by: roll-bounces@ietf.org

07/29/2009 04:18 PM

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work

 




JP, all,

We should use this early design stage to come up with one solution - = one
solution which is not necessarily optimum for all cases but for the =
(e.g.) 95% quantile. The PHY guys learned to live with such an = approach.
The MAC folks are getting there and we should take our chance now. = 95%
means clearly to concentrate on the core issues, of which loop =
detection/avoidance, p2p and security are somehow still = open.

I do understand the concept of loops arising. I have doubts that = with
the dynamics of typical ROLL networks, these will give us headaches =
within this 95% application quantile. I have read tons of papers =
produced in the last decade on routing in ROLL-type networks. Loop =
detection and avoidance was clearly not something people (including =
those doing practical rollouts and running their companies today) = were
worried about too much. Unless somebody provides me with a = convincing
study, I propose to merely adopt some simple and possibly = sub-optimum
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten = about
the p2p paragraph). However, again, are we talking about the 95% =
quantile here? Furthermore, how much p2p exactly are you talking = about?
Any node truly to any node? Are we back to pure ad hoc then? I guess = if
IETF couldn't provide us with a magic ultra low power solution for = ad
hoc networks in past years, then chances are slim that this will = work
out now. Unless somebody provides me with a convincing study that =
adopting a general p2p ROLL protocol will not jeopardize the = efficiency
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies = at an
 M2M event in Paris a few months ago organized by Orange where = we met
with JP and others. The large majority of companies present there =
explicitly told me that - for a very varying set of reasons - they = would
never let IP run over their ROLL-type networks. The sheer majority = did
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG = document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was = excellent
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an = adequate foundation
> for the ROLL routing protocol work", there was clearly a = good consensus
> in the WG meeting. It was also recognized there are still = several open
> issues for which we WILL need help from many WG contributors, including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=
------=_NextPart_000_0145_01CA10F5.E01DC600-- From d.sturek@att.net Thu Jul 30 09:44:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C536F3A68EF for ; Thu, 30 Jul 2009 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdLdM63iYti7 for ; Thu, 30 Jul 2009 09:44:23 -0700 (PDT) Received: from smtp122.sbc.mail.re3.yahoo.com (smtp122.sbc.mail.re3.yahoo.com [66.196.96.95]) by core3.amsl.com (Postfix) with SMTP id 126EA3A6FC7 for ; Thu, 30 Jul 2009 09:44:02 -0700 (PDT) Received: (qmail 89233 invoked from network); 30 Jul 2009 16:44:04 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp122.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 16:44:04 -0000 X-YMail-OSG: e.G6gccVM1kh0AmoxoJ7OcU.nzZ7wlzYd2zLsKQl1COXEdlGw41DSMlSJatOJSO6.Fv__n6wduXhv9NNqLOSYVsShrTi7S.hLJHPGjBsuYkpZGfmT1kcehIGklUp3PUuxS3WCK1kVFn37vrHTPx2ImtTmzz5IGP1HqN8s.9xdQe8BFMI6h9lgOcbxP7VpA7HSB7zIbwM.wudCYD9ZyfnZ.Ab1VD0Tnzx85o3bXwx_r1qrI15tbCAAktOYq8YeG4B38Szrk9vZPddryPevYrNzr9nmvdJQ0dNquz2KrMcJ3Lo X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" , "'Mischa Dohler'" References: <739450438.6404891248959338493.JavaMail.root@mail02.pantherlink.uwm.edu> <1435187642.6407451248959865082.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1435187642.6407451248959865082.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 30 Jul 2009 09:43:57 -0700 Message-ID: <019501ca1134$ef919eb0$ceb4dc10$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRGCMlbLaOJsdlSkqntkmbvLQ37AAG7RkA Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:44:24 -0000 Hi Mischa and Mukul, One thing I would like to add are the following 95% quantile issues: 1) No flooding to establish routes (since we all know this does not scale very well) 2) No "order (n)" increase of storage to support routing (where "order(n)" means we don't have a requirement to maintain route state information that scales with the number of routing paths a given device supports). What I would like to see is the following: 1) Limit/avoid flooding and maintenance of route state information along the routing path. 2) Optimize P2P (I think it would be worthwhile to have a separate thread that just discusses this topic and defines it with respect to the ROLL effort). For example, it would be nice to define exactly what we mean by optimized P2P: low overhead in the network to set up (no flooding), no route state storage requirements along the route, minimize route cost/hop/etc. and here it would be nice to understand our definition. 3) Scales and meets various data transmission patterns (MP2P, MP2P with return acknowledgement, P2P) It would be nice to discuss these design goals with respect to the requirements we have in place and then evaluate the proposals on the table in this light. Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Thursday, July 30, 2009 6:18 AM To: Mischa Dohler Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work Mischa, >We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as P2P routing). But, the implication of giving it the WG status seems to be that RPL would be the _framework_ on which all future ROLL work would be based. I am not in support of the use of RPL as a framework unless it eliminates its current tight coupling with DAGs (a, rather heavy duty, loop prevention mechanism). >I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. I agree. I was surprised to see such heavy emphasis in RPL on loop prevention. It should be possible for an LLN application to use a simple mechanism to deal with loops or decide not to deal with loops at all. RPL does not allow that. With RPL, you have to use DAGs, which is a very restrictive and very heavy duty loop prevention mechanism. >P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Absolutely, P2P routing requirement is well within 95 percentile domain. I guess other folks will affirm this. Meeting this requirement is not as difficult as it may seem (even within RPL). >Security is an important issue. >Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I agree there is a concern if the overhead of running IP is worth the benefits. > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Unfortunately, I can not support such a move at present. Thanks Mukul JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Thu Jul 30 09:44:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE8F3A68EF; Thu, 30 Jul 2009 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fte1HfDxY4HQ; Thu, 30 Jul 2009 09:44:37 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id 0A8933A6BC1; Thu, 30 Jul 2009 09:44:33 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSnHN8xE/bewyJU4lVrKKWi1qiP6Y8+OF@postini.com; Thu, 30 Jul 2009 09:44:36 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009073011445901-1018233 ; Thu, 30 Jul 2009 11:44:59 -0500 In-Reply-To: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> MIME-Version: 1.0 To: X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 30 Jul 2009 11:44:24 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/30/2009 11:44:29 AM, Serialize complete at 07/30/2009 11:44:29 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 11:44:59 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 11:45:04 AM, Serialize complete at 07/30/2009 11:45:04 AM Content-Type: multipart/alternative; boundary="=_alternative 005BF45186257603_=" Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:44:48 -0000 This is a multipart message in MIME format. --=_alternative 005BF45186257603_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hi Don, As I read the draft, RPL doesn't currently guarantee p2p communication=20 regardless of hop count. Only if some node higher in the DAG elects to=20 provide a path back down the DAG to the destination then there is p2p=20 path. RPL doesn't mandate this even for the LBR. Hence a packet could=20 squirt all the way up to the LBR and still be dropped since the LBR itself = has no route defined to the destination. You need to keep in mind that=20 the LLN devices are primarily a building controllers that 'moonlight' as a = router; it's not a router that happens to also do building control. The=20 likelihood that a controller sitting higher in the DAG being altruist and=20 defining pathways to all possible sub-DAG devices is nil. As for hops, this is very important too. Not so much for latency. The=20 time constant for most building HVAC control loops is in minutes so=20 having a packet arrive at its destination a tad late is not too=20 concerning. (NOTE: Fire and lighting applications are much more time=20 critical). The problem is that the source device, typically a battery=20 powered sensor must stay awake and leave its receiver active until the=20 packet has migrated to its destination and the application ACK has been=20 received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes. Sure we could have=20 defined the PAN to be the entire complex and then require 10K nodes as do=20 the other requirement specs. Empirical testing however determined that=20 managing 250 nodes on a single wireless domain was difficult enough with=20 regard to channel management, interference and hop count. Limiting PAN=20 size to a floor seems to be the right balance point for complexity and=20 flexibility. Jerry "Don Sturek" =20 07/30/2009 11:12 AM Please respond to To , "'Mischa Dohler'" cc "'ROLL WG'" , Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, =20 I think RPL does support P2P but does not optimize the number of hops. I=20 think that is the central issue you and Mukul are bringing up. =20 I do question whether optimizing hops is really necessary. I think most=20 applications (including building controls) can take advantage of a=20 solution that well supports MP2P and P2MP with extensions to provide P2P=20 capability (admittedly not optimized for hop count/cost but then also=20 without nearly the overhead of packet flooding or storage of state=20 information that optimized P2P solutions impose).=20 =20 I really don?t see that trying (once again as they have in MANET for some=20 time) to find a single protocol that efficiently implements P2P and scales = while addressing the various data transmission patterns will result in=20 anything other than the same set of solutions we have today (distance=20 vector with flooding, link state routing and its derivatives, source=20 routing and its derivatives).=20 =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work =20 Hi Mischa,=20 Nearly all communication in a commercial building facility management=20 system is point to point. I'm surprised the other three requirements=20 don't also have a strong p2p requirement. Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply=20 upload their current environmental information to a centralized=20 minicomputer. This centralized model was not scalable nor fault tolerant. = That is if the minicomputer 'blew a gasket', the entire building went out = of control.=20 As soon as it was economically viable, we decentralized control by moving=20 it down into the rooms. Now each room was controlled independently with=20 an array of room sensors and room controllers. Now if a controller=20 failed, only the room might lose control, not the entire complex. The=20 room controllers were then further controlled by higher level controllers. = This distributed architecture has been in place for 25 years and is the=20 mainstay of building control. =20 My point is that is the Commercial Market the LLN is not just a path for=20 moving data nortbound. Most of the packets sent on the LLN are destined=20 to other nodes on the LLN. They all require application ACKs. About 20%=20 of the packets are destined to the LBR and onwards. These are event=20 packets being sent to the higher layers for further analysis.=20 If we don't support a robust p2p protocol option in ROLL, we will knock=20 out the Building Market in its entirety which means at best you will only=20 solve 75% of the need.=20 Jerry=20 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =20 JP, all, We should use this early design stage to come up with one solution - one=20 solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach.=20 The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers=20 produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95%=20 quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an=20 M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would=20 never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation=20 > for the ROLL routing protocol work", there was clearly a good consensus=20 > in the WG meeting. It was also recognized there are still several open=20 > issues for which we WILL need help from many WG contributors, including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01=20 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 005BF45186257603_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi Don,

As I read the draft, RPL doesn't cur= rently guarantee p2p communication regardless of hop count.  Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path.  RPL doesn't mandate this even for the LBR.  Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the desti= nation.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control.  The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil.

As for hops, this is very important too.  Not so much for latency.  The time constant for most buildi= ng HVAC  control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical).  The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received.  This will reduce battery life at least 10x.
As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes.  Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs.  = ;Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count.  Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility.

Jerry



"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM
Please respond to
<d.sturek@att.net>
To
<Jerald.P.Martocci@jci.com>, &= quot;'Mischa Dohler'" <mischa.dohler@cttc.es>
cc
"'ROLL WG'" <roll@ietf.= org>, <roll-bounces@ietf.org>
Subject
RE: [Roll] Moving forward with the p= rotocol work





Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up.
 
I do question whether o= ptimizing hops is really necessary.  I think most applications (including buildi= ng controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impos= e).  
 
I really don’t se= e that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From: roll-bounces@ietf.org [mail= to:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work
 


Hi Mischa,

Nearly all communication in a commercial building facility management system is point to point.  I'm surprised the other three requirements don't also have a strong p2p requirement.  Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicompute= r.  This centralized model was not scalable nor fault tolerant.  That is if the minicomputer 'blew a gasket', the entire building went out of control.

As soon as it was economically viable, we decentralized control by moving it down into the rooms.  Now each room was controlled independently with an array of room sensors and room controllers.  Now if a controll= er failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destin= ed to other nodes on the LLN.  They all require application ACKs.  A= bout 20% of the packets are destined to the LBR and onwards.  These are event packets being sent to the higher layers for further analysis.<= font size=3D3 face=3D"Times New Roman">

If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.


Jerry


Mischa Dohler <mischa.d= ohler@cttc.es>
Sent by: roll-bounces@ietf.org07/29/2009 04:18 PM
To
JP Vasseur <jvasseur@cisco= .com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protoc= ol work

 







JP, all,

We should use this early design stage to come up with one solution - one
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach.
The MAC folks are getting there and we should take our chance now. 95%
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were
worried about too much. Unless somebody provides me with a convincing
study, I propose to merely adopt some simple and possibly sub-optimum
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about?
Any node truly to any node? Are we back to pure ad hoc then? I guess if
IETF couldn't provide us with a magic ultra low power solution for ad
hoc networks in past years, then chances are slim that this will work
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency
of the 95% quantile applications, I propose to adopt some simple and
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an
M2M event in Paris a few months ago organized by Orange where we met
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would
never let IP run over their ROLL-type networks. The sheer majority did
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have devoted
> during the past few weeks on the protocol work. There was excellent
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate found= ation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several open
> issues for which we WILL need help from many WG contributors, including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 005BF45186257603_=-- From d.sturek@att.net Thu Jul 30 10:06:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A793A6A17 for ; Thu, 30 Jul 2009 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9FK3xhv+gIr for ; Thu, 30 Jul 2009 10:06:41 -0700 (PDT) Received: from smtp116.sbc.mail.re3.yahoo.com (smtp116.sbc.mail.re3.yahoo.com [66.196.96.89]) by core3.amsl.com (Postfix) with SMTP id D8EEA3A67F5 for ; Thu, 30 Jul 2009 10:06:40 -0700 (PDT) Received: (qmail 17659 invoked from network); 30 Jul 2009 17:00:00 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp116.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 16:59:59 -0000 X-YMail-OSG: dUAW3MAVM1nF6H5om1zdxB4TBnNsk4ZTOtwRhVj4uyRXhMCaNrw6qCEUlxinGQ6PnMhA5jRBETlw1kuJxrfaye8cL.OVf7hYPjVAqiZySnkQXeeQyypmsdAwX1dylZhydJ8qhgJzz7vJATPtLSU644F9SpdtcFjrxJSI02s8DMlnDe_kPM70mG8yzJA241HW5sSDOgElv2vx6eZAKMgWaNzfyIh3AUIHeNJPKX89RyKR8iBp2QLYCrAsF9KwQXgds4de8SwPGADUYn9t.KV.jx5EThqSeFhDXgMOkDj7PxI- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> In-Reply-To: Date: Thu, 30 Jul 2009 09:59:50 -0700 Message-ID: <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01CA10FC.7C75AC10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJg Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:06:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A3_01CA10FC.7C75AC10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Jerry, I may have misread the RPL proposal. I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases. I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first). I thought in all cases P2P was supported (just without a mechanism to minimize the hop count). Could someone from the DT comment on the assumptions above? Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts? If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network? I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL... Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work Hi Don, As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil. As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility. Jerry "Don Sturek" 07/30/2009 11:12 AM Please respond to To , "'Mischa Dohler'" cc "'ROLL WG'" , Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_01A3_01CA10FC.7C75AC10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Jerry,

 

I may have misread the RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back = down to a device in the DAG and that feature enabled P2P in all cases.  I = thought also the Destination Address notifications for devices with lower = depth/rank could be used by devices within a DAG to more efficiently reroute P2P = traffic within the DAG (not optimally, just “more efficiently than sending = the packet all the way to the DAG root first).  I thought in all cases P2P was supported (just without a mechanism to minimize the hop = count).

 

Could someone from the DT comment on the assumptions = above?

 

Did I understand that optimizing P2P for building = controls is mainly about minimizing hop counts?   If a building controls = solution could choose between optimizing hop count for P2P and flooding the = network to find the optimal P2P hop count, would it choose to flood the = network?  I think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found so = attractive about RPL…..


Don

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] Moving forward with the protocol = work

 


Hi = Don,

As I = read the draft, RPL doesn't currently guarantee p2p communication regardless of = hop count.  Only if some node higher in the DAG elects to provide a = path back down the DAG to the destination then there is p2p path.  RPL = doesn't mandate this even for the LBR.  Hence a packet could squirt all the = way up to the LBR and still be dropped since the LBR itself has no route = defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not = a router that happens to also do building control.  The likelihood = that a controller sitting higher in the DAG being altruist and defining = pathways to all possible sub-DAG devices is nil.

As for = hops, this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes so = having a packet arrive at its destination a tad late is not too concerning. = (NOTE: Fire and lighting applications are much more time critical).  The = problem is that the source device, typically a battery powered sensor must stay = awake and leave its receiver active until the packet has migrated to its = destination and the application ACK has been received.  This will reduce battery = life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes.  Sure we could have defined = the PAN to be the entire complex and then require 10K nodes as do the other = requirement specs.  Empirical testing however determined that managing 250 = nodes on a single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a floor seems to = be the right balance point for complexity and flexibility.

Jerry =


"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> =

cc=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

Subject=

RE: [Roll] Moving forward with the protocol work

 




Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think = most applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also without = nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will result in = anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work =
 


Hi Mischa,

Nearly all communication in a commercial building facility management = system is point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant.  That is if = the minicomputer 'blew a gasket', the entire building went out of = control.

As soon as it was economically viable, we decentralized control by = moving it down into the rooms.  Now each room was controlled independently = with an array of room sensors and room controllers.  Now if a controller = failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and = is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are destined = to other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will only solve = 75% of the need.


Jerry

Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

 

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work


 

 





JP, all,

We should use this early design stage to come up with one solution - one =
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. =
The MAC folks are getting there and we should take our chance now. 95% =
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with =
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were =
worried about too much. Unless somebody provides me with a convincing =
study, I propose to merely adopt some simple and possibly sub-optimum =
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about =
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about? =
Any node truly to any node? Are we back to pure ad hoc then? I guess if =
IETF couldn't provide us with a magic ultra low power solution for ad =
hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency =
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an =
M2M event in Paris a few months ago organized by Orange where we met =
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would =
never let IP run over their ROLL-type networks. The sheer majority did =
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was excellent =
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several = open
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_01A3_01CA10FC.7C75AC10-- From pthubert@cisco.com Thu Jul 30 10:17:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFE53A71BF; Thu, 30 Jul 2009 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.024 X-Spam-Level: X-Spam-Status: No, score=-9.024 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3ix4BaQLGGR3; Thu, 30 Jul 2009 10:17:02 -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 7A9073A71C3; Thu, 30 Jul 2009 10:17:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAAC5ycUqQ/uCLe2dsb2JhbACCJy6XNxYkBqEmiCeQLQWEEYFO X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="46160780" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 17:17:00 +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 n6UHH0HQ012667; Thu, 30 Jul 2009 19:17:00 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UHH05T028143; Thu, 30 Jul 2009 17:17:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 19:17:01 +0200 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_01CA1139.8CAC5028" Date: Thu, 30 Jul 2009 19:16:47 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07DC2ED5@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P discussion [ was RE: [Roll] Moving forward with the protocol work ] Thread-Index: AcoRNRMzsRAHb1zGRW2OJqijSol+QQAAD4BQ References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 30 Jul 2009 17:17:01.0153 (UTC) FILETIME=[8D193D10:01CA1139] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=34973; t=1248974220; x=1249838220; 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:=20P2P=20discussion=20[=20was=20RE=3A=20[Roll]=20M oving=20forward=20with=20the=20protocol=20work=20] |Sender:=20; bh=j0zX70VKg6QFgsz47zHPT+pktcBNmN7WWHP1QTSZHHc=; b=eODd8cTpqw+xC8hCzzWQXoBLjwmyl2N+dcp6UoJ/vwTcHgLVpKRNhyD6Gc 83nNaajKSYt8P7W7ERilFslis2Rp62ocwoSgwLxVsoey+4bh4L0Ek5SaUa71 Mbf2xvFBtR; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: [Roll] P2P discussion [ was RE: Moving forward with the protocol work ] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:17:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1139.8CAC5028 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerry =20 As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil.=20 This is a product /deployment issue. The protocol enables P2P and then you use it or not. If the use case (say building) requires the P2P routes then I suspect you'll design devices that can afford the necessary states and setup the devices to use them. OTOH the protocol should not force anything because that would have the counterproductive effect of forcing small devices to store states that they do not need in other use cases. As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. This looks a lot like a APP layer mingling with routing affairs. The routing delays will be what they will be, whether they are optimized or not, and you'll have to deal with that. It is not unheard of for upper layers to measure a turn around trip (TAT) delay - aka Round trip Time (RTT) and be smart about it. TCP does that (see RFC 2988). ISA100.11a applications that actually need a application layer ack also do that (over UDP).=20 I suspect that after some exchanges, the node can learn what a typical TAT is, what the variance is, and go to sleep until the ack has a fair chance to be back. But do not accuse the routing for every pain in the world. =20 As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility.=20 I'd like to figure what a typical depth (rank?) that would cause. Say your 250 nodes create a matrix of 16*16.=20 If the sink is in the middle of the matrix the max depth is about 8. That a node's transmission power enables a rank stripe to be about 2 nodes deep then the max depth goes down to 4. We'd have to run a computer simulation to get stats, but it appears that in many cases, RPL does not add that much stretch. We can improve P2P by a number of techniques, the question being to prove that this addition is required. It's good nevertheless to be prepared and discuss those additions so you get a reasonable idea that it is doable Cheers =20 Pascal =20 =20 Jerry=20 "Don Sturek" =20 07/30/2009 11:12 AM=20 Please respond to To , "'Mischa Dohler'" =20 cc "'ROLL WG'" , =20 Subject RE: [Roll] Moving forward with the protocol work =20 =09 Hi Jerry,=20 =20 I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up.=20 =20 I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). =20 =20 I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). =20 =20 Don=20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work=20 =20 Hi Mischa,=20 Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control.=20 As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. =20 My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis.=20 If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.=20 Jerry=20 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 =20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =20 =20 =09 JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers=20 produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95%=20 quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus=20 > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 ------_=_NextPart_001_01CA1139.8CAC5028 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jerry

 

As I read the draft, RPL doesn't = currently guarantee p2p communication regardless of hop count.  Only if some = node higher in the DAG elects to provide a path back down the DAG to the = destination then there is p2p path.  RPL doesn't mandate this even for the LBR.  Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. =  You need to keep in mind that the LLN devices are primarily a building = controllers that 'moonlight' as a router; it's not a router that happens to also do = building control.  The likelihood that a controller sitting higher in the = DAG being altruist and defining pathways to all possible sub-DAG devices is = nil.

This is a product = /deployment issue. The protocol enables P2P and then you use it or not. If the use = case (say building) requires the P2P routes then I suspect you’ll = design devices that can afford the necessary states and setup the devices to = use them. OTOH the protocol should not force anything because that would have the = counterproductive effect of forcing small devices to store states that they do not need in = other use cases.


As for = hops, this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes so = having a packet arrive at its destination a tad late is not too concerning. = (NOTE: Fire and lighting applications are much more time critical).  The = problem is that the source device, typically a battery powered sensor must stay = awake and leave its receiver active until the packet has migrated to its = destination and the application ACK has been received.  This will reduce battery = life at least 10x.

This looks a lot like = a APP layer mingling with routing affairs. The routing delays will be what = they will be, whether they are optimized or not, and you’ll have to deal = with that. It is not unheard of for upper layers to measure a turn around trip = (TAT) delay - aka Round trip Time (RTT) and be smart about it. TCP does that (see = RFC 2988). ISA100.11a applications that actually need a application layer ack also = do that (over UDP).

I suspect that after = some exchanges, the node can learn what a typical TAT is, what the variance is, and go = to sleep until the ack has a fair chance to be back. But do not accuse the = routing for every pain in the world.

 
As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes.  Sure we could have defined = the PAN to be the entire complex and then require 10K nodes as do the other = requirement specs.  Empirical testing however determined that managing 250 = nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count.  Limiting PAN size to a floor seems to = be the right balance point for complexity and flexibility.

I’d like to = figure what a typical depth (rank?) that would cause. Say your 250 nodes create a = matrix of 16*16.

If the sink is in the = middle of the matrix the max depth is about 8.

That a node’s transmission power enables a rank stripe to be about 2 nodes deep then = the max depth goes down to 4.

We’d have to run = a computer simulation  to get stats, but it appears that in many cases, RPL = does not add that much stretch.

We can improve P2P by = a number of techniques, the question being to prove that this addition is = required.

It’s good = nevertheless to be prepared and discuss those additions so you get a reasonable idea = that it is doable

Cheers

 

Pascal

 

 


Jerry =


"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> =

cc=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

Subject=

RE: [Roll] Moving forward with the protocol work

 




Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think = most applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also without = nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will result in = anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work =
 


Hi Mischa,

Nearly all communication in a commercial building facility management = system is point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant.  That is if = the minicomputer 'blew a gasket', the entire building went out of = control.

As soon as it was economically viable, we decentralized control by = moving it down into the rooms.  Now each room was controlled independently = with an array of room sensors and room controllers.  Now if a controller = failed, only the room might lose control, not the entire complex.  The room = controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the = mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are destined = to other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will only solve = 75% of the need.


Jerry

Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

 

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work


 

 





JP, all,

We should use this early design stage to come up with one solution - one =
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. =
The MAC folks are getting there and we should take our chance now. 95% =
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with =
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were =
worried about too much. Unless somebody provides me with a convincing =
study, I propose to merely adopt some simple and possibly sub-optimum =
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about =
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about? =
Any node truly to any node? Are we back to pure ad hoc then? I guess if =
IETF couldn't provide us with a magic ultra low power solution for ad =
hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency =
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an =
M2M event in Paris a few months ago organized by Orange where we met =
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would =
never let IP run over their ROLL-type networks. The sheer majority did =
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was excellent =
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several = open
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CA1139.8CAC5028-- From Matthew.Anderson@us.elster.com Thu Jul 30 10:18:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BEE28C2D5 for ; Thu, 30 Jul 2009 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udnT-IXJmvMO for ; Thu, 30 Jul 2009 10:18:17 -0700 (PDT) Received: from mail44.messagelabs.com (mail44.messagelabs.com [216.82.249.179]) by core3.amsl.com (Postfix) with SMTP id 3491628C2CE for ; Thu, 30 Jul 2009 10:18:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-12.tower-44.messagelabs.com!1248974297!11870544!1 X-StarScan-Version: 6.1.2; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 29411 invoked from network); 30 Jul 2009 17:18:18 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-12.tower-44.messagelabs.com with SMTP; 30 Jul 2009 17:18:18 -0000 In-Reply-To: References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> To: roll@ietf.org MIME-Version: 1.0 X-KeepSent: B457AF6F:98845974-85257603:005CECDC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Matthew.Anderson@us.elster.com Date: Thu, 30 Jul 2009 13:18:06 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5 HF460|May 15, 2009) at 07/30/2009 01:17:03 PM, Serialize complete at 07/30/2009 01:17:03 PM Content-Type: multipart/alternative; boundary="=_alternative 005F08CBC1257603_=" Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:18:19 -0000 This is a multipart message in MIME format. --=_alternative 005F08CBC1257603_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U28gSSBhZ3JlZSB3aXRoIGJvdGggRG9uIGFuZCBKZXJyeS4gIENlcnRhaW5seSB3aXRoaW4gYSBQ QU4sIHNvbWVvbmUgaGFzIA0KdG8gYmUgYWJsZSByb3V0ZSBwYWNrZXRzIHdpdGhpbiB0aGF0IFBB TiB0byBzdXBwb3J0IFAyUC4gSSB0aG91Z2h0IHRoZSBEQUcgDQpyb290cyB3ZXJlIHJlcXVpcmVk IHRvIGRvIHRoaXMsIGJ1dCBpbiByZWFkaW5nIHRoZSBSUEwgZHJhZnQgYWdhaW4sIEkgDQpkb24n dCBzZWUgdGhhdC4gDQoNClRoYXQgc2FpZCBoYXZpbmcgYWxsIG5vZGVzIGFibGUgdG8gcm91dGUg dG8gYWxsIG5laWdoYm9yIG5vZGVzIGlzIHByb2JhYmx5IA0Kbm90IGdvaW5nIHRvIHdvcmsgZHVl IHRvIHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUgbm9kZXMgdGhlbXNlbHZlcyAoSUVFRSANCjgwMi4x NS41IHByb3ZpZGVzIGEgZGVzaWduIGZvciB0aGlzIGlmIGFueW9uZSB3b3VsZCBsaWtlIHRvIHJl YWQgaXQpLiANClRoZXNlIGFyZSBsb3cgcG93ZXIgYW5kIHVzdWFsbHkgcmVzb3VyY2UgbGltaXRl ZCBkZXZpY2VzLg0KDQpQZXJoYXBzIG1ha2luZyB0aGUgREFHIHJvb3RzIC0gd2hpY2ggd2lsbCBo YXZlIHRvIGJlIG1vcmUgcG93ZXJmdWwgdGhhbiANCnRoZSBtYWpvcml0eSBvZiB0aGUgbm9kZXMg aW4gdGhlIExMTiAtIGJlIHJlcXVpcmVkIHRvIHJvdXRlIHdpdGhpbiB0aGUgDQpQQU4ncyBzaG91 bGQgYmUgbWFkZSBhIHJlcXVpcmVtZW50LiAgIEFzIERvbiBzYWlkLCB0aGlzIHdvbid0IG9wdGlt aXplIGhvcCANCmNvdW50IGFuZCBpdCB3b3VsZCBiZSB1bmZvcnR1bmF0ZSBpZiB0d28gc2lkZS1i eS1zaWRlIG5vZGVzIGhhdmUgdG8gDQpjb21tdW5pY2F0ZSB0aHJ1IGEgREFHIHJvb3QgNyBob3Bz IGF3YXkgLSBidXQgaXQgbWF5IGJlIGEgcmVhbGl0eSBvZiB0aGVzZSANCm5ldHdvcmtzLiAgQXQg YSAic29sdXRpb24gbGV2ZWwiLCBpZiB5b3VyIFBBTiBjYW4gYWZmb3JkIG1vcmUgREFHIHJvb3Rz IHRvIA0KbWluaW1pemUgdGhlIGhvcHMsIHlvdSBwdXQgdGhlbSBpbi4gIElmIHlvdSBjYW4ndCwg eW91IGRlYWwgd2l0aCBsZXNzIHRoYW4gDQpvcHRpbWl6ZWQgcm91dGluZy4gIEJ1dCBhdCBhIHBy b3RvY29sIGxldmVsLCB3ZSBtYXkgaGF2ZSB0byBtYWtlIHNvbWUgDQpzYWNyaWZpY2VzIC0gYXMg bG9uZyBhcyB3ZSBlbnN1cmUgdGhlIHByb3RvY29sIGRvZXMgZW5zdXJlIHRoYXQgUDJQIGlzIA0K ZW5hYmxlZCBpbiBzb21lIGZvcm0uDQoNCg0KDQoNCg0KDQpGcm9tOg0KSmVyYWxkLlAuTWFydG9j Y2lAamNpLmNvbQ0KVG86DQo8ZC5zdHVyZWtAYXR0Lm5ldD4NCkNjOg0KJ1JPTEwgV0cnIDxyb2xs QGlldGYub3JnPiwgcm9sbC1ib3VuY2VzQGlldGYub3JnDQpEYXRlOg0KMDcvMzAvMjAwOSAwNjo0 NCBQTQ0KU3ViamVjdDoNClJlOiBbUm9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgcHJvdG9j b2wgd29yaw0KU2VudCBieToNCnJvbGwtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KDQpIaSBEb24s IA0KDQpBcyBJIHJlYWQgdGhlIGRyYWZ0LCBSUEwgZG9lc24ndCBjdXJyZW50bHkgZ3VhcmFudGVl IHAycCBjb21tdW5pY2F0aW9uIA0KcmVnYXJkbGVzcyBvZiBob3AgY291bnQuICBPbmx5IGlmIHNv bWUgbm9kZSBoaWdoZXIgaW4gdGhlIERBRyBlbGVjdHMgdG8gDQpwcm92aWRlIGEgcGF0aCBiYWNr IGRvd24gdGhlIERBRyB0byB0aGUgZGVzdGluYXRpb24gdGhlbiB0aGVyZSBpcyBwMnAgDQpwYXRo LiAgUlBMIGRvZXNuJ3QgbWFuZGF0ZSB0aGlzIGV2ZW4gZm9yIHRoZSBMQlIuICBIZW5jZSBhIHBh Y2tldCBjb3VsZCANCnNxdWlydCBhbGwgdGhlIHdheSB1cCB0byB0aGUgTEJSIGFuZCBzdGlsbCBi ZSBkcm9wcGVkIHNpbmNlIHRoZSBMQlIgaXRzZWxmIA0KaGFzIG5vIHJvdXRlIGRlZmluZWQgdG8g dGhlIGRlc3RpbmF0aW9uLiAgWW91IG5lZWQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgDQp0aGUgTExO IGRldmljZXMgYXJlIHByaW1hcmlseSBhIGJ1aWxkaW5nIGNvbnRyb2xsZXJzIHRoYXQgJ21vb25s aWdodCcgYXMgYSANCnJvdXRlcjsgaXQncyBub3QgYSByb3V0ZXIgdGhhdCBoYXBwZW5zIHRvIGFs c28gZG8gYnVpbGRpbmcgY29udHJvbC4gIFRoZSANCmxpa2VsaWhvb2QgdGhhdCBhIGNvbnRyb2xs ZXIgc2l0dGluZyBoaWdoZXIgaW4gdGhlIERBRyBiZWluZyBhbHRydWlzdCBhbmQgDQpkZWZpbmlu ZyBwYXRod2F5cyB0byBhbGwgcG9zc2libGUgc3ViLURBRyBkZXZpY2VzIGlzIG5pbC4gDQoNCkFz IGZvciBob3BzLCB0aGlzIGlzIHZlcnkgaW1wb3J0YW50IHRvby4gIE5vdCBzbyBtdWNoIGZvciBs YXRlbmN5LiAgVGhlIA0KdGltZSBjb25zdGFudCBmb3IgbW9zdCBidWlsZGluZyBIVkFDICBjb250 cm9sIGxvb3BzIGlzIGluIG1pbnV0ZXMgc28gDQpoYXZpbmcgYSBwYWNrZXQgYXJyaXZlIGF0IGl0 cyBkZXN0aW5hdGlvbiBhIHRhZCBsYXRlIGlzIG5vdCB0b28gDQpjb25jZXJuaW5nLiAoTk9URTog RmlyZSBhbmQgbGlnaHRpbmcgYXBwbGljYXRpb25zIGFyZSBtdWNoIG1vcmUgdGltZSANCmNyaXRp Y2FsKS4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHNvdXJjZSBkZXZpY2UsIHR5cGljYWxseSBh IGJhdHRlcnkgDQpwb3dlcmVkIHNlbnNvciBtdXN0IHN0YXkgYXdha2UgYW5kIGxlYXZlIGl0cyBy ZWNlaXZlciBhY3RpdmUgdW50aWwgdGhlIA0KcGFja2V0IGhhcyBtaWdyYXRlZCB0byBpdHMgZGVz dGluYXRpb24gYW5kIHRoZSBhcHBsaWNhdGlvbiBBQ0sgaGFzIGJlZW4gDQpyZWNlaXZlZC4gIFRo aXMgd2lsbCByZWR1Y2UgYmF0dGVyeSBsaWZlIGF0IGxlYXN0IDEweC4NCg0KQXMgZm9yIHNjYWxh YmlsaXR5LCBhIHR5cGljYWwgUEFOIGluIGEgY29tbWVyY2lhbCBidWlsZGluZyBpcyBsaW1pdGVk IHRvIGEgDQpmbG9vciB3aGljaCBtYXkgcmVxdWlyZSB1cHdhcmRzIHRvIDI1MCBMTE4gbm9kZXMu ICBTdXJlIHdlIGNvdWxkIGhhdmUgDQpkZWZpbmVkIHRoZSBQQU4gdG8gYmUgdGhlIGVudGlyZSBj b21wbGV4IGFuZCB0aGVuIHJlcXVpcmUgMTBLIG5vZGVzIGFzIGRvIA0KdGhlIG90aGVyIHJlcXVp cmVtZW50IHNwZWNzLiAgRW1waXJpY2FsIHRlc3RpbmcgaG93ZXZlciBkZXRlcm1pbmVkIHRoYXQg DQptYW5hZ2luZyAyNTAgbm9kZXMgb24gYSBzaW5nbGUgd2lyZWxlc3MgZG9tYWluIHdhcyBkaWZm aWN1bHQgZW5vdWdoIHdpdGggDQpyZWdhcmQgdG8gY2hhbm5lbCBtYW5hZ2VtZW50LCBpbnRlcmZl cmVuY2UgYW5kIGhvcCBjb3VudC4gIExpbWl0aW5nIFBBTiANCnNpemUgdG8gYSBmbG9vciBzZWVt cyB0byBiZSB0aGUgcmlnaHQgYmFsYW5jZSBwb2ludCBmb3IgY29tcGxleGl0eSBhbmQgDQpmbGV4 aWJpbGl0eS4gDQoNCkplcnJ5IA0KDQoNCg0KIkRvbiBTdHVyZWsiIDxkLnN0dXJla0BhdHQubmV0 PiANCjA3LzMwLzIwMDkgMTE6MTIgQU0gDQoNClBsZWFzZSByZXNwb25kIHRvDQo8ZC5zdHVyZWtA YXR0Lm5ldD4NCg0KDQpUbw0KPEplcmFsZC5QLk1hcnRvY2NpQGpjaS5jb20+LCAiJ01pc2NoYSBE b2hsZXInIiA8bWlzY2hhLmRvaGxlckBjdHRjLmVzPiANCmNjDQoiJ1JPTEwgV0cnIiA8cm9sbEBp ZXRmLm9yZz4sIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+IA0KU3ViamVjdA0KUkU6IFtSb2xsXSBN b3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBwcm90b2NvbCB3b3JrDQoNCg0KDQoNCg0KDQoNCg0KSGkg SmVycnksIA0KICANCkkgdGhpbmsgUlBMIGRvZXMgc3VwcG9ydCBQMlAgYnV0IGRvZXMgbm90IG9w dGltaXplIHRoZSBudW1iZXIgb2YgaG9wcy4gSSANCnRoaW5rIHRoYXQgaXMgdGhlIGNlbnRyYWwg aXNzdWUgeW91IGFuZCBNdWt1bCBhcmUgYnJpbmdpbmcgdXAuIA0KICANCkkgZG8gcXVlc3Rpb24g d2hldGhlciBvcHRpbWl6aW5nIGhvcHMgaXMgcmVhbGx5IG5lY2Vzc2FyeS4gIEkgdGhpbmsgbW9z dCANCmFwcGxpY2F0aW9ucyAoaW5jbHVkaW5nIGJ1aWxkaW5nIGNvbnRyb2xzKSBjYW4gdGFrZSBh ZHZhbnRhZ2Ugb2YgYSANCnNvbHV0aW9uIHRoYXQgd2VsbCBzdXBwb3J0cyBNUDJQIGFuZCBQMk1Q IHdpdGggZXh0ZW5zaW9ucyB0byBwcm92aWRlIFAyUCANCmNhcGFiaWxpdHkgKGFkbWl0dGVkbHkg bm90IG9wdGltaXplZCBmb3IgaG9wIGNvdW50L2Nvc3QgYnV0IHRoZW4gYWxzbyANCndpdGhvdXQg bmVhcmx5IHRoZSBvdmVyaGVhZCBvZiBwYWNrZXQgZmxvb2Rpbmcgb3Igc3RvcmFnZSBvZiBzdGF0 ZSANCmluZm9ybWF0aW9uIHRoYXQgb3B0aW1pemVkIFAyUCBzb2x1dGlvbnMgaW1wb3NlKS4gICAN CiAgDQpJIHJlYWxseSBkb27igJl0IHNlZSB0aGF0IHRyeWluZyAob25jZSBhZ2FpbiBhcyB0aGV5 IGhhdmUgaW4gTUFORVQgZm9yIHNvbWUgDQp0aW1lKSB0byBmaW5kIGEgc2luZ2xlIHByb3RvY29s IHRoYXQgZWZmaWNpZW50bHkgaW1wbGVtZW50cyBQMlAgYW5kIHNjYWxlcyANCndoaWxlIGFkZHJl c3NpbmcgdGhlIHZhcmlvdXMgZGF0YSB0cmFuc21pc3Npb24gcGF0dGVybnMgd2lsbCByZXN1bHQg aW4gDQphbnl0aGluZyBvdGhlciB0aGFuIHRoZSBzYW1lIHNldCBvZiBzb2x1dGlvbnMgd2UgaGF2 ZSB0b2RheSAoZGlzdGFuY2UgDQp2ZWN0b3Igd2l0aCBmbG9vZGluZywgbGluayBzdGF0ZSByb3V0 aW5nIGFuZCBpdHMgZGVyaXZhdGl2ZXMsIHNvdXJjZSANCnJvdXRpbmcgYW5kIGl0cyBkZXJpdmF0 aXZlcykuICAgDQogIA0KRG9uIA0KICANCiAgDQpGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCkplcmFsZC5QLk1h cnRvY2NpQGpjaS5jb20NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IDg6NTggQU0NClRv OiBNaXNjaGEgRG9obGVyDQpDYzogUk9MTCBXRzsgcm9sbC1ib3VuY2VzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW1JvbGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcmsgDQog IA0KDQoNCkhpIE1pc2NoYSwgDQoNCk5lYXJseSBhbGwgY29tbXVuaWNhdGlvbiBpbiBhIGNvbW1l cmNpYWwgYnVpbGRpbmcgZmFjaWxpdHkgbWFuYWdlbWVudCANCnN5c3RlbSBpcyBwb2ludCB0byBw b2ludC4gIEknbSBzdXJwcmlzZWQgdGhlIG90aGVyIHRocmVlIHJlcXVpcmVtZW50cyANCmRvbid0 IGFsc28gaGF2ZSBhIHN0cm9uZyBwMnAgcmVxdWlyZW1lbnQuICBCYWNrIGluIHRoZSBlYXJseSA4 MCdzIHByaW9yIHRvIA0KcHJvY2Vzc29yIGJhc2VkIHNlbnNvcnMsIHdlIGRlcGxveWVkICdkdW1i IHNlbnNvcnMnIHRoYXQgd291bGQgc2ltcGx5IA0KdXBsb2FkIHRoZWlyIGN1cnJlbnQgZW52aXJv bm1lbnRhbCBpbmZvcm1hdGlvbiB0byBhIGNlbnRyYWxpemVkIA0KbWluaWNvbXB1dGVyLiAgVGhp cyBjZW50cmFsaXplZCBtb2RlbCB3YXMgbm90IHNjYWxhYmxlIG5vciBmYXVsdCB0b2xlcmFudC4g DQogVGhhdCBpcyBpZiB0aGUgbWluaWNvbXB1dGVyICdibGV3IGEgZ2Fza2V0JywgdGhlIGVudGly ZSBidWlsZGluZyB3ZW50IG91dCANCm9mIGNvbnRyb2wuIA0KDQpBcyBzb29uIGFzIGl0IHdhcyBl Y29ub21pY2FsbHkgdmlhYmxlLCB3ZSBkZWNlbnRyYWxpemVkIGNvbnRyb2wgYnkgbW92aW5nIA0K aXQgZG93biBpbnRvIHRoZSByb29tcy4gIE5vdyBlYWNoIHJvb20gd2FzIGNvbnRyb2xsZWQgaW5k ZXBlbmRlbnRseSB3aXRoIA0KYW4gYXJyYXkgb2Ygcm9vbSBzZW5zb3JzIGFuZCByb29tIGNvbnRy b2xsZXJzLiAgTm93IGlmIGEgY29udHJvbGxlciANCmZhaWxlZCwgb25seSB0aGUgcm9vbSBtaWdo dCBsb3NlIGNvbnRyb2wsIG5vdCB0aGUgZW50aXJlIGNvbXBsZXguICBUaGUgDQpyb29tIGNvbnRy b2xsZXJzIHdlcmUgdGhlbiBmdXJ0aGVyIGNvbnRyb2xsZWQgYnkgaGlnaGVyIGxldmVsIGNvbnRy b2xsZXJzLiANCiBUaGlzIGRpc3RyaWJ1dGVkIGFyY2hpdGVjdHVyZSBoYXMgYmVlbiBpbiBwbGFj ZSBmb3IgMjUgeWVhcnMgYW5kIGlzIHRoZSANCm1haW5zdGF5IG9mIGJ1aWxkaW5nIGNvbnRyb2wu ICAgDQoNCk15IHBvaW50IGlzIHRoYXQgaXMgdGhlIENvbW1lcmNpYWwgTWFya2V0IHRoZSBMTE4g aXMgbm90IGp1c3QgYSBwYXRoIGZvciANCm1vdmluZyBkYXRhIG5vcnRib3VuZC4gIE1vc3Qgb2Yg dGhlIHBhY2tldHMgc2VudCBvbiB0aGUgTExOIGFyZSBkZXN0aW5lZCANCnRvIG90aGVyIG5vZGVz IG9uIHRoZSBMTE4uICBUaGV5IGFsbCByZXF1aXJlIGFwcGxpY2F0aW9uIEFDS3MuICBBYm91dCAy MCUgDQpvZiB0aGUgcGFja2V0cyBhcmUgZGVzdGluZWQgdG8gdGhlIExCUiBhbmQgb253YXJkcy4g IFRoZXNlIGFyZSBldmVudCANCnBhY2tldHMgYmVpbmcgc2VudCB0byB0aGUgaGlnaGVyIGxheWVy cyBmb3IgZnVydGhlciBhbmFseXNpcy4gDQoNCklmIHdlIGRvbid0IHN1cHBvcnQgYSByb2J1c3Qg cDJwIHByb3RvY29sIG9wdGlvbiBpbiBST0xMLCB3ZSB3aWxsIGtub2NrIA0Kb3V0IHRoZSBCdWls ZGluZyBNYXJrZXQgaW4gaXRzIGVudGlyZXR5IHdoaWNoIG1lYW5zIGF0IGJlc3QgeW91IHdpbGwg b25seSANCnNvbHZlIDc1JSBvZiB0aGUgbmVlZC4gDQoNCg0KSmVycnkgDQoNCg0KDQpNaXNjaGEg RG9obGVyIDxtaXNjaGEuZG9obGVyQGN0dGMuZXM+IA0KU2VudCBieTogcm9sbC1ib3VuY2VzQGll dGYub3JnIA0KMDcvMjkvMjAwOSAwNDoxOCBQTSANCg0KDQpUbw0KSlAgVmFzc2V1ciA8anZhc3Nl dXJAY2lzY28uY29tPiANCmNjDQpST0xMIFdHIDxyb2xsQGlldGYub3JnPiANClN1YmplY3QNClJl OiBbUm9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgcHJvdG9jb2wgd29yaw0KDQogIA0KDQoN Cg0KDQoNCg0KDQoNCg0KSlAsIGFsbCwNCg0KV2Ugc2hvdWxkIHVzZSB0aGlzIGVhcmx5IGRlc2ln biBzdGFnZSB0byBjb21lIHVwIHdpdGggb25lIHNvbHV0aW9uIC0gb25lIA0Kc29sdXRpb24gd2hp Y2ggaXMgbm90IG5lY2Vzc2FyaWx5IG9wdGltdW0gZm9yIGFsbCBjYXNlcyBidXQgZm9yIHRoZSAN CihlLmcuKSA5NSUgcXVhbnRpbGUuIFRoZSBQSFkgZ3V5cyBsZWFybmVkIHRvIGxpdmUgd2l0aCBz dWNoIGFuIGFwcHJvYWNoLiANClRoZSBNQUMgZm9sa3MgYXJlIGdldHRpbmcgdGhlcmUgYW5kIHdl IHNob3VsZCB0YWtlIG91ciBjaGFuY2Ugbm93LiA5NSUgDQptZWFucyBjbGVhcmx5IHRvIGNvbmNl bnRyYXRlIG9uIHRoZSBjb3JlIGlzc3Vlcywgb2Ygd2hpY2ggbG9vcCANCmRldGVjdGlvbi9hdm9p ZGFuY2UsIHAycCBhbmQgc2VjdXJpdHkgYXJlIHNvbWVob3cgc3RpbGwgb3Blbi4NCg0KSSBkbyB1 bmRlcnN0YW5kIHRoZSBjb25jZXB0IG9mIGxvb3BzIGFyaXNpbmcuIEkgaGF2ZSBkb3VidHMgdGhh dCB3aXRoIA0KdGhlIGR5bmFtaWNzIG9mIHR5cGljYWwgUk9MTCBuZXR3b3JrcywgdGhlc2Ugd2ls bCBnaXZlIHVzIGhlYWRhY2hlcyANCndpdGhpbiB0aGlzIDk1JSBhcHBsaWNhdGlvbiBxdWFudGls ZS4gSSBoYXZlIHJlYWQgdG9ucyBvZiBwYXBlcnMgDQpwcm9kdWNlZCBpbiB0aGUgbGFzdCBkZWNh ZGUgb24gcm91dGluZyBpbiBST0xMLXR5cGUgbmV0d29ya3MuIExvb3AgDQpkZXRlY3Rpb24gYW5k IGF2b2lkYW5jZSB3YXMgY2xlYXJseSBub3Qgc29tZXRoaW5nIHBlb3BsZSAoaW5jbHVkaW5nIA0K dGhvc2UgZG9pbmcgcHJhY3RpY2FsIHJvbGxvdXRzIGFuZCBydW5uaW5nIHRoZWlyIGNvbXBhbmll cyB0b2RheSkgd2VyZSANCndvcnJpZWQgYWJvdXQgdG9vIG11Y2guIFVubGVzcyBzb21lYm9keSBw cm92aWRlcyBtZSB3aXRoIGEgY29udmluY2luZyANCnN0dWR5LCBJIHByb3Bvc2UgdG8gbWVyZWx5 IGFkb3B0IHNvbWUgc2ltcGxlIGFuZCBwb3NzaWJseSBzdWItb3B0aW11bSANCmhldXJpc3RpY3Mg YW5kIHRoZW4gZm9yZ2V0IGFib3V0IGl0Lg0KDQpQMlAgc2VlbXMgdG8gd29ycnkgc29tZSBvZiB1 cyAoc29ycnksIEplcnJ5LCBmb3IgaGF2aW5nIGZvcmdvdHRlbiBhYm91dCANCnRoZSBwMnAgcGFy YWdyYXBoKS4gSG93ZXZlciwgYWdhaW4sIGFyZSB3ZSB0YWxraW5nIGFib3V0IHRoZSA5NSUgDQpx dWFudGlsZSBoZXJlPyBGdXJ0aGVybW9yZSwgaG93IG11Y2ggcDJwIGV4YWN0bHkgYXJlIHlvdSB0 YWxraW5nIGFib3V0PyANCkFueSBub2RlIHRydWx5IHRvIGFueSBub2RlPyBBcmUgd2UgYmFjayB0 byBwdXJlIGFkIGhvYyB0aGVuPyBJIGd1ZXNzIGlmIA0KSUVURiBjb3VsZG4ndCBwcm92aWRlIHVz IHdpdGggYSBtYWdpYyB1bHRyYSBsb3cgcG93ZXIgc29sdXRpb24gZm9yIGFkIA0KaG9jIG5ldHdv cmtzIGluIHBhc3QgeWVhcnMsIHRoZW4gY2hhbmNlcyBhcmUgc2xpbSB0aGF0IHRoaXMgd2lsbCB3 b3JrIA0Kb3V0IG5vdy4gVW5sZXNzIHNvbWVib2R5IHByb3ZpZGVzIG1lIHdpdGggYSBjb252aW5j aW5nIHN0dWR5IHRoYXQgDQphZG9wdGluZyBhIGdlbmVyYWwgcDJwIFJPTEwgcHJvdG9jb2wgd2ls bCBub3QgamVvcGFyZGl6ZSB0aGUgZWZmaWNpZW5jeSANCm9mIHRoZSA5NSUgcXVhbnRpbGUgYXBw bGljYXRpb25zLCBJIHByb3Bvc2UgdG8gYWRvcHQgc29tZSBzaW1wbGUgYW5kIA0KcG9zc2libHkg c3ViLW9wdGltdW0gaGV1cmlzdGljcyBhbmQgdGhlbiBmb3JnZXQgYWJvdXQgaXQuDQoNClNlY3Vy aXR5IGlzIGFuIGltcG9ydGFudCBpc3N1ZS4NCg0KTm93IHRoYXQgd2UgYXJlIGF0IGl0LCBJIHNh bXBsZWQgcXVpdGUgYSBsYXJnZSBudW1iZXIgb2YgY29tcGFuaWVzIGF0IGFuIA0KTTJNIGV2ZW50 IGluIFBhcmlzIGEgZmV3IG1vbnRocyBhZ28gb3JnYW5pemVkIGJ5IE9yYW5nZSB3aGVyZSB3ZSBt ZXQgDQp3aXRoIEpQIGFuZCBvdGhlcnMuIFRoZSBsYXJnZSBtYWpvcml0eSBvZiBjb21wYW5pZXMg cHJlc2VudCB0aGVyZSANCmV4cGxpY2l0bHkgdG9sZCBtZSB0aGF0IC0gZm9yIGEgdmVyeSB2YXJ5 aW5nIHNldCBvZiByZWFzb25zIC0gdGhleSB3b3VsZCANCm5ldmVyIGxldCBJUCBydW4gb3ZlciB0 aGVpciBST0xMLXR5cGUgbmV0d29ya3MuIFRoZSBzaGVlciBtYWpvcml0eSBkaWQgDQpzdXByaXNl IG1lLiBXZSBzdGlsbCBoYXZlIGEgbG90IG9mIHdvcmsgYWhlYWQuDQoNCkkgYW0gaW4gZmF2b3Vy IG9mIGFkb3B0aW5nIGRyYWZ0LWR0LXJvbGwtcnBsLTAxIGFzIGEgV0cgZG9jdW1lbnQuDQoNCk1p c2NoYS4NCg0KDQoNCg0KDQoNCkpQIFZhc3NldXIgd3JvdGU6DQo+IERlYXIgV0csDQo+IA0KPiBG aXJzdCBvZiBhbGwsIHRoYW5rcyBmb3IgYWxsIHRoZSB0aW1lIGFuZCBlbmVyZ3kgeW91IGFsbCBo YXZlIGRldm90ZWQgDQo+IGR1cmluZyB0aGUgcGFzdCBmZXcgd2Vla3Mgb24gdGhlIHByb3RvY29s IHdvcmsuIFRoZXJlIHdhcyBleGNlbGxlbnQgDQo+IGZvbGxvd3VwIGRpc2N1c3Npb24gYXQgdGhl IHBoeXNpY2FsIFdHIG1lZXRpbmcuDQo+IA0KPiBUbyB0aGUgcXVlc3Rpb24gIkRvIHlvdSB0aGlu ayB0aGF0IFJQTCBwcm92aWRlcyBhbiBhZGVxdWF0ZSBmb3VuZGF0aW9uIA0KPiBmb3IgdGhlIFJP TEwgcm91dGluZyBwcm90b2NvbCB3b3JrIiwgdGhlcmUgd2FzIGNsZWFybHkgYSBnb29kIGNvbnNl bnN1cyANCj4gaW4gdGhlIFdHIG1lZXRpbmcuIEl0IHdhcyBhbHNvIHJlY29nbml6ZWQgdGhlcmUg YXJlIHN0aWxsIHNldmVyYWwgb3BlbiANCj4gaXNzdWVzIGZvciB3aGljaCB3ZSBXSUxMIG5lZWQg aGVscCBmcm9tIG1hbnkgV0cgY29udHJpYnV0b3JzLCBpbmNsdWRpbmcgDQo+IHRoZSBhdXRob3Jz IG9mIG90aGVyIGRvY3VtZW50cy4NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2UgY29uZmlybSAob3Ig bm90KSB0aGUgYWRvcHRpb24gb2YgZHJhZnQtZHQtcm9sbC1ycGwtMDEgDQo+IGFzIGEgV0cgZG9j dW1lbnQgPw0KPiANCj4gVGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBtb3ZlIHRvIHRoZSBuZXh0IHN0 ZXAuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBKUCBhbmQgRGF2aWQNCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcg bGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgZW1haWwgaGFz IGJlZW4gc3BhbSBhbmQgdmlydXMgY2hlY2tlZCBieSBFbHN0ZXIgSVQgU2VydmljZXMuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5n IGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbA0KDQoNCg== --=_alternative 005F08CBC1257603_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvIEkgYWdyZWUgd2l0aCBib3RoIERvbiBh bmQgSmVycnkuICZuYnNwO0NlcnRhaW5seQ0Kd2l0aGluIGEgUEFOLCBzb21lb25lIGhhcyB0byBi ZSBhYmxlIHJvdXRlIHBhY2tldHMgd2l0aGluIHRoYXQgUEFOIHRvIHN1cHBvcnQNClAyUC4gSSB0 aG91Z2h0IHRoZSBEQUcgcm9vdHMgd2VyZSByZXF1aXJlZCB0byBkbyB0aGlzLCBidXQgaW4gcmVh ZGluZyB0aGUNClJQTCBkcmFmdCBhZ2FpbiwgSSBkb24ndCBzZWUgdGhhdC4gJm5ic3A7PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGF0IHNhaWQgaGF2 aW5nIGFsbCBub2RlcyBhYmxlIHRvIHJvdXRlDQp0byBhbGwgbmVpZ2hib3Igbm9kZXMgaXMgcHJv YmFibHkgbm90IGdvaW5nIHRvIHdvcmsgZHVlIHRvIHRoZSBsaW1pdGF0aW9ucw0Kb2YgdGhlIG5v ZGVzIHRoZW1zZWx2ZXMgKElFRUUgODAyLjE1LjUgcHJvdmlkZXMgYSBkZXNpZ24gZm9yIHRoaXMg aWYgYW55b25lDQp3b3VsZCBsaWtlIHRvIHJlYWQgaXQpLiAmbmJzcDtUaGVzZSBhcmUgbG93IHBv d2VyIGFuZCB1c3VhbGx5IHJlc291cmNlDQpsaW1pdGVkIGRldmljZXMuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QZXJoYXBzIG1ha2luZyB0aGUgREFH IHJvb3RzIC0gd2hpY2gNCndpbGwgaGF2ZSB0byBiZSBtb3JlIHBvd2VyZnVsIHRoYW4gdGhlIG1h am9yaXR5IG9mIHRoZSBub2RlcyBpbiB0aGUgTExODQotIGJlIHJlcXVpcmVkIHRvIHJvdXRlIHdp dGhpbiB0aGUgUEFOJ3Mgc2hvdWxkIGJlIG1hZGUgYSByZXF1aXJlbWVudC4gJm5ic3A7DQpBcyBE b24gc2FpZCwgdGhpcyB3b24ndCBvcHRpbWl6ZSBob3AgY291bnQgYW5kIGl0IHdvdWxkIGJlIHVu Zm9ydHVuYXRlDQppZiB0d28gc2lkZS1ieS1zaWRlIG5vZGVzIGhhdmUgdG8gY29tbXVuaWNhdGUg dGhydSBhIERBRyByb290IDcgaG9wcyBhd2F5DQotIGJ1dCBpdCBtYXkgYmUgYSByZWFsaXR5IG9m IHRoZXNlIG5ldHdvcmtzLiAmbmJzcDtBdCBhICZxdW90O3NvbHV0aW9uDQpsZXZlbCZxdW90Oywg aWYgeW91ciBQQU4gY2FuIGFmZm9yZCBtb3JlIERBRyByb290cyB0byBtaW5pbWl6ZSB0aGUgaG9w cywNCnlvdSBwdXQgdGhlbSBpbi4gJm5ic3A7SWYgeW91IGNhbid0LCB5b3UgZGVhbCB3aXRoIGxl c3MgdGhhbiBvcHRpbWl6ZWQNCnJvdXRpbmcuICZuYnNwO0J1dCBhdCBhIHByb3RvY29sIGxldmVs LCB3ZSBtYXkgaGF2ZSB0byBtYWtlIHNvbWUgc2FjcmlmaWNlcw0KLSBhcyBsb25nIGFzIHdlIGVu c3VyZSB0aGUgcHJvdG9jb2wgZG9lcyBlbnN1cmUgdGhhdCBQMlAgaXMgZW5hYmxlZCBpbg0Kc29t ZSBmb3JtLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1 ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPkplcmFsZC5QLk1hcnRvY2NpQGpjaS5jb208L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5Ubzo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtkLnN0 dXJla0BhdHQubmV0Jmd0OzwvZm9udD4NCjx0cj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkNjOjwvZm9udD4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+J1JPTEwgV0cnICZsdDtyb2xsQGlldGYub3JnJmd0Oywg cm9sbC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQg c2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTo8L2ZvbnQ+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA3LzMwLzIwMDkgMDY6NDQgUE08L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJz YW5zLXNlcmlmIj5TdWJqZWN0OjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFtSb2xsXSBNb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBwcm90b2NvbA0Kd29yazwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5yb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxo ciBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpIaSBEb24sPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpBcyBJIHJlYWQgdGhlIGRyYWZ0LCBSUEwgZG9l c24ndCBjdXJyZW50bHkgZ3VhcmFudGVlIHAycCBjb21tdW5pY2F0aW9uDQpyZWdhcmRsZXNzIG9m IGhvcCBjb3VudC4gJm5ic3A7T25seSBpZiBzb21lIG5vZGUgaGlnaGVyIGluIHRoZSBEQUcgZWxl Y3RzDQp0byBwcm92aWRlIGEgcGF0aCBiYWNrIGRvd24gdGhlIERBRyB0byB0aGUgZGVzdGluYXRp b24gdGhlbiB0aGVyZSBpcyBwMnANCnBhdGguICZuYnNwO1JQTCBkb2Vzbid0IG1hbmRhdGUgdGhp cyBldmVuIGZvciB0aGUgTEJSLiAmbmJzcDtIZW5jZSBhIHBhY2tldA0KY291bGQgc3F1aXJ0IGFs bCB0aGUgd2F5IHVwIHRvIHRoZSBMQlIgYW5kIHN0aWxsIGJlIGRyb3BwZWQgc2luY2UgdGhlIExC Ug0KaXRzZWxmIGhhcyBubyByb3V0ZSBkZWZpbmVkIHRvIHRoZSBkZXN0aW5hdGlvbi4gJm5ic3A7 WW91IG5lZWQgdG8ga2VlcA0KaW4gbWluZCB0aGF0IHRoZSBMTE4gZGV2aWNlcyBhcmUgcHJpbWFy aWx5IGEgYnVpbGRpbmcgY29udHJvbGxlcnMgdGhhdA0KJ21vb25saWdodCcgYXMgYSByb3V0ZXI7 IGl0J3Mgbm90IGEgcm91dGVyIHRoYXQgaGFwcGVucyB0byBhbHNvIGRvIGJ1aWxkaW5nDQpjb250 cm9sLiAmbmJzcDtUaGUgbGlrZWxpaG9vZCB0aGF0IGEgY29udHJvbGxlciBzaXR0aW5nIGhpZ2hl ciBpbiB0aGUgREFHDQpiZWluZyBhbHRydWlzdCBhbmQgZGVmaW5pbmcgcGF0aHdheXMgdG8gYWxs IHBvc3NpYmxlIHN1Yi1EQUcgZGV2aWNlcyBpcw0KbmlsLjwvZm9udD48Zm9udCBzaXplPTM+IDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQXMgZm9yIGhv cHMsIHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQgdG9vLiAmbmJzcDtOb3Qgc28gbXVjaCBmb3IgbGF0 ZW5jeS4NCiZuYnNwO1RoZSB0aW1lIGNvbnN0YW50IGZvciBtb3N0IGJ1aWxkaW5nIEhWQUMgJm5i c3A7Y29udHJvbCBsb29wcyBpcyBpbg0KbWludXRlcyBzbyBoYXZpbmcgYSBwYWNrZXQgYXJyaXZl IGF0IGl0cyBkZXN0aW5hdGlvbiBhIHRhZCBsYXRlIGlzIG5vdA0KdG9vIGNvbmNlcm5pbmcuIChO T1RFOiBGaXJlIGFuZCBsaWdodGluZyBhcHBsaWNhdGlvbnMgYXJlIG11Y2ggbW9yZSB0aW1lDQpj cml0aWNhbCkuICZuYnNwO1RoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHNvdXJjZSBkZXZpY2UsIHR5 cGljYWxseSBhIGJhdHRlcnkNCnBvd2VyZWQgc2Vuc29yIG11c3Qgc3RheSBhd2FrZSBhbmQgbGVh dmUgaXRzIHJlY2VpdmVyIGFjdGl2ZSB1bnRpbCB0aGUNCnBhY2tldCBoYXMgbWlncmF0ZWQgdG8g aXRzIGRlc3RpbmF0aW9uIGFuZCB0aGUgYXBwbGljYXRpb24gQUNLIGhhcyBiZWVuDQpyZWNlaXZl ZC4gJm5ic3A7VGhpcyB3aWxsIHJlZHVjZSBiYXR0ZXJ5IGxpZmUgYXQgbGVhc3QgMTB4LjwvZm9u dD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpBcyBmb3Igc2NhbGFiaWxpdHksIGEgdHlwaWNhbCBQQU4gaW4gYSBjb21tZXJjaWFs IGJ1aWxkaW5nIGlzIGxpbWl0ZWQgdG8NCmEgZmxvb3Igd2hpY2ggbWF5IHJlcXVpcmUgdXB3YXJk cyB0byAyNTAgTExOIG5vZGVzLiAmbmJzcDtTdXJlIHdlIGNvdWxkDQpoYXZlIGRlZmluZWQgdGhl IFBBTiB0byBiZSB0aGUgZW50aXJlIGNvbXBsZXggYW5kIHRoZW4gcmVxdWlyZSAxMEsgbm9kZXMN CmFzIGRvIHRoZSBvdGhlciByZXF1aXJlbWVudCBzcGVjcy4gJm5ic3A7RW1waXJpY2FsIHRlc3Rp bmcgaG93ZXZlciBkZXRlcm1pbmVkDQp0aGF0IG1hbmFnaW5nIDI1MCBub2RlcyBvbiBhIHNpbmds ZSB3aXJlbGVzcyBkb21haW4gd2FzIGRpZmZpY3VsdCBlbm91Z2gNCndpdGggcmVnYXJkIHRvIGNo YW5uZWwgbWFuYWdlbWVudCwgaW50ZXJmZXJlbmNlIGFuZCBob3AgY291bnQuICZuYnNwO0xpbWl0 aW5nDQpQQU4gc2l6ZSB0byBhIGZsb29yIHNlZW1zIHRvIGJlIHRoZSByaWdodCBiYWxhbmNlIHBv aW50IGZvciBjb21wbGV4aXR5DQphbmQgZmxleGliaWxpdHkuPC9mb250Pjxmb250IHNpemU9Mz4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpKZXJyeTwv Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzIlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtEb24gU3R1cmVrJnF1b3Q7DQombHQ7ZC5zdHVyZWtAYXR0 Lm5ldCZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4w Ny8zMC8yMDA5IDExOjEyIEFNPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjxicj4NCjx0 YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBh bGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSByZXNwb25k IHRvPGJyPg0KJmx0O2Quc3R1cmVrQGF0dC5uZXQmZ3Q7PC9mb250PjwvZGl2PjwvdGFibGU+DQo8 cD4NCjx0ZCB3aWR0aD02NyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTklPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTAlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mbHQ7SmVyYWxkLlAuTWFydG9jY2lAamNpLmNvbSZndDssDQomcXVvdDsnTWlz Y2hhIERvaGxlcicmcXVvdDsgJmx0O21pc2NoYS5kb2hsZXJAY3R0Yy5lcyZndDs8L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7J1JPTEwgV0cnJnF1b3Q7ICZsdDty b2xsQGlldGYub3JnJmd0OywNCiZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxm b250IHNpemU9Mz4gPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW1JvbGxdIE1vdmluZyBmb3J3 YXJkIHdpdGggdGhlIHByb3RvY29sDQp3b3JrPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+ DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBKZXJyeSw8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCkkgdGhpbmsgUlBMIGRvZXMgc3VwcG9ydCBQMlAgYnV0 IGRvZXMgbm90IG9wdGltaXplIHRoZSBudW1iZXIgb2YgaG9wcy4NCkkgdGhpbmsgdGhhdCBpcyB0 aGUgY2VudHJhbCBpc3N1ZSB5b3UgYW5kIE11a3VsIGFyZSBicmluZ2luZyB1cC48L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli cmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGRvIHF1ZXN0aW9uIHdoZXRoZXIg b3B0aW1pemluZyBob3BzIGlzIHJlYWxseSBuZWNlc3NhcnkuICZuYnNwO0kgdGhpbmsNCm1vc3Qg YXBwbGljYXRpb25zIChpbmNsdWRpbmcgYnVpbGRpbmcgY29udHJvbHMpIGNhbiB0YWtlIGFkdmFu dGFnZSBvZiBhDQpzb2x1dGlvbiB0aGF0IHdlbGwgc3VwcG9ydHMgTVAyUCBhbmQgUDJNUCB3aXRo IGV4dGVuc2lvbnMgdG8gcHJvdmlkZSBQMlANCmNhcGFiaWxpdHkgKGFkbWl0dGVkbHkgbm90IG9w dGltaXplZCBmb3IgaG9wIGNvdW50L2Nvc3QgYnV0IHRoZW4gYWxzbyB3aXRob3V0DQpuZWFybHkg dGhlIG92ZXJoZWFkIG9mIHBhY2tldCBmbG9vZGluZyBvciBzdG9yYWdlIG9mIHN0YXRlIGluZm9y bWF0aW9uDQp0aGF0IG9wdGltaXplZCBQMlAgc29sdXRpb25zIGltcG9zZSkuICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJD YWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSSByZWFsbHkgZG9u4oCZdCBz ZWUgdGhhdCB0cnlpbmcgKG9uY2UgYWdhaW4gYXMgdGhleSBoYXZlIGluIE1BTkVUIGZvciBzb21l DQp0aW1lKSB0byBmaW5kIGEgc2luZ2xlIHByb3RvY29sIHRoYXQgZWZmaWNpZW50bHkgaW1wbGVt ZW50cyBQMlAgYW5kIHNjYWxlcw0Kd2hpbGUgYWRkcmVzc2luZyB0aGUgdmFyaW91cyBkYXRhIHRy YW5zbWlzc2lvbiBwYXR0ZXJucyB3aWxsIHJlc3VsdCBpbg0KYW55dGhpbmcgb3RoZXIgdGhhbiB0 aGUgc2FtZSBzZXQgb2Ygc29sdXRpb25zIHdlIGhhdmUgdG9kYXkgKGRpc3RhbmNlIHZlY3Rvcg0K d2l0aCBmbG9vZGluZywgbGluayBzdGF0ZSByb3V0aW5nIGFuZCBpdHMgZGVyaXZhdGl2ZXMsIHNv dXJjZSByb3V0aW5nIGFuZA0KaXRzIGRlcml2YXRpdmVzKS4gJm5ic3A7PC9mb250Pjxmb250IHNp emU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxi cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpEb248L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9u dD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZh Y2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gcm9sbC1ib3VuY2VzQGll dGYub3JnIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZv bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K ZXJhbGQuUC5NYXJ0b2NjaUBqY2kuY29tPGI+PGJyPg0KU2VudDo8L2I+IFRodXJzZGF5LCBKdWx5 IDMwLCAyMDA5IDg6NTggQU08Yj48YnI+DQpUbzo8L2I+IE1pc2NoYSBEb2hsZXI8Yj48YnI+DQpD Yzo8L2I+IFJPTEwgV0c7IHJvbGwtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9i PiBSZTogW1JvbGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcms8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NCjxicj4NCjxicj4NCkhpIE1pc2NoYSw8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCjxicj4NCk5lYXJseSBhbGwgY29tbXVuaWNhdGlvbiBpbiBhIGNvbW1lcmNpYWwgYnVp bGRpbmcgZmFjaWxpdHkgbWFuYWdlbWVudCBzeXN0ZW0NCmlzIHBvaW50IHRvIHBvaW50LiAmbmJz cDtJJ20gc3VycHJpc2VkIHRoZSBvdGhlciB0aHJlZSByZXF1aXJlbWVudHMgZG9uJ3QNCmFsc28g aGF2ZSBhIHN0cm9uZyBwMnAgcmVxdWlyZW1lbnQuICZuYnNwO0JhY2sgaW4gdGhlIGVhcmx5IDgw J3MgcHJpb3INCnRvIHByb2Nlc3NvciBiYXNlZCBzZW5zb3JzLCB3ZSBkZXBsb3llZCAnZHVtYiBz ZW5zb3JzJyB0aGF0IHdvdWxkIHNpbXBseQ0KdXBsb2FkIHRoZWlyIGN1cnJlbnQgZW52aXJvbm1l bnRhbCBpbmZvcm1hdGlvbiB0byBhIGNlbnRyYWxpemVkIG1pbmljb21wdXRlci4NCiZuYnNwO1Ro aXMgY2VudHJhbGl6ZWQgbW9kZWwgd2FzIG5vdCBzY2FsYWJsZSBub3IgZmF1bHQgdG9sZXJhbnQu ICZuYnNwO1RoYXQNCmlzIGlmIHRoZSBtaW5pY29tcHV0ZXIgJ2JsZXcgYSBnYXNrZXQnLCB0aGUg ZW50aXJlIGJ1aWxkaW5nIHdlbnQgb3V0IG9mDQpjb250cm9sLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KPGJyPg0KQXMgc29vbiBhcyBpdCB3YXMgZWNvbm9taWNhbGx5IHZpYWJsZSwgd2UgZGVj ZW50cmFsaXplZCBjb250cm9sIGJ5IG1vdmluZw0KaXQgZG93biBpbnRvIHRoZSByb29tcy4gJm5i c3A7Tm93IGVhY2ggcm9vbSB3YXMgY29udHJvbGxlZCBpbmRlcGVuZGVudGx5DQp3aXRoIGFuIGFy cmF5IG9mIHJvb20gc2Vuc29ycyBhbmQgcm9vbSBjb250cm9sbGVycy4gJm5ic3A7Tm93IGlmIGEg Y29udHJvbGxlcg0KZmFpbGVkLCBvbmx5IHRoZSByb29tIG1pZ2h0IGxvc2UgY29udHJvbCwgbm90 IHRoZSBlbnRpcmUgY29tcGxleC4gJm5ic3A7VGhlDQpyb29tIGNvbnRyb2xsZXJzIHdlcmUgdGhl biBmdXJ0aGVyIGNvbnRyb2xsZWQgYnkgaGlnaGVyIGxldmVsIGNvbnRyb2xsZXJzLg0KJm5ic3A7 VGhpcyBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgaGFzIGJlZW4gaW4gcGxhY2UgZm9yIDI1IHll YXJzIGFuZA0KaXMgdGhlIG1haW5zdGF5IG9mIGJ1aWxkaW5nIGNvbnRyb2wuICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCk15IHBvaW50IGlzIHRoYXQgaXMgdGhlIENvbW1l cmNpYWwgTWFya2V0IHRoZSBMTE4gaXMgbm90IGp1c3QgYSBwYXRoIGZvcg0KbW92aW5nIGRhdGEg bm9ydGJvdW5kLiAmbmJzcDtNb3N0IG9mIHRoZSBwYWNrZXRzIHNlbnQgb24gdGhlIExMTiBhcmUg ZGVzdGluZWQNCnRvIG90aGVyIG5vZGVzIG9uIHRoZSBMTE4uICZuYnNwO1RoZXkgYWxsIHJlcXVp cmUgYXBwbGljYXRpb24gQUNLcy4gJm5ic3A7QWJvdXQNCjIwJSBvZiB0aGUgcGFja2V0cyBhcmUg ZGVzdGluZWQgdG8gdGhlIExCUiBhbmQgb253YXJkcy4gJm5ic3A7VGhlc2UgYXJlDQpldmVudCBw YWNrZXRzIGJlaW5nIHNlbnQgdG8gdGhlIGhpZ2hlciBsYXllcnMgZm9yIGZ1cnRoZXIgYW5hbHlz aXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KSWYgd2UgZG9uJ3Qgc3VwcG9ydCBh IHJvYnVzdCBwMnAgcHJvdG9jb2wgb3B0aW9uIGluIFJPTEwsIHdlIHdpbGwga25vY2sNCm91dCB0 aGUgQnVpbGRpbmcgTWFya2V0IGluIGl0cyBlbnRpcmV0eSB3aGljaCBtZWFucyBhdCBiZXN0IHlv dSB3aWxsIG9ubHkNCnNvbHZlIDc1JSBvZiB0aGUgbmVlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCjxicj4NCkplcnJ5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDQlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+ TWlzY2hhIERvaGxlciAmbHQ7bWlzY2hhLmRvaGxlckBjdHRjLmVzJmd0OzwvYj4NCjxicj4NClNl bnQgYnk6IHJvbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MDcv MjkvMjAwOSAwNDoxOCBQTTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4NCjwvZm9udD4NCjx0ZCB3aWR0aD01NSU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTE0JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD04NSU+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj5KUCBWYXNzZXVyICZsdDtqdmFzc2V1ckBjaXNjby5jb20mZ3Q7PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJBcmlh bCI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5ST0xMIFdH ICZsdDtyb2xsQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SZTogW1JvbGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhl IHByb3RvY29sDQp3b3JrPC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PHA+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxwPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0KSlAsIGFsbCw8YnI+DQo8YnI+DQpXZSBz aG91bGQgdXNlIHRoaXMgZWFybHkgZGVzaWduIHN0YWdlIHRvIGNvbWUgdXAgd2l0aCBvbmUgc29s dXRpb24gLSBvbmUNCjxicj4NCnNvbHV0aW9uIHdoaWNoIGlzIG5vdCBuZWNlc3NhcmlseSBvcHRp bXVtIGZvciBhbGwgY2FzZXMgYnV0IGZvciB0aGUgPGJyPg0KKGUuZy4pIDk1JSBxdWFudGlsZS4g VGhlIFBIWSBndXlzIGxlYXJuZWQgdG8gbGl2ZSB3aXRoIHN1Y2ggYW4gYXBwcm9hY2guDQo8YnI+ DQpUaGUgTUFDIGZvbGtzIGFyZSBnZXR0aW5nIHRoZXJlIGFuZCB3ZSBzaG91bGQgdGFrZSBvdXIg Y2hhbmNlIG5vdy4gOTUlDQo8YnI+DQptZWFucyBjbGVhcmx5IHRvIGNvbmNlbnRyYXRlIG9uIHRo ZSBjb3JlIGlzc3Vlcywgb2Ygd2hpY2ggbG9vcCA8YnI+DQpkZXRlY3Rpb24vYXZvaWRhbmNlLCBw MnAgYW5kIHNlY3VyaXR5IGFyZSBzb21laG93IHN0aWxsIG9wZW4uPGJyPg0KPGJyPg0KSSBkbyB1 bmRlcnN0YW5kIHRoZSBjb25jZXB0IG9mIGxvb3BzIGFyaXNpbmcuIEkgaGF2ZSBkb3VidHMgdGhh dCB3aXRoIDxicj4NCnRoZSBkeW5hbWljcyBvZiB0eXBpY2FsIFJPTEwgbmV0d29ya3MsIHRoZXNl IHdpbGwgZ2l2ZSB1cyBoZWFkYWNoZXMgPGJyPg0Kd2l0aGluIHRoaXMgOTUlIGFwcGxpY2F0aW9u IHF1YW50aWxlLiBJIGhhdmUgcmVhZCB0b25zIG9mIHBhcGVycyA8YnI+DQpwcm9kdWNlZCBpbiB0 aGUgbGFzdCBkZWNhZGUgb24gcm91dGluZyBpbiBST0xMLXR5cGUgbmV0d29ya3MuIExvb3AgPGJy Pg0KZGV0ZWN0aW9uIGFuZCBhdm9pZGFuY2Ugd2FzIGNsZWFybHkgbm90IHNvbWV0aGluZyBwZW9w bGUgKGluY2x1ZGluZyA8YnI+DQp0aG9zZSBkb2luZyBwcmFjdGljYWwgcm9sbG91dHMgYW5kIHJ1 bm5pbmcgdGhlaXIgY29tcGFuaWVzIHRvZGF5KSB3ZXJlDQo8YnI+DQp3b3JyaWVkIGFib3V0IHRv byBtdWNoLiBVbmxlc3Mgc29tZWJvZHkgcHJvdmlkZXMgbWUgd2l0aCBhIGNvbnZpbmNpbmcgPGJy Pg0Kc3R1ZHksIEkgcHJvcG9zZSB0byBtZXJlbHkgYWRvcHQgc29tZSBzaW1wbGUgYW5kIHBvc3Np Ymx5IHN1Yi1vcHRpbXVtIDxicj4NCmhldXJpc3RpY3MgYW5kIHRoZW4gZm9yZ2V0IGFib3V0IGl0 Ljxicj4NCjxicj4NClAyUCBzZWVtcyB0byB3b3JyeSBzb21lIG9mIHVzIChzb3JyeSwgSmVycnks IGZvciBoYXZpbmcgZm9yZ290dGVuIGFib3V0DQo8YnI+DQp0aGUgcDJwIHBhcmFncmFwaCkuIEhv d2V2ZXIsIGFnYWluLCBhcmUgd2UgdGFsa2luZyBhYm91dCB0aGUgOTUlIDxicj4NCnF1YW50aWxl IGhlcmU/IEZ1cnRoZXJtb3JlLCBob3cgbXVjaCBwMnAgZXhhY3RseSBhcmUgeW91IHRhbGtpbmcg YWJvdXQ/DQo8YnI+DQpBbnkgbm9kZSB0cnVseSB0byBhbnkgbm9kZT8gQXJlIHdlIGJhY2sgdG8g cHVyZSBhZCBob2MgdGhlbj8gSSBndWVzcyBpZg0KPGJyPg0KSUVURiBjb3VsZG4ndCBwcm92aWRl IHVzIHdpdGggYSBtYWdpYyB1bHRyYSBsb3cgcG93ZXIgc29sdXRpb24gZm9yIGFkIDxicj4NCmhv YyBuZXR3b3JrcyBpbiBwYXN0IHllYXJzLCB0aGVuIGNoYW5jZXMgYXJlIHNsaW0gdGhhdCB0aGlz IHdpbGwgd29yayA8YnI+DQpvdXQgbm93LiBVbmxlc3Mgc29tZWJvZHkgcHJvdmlkZXMgbWUgd2l0 aCBhIGNvbnZpbmNpbmcgc3R1ZHkgdGhhdCA8YnI+DQphZG9wdGluZyBhIGdlbmVyYWwgcDJwIFJP TEwgcHJvdG9jb2wgd2lsbCBub3QgamVvcGFyZGl6ZSB0aGUgZWZmaWNpZW5jeQ0KPGJyPg0Kb2Yg dGhlIDk1JSBxdWFudGlsZSBhcHBsaWNhdGlvbnMsIEkgcHJvcG9zZSB0byBhZG9wdCBzb21lIHNp bXBsZSBhbmQgPGJyPg0KcG9zc2libHkgc3ViLW9wdGltdW0gaGV1cmlzdGljcyBhbmQgdGhlbiBm b3JnZXQgYWJvdXQgaXQuPGJyPg0KPGJyPg0KU2VjdXJpdHkgaXMgYW4gaW1wb3J0YW50IGlzc3Vl Ljxicj4NCjxicj4NCk5vdyB0aGF0IHdlIGFyZSBhdCBpdCwgSSBzYW1wbGVkIHF1aXRlIGEgbGFy Z2UgbnVtYmVyIG9mIGNvbXBhbmllcyBhdCBhbg0KPGJyPg0KTTJNIGV2ZW50IGluIFBhcmlzIGEg ZmV3IG1vbnRocyBhZ28gb3JnYW5pemVkIGJ5IE9yYW5nZSB3aGVyZSB3ZSBtZXQgPGJyPg0Kd2l0 aCBKUCBhbmQgb3RoZXJzLiBUaGUgbGFyZ2UgbWFqb3JpdHkgb2YgY29tcGFuaWVzIHByZXNlbnQg dGhlcmUgPGJyPg0KZXhwbGljaXRseSB0b2xkIG1lIHRoYXQgLSBmb3IgYSB2ZXJ5IHZhcnlpbmcg c2V0IG9mIHJlYXNvbnMgLSB0aGV5IHdvdWxkDQo8YnI+DQpuZXZlciBsZXQgSVAgcnVuIG92ZXIg dGhlaXIgUk9MTC10eXBlIG5ldHdvcmtzLiBUaGUgc2hlZXIgbWFqb3JpdHkgZGlkDQo8YnI+DQpz dXByaXNlIG1lLiBXZSBzdGlsbCBoYXZlIGEgbG90IG9mIHdvcmsgYWhlYWQuPGJyPg0KPGJyPg0K SSBhbSBpbiBmYXZvdXIgb2YgYWRvcHRpbmcgZHJhZnQtZHQtcm9sbC1ycGwtMDEgYXMgYSBXRyBk b2N1bWVudC48YnI+DQo8YnI+DQpNaXNjaGEuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KSlAgVmFzc2V1ciB3cm90ZTo8YnI+DQomZ3Q7IERlYXIgV0csPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEZpcnN0IG9mIGFsbCwgdGhhbmtzIGZvciBhbGwgdGhlIHRpbWUgYW5kIGVu ZXJneSB5b3UgYWxsIGhhdmUgZGV2b3RlZA0KPGJyPg0KJmd0OyBkdXJpbmcgdGhlIHBhc3QgZmV3 IHdlZWtzIG9uIHRoZSBwcm90b2NvbCB3b3JrLiBUaGVyZSB3YXMgZXhjZWxsZW50DQo8YnI+DQom Z3Q7IGZvbGxvd3VwIGRpc2N1c3Npb24gYXQgdGhlIHBoeXNpY2FsIFdHIG1lZXRpbmcuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRvIHRoZSBxdWVzdGlvbiAmcXVvdDtEbyB5b3UgdGhpbmsgdGhhdCBS UEwgcHJvdmlkZXMgYW4gYWRlcXVhdGUgZm91bmRhdGlvbg0KPGJyPg0KJmd0OyBmb3IgdGhlIFJP TEwgcm91dGluZyBwcm90b2NvbCB3b3JrJnF1b3Q7LCB0aGVyZSB3YXMgY2xlYXJseSBhIGdvb2QN CmNvbnNlbnN1cyA8YnI+DQomZ3Q7IGluIHRoZSBXRyBtZWV0aW5nLiBJdCB3YXMgYWxzbyByZWNv Z25pemVkIHRoZXJlIGFyZSBzdGlsbCBzZXZlcmFsDQpvcGVuIDxicj4NCiZndDsgaXNzdWVzIGZv ciB3aGljaCB3ZSBXSUxMIG5lZWQgaGVscCBmcm9tIG1hbnkgV0cgY29udHJpYnV0b3JzLCBpbmNs dWRpbmcNCjxicj4NCiZndDsgdGhlIGF1dGhvcnMgb2Ygb3RoZXIgZG9jdW1lbnRzLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBDb3VsZCB5b3UgcGxlYXNlIGNvbmZpcm0gKG9yIG5vdCkgdGhlIGFkb3B0 aW9uIG9mIGRyYWZ0LWR0LXJvbGwtcnBsLTAxDQo8YnI+DQomZ3Q7IGFzIGEgV0cgZG9jdW1lbnQg Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVuIHdlIHdpbGwgb2YgY291cnNlIG1vdmUgdG8gdGhl IG5leHQgc3RlcC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgPGJyPg0K Jmd0OyBKUCBhbmQgRGF2aWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgUm9sbCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFJvbGxAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48YSBo cmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbDwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwg bWFpbGluZyBsaXN0PGJyPg0KUm9sbEBpZXRmLm9yZzxicj4NCjwvZm9udD48YSBocmVmPWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRo aXMgZW1haWwgaGFzIGJlZW4gc3BhbSBhbmQgdmlydXMgY2hlY2tlZCBieSBFbHN0ZXIgSVQgU2Vy dmljZXMuPC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NClJvbGxAaWV0 Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4N CjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 005F08CBC1257603_=-- From pthubert@cisco.com Thu Jul 30 10:30:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C713A6C96; Thu, 30 Jul 2009 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.338 X-Spam-Level: X-Spam-Status: No, score=-9.338 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7yIddRKFmmgL; Thu, 30 Jul 2009 10:30:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7483C3A6B23; Thu, 30 Jul 2009 10:30:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAALN1cUqQ/uCLe2dsb2JhbACCJy6XNxYkBqEdiCeQLgWEEQ X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="46161276" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 17:30:22 +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 n6UHUMla014565; Thu, 30 Jul 2009 19:30:22 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UHUMMv000036; Thu, 30 Jul 2009 17:30:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 19:30:22 +0200 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_01CA113B.6AA25D24" Date: Thu, 30 Jul 2009 19:29:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> In-Reply-To: <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MUSTing P2P states [was RE: [Roll] Moving forward with the protocol work] Thread-Index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJgAADviOA= References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 30 Jul 2009 17:30:22.0765 (UTC) FILETIME=[6AE585D0:01CA113B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38691; t=1248975022; x=1249839022; 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:=20MUSTing=20P2P=20states=20[was=20RE=3A=20[Roll]= 20Moving=20forward=20with=20the=20protocol=20work] |Sender:=20; bh=J/ijmmwkp3L2E8gTtAK6W5rBzKQJGory1k3mn02MLJA=; b=sMl8c/W/uHruF2iORibGtdXNDVU87Hn/+scuuknUuawYkETRylGnbvtrpm A9f36AXttMi5ei70Pm3OEazDevAYsPTFF8SGaViL6GnzNnL8POuBVyDdtfkA lnbAN566Sr; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: [Roll] MUSTing P2P states [was RE: Moving forward with the protocol work] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:30:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA113B.6AA25D24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don: =20 You're correct. If the DAO states are enabled everywhere, the first common parent will route down to the destination. =20 But the doc cannot MUST keeping states in all nodes at the protocol level because there are some use cases where that makes no sense. There might even be a case where no data whatsoever is unicast to the devices, in which case even storing source route paths at the root would be ridiculous. An example of that would be environmental monitoring using widespread cheap sensors.=20 =20 It seems to me that this discussion is caused by a confusion between what belongs to protocol and what belongs to product and deployment. The protocol gives you tools, and then you have to use them intelligently in the products you build. =20 Another confusion I've seen here is that between the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is NOT a ballot. This is just to create a foundation for the WG to work on. So obviously the doc does not have everything ironed out. The question is rather whether the doc is a good foundation for that work at it appears that many people agree on that. =20 Cheers, =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: jeudi 30 juillet 2009 19:00 To: Jerald.P.Martocci@jci.com Cc: 'ROLL WG'; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work =20 Hi Jerry, =20 I may have misread the RPL proposal. I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases. I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first). I thought in all cases P2P was supported (just without a mechanism to minimize the hop count). =20 Could someone from the DT comment on the assumptions above? =20 Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts? If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network? I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL..... Don =20 =20 From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]=20 Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work =20 Hi Don,=20 As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil.=20 As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility.=20 Jerry=20 "Don Sturek" =20 07/30/2009 11:12 AM=20 Please respond to To , "'Mischa Dohler'" =20 cc "'ROLL WG'" , =20 Subject RE: [Roll] Moving forward with the protocol work =20 =09 Hi Jerry,=20 =20 I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up.=20 =20 I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). =20 =20 I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). =20 =20 Don=20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work=20 =20 Hi Mischa,=20 Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control.=20 As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. =20 My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis.=20 If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.=20 Jerry=20 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 =20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =20 =20 =09 JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers=20 produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95%=20 quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus=20 > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 ------_=_NextPart_001_01CA113B.6AA25D24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don:

 

You’re correct. If the DAO states are enabled = everywhere, the first common parent will route down to the = destination.

 

But the doc cannot MUST keeping states in all nodes at = the protocol level because there are some use cases where that makes no = sense.

There might even be a case where no data whatsoever is = unicast to the devices, in which case even storing source route paths at the = root would be ridiculous. An example of that would be environmental monitoring = using widespread cheap sensors.

 

It seems to me that this discussion is caused by a = confusion between what belongs to protocol and what belongs to product and deployment. The protocol gives you tools, and then you have to use them intelligently in = the products you build.

 

Another confusion I’ve seen here is that between = the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is = NOT a ballot. This is just to create a foundation for the WG to work on. So = obviously the doc does not have everything ironed out. The question is rather = whether the doc is a good foundation for that work at it appears that many people = agree on that.

 

Cheers,

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Don Sturek
Sent: jeudi 30 juillet 2009 19:00
To: Jerald.P.Martocci@jci.com
Cc: 'ROLL WG'; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol = work

 

Hi Jerry,

 

I may have misread the RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back = down to a device in the DAG and that feature enabled P2P in all cases.  I = thought also the Destination Address notifications for devices with lower = depth/rank could be used by devices within a DAG to more efficiently reroute P2P = traffic within the DAG (not optimally, just “more efficiently than sending = the packet all the way to the DAG root first).  I thought in all cases = P2P was supported (just without a mechanism to minimize the hop = count).

 

Could someone from the DT comment on the assumptions = above?

 

Did I understand that optimizing P2P for building = controls is mainly about minimizing hop counts?   If a building controls = solution could choose between optimizing hop count for P2P and flooding the = network to find the optimal P2P hop count, would it choose to flood the = network?  I think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found so = attractive about RPL…..


Don

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] Moving forward with the protocol = work

 


Hi = Don,

As I = read the draft, RPL doesn't currently guarantee p2p communication regardless of = hop count.  Only if some node higher in the DAG elects to provide a = path back down the DAG to the destination then there is p2p path.  RPL = doesn't mandate this even for the LBR.  Hence a packet could squirt all the = way up to the LBR and still be dropped since the LBR itself has no route = defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not = a router that happens to also do building control.  The likelihood = that a controller sitting higher in the DAG being altruist and defining = pathways to all possible sub-DAG devices is nil.

As for = hops, this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes so = having a packet arrive at its destination a tad late is not too concerning. = (NOTE: Fire and lighting applications are much more time critical).  The = problem is that the source device, typically a battery powered sensor must stay = awake and leave its receiver active until the packet has migrated to its = destination and the application ACK has been received.  This will reduce battery = life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes.  Sure we could have defined = the PAN to be the entire complex and then require 10K nodes as do the other = requirement specs.  Empirical testing however determined that managing 250 = nodes on a single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a floor seems to = be the right balance point for complexity and flexibility.

Jerry =

"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> =

cc=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

Subject=

RE: [Roll] Moving forward with the protocol work

 




Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think = most applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also without = nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will result in = anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work =
 


Hi Mischa,

Nearly all communication in a commercial building facility management = system is point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant.  That is if = the minicomputer 'blew a gasket', the entire building went out of = control.

As soon as it was economically viable, we decentralized control by = moving it down into the rooms.  Now each room was controlled independently = with an array of room sensors and room controllers.  Now if a controller = failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and = is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are destined = to other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will only solve = 75% of the need.


Jerry

Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

 

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work


 

 





JP, all,

We should use this early design stage to come up with one solution - one =
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. =
The MAC folks are getting there and we should take our chance now. 95% =
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with =
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were =
worried about too much. Unless somebody provides me with a convincing =
study, I propose to merely adopt some simple and possibly sub-optimum =
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about =
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about? =
Any node truly to any node? Are we back to pure ad hoc then? I guess if =
IETF couldn't provide us with a magic ultra low power solution for ad =
hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency =
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an =
M2M event in Paris a few months ago organized by Orange where we met =
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would =
never let IP run over their ROLL-type networks. The sheer majority did =
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was excellent =
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several = open
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CA113B.6AA25D24-- From jvasseur@cisco.com Thu Jul 30 10:42:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA74928C304; Thu, 30 Jul 2009 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.509 X-Spam-Level: X-Spam-Status: No, score=-9.509 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kyyPrxkzjRvN; Thu, 30 Jul 2009 10:42: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 10ABC3A6969; Thu, 30 Jul 2009 10:42:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAABV4cUqQ/uCLe2dsb2JhbACCKSwhlxYWJAahGognkC8FhBE X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="46161822" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 17:42:44 +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 n6UHgix1016551; Thu, 30 Jul 2009 19:42:44 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UHgi5P002065; Thu, 30 Jul 2009 17:42:44 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 19:42:44 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 19:42:42 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-21-85622255 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 19:42:41 +0200 References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jul 2009 17:42:43.0138 (UTC) FILETIME=[24317A20:01CA113D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=56241; t=1248975764; x=1249839764; 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[Roll]=20MUSTing=20P2P=20states=20[was= 20RE=3A=20Moving=20forward=20with=20the=20protocol=20work] |Sender:=20; bh=/sx//aYDA/yboZTfXKqir1DSRLq2kV+6jOZ3S2lvwyE=; b=jAzjmfJtxWx6H7g3JF5HfK9tjf8X2++4s7YyfdPM62sYmnz1a+jDkmIlpB D83reI5uiBMBYuV1fR5Z3qPFxEJ2u1Fn9tGwqQh3Is/p0sRs2VXnaZyrzHBf dHW8fUKfLv; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] MUSTing P2P states [was RE: Moving forward with the protocol work] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:42:49 -0000 --Apple-Mail-21-85622255 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 30, 2009, at 7:29 PM, Pascal Thubert (pthubert) wrote: > Hi Don: > > You=92re correct. If the DAO states are enabled everywhere, the first =20= > common parent will route down to the destination. > > But the doc cannot MUST keeping states in all nodes at the protocol =20= > level because there are some use cases where that makes no sense. this is where smart route aggregation techniques will help. > There might even be a case where no data whatsoever is unicast to =20 > the devices, in which case even storing source route paths at the =20 > root would be ridiculous. An example of that would be environmental =20= > monitoring using widespread cheap sensors. > > It seems to me that this discussion is caused by a confusion between =20= > what belongs to protocol and what belongs to product and deployment. =20= > The protocol gives you tools, and then you have to use them =20 > intelligently in the products you build. > > Another confusion I=92ve seen here is that between the rough consensus = =20 > to get WG Doc and a ballot at IEEE or others. The call here is NOT a =20= > ballot. This is just to create a foundation for the WG to work on. =20 > So obviously the doc does not have everything ironed out. The =20 > question is rather whether the doc is a good foundation for that =20 > work at it appears that many people agree on that. > > Cheers, > > Pascal > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Don Sturek > Sent: jeudi 30 juillet 2009 19:00 > To: Jerald.P.Martocci@jci.com > Cc: 'ROLL WG'; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > Hi Jerry, > > I may have misread the RPL proposal. I thought the Destination =20 > Address notifications allowed the DAG root to route back down to a =20 > device in the DAG and that feature enabled P2P in all cases. I =20 > thought also the Destination Address notifications for devices with =20= > lower depth/rank could be used by devices within a DAG to more =20 > efficiently reroute P2P traffic within the DAG (not optimally, just =20= > =93more efficiently than sending the packet all the way to the DAG =20 > root first). I thought in all cases P2P was supported (just without =20= > a mechanism to minimize the hop count). > > Could someone from the DT comment on the assumptions above? > > Did I understand that optimizing P2P for building controls is mainly =20= > about minimizing hop counts? If a building controls solution could =20= > choose between optimizing hop count for P2P and flooding the network =20= > to find the optimal P2P hop count, would it choose to flood the =20 > network? I think it is the lack of network flooding to establish =20 > routes and the minimal storage of route state information along the =20= > route that I found so attractive about RPL=85.. > > Don > > > From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] > Sent: Thursday, July 30, 2009 9:44 AM > To: d.sturek@att.net > Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org > Subject: RE: [Roll] Moving forward with the protocol work > > > Hi Don, > > As I read the draft, RPL doesn't currently guarantee p2p =20 > communication regardless of hop count. Only if some node higher in =20= > the DAG elects to provide a path back down the DAG to the =20 > destination then there is p2p path. RPL doesn't mandate this even =20 > for the LBR. Hence a packet could squirt all the way up to the LBR =20= > and still be dropped since the LBR itself has no route defined to =20 > the destination. You need to keep in mind that the LLN devices are =20= > primarily a building controllers that 'moonlight' as a router; it's =20= > not a router that happens to also do building control. The =20 > likelihood that a controller sitting higher in the DAG being =20 > altruist and defining pathways to all possible sub-DAG devices is nil. > > As for hops, this is very important too. Not so much for latency. =20= > The time constant for most building HVAC control loops is in =20 > minutes so having a packet arrive at its destination a tad late is =20 > not too concerning. (NOTE: Fire and lighting applications are much =20 > more time critical). The problem is that the source device, =20 > typically a battery powered sensor must stay awake and leave its =20 > receiver active until the packet has migrated to its destination and =20= > the application ACK has been received. This will reduce battery =20 > life at least 10x. > > As for scalability, a typical PAN in a commercial building is =20 > limited to a floor which may require upwards to 250 LLN nodes. Sure =20= > we could have defined the PAN to be the entire complex and then =20 > require 10K nodes as do the other requirement specs. Empirical =20 > testing however determined that managing 250 nodes on a single =20 > wireless domain was difficult enough with regard to channel =20 > management, interference and hop count. Limiting PAN size to a =20 > floor seems to be the right balance point for complexity and =20 > flexibility. > > Jerry > > > "Don Sturek" > 07/30/2009 11:12 AM > > Please respond to > > To > , "'Mischa Dohler'" > cc > "'ROLL WG'" , > Subject > RE: [Roll] Moving forward with the protocol work > > > > > Hi Jerry, > > I think RPL does support P2P but does not optimize the number of =20 > hops. I think that is the central issue you and Mukul are bringing up. > > I do question whether optimizing hops is really necessary. I think =20= > most applications (including building controls) can take advantage =20 > of a solution that well supports MP2P and P2MP with extensions to =20 > provide P2P capability (admittedly not optimized for hop count/cost =20= > but then also without nearly the overhead of packet flooding or =20 > storage of state information that optimized P2P solutions impose). > > I really don=92t see that trying (once again as they have in MANET for = =20 > some time) to find a single protocol that efficiently implements P2P =20= > and scales while addressing the various data transmission patterns =20 > will result in anything other than the same set of solutions we have =20= > today (distance vector with flooding, link state routing and its =20 > derivatives, source routing and its derivatives). > > Don > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Jerald.P.Martocci@jci.com > Sent: Thursday, July 30, 2009 8:58 AM > To: Mischa Dohler > Cc: ROLL WG; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > > > Hi Mischa, > > Nearly all communication in a commercial building facility =20 > management system is point to point. I'm surprised the other three =20= > requirements don't also have a strong p2p requirement. Back in the =20= > early 80's prior to processor based sensors, we deployed 'dumb =20 > sensors' that would simply upload their current environmental =20 > information to a centralized minicomputer. This centralized model =20 > was not scalable nor fault tolerant. That is if the minicomputer =20 > 'blew a gasket', the entire building went out of control. > > As soon as it was economically viable, we decentralized control by =20 > moving it down into the rooms. Now each room was controlled =20 > independently with an array of room sensors and room controllers. =20 > Now if a controller failed, only the room might lose control, not =20 > the entire complex. The room controllers were then further =20 > controlled by higher level controllers. This distributed =20 > architecture has been in place for 25 years and is the mainstay of =20 > building control. > > My point is that is the Commercial Market the LLN is not just a path =20= > for moving data nortbound. Most of the packets sent on the LLN are =20= > destined to other nodes on the LLN. They all require application =20 > ACKs. About 20% of the packets are destined to the LBR and =20 > onwards. These are event packets being sent to the higher layers =20 > for further analysis. > > If we don't support a robust p2p protocol option in ROLL, we will =20 > knock out the Building Market in its entirety which means at best =20 > you will only solve 75% of the need. > > > Jerry > > Mischa Dohler > Sent by: roll-bounces@ietf.org > 07/29/2009 04:18 PM > > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] Moving forward with the protocol work > > > > > > > > > JP, all, > > We should use this early design stage to come up with one solution - =20= > one > solution which is not necessarily optimum for all cases but for the > (e.g.) 95% quantile. The PHY guys learned to live with such an =20 > approach. > The MAC folks are getting there and we should take our chance now. 95% > means clearly to concentrate on the core issues, of which loop > detection/avoidance, p2p and security are somehow still open. > > I do understand the concept of loops arising. I have doubts that with > the dynamics of typical ROLL networks, these will give us headaches > within this 95% application quantile. I have read tons of papers > produced in the last decade on routing in ROLL-type networks. Loop > detection and avoidance was clearly not something people (including > those doing practical rollouts and running their companies today) were > worried about too much. Unless somebody provides me with a convincing > study, I propose to merely adopt some simple and possibly sub-optimum > heuristics and then forget about it. > > P2P seems to worry some of us (sorry, Jerry, for having forgotten =20 > about > the p2p paragraph). However, again, are we talking about the 95% > quantile here? Furthermore, how much p2p exactly are you talking =20 > about? > Any node truly to any node? Are we back to pure ad hoc then? I guess =20= > if > IETF couldn't provide us with a magic ultra low power solution for ad > hoc networks in past years, then chances are slim that this will work > out now. Unless somebody provides me with a convincing study that > adopting a general p2p ROLL protocol will not jeopardize the =20 > efficiency > of the 95% quantile applications, I propose to adopt some simple and > possibly sub-optimum heuristics and then forget about it. > > Security is an important issue. > > Now that we are at it, I sampled quite a large number of companies =20 > at an > M2M event in Paris a few months ago organized by Orange where we met > with JP and others. The large majority of companies present there > explicitly told me that - for a very varying set of reasons - they =20 > would > never let IP run over their ROLL-type networks. The sheer majority did > suprise me. We still have a lot of work ahead. > > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. > > Mischa. > > > > > > > JP Vasseur wrote: > > Dear WG, > > > > First of all, thanks for all the time and energy you all have =20 > devoted > > during the past few weeks on the protocol work. There was excellent > > followup discussion at the physical WG meeting. > > > > To the question "Do you think that RPL provides an adequate =20 > foundation > > for the ROLL routing protocol work", there was clearly a good =20 > consensus > > in the WG meeting. It was also recognized there are still several =20= > open > > issues for which we WILL need help from many WG contributors, =20 > including > > the authors of other documents. > > > > Could you please confirm (or not) the adoption of draft-dt-roll-=20 > rpl-01 > > as a WG document ? > > > > Then we will of course move to the next step. > > > > Thanks, > > > > JP and David > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-21-85622255 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 30, 2009, = at 7:29 PM, Pascal Thubert (pthubert) wrote:

Hi Don:
You=92re correct. If the DAO states are enabled = everywhere, the first common parent will route down to the = destination.
 
But the doc cannot MUST keeping = states in all nodes at the protocol level because there are some use = cases where that makes no = sense.

thi= s is where smart route aggregation techniques will = help.

There might even be a case where no data whatsoever = is unicast to the devices, in which case even storing source route paths = at the root would be ridiculous. An example of that would be = environmental monitoring using widespread cheap = sensors.
 
It seems to me that this = discussion is caused by a confusion between what belongs to protocol and = what belongs to product and deployment. The protocol gives you tools, = and then you have to use them intelligently in the products you = build.
 
Another confusion I=92ve seen = here is that between the rough consensus to get WG Doc and a ballot at = IEEE or others. The call here is NOT a ballot. This is just to create a = foundation for the WG to work on. So obviously the doc does not have = everything ironed out. The question is rather whether the doc is a good = foundation for that work at it appears that many people agree on = that.
 
 
Pascal
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don = Sturek
Sent: jeudi 30 juillet 2009 = 19:00
To:  'ROLL WG';  Re: [Roll] Moving forward = with the protocol work
From: Jerald.P.Martocci@jci.com = [mailto:Jerald.P.Martocci@jci.com] 
Sent: Thursday, July 30, 2009 = 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL = WG';  RE: [Roll] Moving forward = with the protocol work


Hi Don, 

As I read = the draft, RPL doesn't currently guarantee p2p communication regardless = of hop count.  Only if some node higher in the DAG elects to = provide a path back down the DAG to the destination then there is p2p = path.  RPL doesn't mandate this even for the LBR.  Hence a = packet could squirt all the way up to the LBR and still be dropped since = the LBR itself has no route defined to the destination.  You need = to keep in mind that the LLN devices are primarily a building = controllers that 'moonlight' as a router; it's not a router that happens = to also do building control.  The likelihood that a controller = sitting higher in the DAG being altruist and defining pathways to all = possible sub-DAG devices is nil. 

As for hops, = this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes = so having a packet arrive at its destination a tad late is not too = concerning. (NOTE: Fire and lighting applications are much more time = critical).  The problem is that the source device, typically a = battery powered sensor must stay awake and leave its receiver active = until the packet has migrated to its destination and the application ACK = has been received.  This will reduce battery life at least = 10x.

As for scalability, a typical PAN in a commercial building = is limited to a floor which may require upwards to 250 LLN nodes. =  Sure we could have defined the PAN to be the entire complex and = then require 10K nodes as do the other requirement specs. =  Empirical testing however determined that managing 250 nodes on a = single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a = floor seems to be the right balance point for complexity and = flexibility. 

 

"Don Sturek" <

07/30/2009 11:12 = AM

Please respond to
<d.sturek@att.net>
To
 




Hi = Jerry, 
  
I = think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing = up. 
  
I do = question whether optimizing hops is really necessary.  I think most = applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also = without nearly the overhead of packet flooding or storage of state = information that optimized P2P solutions impose).   
 
I = really don=92t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will = result in anything other than the same set of solutions we have today = (distance vector with flooding, link state routing and its derivatives, = source routing and its derivatives).   
 
 
  
 
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of  Thursday, July 30, 2009 = 8:58 AM
To: Mischa = Dohler
Cc: ROLL WG;  Re: [Roll] Moving forward = with the protocol work 
  


Hi Mischa, 

Nearly all communication in = a commercial building facility management system is point to point. =  I'm surprised the other three requirements don't also have a = strong p2p requirement.  Back in the early 80's prior to processor = based sensors, we deployed 'dumb sensors' that would simply upload their = current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant. =  That is if the minicomputer 'blew a gasket', the entire building = went out of control. 

As soon as it was = economically viable, we decentralized control by moving it down into the = rooms.  Now each room was controlled independently with an array of = room sensors and room controllers.  Now if a controller failed, = only the room might lose control, not the entire complex.  The room = controllers were then further controlled by higher level controllers. =  This distributed architecture has been in place for 25 years and = is the mainstay of building control.   

My point is that is the = Commercial Market the LLN is not just a path for moving data nortbound. =  Most of the packets sent on the LLN are destined to other nodes on = the LLN.  They all require application ACKs.  About 20% of the = packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further = analysis. 

If we don't support a = robust p2p protocol option in ROLL, we will knock out the Building = Market in its entirety which means at best you will only solve 75% of = the need. 

 
JP Vasseur <
cc

 





JP, all,

We should use this early design = stage to come up with one solution - one 
solution which is not = necessarily optimum for all cases but for the 
(e.g.) 95% quantile. = The PHY guys learned to live with such an approach. 
The MAC folks are = getting there and we should take our chance now. 95% 
means clearly to = concentrate on the core issues, of which loop 
detection/avoidance, = p2p and security are somehow still open.

I do understand the = concept of loops arising. I have doubts that with 
the dynamics of typical = ROLL networks, these will give us headaches 
within this 95% = application quantile. I have read tons of papers 
produced in the last = decade on routing in ROLL-type networks. Loop 
detection and avoidance = was clearly not something people (including 
those doing practical = rollouts and running their companies today) were 
worried about too much. = Unless somebody provides me with a convincing 
study, I propose to = merely adopt some simple and possibly sub-optimum 
heuristics and then = forget about it.

P2P seems to worry some of us (sorry, Jerry, for = having forgotten about 
the p2p paragraph). = However, again, are we talking about the 95% 
quantile here? = Furthermore, how much p2p exactly are you talking about? 
Any node truly to any = node? Are we back to pure ad hoc then? I guess if 
IETF couldn't provide = us with a magic ultra low power solution for ad 
hoc networks in past = years, then chances are slim that this will work 
out now. Unless = somebody provides me with a convincing study that 
adopting a general p2p = ROLL protocol will not jeopardize the efficiency 
of the 95% quantile = applications, I propose to adopt some simple and 
possibly sub-optimum = heuristics and then forget about it.

Security is an important = issue.

Now that we are at it, I sampled quite a large number of = companies at an 
M2M = event in Paris a few months ago organized by Orange where we met 
with JP and others. The = large majority of companies present there 
explicitly told me that = - for a very varying set of reasons - they would 
never let IP run over = their ROLL-type networks. The sheer majority did 
suprise me. We still = have a lot of work ahead.

I am in favour of adopting = draft-dt-roll-rpl-01 as a WG = document.

Mischa.






JP Vasseur = wrote:
> Dear WG,
> 
> First of all, = thanks for all the time and energy you all have devoted 
> during the past = few weeks on the protocol work. There was excellent 
> followup = discussion at the physical WG meeting.
> 
> To the question = "Do you think that RPL provides an adequate foundation 
> for the ROLL = routing protocol work", there was clearly a good consensus 
> in the WG meeting. = It was also recognized there are still several open 
> issues for which = we WILL need help from many WG contributors, including 
> the authors of = other documents.
> 
> Could you please = confirm (or not) the adoption of draft-dt-roll-rpl-01 
> as a WG document = ?
> 
> = Then we will of course move to the next step.
> 
> = Thanks,
> 
>= JP and David
> 
> 
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> Roll@ietf.org
Roll@ietf.org
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MUSTing P2P states [was RE: [Roll] Moving forward with theprotocol work] Thread-Index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJgAADviOAAARNlwQ== References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net><01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" X-Mailman-Approved-At: Thu, 30 Jul 2009 10:59:27 -0700 Cc: ROLL WG Subject: Re: [Roll] MUSTing P2P states [was RE: Moving forward with the protocolwork] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:53:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA113E.A3B6F460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comment inline ... =20 Cheers, Anders ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Pascal Thubert (pthubert) Sendt: to 30-07-2009 19:29 Til: d.sturek@att.net; Jerald.P.Martocci@jci.com Cc: ROLL WG; roll-bounces@ietf.org Emne: [Roll] MUSTing P2P states [was RE: Moving forward with the = protocolwork] Hi Don: =20 You're correct. If the DAO states are enabled everywhere, the first = common parent will route down to the destination. =20 But the doc cannot MUST keeping states in all nodes at the protocol = level because there are some use cases where that makes no sense. There might even be a case where no data whatsoever is unicast to the = devices, in which case even storing source route paths at the root would = be ridiculous. An example of that would be environmental monitoring = using widespread cheap sensors.=20 =20 It seems to me that this discussion is caused by a confusion between = what belongs to protocol and what belongs to product and deployment. The = protocol gives you tools, and then you have to use them intelligently in = the products you build. =20 ABR> But will a smart product have access to the tools needed to = determine some transit nodes and build some (more optimal) source routes to avoid having to = walk all the way to the top? I agree with Jerry that battery life time will be severely = affected if not having some (relatively) direct connections between sensor and controller. This also = applies to the home control domain. =20 Another confusion I've seen here is that between the rough consensus to = get WG Doc and a ballot at IEEE or others. The call here is NOT a = ballot. This is just to create a foundation for the WG to work on. So = obviously the doc does not have everything ironed out. The question is = rather whether the doc is a good foundation for that work at it appears = that many people agree on that. =20 Cheers, =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Don Sturek Sent: jeudi 30 juillet 2009 19:00 To: Jerald.P.Martocci@jci.com Cc: 'ROLL WG'; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work =20 Hi Jerry, =20 I may have misread the RPL proposal. I thought the Destination Address = notifications allowed the DAG root to route back down to a device in the = DAG and that feature enabled P2P in all cases. I thought also the = Destination Address notifications for devices with lower depth/rank = could be used by devices within a DAG to more efficiently reroute P2P = traffic within the DAG (not optimally, just "more efficiently than = sending the packet all the way to the DAG root first). I thought in all = cases P2P was supported (just without a mechanism to minimize the hop = count). =20 Could someone from the DT comment on the assumptions above? =20 Did I understand that optimizing P2P for building controls is mainly = about minimizing hop counts? If a building controls solution could = choose between optimizing hop count for P2P and flooding the network to = find the optimal P2P hop count, would it choose to flood the network? I = think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found = so attractive about RPL..... Don =20 =20 From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]=20 Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work =20 Hi Don,=20 As I read the draft, RPL doesn't currently guarantee p2p communication = regardless of hop count. Only if some node higher in the DAG elects to = provide a path back down the DAG to the destination then there is p2p = path. RPL doesn't mandate this even for the LBR. Hence a packet could = squirt all the way up to the LBR and still be dropped since the LBR = itself has no route defined to the destination. You need to keep in = mind that the LLN devices are primarily a building controllers that = 'moonlight' as a router; it's not a router that happens to also do = building control. The likelihood that a controller sitting higher in = the DAG being altruist and defining pathways to all possible sub-DAG = devices is nil.=20 As for hops, this is very important too. Not so much for latency. The = time constant for most building HVAC control loops is in minutes so = having a packet arrive at its destination a tad late is not too = concerning. (NOTE: Fire and lighting applications are much more time = critical). The problem is that the source device, typically a battery = powered sensor must stay awake and leave its receiver active until the = packet has migrated to its destination and the application ACK has been = received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to = a floor which may require upwards to 250 LLN nodes. Sure we could have = defined the PAN to be the entire complex and then require 10K nodes as = do the other requirement specs. Empirical testing however determined = that managing 250 nodes on a single wireless domain was difficult enough = with regard to channel management, interference and hop count. Limiting = PAN size to a floor seems to be the right balance point for complexity = and flexibility.=20 Jerry=20 "Don Sturek" =20 07/30/2009 11:12 AM=20 Please respond to To , "'Mischa Dohler'" =20 cc "'ROLL WG'" , =20 Subject RE: [Roll] Moving forward with the protocol work =20 =09 Hi Jerry,=20 =20 I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.=20 =20 I do question whether optimizing hops is really necessary. I think most = applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also = without nearly the overhead of packet flooding or storage of state = information that optimized P2P solutions impose). =20 =20 I really don't see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will = result in anything other than the same set of solutions we have today = (distance vector with flooding, link state routing and its derivatives, = source routing and its derivatives). =20 =20 Don=20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work=20 =20 Hi Mischa,=20 Nearly all communication in a commercial building facility management = system is point to point. I'm surprised the other three requirements = don't also have a strong p2p requirement. Back in the early 80's prior = to processor based sensors, we deployed 'dumb sensors' that would simply = upload their current environmental information to a centralized = minicomputer. This centralized model was not scalable nor fault = tolerant. That is if the minicomputer 'blew a gasket', the entire = building went out of control.=20 As soon as it was economically viable, we decentralized control by = moving it down into the rooms. Now each room was controlled = independently with an array of room sensors and room controllers. Now = if a controller failed, only the room might lose control, not the entire = complex. The room controllers were then further controlled by higher = level controllers. This distributed architecture has been in place for = 25 years and is the mainstay of building control. =20 My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound. Most of the packets sent on the LLN are destined = to other nodes on the LLN. They all require application ACKs. About = 20% of the packets are destined to the LBR and onwards. These are event = packets being sent to the higher layers for further analysis.=20 If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will = only solve 75% of the need.=20 Jerry=20 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 =20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =20 =20 =09 JP, all, We should use this early design stage to come up with one solution - one = solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach. = The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers=20 produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95%=20 quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an = M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would = never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation = > for the ROLL routing protocol work", there was clearly a good = consensus=20 > in the WG meeting. It was also recognized there are still several open = > issues for which we WILL need help from many WG contributors, = including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 = > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 ------_=_NextPart_001_01CA113E.A3B6F460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
comment = inline ...
=0A=
 
=0A=
Cheers,
  = Anders
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Pascal Thubert (pthubert)
Sendt: to 30-07-2009 = 19:29
Til: d.sturek@att.net; = Jerald.P.Martocci@jci.com
Cc: ROLL WG; = roll-bounces@ietf.org
Emne: [Roll] MUSTing P2P states [was RE: = Moving forward with the protocolwork]

=0A=
=0A=
=0A=

Hi Don:

=0A=

 

=0A=

You’re correct. If the DAO = states are enabled everywhere, the first common parent will route down = to the destination.

=0A=

 

=0A=

But the doc cannot MUST keeping = states in all nodes at the protocol level because there are some use = cases where that makes no sense.

=0A=

There might even be a case where no = data whatsoever is unicast to the devices, in which case even storing = source route paths at the root would be ridiculous. An example of that = would be environmental monitoring using widespread cheap sensors. =

=0A=

 

=0A=

It seems to me that this discussion = is caused by a confusion between what belongs to protocol and what = belongs to product and deployment. The protocol gives you tools, and = then you have to use them intelligently in the products you = build.

=0A=

 

=0A=

ABR> But = will a smart product have access to the tools needed to determine some = transit nodes
       and build some = (more optimal) source routes to avoid having to walk all the way to the = top?
       I agree with Jerry that = battery life time will be severely affected if not having some = (relatively)
       direct connections = between sensor and controller. This also applies to the home control = domain.

=0A=

 

=0A=

Another confusion I’ve seen = here is that between the rough consensus to get WG Doc and a ballot at = IEEE or others. The call here is NOT a ballot. This is just to create a = foundation for the WG to work on. So obviously the doc does not have = everything ironed out. The question is rather whether the doc is a good = foundation for that work at it appears that many people agree on = that.

=0A=

 

=0A=

Cheers,

=0A=

 

=0A=

Pascal

=0A=
=0A=
=0A=
=0A=

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On Behalf Of Don = Sturek
Sent: jeudi 30 juillet 2009 19:00
To: = Jerald.P.Martocci@jci.com
Cc: 'ROLL WG'; = roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with = the protocol work

=0A=

 

=0A=

Hi Jerry,

=0A=

 

=0A=

I may have misread the RPL = proposal.  I thought the Destination Address notifications allowed = the DAG root to route back down to a device in the DAG and that feature = enabled P2P in all cases.  I thought also the Destination Address = notifications for devices with lower depth/rank could be used by devices = within a DAG to more efficiently reroute P2P traffic within the DAG (not = optimally, just “more efficiently than sending the packet all the = way to the DAG root first).  I thought in all cases P2P was = supported (just without a mechanism to minimize the hop = count).

=0A=

 

=0A=

Could someone from the DT comment = on the assumptions above?

=0A=

 

=0A=

Did I understand that optimizing = P2P for building controls is mainly about minimizing hop = counts?   If a building controls solution could choose between = optimizing hop count for P2P and flooding the network to find the = optimal P2P hop count, would it choose to flood the network?  I = think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found = so attractive about RPL…..

=0A=


Don

=0A=

 

=0A=

 

=0A=
=0A=

From: Jerald.P.Martocci@jci.com = [mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, = 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa = Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] = Moving forward with the protocol work

=0A=

 

=0A=


Hi = Don,

As I read the draft, RPL doesn't currently = guarantee p2p communication regardless of hop count.  Only if some = node higher in the DAG elects to provide a path back down the DAG to the = destination then there is p2p path.  RPL doesn't mandate this even = for the LBR.  Hence a packet could squirt all the way up to the LBR = and still be dropped since the LBR itself has no route defined to the = destination.  You need to keep in mind that the LLN devices are = primarily a building controllers that 'moonlight' as a router; it's not = a router that happens to also do building control.  The likelihood = that a controller sitting higher in the DAG being altruist and defining = pathways to all possible sub-DAG devices is nil.

As for = hops, this is very important too.  Not so much for latency. =  The time constant for most building HVAC  control loops is in = minutes so having a packet arrive at its destination a tad late is not = too concerning. (NOTE: Fire and lighting applications are much more time = critical).  The problem is that the source device, typically a = battery powered sensor must stay awake and leave its receiver active = until the packet has migrated to its destination and the application ACK = has been received.  This will reduce battery life at least = 10x.

As for scalability, a typical PAN in a commercial = building is limited to a floor which may require upwards to 250 LLN = nodes.  Sure we could have defined the PAN to be the entire complex = and then require 10K nodes as do the other requirement specs. =  Empirical testing however determined that managing 250 nodes on a = single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a = floor seems to be the right balance point for complexity and = flexibility.

Jerry

=0A= =0A= =0A= =0A= =0A=
=0A=

"Don Sturek" = <d.sturek@att.net>

=0A=

07/30/2009 11:12 AM

=0A= =0A= =0A= =0A=
=0A=

Please = respond = to
<d.sturek@att.net>

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

To

=0A=

<Jerald.P.Martocci@jci.com>, "'Mischa = Dohler'" <mischa.dohler@cttc.es>

=0A=

cc

=0A=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

=0A=

Subject

=0A=

RE: [Roll] Moving forward with the protocol = work

=0A=

 

=0A= =0A= =0A= =0A= =0A=
=0A=

=0A=




Hi Jerry,
  =
I think RPL does support P2P but does not = optimize the number of hops. I think that is the central issue you and = Mukul are bringing up.
 
I do question whether optimizing hops is really = necessary.  I think most applications (including building controls) = can take advantage of a solution that well supports MP2P and P2MP with = extensions to provide P2P capability (admittedly not optimized for hop = count/cost but then also without nearly the overhead of packet flooding = or storage of state information that optimized P2P solutions impose). =  
 
I really don’t see that trying (once again = as they have in MANET for some time) to find a single protocol that = efficiently implements P2P and scales while addressing the various data = transmission patterns will result in anything other than the same set of = solutions we have today (distance vector with flooding, link state = routing and its derivatives, source routing and its derivatives). =  
 
Don
  =
 
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 = 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; = roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with = the protocol work
 


Hi Mischa,

Nearly = all communication in a commercial building facility management system is = point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior = to processor based sensors, we deployed 'dumb sensors' that would simply = upload their current environmental information to a centralized = minicomputer.  This centralized model was not scalable nor fault = tolerant.  That is if the minicomputer 'blew a gasket', the entire = building went out of control.

As soon as it was economically = viable, we decentralized control by moving it down into the rooms. =  Now each room was controlled independently with an array of room = sensors and room controllers.  Now if a controller failed, only the = room might lose control, not the entire complex.  The room = controllers were then further controlled by higher level controllers. =  This distributed architecture has been in place for 25 years and = is the mainstay of building control.  

My = point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are = destined to other nodes on the LLN.  They all require application = ACKs.  About 20% of the packets are destined to the LBR and = onwards.  These are event packets being sent to the higher layers = for further analysis.

If we don't support a robust p2p = protocol option in ROLL, we will knock out the Building Market in its = entirety which means at best you will only solve 75% of the need. =


Jerry

=0A= =0A= =0A= =0A= =0A=
=0A=

Mischa Dohler = <mischa.dohler@cttc.es>
Sent by: = roll-bounces@ietf.org

=0A=

07/29/2009 04:18 PM

=0A=

 

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

To

=0A=

JP Vasseur <jvasseur@cisco.com> =

=0A=

cc

=0A=

ROLL WG <roll@ietf.org>

=0A=

Subject

=0A=

Re: [Roll] Moving forward with the protocol = work

=0A=


 

=0A=

 

=0A= =0A= =0A= =0A= =0A=
=0A=

=0A=





JP, all,

We should use this early design stage to come = up with one solution - one
solution which is not necessarily optimum = for all cases but for the
(e.g.) 95% quantile. The PHY guys learned = to live with such an approach.
The MAC folks are getting there and = we should take our chance now. 95%
means clearly to concentrate on = the core issues, of which loop
detection/avoidance, p2p and security = are somehow still open.

I do understand the concept of loops = arising. I have doubts that with
the dynamics of typical ROLL = networks, these will give us headaches
within this 95% application = quantile. I have read tons of papers
produced in the last decade on = routing in ROLL-type networks. Loop
detection and avoidance was = clearly not something people (including
those doing practical = rollouts and running their companies today) were
worried about too = much. Unless somebody provides me with a convincing
study, I propose = to merely adopt some simple and possibly sub-optimum
heuristics and = then forget about it.

P2P seems to worry some of us (sorry, = Jerry, for having forgotten about
the p2p paragraph). However, = again, are we talking about the 95%
quantile here? Furthermore, how = much p2p exactly are you talking about?
Any node truly to any node? = Are we back to pure ad hoc then? I guess if
IETF couldn't provide us = with a magic ultra low power solution for ad
hoc networks in past = years, then chances are slim that this will work
out now. Unless = somebody provides me with a convincing study that
adopting a general = p2p ROLL protocol will not jeopardize the efficiency
of the 95% = quantile applications, I propose to adopt some simple and
possibly = sub-optimum heuristics and then forget about it.

Security is an = important issue.

Now that we are at it, I sampled quite a large = number of companies at an
M2M event in Paris a few months ago = organized by Orange where we met
with JP and others. The large = majority of companies present there
explicitly told me that - for a = very varying set of reasons - they would
never let IP run over their = ROLL-type networks. The sheer majority did
suprise me. We still have = a lot of work ahead.

I am in favour of adopting = draft-dt-roll-rpl-01 as a WG = document.

Mischa.






JP Vasseur = wrote:
> Dear WG,
>
> First of all, thanks for all = the time and energy you all have devoted
> during the past few = weeks on the protocol work. There was excellent
> followup = discussion at the physical WG meeting.
>
> To the question = "Do you think that RPL provides an adequate foundation
> for the = ROLL routing protocol work", there was clearly a good consensus
> = in the WG meeting. It was also recognized there are still several open =
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> = Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 =
> as a WG document ?
>
> Then we will of course move = to the next step.
>
> Thanks,
>
> JP and = David
>
>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> = https://www.ietf.org/mailman/listinfo/roll
___________________________= ____________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CA113E.A3B6F460-- From jvasseur@cisco.com Thu Jul 30 11:02:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893CC3A71E6 for ; Thu, 30 Jul 2009 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YRqWXNjW8Fn0 for ; Thu, 30 Jul 2009 11:02:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0B67C3A71E3 for ; Thu, 30 Jul 2009 11:02:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAALt8cUqQ/uCKe2dsb2JhbACCKSwhlxYWJAahC4gnkC0FhBE X-IronPort-AV: E=Sophos;i="4.43,296,1246838400"; d="scan'208,217";a="46162339" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 18:02: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 n6UI2Cm8009136; Thu, 30 Jul 2009 20:02:12 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6UI2Ccv004355; Thu, 30 Jul 2009 18:02:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 20:02:12 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 20:02:10 +0200 Message-Id: <9D8D4164-A8FB-4C09-82FD-328FC1421AD0@cisco.com> From: JP Vasseur To: "Anders Brandt" In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3EF16C7D@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-22-86790689 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 20:02:10 +0200 References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net><01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3EF16C7D@zensys17.zensys.local> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jul 2009 18:02:11.0147 (UTC) FILETIME=[DC6181B0:01CA113F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=59594; t=1248976932; x=1249840932; 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[Roll]=20MUSTing=20P2P=20states=20 |Sender:=20; bh=ue94J0bs8F0qmCnAaXByoxUxDFAOplWn9LRMAYxxAu8=; b=fTdMdoApjJZ3oL4lthFGntozOz4H3W9xagCchLVRsPedYG0g4S5KCRCW4F hvvEZRU2HHPwyEBGDN+1saah0Ui/c/DhEw5otDqxKxIIven/uoJSXh/qk9f0 KNAinQSEZ2; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] MUSTing P2P states X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:02:17 -0000 --Apple-Mail-22-86790689 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 30, 2009, at 7:53 PM, Anders Brandt wrote: > comment inline ... > > Cheers, > Anders > > Fra: roll-bounces@ietf.org p=E5 vegne af Pascal Thubert (pthubert) > Sendt: to 30-07-2009 19:29 > Til: d.sturek@att.net; Jerald.P.Martocci@jci.com > Cc: ROLL WG; roll-bounces@ietf.org > Emne: [Roll] MUSTing P2P states [was RE: Moving forward with the =20 > protocolwork] > > Hi Don: > > You=92re correct. If the DAO states are enabled everywhere, the first =20= > common parent will route down to the destination. > > But the doc cannot MUST keeping states in all nodes at the protocol =20= > level because there are some use cases where that makes no sense. > There might even be a case where no data whatsoever is unicast to =20 > the devices, in which case even storing source route paths at the =20 > root would be ridiculous. An example of that would be environmental =20= > monitoring using widespread cheap sensors. > > It seems to me that this discussion is caused by a confusion between =20= > what belongs to protocol and what belongs to product and deployment. =20= > The protocol gives you tools, and then you have to use them =20 > intelligently in the products you build. > > ABR> But will a smart product have access to the tools needed to =20 > determine some transit nodes > and build some (more optimal) source routes to avoid having =20 > to walk all the way to the top? > I agree with Jerry that battery life time will be severely =20 > affected if not having some (relatively) > direct connections between sensor and controller. This also =20 > applies to the home control domain. (co-chair hat off). Completely agreeing and again this is clearly =20 spelled out in the requirements documents. > > Another confusion I=92ve seen here is that between the rough consensus = =20 > to get WG Doc and a ballot at IEEE or others. The call here is NOT a =20= > ballot. This is just to create a foundation for the WG to work on. =20 > So obviously the doc does not have everything ironed out. The =20 > question is rather whether the doc is a good foundation for that =20 > work at it appears that many people agree on that. > > Cheers, > > Pascal > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Don Sturek > Sent: jeudi 30 juillet 2009 19:00 > To: Jerald.P.Martocci@jci.com > Cc: 'ROLL WG'; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > Hi Jerry, > > I may have misread the RPL proposal. I thought the Destination =20 > Address notifications allowed the DAG root to route back down to a =20 > device in the DAG and that feature enabled P2P in all cases. I =20 > thought also the Destination Address notifications for devices with =20= > lower depth/rank could be used by devices within a DAG to more =20 > efficiently reroute P2P traffic within the DAG (not optimally, just =20= > =93more efficiently than sending the packet all the way to the DAG =20 > root first). I thought in all cases P2P was supported (just without =20= > a mechanism to minimize the hop count). > > Could someone from the DT comment on the assumptions above? > > Did I understand that optimizing P2P for building controls is mainly =20= > about minimizing hop counts? If a building controls solution could =20= > choose between optimizing hop count for P2P and flooding the network =20= > to find the optimal P2P hop count, would it choose to flood the =20 > network? I think it is the lack of network flooding to establish =20 > routes and the minimal storage of route state information along the =20= > route that I found so attractive about RPL=85.. > > Don > > > From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] > Sent: Thursday, July 30, 2009 9:44 AM > To: d.sturek@att.net > Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org > Subject: RE: [Roll] Moving forward with the protocol work > > > Hi Don, > > As I read the draft, RPL doesn't currently guarantee p2p =20 > communication regardless of hop count. Only if some node higher in =20= > the DAG elects to provide a path back down the DAG to the =20 > destination then there is p2p path. RPL doesn't mandate this even =20 > for the LBR. Hence a packet could squirt all the way up to the LBR =20= > and still be dropped since the LBR itself has no route defined to =20 > the destination. You need to keep in mind that the LLN devices are =20= > primarily a building controllers that 'moonlight' as a router; it's =20= > not a router that happens to also do building control. The =20 > likelihood that a controller sitting higher in the DAG being =20 > altruist and defining pathways to all possible sub-DAG devices is nil. > > As for hops, this is very important too. Not so much for latency. =20= > The time constant for most building HVAC control loops is in =20 > minutes so having a packet arrive at its destination a tad late is =20 > not too concerning. (NOTE: Fire and lighting applications are much =20 > more time critical). The problem is that the source device, =20 > typically a battery powered sensor must stay awake and leave its =20 > receiver active until the packet has migrated to its destination and =20= > the application ACK has been received. This will reduce battery =20 > life at least 10x. > > As for scalability, a typical PAN in a commercial building is =20 > limited to a floor which may require upwards to 250 LLN nodes. Sure =20= > we could have defined the PAN to be the entire complex and then =20 > require 10K nodes as do the other requirement specs. Empirical =20 > testing however determined that managing 250 nodes on a single =20 > wireless domain was difficult enough with regard to channel =20 > management, interference and hop count. Limiting PAN size to a =20 > floor seems to be the right balance point for complexity and =20 > flexibility. > > Jerry > > > "Don Sturek" > 07/30/2009 11:12 AM > > Please respond to > > To > , "'Mischa Dohler'" > cc > "'ROLL WG'" , > Subject > RE: [Roll] Moving forward with the protocol work > > > > > Hi Jerry, > > I think RPL does support P2P but does not optimize the number of =20 > hops. I think that is the central issue you and Mukul are bringing up. > > I do question whether optimizing hops is really necessary. I think =20= > most applications (including building controls) can take advantage =20 > of a solution that well supports MP2P and P2MP with extensions to =20 > provide P2P capability (admittedly not optimized for hop count/cost =20= > but then also without nearly the overhead of packet flooding or =20 > storage of state information that optimized P2P solutions impose). > > I really don=92t see that trying (once again as they have in MANET for = =20 > some time) to find a single protocol that efficiently implements P2P =20= > and scales while addressing the various data transmission patterns =20 > will result in anything other than the same set of solutions we have =20= > today (distance vector with flooding, link state routing and its =20 > derivatives, source routing and its derivatives). > > Don > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Jerald.P.Martocci@jci.com > Sent: Thursday, July 30, 2009 8:58 AM > To: Mischa Dohler > Cc: ROLL WG; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > > > Hi Mischa, > > Nearly all communication in a commercial building facility =20 > management system is point to point. I'm surprised the other three =20= > requirements don't also have a strong p2p requirement. Back in the =20= > early 80's prior to processor based sensors, we deployed 'dumb =20 > sensors' that would simply upload their current environmental =20 > information to a centralized minicomputer. This centralized model =20 > was not scalable nor fault tolerant. That is if the minicomputer =20 > 'blew a gasket', the entire building went out of control. > > As soon as it was economically viable, we decentralized control by =20 > moving it down into the rooms. Now each room was controlled =20 > independently with an array of room sensors and room controllers. =20 > Now if a controller failed, only the room might lose control, not =20 > the entire complex. The room controllers were then further =20 > controlled by higher level controllers. This distributed =20 > architecture has been in place for 25 years and is the mainstay of =20 > building control. > > My point is that is the Commercial Market the LLN is not just a path =20= > for moving data nortbound. Most of the packets sent on the LLN are =20= > destined to other nodes on the LLN. They all require application =20 > ACKs. About 20% of the packets are destined to the LBR and =20 > onwards. These are event packets being sent to the higher layers =20 > for further analysis. > > If we don't support a robust p2p protocol option in ROLL, we will =20 > knock out the Building Market in its entirety which means at best =20 > you will only solve 75% of the need. > > > Jerry > > Mischa Dohler > Sent by: roll-bounces@ietf.org > 07/29/2009 04:18 PM > > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] Moving forward with the protocol work > > > > > > > > JP, all, > > We should use this early design stage to come up with one solution - =20= > one > solution which is not necessarily optimum for all cases but for the > (e.g.) 95% quantile. The PHY guys learned to live with such an =20 > approach. > The MAC folks are getting there and we should take our chance now. 95% > means clearly to concentrate on the core issues, of which loop > detection/avoidance, p2p and security are somehow still open. > > I do understand the concept of loops arising. I have doubts that with > the dynamics of typical ROLL networks, these will give us headaches > within this 95% application quantile. I have read tons of papers > produced in the last decade on routing in ROLL-type networks. Loop > detection and avoidance was clearly not something people (including > those doing practical rollouts and running their companies today) were > worried about too much. Unless somebody provides me with a convincing > study, I propose to merely adopt some simple and possibly sub-optimum > heuristics and then forget about it. > > P2P seems to worry some of us (sorry, Jerry, for having forgotten =20 > about > the p2p paragraph). However, again, are we talking about the 95% > quantile here? Furthermore, how much p2p exactly are you talking =20 > about? > Any node truly to any node? Are we back to pure ad hoc then? I guess =20= > if > IETF couldn't provide us with a magic ultra low power solution for ad > hoc networks in past years, then chances are slim that this will work > out now. Unless somebody provides me with a convincing study that > adopting a general p2p ROLL protocol will not jeopardize the =20 > efficiency > of the 95% quantile applications, I propose to adopt some simple and > possibly sub-optimum heuristics and then forget about it. > > Security is an important issue. > > Now that we are at it, I sampled quite a large number of companies =20 > at an > M2M event in Paris a few months ago organized by Orange where we met > with JP and others. The large majority of companies present there > explicitly told me that - for a very varying set of reasons - they =20 > would > never let IP run over their ROLL-type networks. The sheer majority did > suprise me. We still have a lot of work ahead. > > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. > > Mischa. > > > > > > > JP Vasseur wrote: > > Dear WG, > > > > First of all, thanks for all the time and energy you all have =20 > devoted > > during the past few weeks on the protocol work. There was excellent > > followup discussion at the physical WG meeting. > > > > To the question "Do you think that RPL provides an adequate =20 > foundation > > for the ROLL routing protocol work", there was clearly a good =20 > consensus > > in the WG meeting. It was also recognized there are still several =20= > open > > issues for which we WILL need help from many WG contributors, =20 > including > > the authors of other documents. > > > > Could you please confirm (or not) the adoption of draft-dt-roll-=20 > rpl-01 > > as a WG document ? > > > > Then we will of course move to the next step. > > > > Thanks, > > > > JP and David > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-22-86790689 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 30, 2009, = at 7:53 PM, Anders Brandt wrote:

comment inline ...
 
Cheers,
  = Anders

 


Another confusion = I=92ve seen here is that between the rough consensus to get WG Doc and a = ballot at IEEE or others. The call here is NOT a ballot. This is just to = create a foundation for the WG to work on. So obviously the doc does not = have everything ironed out. The question is rather whether the doc is a = good foundation for that work at it appears that many people agree on = that.

 

Cheers,

 

Pascal

 

 

 

 

 

 

 Jerald.P.Martocci@jci.com = [mailto:Jerald.P.Martocci@jci.com] 
Sent: Thursday, July 30, 2009 = 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL = WG';  RE: [Roll] Moving forward = with the protocol work

 


Hi = Don, 

As I read = the draft, RPL doesn't currently guarantee p2p communication regardless = of hop count.  Only if some node higher in the DAG elects to = provide a path back down the DAG to the destination then there is p2p = path.  RPL doesn't mandate this even for the LBR.  Hence a = packet could squirt all the way up to the LBR and still be dropped since = the LBR itself has no route defined to the destination.  You need = to keep in mind that the LLN devices are primarily a building = controllers that 'moonlight' as a router; it's not a router that happens = to also do building control.  The likelihood that a controller = sitting higher in the DAG being altruist and defining pathways to all = possible sub-DAG devices is nil. 

As for hops, = this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes = so having a packet arrive at its destination a tad late is not too = concerning. (NOTE: Fire and lighting applications are much more time = critical).  The problem is that the source device, typically a = battery powered sensor must stay awake and leave its receiver active = until the packet has migrated to its destination and the application ACK = has been received.  This will reduce battery life at least = 10x.

As for scalability, a typical PAN in a commercial building = is limited to a floor which may require upwards to 250 LLN nodes. =  Sure we could have defined the PAN to be the entire complex and = then require 10K nodes as do the other requirement specs. =  Empirical testing however determined that managing 250 nodes on a = single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a = floor seems to be the right balance point for complexity and = flexibility. 

 

"Don = Sturek" <d.sturek@att.net>07/30/2009 = 11:12 AM

 




Hi Jerry, 
 
I = think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing = up. 
  
I do = question whether optimizing hops is really necessary.  I think most = applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also = without nearly the overhead of packet flooding or storage of state = information that optimized P2P solutions impose).   
 
I = really don=92t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will = result in anything other than the same set of solutions we have today = (distance vector with flooding, link state routing and its derivatives, = source routing and its derivatives).   
 
 
  
 
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of  Thursday, July 30, 2009 = 8:58 AM
To: Mischa = Dohler
Cc: ROLL WG;  Re: [Roll] Moving forward = with the protocol work 
  


Hi Mischa, 

Nearly all communication in = a commercial building facility management system is point to point. =  I'm surprised the other three requirements don't also have a = strong p2p requirement.  Back in the early 80's prior to processor = based sensors, we deployed 'dumb sensors' that would simply upload their = current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant. =  That is if the minicomputer 'blew a gasket', the entire building = went out of control. 

As soon as it was = economically viable, we decentralized control by moving it down into the = rooms.  Now each room was controlled independently with an array of = room sensors and room controllers.  Now if a controller failed, = only the room might lose control, not the entire complex.  The room = controllers were then further controlled by higher level controllers. =  This distributed architecture has been in place for 25 years and = is the mainstay of building control.   

My point is that is the = Commercial Market the LLN is not just a path for moving data nortbound. =  Most of the packets sent on the LLN are destined to other nodes on = the LLN.  They all require application ACKs.  About 20% of the = packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further = analysis. 

If we don't support a = robust p2p protocol option in ROLL, we will knock out the Building = Market in its entirety which means at best you will only solve 75% of = the need. 

07/29/2009 04:18 = PM

 


 
 




JP, all,

We should use this early design = stage to come up with one solution - one 
solution which is not = necessarily optimum for all cases but for the 
(e.g.) 95% quantile. = The PHY guys learned to live with such an approach. 
The MAC folks are = getting there and we should take our chance now. 95% 
means clearly to = concentrate on the core issues, of which loop 
detection/avoidance, = p2p and security are somehow still open.

I do understand the = concept of loops arising. I have doubts that with 
the dynamics of typical = ROLL networks, these will give us headaches 
within this 95% = application quantile. I have read tons of papers 
produced in the last = decade on routing in ROLL-type networks. Loop 
detection and avoidance = was clearly not something people (including 
those doing practical = rollouts and running their companies today) were 
worried about too much. = Unless somebody provides me with a convincing 
study, I propose to = merely adopt some simple and possibly sub-optimum 
heuristics and then = forget about it.

P2P seems to worry some of us (sorry, Jerry, for = having forgotten about 
the p2p paragraph). = However, again, are we talking about the 95% 
quantile here? = Furthermore, how much p2p exactly are you talking about? 
Any node truly to any = node? Are we back to pure ad hoc then? I guess if 
IETF couldn't provide = us with a magic ultra low power solution for ad 
hoc networks in past = years, then chances are slim that this will work 
out now. Unless = somebody provides me with a convincing study that 
adopting a general p2p = ROLL protocol will not jeopardize the efficiency 
of the 95% quantile = applications, I propose to adopt some simple and 
possibly sub-optimum = heuristics and then forget about it.

Security is an important = issue.

Now that we are at it, I sampled quite a large number of = companies at an 
M2M = event in Paris a few months ago organized by Orange where we met 
with JP and others. The = large majority of companies present there 
explicitly told me that = - for a very varying set of reasons - they would 
never let IP run over = their ROLL-type networks. The sheer majority did 
suprise me. We still = have a lot of work ahead.

I am in favour of adopting = draft-dt-roll-rpl-01 as a WG = document.

Mischa.






JP Vasseur = wrote:
> Dear WG,
> 
> First of all, = thanks for all the time and energy you all have devoted 
> during the past = few weeks on the protocol work. There was excellent 
> followup = discussion at the physical WG meeting.
> 
> To the question = "Do you think that RPL provides an adequate foundation 
> for the ROLL = routing protocol work", there was clearly a good consensus 
> in the WG meeting. = It was also recognized there are still several open 
> issues for which = we WILL need help from many WG contributors, including 
> the authors of = other documents.
> 
> Could you please = confirm (or not) the adoption of draft-dt-roll-rpl-01 
> as a WG document = ?
> 
> = Then we will of course move to the next step.
> 
> = Thanks,
> 
>= JP and David
> 
> 
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> Roll@ietf.org
Roll@ietf.org
=20 07/30/2009 12:00 PM Please respond to To cc "'Mischa Dohler'" , "'ROLL WG'" ,=20 Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, =20 I may have misread the RPL proposal. I thought the Destination Address=20 notifications allowed the DAG root to route back down to a device in the=20 DAG and that feature enabled P2P in all cases. I thought also the=20 Destination Address notifications for devices with lower depth/rank could=20 be used by devices within a DAG to more efficiently reroute P2P traffic=20 within the DAG (not optimally, just ?more efficiently than sending the=20 packet all the way to the DAG root first). I thought in all cases P2P was = supported (just without a mechanism to minimize the hop count). =20 Could someone from the DT comment on the assumptions above? =20 Did I understand that optimizing P2P for building controls is mainly about = minimizing hop counts? If a building controls solution could choose=20 between optimizing hop count for P2P and flooding the network to find the=20 optimal P2P hop count, would it choose to flood the network? I think it=20 is the lack of network flooding to establish routes and the minimal=20 storage of route state information along the route that I found so=20 attractive about RPL?.. Don =20 =20 From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]=20 Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work =20 Hi Don,=20 As I read the draft, RPL doesn't currently guarantee p2p communication=20 regardless of hop count. Only if some node higher in the DAG elects to=20 provide a path back down the DAG to the destination then there is p2p=20 path. RPL doesn't mandate this even for the LBR. Hence a packet could=20 squirt all the way up to the LBR and still be dropped since the LBR itself = has no route defined to the destination. You need to keep in mind that=20 the LLN devices are primarily a building controllers that 'moonlight' as a = router; it's not a router that happens to also do building control. The=20 likelihood that a controller sitting higher in the DAG being altruist and=20 defining pathways to all possible sub-DAG devices is nil.=20 As for hops, this is very important too. Not so much for latency. The=20 time constant for most building HVAC control loops is in minutes so=20 having a packet arrive at its destination a tad late is not too=20 concerning. (NOTE: Fire and lighting applications are much more time=20 critical). The problem is that the source device, typically a battery=20 powered sensor must stay awake and leave its receiver active until the=20 packet has migrated to its destination and the application ACK has been=20 received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes. Sure we could have=20 defined the PAN to be the entire complex and then require 10K nodes as do=20 the other requirement specs. Empirical testing however determined that=20 managing 250 nodes on a single wireless domain was difficult enough with=20 regard to channel management, interference and hop count. Limiting PAN=20 size to a floor seems to be the right balance point for complexity and=20 flexibility.=20 Jerry=20 "Don Sturek" =20 07/30/2009 11:12 AM=20 Please respond to To , "'Mischa Dohler'" =20 cc "'ROLL WG'" , =20 Subject RE: [Roll] Moving forward with the protocol work =20 Hi Jerry,=20 =20 I think RPL does support P2P but does not optimize the number of hops. I=20 think that is the central issue you and Mukul are bringing up.=20 =20 I do question whether optimizing hops is really necessary. I think most=20 applications (including building controls) can take advantage of a=20 solution that well supports MP2P and P2MP with extensions to provide P2P=20 capability (admittedly not optimized for hop count/cost but then also=20 without nearly the overhead of packet flooding or storage of state=20 information that optimized P2P solutions impose). =20 =20 I really don?t see that trying (once again as they have in MANET for some=20 time) to find a single protocol that efficiently implements P2P and scales = while addressing the various data transmission patterns will result in=20 anything other than the same set of solutions we have today (distance=20 vector with flooding, link state routing and its derivatives, source=20 routing and its derivatives). =20 =20 Don=20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work=20 =20 Hi Mischa,=20 Nearly all communication in a commercial building facility management=20 system is point to point. I'm surprised the other three requirements=20 don't also have a strong p2p requirement. Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply=20 upload their current environmental information to a centralized=20 minicomputer. This centralized model was not scalable nor fault tolerant. = That is if the minicomputer 'blew a gasket', the entire building went out = of control.=20 As soon as it was economically viable, we decentralized control by moving=20 it down into the rooms. Now each room was controlled independently with=20 an array of room sensors and room controllers. Now if a controller=20 failed, only the room might lose control, not the entire complex. The=20 room controllers were then further controlled by higher level controllers. = This distributed architecture has been in place for 25 years and is the=20 mainstay of building control. =20 My point is that is the Commercial Market the LLN is not just a path for=20 moving data nortbound. Most of the packets sent on the LLN are destined=20 to other nodes on the LLN. They all require application ACKs. About 20%=20 of the packets are destined to the LBR and onwards. These are event=20 packets being sent to the higher layers for further analysis.=20 If we don't support a robust p2p protocol option in ROLL, we will knock=20 out the Building Market in its entirety which means at best you will only=20 solve 75% of the need.=20 Jerry=20 Mischa Dohler =20 Sent by: roll-bounces@ietf.org=20 07/29/2009 04:18 PM=20 =20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work =20 =20 JP, all, We should use this early design stage to come up with one solution - one=20 solution which is not necessarily optimum for all cases but for the=20 (e.g.) 95% quantile. The PHY guys learned to live with such an approach.=20 The MAC folks are getting there and we should take our chance now. 95%=20 means clearly to concentrate on the core issues, of which loop=20 detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with=20 the dynamics of typical ROLL networks, these will give us headaches=20 within this 95% application quantile. I have read tons of papers=20 produced in the last decade on routing in ROLL-type networks. Loop=20 detection and avoidance was clearly not something people (including=20 those doing practical rollouts and running their companies today) were=20 worried about too much. Unless somebody provides me with a convincing=20 study, I propose to merely adopt some simple and possibly sub-optimum=20 heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about=20 the p2p paragraph). However, again, are we talking about the 95%=20 quantile here? Furthermore, how much p2p exactly are you talking about?=20 Any node truly to any node? Are we back to pure ad hoc then? I guess if=20 IETF couldn't provide us with a magic ultra low power solution for ad=20 hoc networks in past years, then chances are slim that this will work=20 out now. Unless somebody provides me with a convincing study that=20 adopting a general p2p ROLL protocol will not jeopardize the efficiency=20 of the 95% quantile applications, I propose to adopt some simple and=20 possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an=20 M2M event in Paris a few months ago organized by Orange where we met=20 with JP and others. The large majority of companies present there=20 explicitly told me that - for a very varying set of reasons - they would=20 never let IP run over their ROLL-type networks. The sheer majority did=20 suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, >=20 > First of all, thanks for all the time and energy you all have devoted=20 > during the past few weeks on the protocol work. There was excellent=20 > followup discussion at the physical WG meeting. >=20 > To the question "Do you think that RPL provides an adequate foundation=20 > for the ROLL routing protocol work", there was clearly a good consensus=20 > in the WG meeting. It was also recognized there are still several open=20 > issues for which we WILL need help from many WG contributors, including=20 > the authors of other documents. >=20 > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01=20 > as a WG document ? >=20 > Then we will of course move to the next step. >=20 > Thanks, >=20 > JP and David >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=20 --=_alternative 0063E7CD86257603_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
I may have misread the draft myself!= !!  I saw nothing in the draft that mandates that a node provides downward links to its sub-DAG.  It said it optional could, it didn't say it must, not even for the LBR.  Hence p2p communication seems to be based only on if a node higher in the DAG is gracious enough to help.  I too would like to hear from the DT on this.  I submitted it as one of my review comments.

Frankly, (I know I am preciously clo= se to being blasphemous now) I have not seen flooding the network as a big issue in our current implementations.  I would much prefer an algorithm that does not require broadcasts.  However, to date I have seen nothing that tells me a asynchronous broadcast needed when new route discovery is required is any worse than constant 1-hop RAs, DIOs and DAOs on a period= ic basis by every node.  Again, keep in mind that my PANS only need to have 250 nodes.

Again, as i stated much of the HVAC control in a building can live with additional latencies.  If someone resets the temp sensor in a room it's not imperative that the A/C gets actuated immediately.  However, this is not true for lighting.  If someone turns on the lights, they need the lights to kick on in msecs, not seconds.  Same is true for Smoke and Fire control.

In the commercial world we have been deploying wired sensor/actuator/controller networks for 40 years.  The devices on these networks were completely accessible to all other devices.  If I sent a message to a device, it was deterministic how long I should wait around for a reply.  If I needed to broadcast, I could broadcast.  This network had all the same accoutrements as other enter= prise networks.  The packets were smaller, the security was thinner and the speed was slower; but overall connectivity was the same.  As we move toward WSN, we need the same communication flexibility.

I apologize to the WG for this conti= nued diatribe.  I am really not trying to throw a monkey wrench into the works.  

Jerry





"Don Sturek" <d.sturek@att.net>

07/30/2009 12:00 PM
Please respond to
<d.sturek@att.net>
To
<Jerald.P.Martocci@jci.com>
cc
"'Mischa Dohler'" <misc= ha.dohler@cttc.es>, "'ROLL WG'" <roll@ietf.org>, <roll-bounces@ietf.org><= /font>
Subject
RE: [Roll] Moving forward with the p= rotocol work





Hi Jerry,
 
I may have misread the = RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases.  I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just “more efficiently than sending the packet all the way to the DAG root first).  I thought in all cases P2P was supported (just without a mechanism to minimize the hop count).
 
Could someone from the = DT comment on the assumptions above?
 
Did I understand that o= ptimizing P2P for building controls is mainly about minimizing hop counts?   If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network?  I think it is the lack of network flooding to establish routes and the minimal storage of route state informa= tion along the route that I found so attractive about RPL…..

Don
 
 
From: Jerald.P.Martocci@jci.com [= mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] Moving forward with the protocol work
 

Hi Don,

As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count.  Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path.  RPL doesn't mandate this even for the LBR.  Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control.  The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil.

As for hops, this is very important too.  Not so much for latency.  The time constant for most building HVAC  control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical).  The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received.  This will reduce battery life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes.  Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs.  Empirical testing however determin= ed that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count.  Limiti= ng PAN size to a floor seems to be the right balance point for complexity and flexibility.

Jerry

"Don Sturek" <= ;d.sturek@att.net>

07/30/2009 11:12 AM


Please respond to
<d.sturek@att.net>
To
<Jerald.P.Martocci@jci.com= >, "'Mischa Dohler'" <mischa.dohler@cttc.es>
cc
"'ROLL WG'" <roll@ietf.org&g= t;, <roll-bounces@ietf.org>
Subject
RE: [Roll] Moving forward with the protoc= ol work

 







Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also witho= ut nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work
 


Hi Mischa,

Nearly all communication in a commercial building facility management system is point to point.  I'm surprised the other three requirements don't also have a strong p2p requirement.  Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicompute= r.  This centralized model was not scalable nor fault tolerant.  That is if the minicomputer 'blew a gasket', the entire building went out of control.

As soon as it was economically viable, we decentralized control by moving it down into the rooms.  Now each room was controlled independently with an array of room sensors and room controllers.  Now if a controll= er failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destin= ed to other nodes on the LLN.  They all require application ACKs.  A= bout 20% of the packets are destined to the LBR and onwards.  These are event packets being sent to the higher layers for further analysis.<= font size=3D3 face=3D"Times New Roman">

If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.


Jerry

Mischa Dohler <mischa.d= ohler@cttc.es>
Sent by: roll-bounces@ietf.org07/29/2009 04:18 PM 		 


To
JP Vasseur <jvasseur@cisco= .com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protoc= ol work


 

 







JP, all,

We should use this early design stage to come up with one solution - one
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach.
The MAC folks are getting there and we should take our chance now. 95%
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were
worried about too much. Unless somebody provides me with a convincing
study, I propose to merely adopt some simple and possibly sub-optimum
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about?
Any node truly to any node? Are we back to pure ad hoc then? I guess if
IETF couldn't provide us with a magic ultra low power solution for ad
hoc networks in past years, then chances are slim that this will work
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency
of the 95% quantile applications, I propose to adopt some simple and
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an
M2M event in Paris a few months ago organized by Orange where we met
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would
never let IP run over their ROLL-type networks. The sheer majority did
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have devoted
> during the past few weeks on the protocol work. There was excellent
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate found= ation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several open
> issues for which we WILL need help from many WG contributors, including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--=_alternative 0063E7CD86257603_=-- From Jerald.P.Martocci@jci.com Thu Jul 30 12:12:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990953A7206; Thu, 30 Jul 2009 12:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hufnwMnHKio; Thu, 30 Jul 2009 12:12:16 -0700 (PDT) Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by core3.amsl.com (Postfix) with ESMTP id 9C00D3A6C8F; Thu, 30 Jul 2009 12:12:15 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKSnHwjgvqEMgCm3VrGq54sygh/EaEKkOJ@postini.com; Thu, 30 Jul 2009 12:12:18 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009073014124130-1032472 ; Thu, 30 Jul 2009 14:12:41 -0500 In-Reply-To: <38F26F36EAA981478A49D1F37F474A86036E750B@xmb-ams-33d.emea.cisco.com> MIME-Version: 1.0 To: "Julien Abeille (jabeille)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 30 Jul 2009 14:12:10 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/30/2009 02:12:11 PM, Serialize complete at 07/30/2009 02:12:11 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 02:12:41 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 02:12:46 PM, Serialize complete at 07/30/2009 02:12:46 PM Content-Type: multipart/alternative; boundary="=_alternative 00697B2286257603_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 19:12:18 -0000 This is a multipart message in MIME format. --=_alternative 00697B2286257603_= Content-Type: text/plain; charset="US-ASCII" Hi Julien, Section 3 of the Building Requirements ID describes the typical devices and device densities in a commercial building; Section 6 describes the traffic flow. Let me try to reiterate here ... The building control application domain includes Heating Ventilation and Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and Fire control. While each has its nuances, they all fall roughly onto the same topology. The leaf layer for these systems are the sensors. There's a plethora of them including temperature sensors, humidity sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, occupancy sensors, light switches, and the list goes on. In a room, you might expect a temp sensor, a humidity sensor, an occupancy sensor, solar sensor, smoke detector and light switches. Now along with the room sensors, there are room actuators and room controllers. The controllers receive the environmental data from the sensors, and determine the necessary control based on conditions, system overrides, time-of-day, etc and then control the environment by tweaking the actuators accordingly. The HVAC system will modulate the airflow and augment heating/cooling. The shade controller will sense solar load and adjust the shades. The lighting will be adjusted as requested by the presentation mode. When I talk about a room, I am not meaning necessarily only a closed door meeting room. This would also apply to public spaces such as an attria, hallways, ballrooms.etc. The key ingredient in this is that each of these areas has a self contained sensor/controller/actuator subsystem. Now, the next layer of controllers are the zone and area controllers. These are higher level devices that supply the facility with more global control systems. HVAC will have air handlers that supply fresh air to the rooms. Chillers that support cold air to the rooms, boilers that supply heat. Lighting panels will control whole floors rather than simply rooms. The point being that these higher order devices are also LLN devices incorporating another whole set of sensors such as outdoor air temp, relative humidity, etc. With regards to your question about layer 2, at present these devices are not IP devices. They typically reside on an EIA-485 network. Hope this helps, Jerry "Julien Abeille (jabeille)" 07/30/2009 11:07 AM To , "Mischa Dohler" cc "ROLL WG" , Subject RE: [Roll] Moving forward with the protocol work Hi Jerald, just to understand better the setup in commercial buildings: in a typical scenario, which devices / how many are present in a room, what is the layer 2 topology and the p2p application flows? Thank you, Julien From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: jeudi 30 juillet 2009 17:58 To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00697B2286257603_= Content-Type: text/html; charset="US-ASCII"

Hi Julien,

Section 3 of the Building Requirements ID describes the typical devices and device densities in a commercial building; Section 6 describes the traffic flow.  Let me try to reiterate here ...

The building control application domain includes Heating Ventilation and Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and Fire control.  While each has its nuances, they all fall roughly onto the same topology.  The leaf layer for these systems are the sensors.  There's a plethora of them including temperature sensors, humidity sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, occupancy sensors, light switches, and the list goes on.  In a room, you might expect a temp sensor, a humidity sensor, an occupancy sensor, solar sensor, smoke detector and light switches.  

Now along with the room sensors, there are room actuators and room controllers.  The controllers receive the environmental data from the sensors, and determine the necessary control based on conditions, system overrides, time-of-day, etc and then control the environment by tweaking the actuators accordingly.  The HVAC system will modulate the airflow and augment heating/cooling.  The shade controller will sense solar load and adjust the shades.  The lighting will be adjusted as requested by the presentation mode.  When I talk about a room, I am not meaning necessarily only a closed door meeting room.  This would also apply to public spaces such as an attria, hallways, ballrooms.etc.  The key ingredient in this is that each of these areas has a self contained sensor/controller/actuator subsystem.

Now, the next layer of controllers are the zone and area controllers.  These are higher level devices that supply the facility with more global control systems.  HVAC will have air handlers that supply fresh air to the rooms.  Chillers that support cold air to the rooms, boilers that supply heat.  Lighting panels will control whole floors rather than simply rooms.  The point being that these higher order devices are also LLN devices incorporating another whole set of sensors such as outdoor air temp, relative humidity, etc.

With regards to your question about layer 2, at present these devices are not IP devices.  They typically reside on an EIA-485 network.

Hope this helps,

Jerry




"Julien Abeille (jabeille)" <jabeille@cisco.com>

07/30/2009 11:07 AM

To
<Jerald.P.Martocci@jci.com>, "Mischa Dohler" <mischa.dohler@cttc.es>
cc
"ROLL WG" <roll@ietf.org>, <roll-bounces@ietf.org>
Subject
RE: [Roll] Moving forward with the protocol work





Hi Jerald,
 
just to understand better the setup in commercial buildings: in a typical scenario,  which devices / how many are present in a room, what is the layer 2 topology and the p2p application flows?
 
Thank you,
Julien

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: jeudi 30 juillet 2009 17:58
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work


Hi Mischa,

Nearly all communication in a commercial building facility management system is point to point.  I'm surprised the other three requirements don't also have a strong p2p requirement.  Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer.  This centralized model was not scalable nor fault tolerant.  That is if the minicomputer 'blew a gasket', the entire building went out of control.

As soon as it was economically viable, we decentralized control by moving it down into the rooms.  Now each room was controlled independently with an array of room sensors and room controllers.  Now if a controller failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destined to other nodes on the LLN.  They all require application ACKs.  About 20% of the packets are destined to the LBR and onwards.  These are event packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need.


Jerry



Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM


To
JP Vasseur <jvasseur@cisco.com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the protocol work







JP, all,

We should use this early design stage to come up with one solution - one
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach.
The MAC folks are getting there and we should take our chance now. 95%
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were
worried about too much. Unless somebody provides me with a convincing
study, I propose to merely adopt some simple and possibly sub-optimum
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about?
Any node truly to any node? Are we back to pure ad hoc then? I guess if
IETF couldn't provide us with a magic ultra low power solution for ad
hoc networks in past years, then chances are slim that this will work
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency
of the 95% quantile applications, I propose to adopt some simple and
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an
M2M event in Paris a few months ago organized by Orange where we met
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would
never let IP run over their ROLL-type networks. The sheer majority did
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have devoted
> during the past few weeks on the protocol work. There was excellent
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several open
> issues for which we WILL need help from many WG contributors, including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00697B2286257603_=-- From d.sturek@att.net Thu Jul 30 13:39:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AC928C194 for ; Thu, 30 Jul 2009 13:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8ptqchoj6d7 for ; Thu, 30 Jul 2009 13:39:54 -0700 (PDT) Received: from smtp121.sbc.mail.re3.yahoo.com (smtp121.sbc.mail.re3.yahoo.com [66.196.96.94]) by core3.amsl.com (Postfix) with SMTP id 3AE0A3A68E8 for ; Thu, 30 Jul 2009 13:39:54 -0700 (PDT) Received: (qmail 95812 invoked from network); 30 Jul 2009 20:33:16 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp121.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 20:33:14 -0000 X-YMail-OSG: 1T9Vf9gVM1nzmbPXOpDSn46J7BFshG0OHuF3Jm.iWIFRrrITuGS3ZM_5jpgktiOmk_aMf8.VNCSA.7Z4Q8.DH3W09mOn8ZW0JEf9zKBUFH0fuK_6tAiqXfqNZ3P4qbDvx9wnRd46GC3HrH_iQArWvgYfS52l8tnUDqW2TPOsIYT177Y3ICx69Bi0fO5ztj7SymB6Gq8XWjTyqBU2lT5cAkjxVrveuzouXzUjyR6GtFfVBlqq_OGkGnEil_sA2vkytmvai2alsmQ.isgFDtHwq8ZxW.x_T6kLm0OCE6ItN38- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com> Date: Thu, 30 Jul 2009 13:33:07 -0700 Message-ID: <00a901ca1154$f5085710$df190530$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01CA111A.48A97F10" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJgAADviOAABplL4A== Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] MUSTing P2P states [was RE: Moving forward with the protocol work] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:39:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01CA111A.48A97F10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Pascal, Thanks for your note. I think it needs to be made clear to all contributors of the various requirements documents (urban, home, building, etc) how their specific requirements are addressed in the RPL draft. Otherwise, we won't find enough consensus on the document to have it as a baseline for ROLL. Is there a way to clearly state to Jerry and the authors of the building automation requirements how P2P is enabled (what they have to do in RPL to make it work) and what impact this has (added resources to hold state information, re-propagation of Destination Advertisements, etc.). I think part of the discussion is pointing out that not everyone can map the RPL draft to how the various requirements are being met. Once we understand what is available in terms of P2P support, and what the implications are, then we can figure out if RPL is acceptable as a baseline across all market areas and whether more work can then focus on improving P2P support, loop avoidance, etc. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, July 30, 2009 10:30 AM To: d.sturek@att.net; Jerald.P.Martocci@jci.com Cc: ROLL WG; roll-bounces@ietf.org Subject: MUSTing P2P states [was RE: [Roll] Moving forward with the protocol work] Hi Don: You're correct. If the DAO states are enabled everywhere, the first common parent will route down to the destination. But the doc cannot MUST keeping states in all nodes at the protocol level because there are some use cases where that makes no sense. There might even be a case where no data whatsoever is unicast to the devices, in which case even storing source route paths at the root would be ridiculous. An example of that would be environmental monitoring using widespread cheap sensors. It seems to me that this discussion is caused by a confusion between what belongs to protocol and what belongs to product and deployment. The protocol gives you tools, and then you have to use them intelligently in the products you build. Another confusion I've seen here is that between the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is NOT a ballot. This is just to create a foundation for the WG to work on. So obviously the doc does not have everything ironed out. The question is rather whether the doc is a good foundation for that work at it appears that many people agree on that. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: jeudi 30 juillet 2009 19:00 To: Jerald.P.Martocci@jci.com Cc: 'ROLL WG'; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Jerry, I may have misread the RPL proposal. I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases. I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first). I thought in all cases P2P was supported (just without a mechanism to minimize the hop count). Could someone from the DT comment on the assumptions above? Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts? If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network? I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL... Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work Hi Don, As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil. As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility. Jerry "Don Sturek" 07/30/2009 11:12 AM Please respond to To , "'Mischa Dohler'" cc "'ROLL WG'" , Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00AA_01CA111A.48A97F10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Thanks for your note.

 

I think it needs to be made clear to all contributors of = the various requirements documents (urban, home, building, etc) how their = specific requirements are addressed in the RPL draft.  Otherwise, we = won’t find enough consensus on the document to have it as a baseline for = ROLL.

 

Is there a way to clearly state to Jerry and the authors = of the building automation requirements how P2P is enabled (what they have to = do in RPL to make it work) and what impact this has (added resources to hold state information, re-propagation of Destination Advertisements, etc.).  = I think part of the discussion is pointing out that not everyone can map the RPL = draft to how the various requirements are being met.

 

Once we understand what is available in terms of P2P = support, and what the implications are, then we can figure out if RPL is = acceptable as a baseline across all market areas and whether more work can then focus on improving P2P support, loop avoidance, etc.

 

Don

 

 

From:= Pascal = Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Thursday, July 30, 2009 10:30 AM
To: d.sturek@att.net; Jerald.P.Martocci@jci.com
Cc: ROLL WG; roll-bounces@ietf.org
Subject: MUSTing P2P states [was RE: [Roll] Moving forward with = the protocol work]

 

Hi Don:

 

You’re correct. If the DAO states are enabled = everywhere, the first common parent will route down to the = destination.

 

But the doc cannot MUST keeping states in all nodes at = the protocol level because there are some use cases where that makes no = sense.

There might even be a case where no data whatsoever is = unicast to the devices, in which case even storing source route paths at the = root would be ridiculous. An example of that would be environmental monitoring = using widespread cheap sensors.

 

It seems to me that this discussion is caused by a = confusion between what belongs to protocol and what belongs to product and = deployment. The protocol gives you tools, and then you have to use them = intelligently in the products you build.

 

Another confusion I’ve seen here is that between = the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is = NOT a ballot. This is just to create a foundation for the WG to work on. So = obviously the doc does not have everything ironed out. The question is rather = whether the doc is a good foundation for that work at it appears that many people = agree on that.

 

Cheers,

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Don Sturek
Sent: jeudi 30 juillet 2009 19:00
To: Jerald.P.Martocci@jci.com
Cc: 'ROLL WG'; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol = work

 

Hi Jerry,

 

I may have misread the RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back = down to a device in the DAG and that feature enabled P2P in all cases.  I = thought also the Destination Address notifications for devices with lower = depth/rank could be used by devices within a DAG to more efficiently reroute P2P = traffic within the DAG (not optimally, just “more efficiently than sending = the packet all the way to the DAG root first).  I thought in all cases = P2P was supported (just without a mechanism to minimize the hop = count).

 

Could someone from the DT comment on the assumptions = above?

 

Did I understand that optimizing P2P for building = controls is mainly about minimizing hop counts?   If a building controls = solution could choose between optimizing hop count for P2P and flooding the = network to find the optimal P2P hop count, would it choose to flood the = network?  I think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found so = attractive about RPL…..


Don

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] Moving forward with the protocol = work

 


Hi = Don,

As I = read the draft, RPL doesn't currently guarantee p2p communication regardless of = hop count.  Only if some node higher in the DAG elects to provide a = path back down the DAG to the destination then there is p2p path.  RPL = doesn't mandate this even for the LBR.  Hence a packet could squirt all the = way up to the LBR and still be dropped since the LBR itself has no route = defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not = a router that happens to also do building control.  The likelihood = that a controller sitting higher in the DAG being altruist and defining = pathways to all possible sub-DAG devices is nil.

As for = hops, this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes so = having a packet arrive at its destination a tad late is not too concerning. = (NOTE: Fire and lighting applications are much more time critical).  The = problem is that the source device, typically a battery powered sensor must stay = awake and leave its receiver active until the packet has migrated to its = destination and the application ACK has been received.  This will reduce battery = life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes.  Sure we could have defined = the PAN to be the entire complex and then require 10K nodes as do the other = requirement specs.  Empirical testing however determined that managing 250 = nodes on a single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a floor seems to = be the right balance point for complexity and flexibility.

Jerry =

"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> =

cc=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

Subject=

RE: [Roll] Moving forward with the protocol work

 




Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think = most applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also without = nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and = scales while addressing the various data transmission patterns will result in = anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).  
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work =
 


Hi Mischa,

Nearly all communication in a commercial building facility management = system is point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant.  That is if = the minicomputer 'blew a gasket', the entire building went out of = control.

As soon as it was economically viable, we decentralized control by = moving it down into the rooms.  Now each room was controlled independently = with an array of room sensors and room controllers.  Now if a controller = failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and = is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are destined = to other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will only solve = 75% of the need.


Jerry

Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

 

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work


 

 





JP, all,

We should use this early design stage to come up with one solution - one =
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. =
The MAC folks are getting there and we should take our chance now. 95% =
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with =
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were =
worried about too much. Unless somebody provides me with a convincing =
study, I propose to merely adopt some simple and possibly sub-optimum =
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about =
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about? =
Any node truly to any node? Are we back to pure ad hoc then? I guess if =
IETF couldn't provide us with a magic ultra low power solution for ad =
hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency =
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an =
M2M event in Paris a few months ago organized by Orange where we met =
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would =
never let IP run over their ROLL-type networks. The sheer majority did =
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was excellent =
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several = open
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_00AA_01CA111A.48A97F10-- From d.sturek@att.net Thu Jul 30 13:45:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04AE3A7204 for ; Thu, 30 Jul 2009 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xUvYyAhBzLJ for ; Thu, 30 Jul 2009 13:45:15 -0700 (PDT) Received: from smtp124.sbc.mail.re3.yahoo.com (smtp124.sbc.mail.re3.yahoo.com [66.196.96.97]) by core3.amsl.com (Postfix) with SMTP id 7AFA43A6A02 for ; Thu, 30 Jul 2009 13:45:14 -0700 (PDT) Received: (qmail 7921 invoked from network); 30 Jul 2009 20:45:16 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp124.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 20:45:15 -0000 X-YMail-OSG: ZZkw7y4VM1ntxDKpVdVUkNwFbUZm7eJYTELP.YdG.NbI3xe4jtuNMKPuLGs2xblguYDMRs_udSTgLPrpOOWm5y4qCd.0L9UP_BJ_aqwiIlFhUnEwnLTFrgrZiX_mj73n8UH1eBP.ZEUZqkkxIUTLibsN9j5MaRUyNLw.D6oTpHVdc4FkcXwMhVsnwGcGjNPgyHEMmED9bs7BdDU6XpNMvEVa1WR9.ZgVTEr_DzBVp_KQNzs68Eu0GsgvWwAPGq2OCEdKlf9YdwbgaQPB_ptAo6RJKd1uHLPPCYU0ALkkaOo- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net> In-Reply-To: Date: Thu, 30 Jul 2009 13:45:10 -0700 Message-ID: <00c001ca1156$a2bc4eb0$e834ec10$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01CA111B.F65D76B0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJgAAf/SLA= Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: [Roll] UPDATED: Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:45:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01CA111B.F65D76B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sorry for the confusion on this... When I said "in all cases" in terms of P2P support below, I meant to say that P2P works whether the source/destination are in the same DAG and different rank/depth or in different DAGs. I did understand (or at least I thought I did!) from the RPL draft that these features need to be supported in a particular deployment instance. My later note suggests the ROLL DT map some of the major requirements from the ROLL market area requirements documents (home, urban, industrial, building controls) to how they are addressed in the draft. We can then have a discussion on how well these features are addressed (not whether they are supported!). I think the draft is not yet clear enough on which requirements are met and how. Don From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, July 30, 2009 10:00 AM To: 'Jerald.P.Martocci@jci.com' Cc: 'Mischa Dohler'; 'ROLL WG'; 'roll-bounces@ietf.org' Subject: RE: [Roll] Moving forward with the protocol work Hi Jerry, I may have misread the RPL proposal. I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases. I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first). I thought in all cases P2P was supported (just without a mechanism to minimize the hop count). Could someone from the DT comment on the assumptions above? Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts? If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network? I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL... Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work Hi Don, As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil. As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility. Jerry "Don Sturek" 07/30/2009 11:12 AM Please respond to To , "'Mischa Dohler'" cc "'ROLL WG'" , Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00C1_01CA111B.F65D76B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Sorry for the confusion on = this…..

 

When I said “in all cases” in terms of P2P = support below, I meant to say that P2P works whether the source/destination are in the = same DAG and different rank/depth or in different DAGs.  I did understand = (or at least I thought I did!) from the RPL draft that these features need to be = supported in a particular deployment instance.

 

My later note suggests the ROLL DT map some of the major = requirements from the ROLL market area requirements documents (home, urban, = industrial, building controls) to how they are addressed in the draft.  We can = then have a discussion on how well these features are addressed (not whether they = are supported!).  I think the draft is not yet clear enough on which = requirements are met and how.

 

Don

 

 

From:= Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, July 30, 2009 10:00 AM
To: 'Jerald.P.Martocci@jci.com'
Cc: 'Mischa Dohler'; 'ROLL WG'; 'roll-bounces@ietf.org'
Subject: RE: [Roll] Moving forward with the protocol = work

 

Hi Jerry,

 

I may have misread the RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back = down to a device in the DAG and that feature enabled P2P in all cases.  I = thought also the Destination Address notifications for devices with lower = depth/rank could be used by devices within a DAG to more efficiently reroute P2P = traffic within the DAG (not optimally, just “more efficiently than sending = the packet all the way to the DAG root first).  I thought in all cases P2P was supported (just without a mechanism to minimize the hop = count).

 

Could someone from the DT comment on the assumptions = above?

 

Did I understand that optimizing P2P for building = controls is mainly about minimizing hop counts?   If a building controls = solution could choose between optimizing hop count for P2P and flooding the = network to find the optimal P2P hop count, would it choose to flood the = network?  I think it is the lack of network flooding to establish routes and the = minimal storage of route state information along the route that I found so = attractive about RPL…..


Don

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Thursday, July 30, 2009 9:44 AM
To: d.sturek@att.net
Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org
Subject: RE: [Roll] Moving forward with the protocol = work

 


Hi = Don,

As I = read the draft, RPL doesn't currently guarantee p2p communication regardless of = hop count.  Only if some node higher in the DAG elects to provide a = path back down the DAG to the destination then there is p2p path.  RPL = doesn't mandate this even for the LBR.  Hence a packet could squirt all the = way up to the LBR and still be dropped since the LBR itself has no route = defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not = a router that happens to also do building control.  The likelihood = that a controller sitting higher in the DAG being altruist and defining = pathways to all possible sub-DAG devices is nil.

As for = hops, this is very important too.  Not so much for latency.  The = time constant for most building HVAC  control loops is in minutes so = having a packet arrive at its destination a tad late is not too concerning. = (NOTE: Fire and lighting applications are much more time critical).  The = problem is that the source device, typically a battery powered sensor must stay = awake and leave its receiver active until the packet has migrated to its = destination and the application ACK has been received.  This will reduce battery = life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a = floor which may require upwards to 250 LLN nodes.  Sure we could have defined = the PAN to be the entire complex and then require 10K nodes as do the other = requirement specs.  Empirical testing however determined that managing 250 = nodes on a single wireless domain was difficult enough with regard to channel = management, interference and hop count.  Limiting PAN size to a floor seems to = be the right balance point for complexity and flexibility.

Jerry =

"Don Sturek" <d.sturek@att.net>

07/30/2009 11:12 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> =

cc=

"'ROLL WG'" <roll@ietf.org>, = <roll-bounces@ietf.org>

Subject=

RE: [Roll] Moving forward with the protocol work

 




Hi Jerry,
 
I think RPL does support P2P but does not optimize the number of hops. I = think that is the central issue you and Mukul are bringing up.
 
I do question whether optimizing hops is really necessary.  I think = most applications (including building controls) can take advantage of a = solution that well supports MP2P and P2MP with extensions to provide P2P = capability (admittedly not optimized for hop count/cost but then also without = nearly the overhead of packet flooding or storage of state information that = optimized P2P solutions impose).  
 
I really don’t see that trying (once again as they have in MANET for = some time) to find a single protocol that efficiently implements P2P and scales = while addressing the various data transmission patterns will result in = anything other than the same set of solutions we have today (distance vector with = flooding, link state routing and its derivatives, source routing and its = derivatives).  
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with the protocol work =
 


Hi Mischa,

Nearly all communication in a commercial building facility management = system is point to point.  I'm surprised the other three requirements don't = also have a strong p2p requirement.  Back in the early 80's prior to = processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. =  This centralized model was not scalable nor fault tolerant.  That is if = the minicomputer 'blew a gasket', the entire building went out of = control.

As soon as it was economically viable, we decentralized control by = moving it down into the rooms.  Now each room was controlled independently = with an array of room sensors and room controllers.  Now if a controller = failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and = is the mainstay of building control.  

My point is that is the Commercial Market the LLN is not just a path for = moving data nortbound.  Most of the packets sent on the LLN are destined = to other nodes on the LLN.  They all require application ACKs.  About = 20% of the packets are destined to the LBR and onwards.  These are event = packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock = out the Building Market in its entirety which means at best you will only solve = 75% of the need.


Jerry

Mischa Dohler <mischa.dohler@cttc.es>
Sent by: roll-bounces@ietf.org

07/29/2009 04:18 PM

 

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Moving forward with the protocol work


 

 





JP, all,

We should use this early design stage to come up with one solution - one =
solution which is not necessarily optimum for all cases but for the
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. =
The MAC folks are getting there and we should take our chance now. 95% =
means clearly to concentrate on the core issues, of which loop
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with =
the dynamics of typical ROLL networks, these will give us headaches
within this 95% application quantile. I have read tons of papers
produced in the last decade on routing in ROLL-type networks. Loop
detection and avoidance was clearly not something people (including
those doing practical rollouts and running their companies today) were =
worried about too much. Unless somebody provides me with a convincing =
study, I propose to merely adopt some simple and possibly sub-optimum =
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about =
the p2p paragraph). However, again, are we talking about the 95%
quantile here? Furthermore, how much p2p exactly are you talking about? =
Any node truly to any node? Are we back to pure ad hoc then? I guess if =
IETF couldn't provide us with a magic ultra low power solution for ad =
hoc networks in past years, then chances are slim that this will work =
out now. Unless somebody provides me with a convincing study that
adopting a general p2p ROLL protocol will not jeopardize the efficiency =
of the 95% quantile applications, I propose to adopt some simple and =
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an =
M2M event in Paris a few months ago organized by Orange where we met =
with JP and others. The large majority of companies present there
explicitly told me that - for a very varying set of reasons - they would =
never let IP run over their ROLL-type networks. The sheer majority did =
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
>
> First of all, thanks for all the time and energy you all have = devoted
> during the past few weeks on the protocol work. There was excellent =
> followup discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation
> for the ROLL routing protocol work", there was clearly a good consensus
> in the WG meeting. It was also recognized there are still several = open
> issues for which we WILL need help from many WG contributors, = including
> the authors of other documents.
>
> Could you please confirm (or not) the adoption of = draft-dt-roll-rpl-01
> as a WG document ?
>
> Then we will of course move to the next step.
>
> Thanks,
>
> JP and David
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_00C1_01CA111B.F65D76B0-- From Jerald.P.Martocci@jci.com Thu Jul 30 13:59:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52ADE3A6C3E; Thu, 30 Jul 2009 13:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFm+m6AMSUsr; Thu, 30 Jul 2009 13:59:38 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by core3.amsl.com (Postfix) with ESMTP id 2F4263A693C; Thu, 30 Jul 2009 13:59:38 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKSnIJum2f9HHA8/6J3FTi4l7+Lle+Dma5@postini.com; Thu, 30 Jul 2009 13:59:40 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009073016000471-1042683 ; Thu, 30 Jul 2009 16:00:04 -0500 In-Reply-To: <4A71B613.7000504@sensinode.com> MIME-Version: 1.0 To: Zach Shelby X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 30 Jul 2009 15:59:30 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 07/30/2009 03:59:36 PM, Serialize complete at 07/30/2009 03:59:36 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 04:00:04 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 07/30/2009 04:00:09 PM, Serialize complete at 07/30/2009 04:00:09 PM Content-Type: multipart/alternative; boundary="=_alternative 00734F4F86257603_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:59:45 -0000 This is a multipart message in MIME format. --=_alternative 00734F4F86257603_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Zach, When the design team was formed it stated its plan was to develop a core=20 routing specification that met the needs of all the requirement=20 specifications and then ancillary specifications to meet the specific=20 needs for each of the requirements. RPL as currently written seems=20 perfectly suitable for the MP2P requirement, yet not too suitable for P2P=20 requirement. Could we repackage RPL so that its base spec contains only=20 the generic routing requirements such as 1) using varied metrics to define = path preferences, 2) OCP to advertise path strategy and 3) trickle to=20 cleanly vary periodic requirements. Then RPL-1 could be then enhancements = for MP2P applications and would include the DAG. This would allow us to=20 define a different extension, RPL-2, for P2P requirements that need not be = DAG based. JP has promised that if I just shut-up and give the DT some time, they=20 will provide a solid P2P solution. I am willing to do that. However, I=20 would hate to start compromising the MP2P solution to wedge in a=20 sub-optimal P2P solution. Maybe we can have our cake and eat it too if we = simply repackage the specs a bit. Jerry Zach Shelby =20 Sent by: roll-bounces@ietf.org 07/30/2009 10:02 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Moving forward with the protocol work Hi, Mukul Goyal wrote: > Mischa, >=20 >> We should use this early design stage to come up with one solution -=20 one=20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an approach. = > The MAC folks are getting there and we should take our chance now. 95%=20 > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open. >=20 > When you say a solution, it seems that you want one particular protocol. = I am OK with RPL as a protocol even though it has deficiencies (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the =5Fframework=5F on which all future ROLL work woul= d=20 be based. I am not in support of the use of RPL as a framework unless it=20 eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism). The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach. From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially. Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop prevention. Zach --=20 http://www.sensinode.com 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 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00734F4F86257603_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

Zach,

When the design team was formed it s= tated its plan was to develop a core routing specification that met the needs of all the requirement specifications and then ancillary specifications to meet the specific needs for each of the requirements.  RPL as curre= ntly written seems perfectly suitable for the MP2P requirement, yet not too suitable for P2P requirement.  Could we repackage RPL so that its base spec contains only the generic routing requirements such as 1) using varied metrics to define path preferences, 2) OCP to advertise path strategy and 3) trickle to cleanly vary periodic requirements.  Then RPL-1 could be then enhancements for MP2P applications and would include the DAG.  This would allow us to define a different extension, RPL-2, for P2P requirements that need not be DAG based.

JP has promised that if I just shut-= up and give the DT some time, they will provide a solid P2P solution.  I am willing to do that.  However, I would hate to start compromising the MP2P solution to wedge in a sub-optimal P2P solution.  Maybe we can have our cake and eat it too if we simply repackage the specs a bit.

Jerry




Zach Shelby <zach@= sensinode.com>
Sent by: roll-bounces@ietf.org

07/30/2009 10:02 AM

To
Mukul Goyal <mukul@uwm.edu>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Moving forward with the p= rotocol work





Hi,

Mukul Goyal wrote:
> Mischa,
>
>> We should use this early design stage to come up with one solution - one
> solution which is not necessarily optimum for all cases but for the
> (e.g.) 95% quantile. The PHY guys learned to live with such an approac= h.
> The MAC folks are getting there and we should take our chance now. 95%
> means clearly to concentrate on the core issues, of which loop
> detection/avoidance, p2p and security are somehow still open.
>
> When you say a solution, it seems that you want one particular protoco= l. I am OK with RPL as a protocol even though it has deficiencies (such as
P2P routing). But, the implication of giving it the WG status seems to
be that RPL would be the =5Fframework=5F on which all future ROLL work would
be based. I am not in support of the use of RPL as a framework unless it
eliminates its current tight coupling with DAGs (a, rather heavy duty,
loop prevention mechanism).

The goal of the WG from my understanding, is to produce *one* protocol
in the current charter. RPL is definitely suitable as a starting point
for that protocol (JP said foundation, not framework). I completely
support this approach.

From the industry point of view we need a single solution, which
fulfills application requirements sufficiently and thus can be widely
deployed commercially.

Regarding loop prevention, so what if RPL does a better job than is
necessary? Does it break some requirement doing that? If so, we should
fix it. There are other reasons for using DAGs than just loop prevention.
Zach

--
http://www.sensinode.com
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
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00734F4F86257603_=-- From ryusuke.masuoka@us.fujitsu.com Thu Jul 30 14:21:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DD23A6B54 for ; Thu, 30 Jul 2009 14:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ7-yVJPQsDW for ; Thu, 30 Jul 2009 14:21:25 -0700 (PDT) Received: from fujitsu1.fujitsu.com (fujitsu1.fujitsu.com [192.240.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E233A6AFD for ; Thu, 30 Jul 2009 14:21:25 -0700 (PDT) Received: from fujitsu1.fujitsu.com (localhost [127.0.0.1]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6ULLQ0w010769 for ; Thu, 30 Jul 2009 14:21:26 -0700 (PDT) Received: from mailserv1.fla.fujitsu.com (mailserv1.fla.fujitsu.com [128.8.244.161]) by fujitsu1.fujitsu.com (8.14.2/8.14.2) with ESMTP id n6ULLPXx010746 for ; Thu, 30 Jul 2009 14:21:25 -0700 (PDT) Received: from FLACPR8Y053PC (host-78-64-88-86.homerun.telia.com [78.64.88.86]) (authenticated bits=0) by mailserv1.fla.fujitsu.com (8.13.8/8.13.8) with ESMTP id n6ULLMGt022511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 30 Jul 2009 17:21:24 -0400 From: "Ryusuke Masuoka" To: "'ROLL WG'" References: <4A71B613.7000504@sensinode.com> In-Reply-To: Date: Thu, 30 Jul 2009 17:21:21 -0400 Organization: Fujitsu Laboratories of America, Inc. Message-ID: <014601ca115b$b0629fb0$1127df10$@masuoka@us.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRWeLm0v/vLxfvTnmM/4rPO04RdgAAS8Rw Content-Language: en-us Subject: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryusuke.masuoka@us.fujitsu.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:21:26 -0000 Hi, ROLL WG members, In order to move ahead and for us to determine what we/DADR can contribute, we (Fujitsu) would like to do the following. At the ROLL meeting, we realized that many people are interested in 802.15.4 radio. Our current implementation is on 802.11b radio (1 Mbps) and two wireless characteristics are different. We thought that many ROLL members could not determine how good DADR would be when it is applied to 802.15.4 radio. In that regard: (1) We will provide PER (packet error rate) and other wireless characteristics for both 802.11b (which we already have) and 802.15.4 radios in a couple of weeks. (2) We will share our DADR 802.15.4 radio implementation experiment results by the end of August or in early September. It would be a rather small (50 nodes or so) and preliminary with experiment assumptions, (average) hops, data reachability, etc. (We plan to do a larger experiments (in the order of hundreds of nodes), but it will be somewhat later.) As this is done as a part of system test for customer deployment, we are not sure we can accommodate them all, but please let us know what kinds of things/conditions/assumptions we should incorporate/consider/make in this experiment. We would appreciate your input very much. We also plan to see which LLN requirements DADR meets or not, according to: Overview of Existing Routing Protocols for Low Power and Lossy Networks draft-ietf-roll-protocols-survey-07 so that we can better determine which parts of DADR are useful or not. We will try to be as fair as possible. However, if someone can volunteer to do this, that would be great as we can get a third-party evaluation, we would appreciate it very much and we will support the person/group with the information necessary. (... but I am afraid that everyone other than us is too busy for this.) Regards, Ryu From zach@sensinode.com Thu Jul 30 14:55:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D76D3A6A4E for ; Thu, 30 Jul 2009 14:55:34 -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 rED20G4BZYen for ; Thu, 30 Jul 2009 14:55:33 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0DF913A699C for ; Thu, 30 Jul 2009 14:55:32 -0700 (PDT) Received: from host-78-64-88-8.homerun.telia.com (host-78-64-88-8.homerun.telia.com [78.64.88.8]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n6ULtRri012123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 00:55:28 +0300 Message-ID: <4A7216D2.8040304@sensinode.com> Date: Fri, 31 Jul 2009 00:55:30 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:55:34 -0000 Jerry, Jerald.P.Martocci@jci.com wrote: > > > Zach, > > When the design team was formed it stated its plan was to develop a core > routing specification that met the needs of all the requirement > specifications and then ancillary specifications to meet the specific > needs for each of the requirements. RPL as currently written seems > perfectly suitable for the MP2P requirement, yet not too suitable for > P2P requirement. Could we repackage RPL so that its base spec contains > only the generic routing requirements such as 1) using varied metrics to > define path preferences, 2) OCP to advertise path strategy and 3) > trickle to cleanly vary periodic requirements. Then RPL-1 could be then > enhancements for MP2P applications and would include the DAG. This > would allow us to define a different extension, RPL-2, for P2P > requirements that need not be DAG based. We all agree that RPL currently only contains basic P2P support using the DV state built up on the DAG. I also agree with you that the wording on keeping DV state in routers (within memory constraints) should be fixed (easy). There is definitely consensus that the next version needs a solid P2P mechanism. There is no reason that an additional P2P feature would be suboptimal with the DAG - I see them as being complimentary. > JP has promised that if I just shut-up and give the DT some time, they > will provide a solid P2P solution. I am willing to do that. However, I > would hate to start compromising the MP2P solution to wedge in a > sub-optimal P2P solution. Maybe we can have our cake and eat it too if > we simply repackage the specs a bit. This is just -01 of this draft, so JP is right ;-) The DT was clear this is an early draft and that P2P is coming. So... on the P2P front, it would be great to see contributions to the WG on how to include suitable P2P support to RPL. The thing about a WG document - is that we work together on it. Zach > Jerry > > > > > *Zach Shelby * > Sent by: roll-bounces@ietf.org > > 07/30/2009 10:02 AM > > > To > Mukul Goyal > cc > ROLL WG > Subject > Re: [Roll] Moving forward with the protocol work > > > > > > > > > Hi, > > Mukul Goyal wrote: > > Mischa, > > > >> We should use this early design stage to come up with one solution - > one > > solution which is not necessarily optimum for all cases but for the > > (e.g.) 95% quantile. The PHY guys learned to live with such an approach. > > The MAC folks are getting there and we should take our chance now. 95% > > means clearly to concentrate on the core issues, of which loop > > detection/avoidance, p2p and security are somehow still open. > > > > When you say a solution, it seems that you want one particular > protocol. I am OK with RPL as a protocol even though it has deficiencies > (such as > P2P routing). But, the implication of giving it the WG status seems to > be that RPL would be the _framework_ on which all future ROLL work would > be based. I am not in support of the use of RPL as a framework unless it > eliminates its current tight coupling with DAGs (a, rather heavy duty, > loop prevention mechanism). > > The goal of the WG from my understanding, is to produce *one* protocol > in the current charter. RPL is definitely suitable as a starting point > for that protocol (JP said foundation, not framework). I completely > support this approach. > > From the industry point of view we need a single solution, which > fulfills application requirements sufficiently and thus can be widely > deployed commercially. > > Regarding loop prevention, so what if RPL does a better job than is > necessary? Does it break some requirement doing that? If so, we should > fix it. There are other reasons for using DAGs than just loop prevention. > > Zach > > -- > http://www.sensinode.com > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- http://www.sensinode.com 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 Matthew.Anderson@us.elster.com Thu Jul 30 15:06:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4453A6CA5 for ; Thu, 30 Jul 2009 15:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDfPAzXox0jh for ; Thu, 30 Jul 2009 15:06:38 -0700 (PDT) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id AE70A3A6A35 for ; Thu, 30 Jul 2009 15:06:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-15.tower-53.messagelabs.com!1248991599!30663786!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 18459 invoked from network); 30 Jul 2009 22:06:40 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-15.tower-53.messagelabs.com with SMTP; 30 Jul 2009 22:06:40 -0000 To: ROLL WG MIME-Version: 1.0 X-KeepSent: FBBFD1C0:A25CDD21-85257603:0078BFFD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Matthew.Anderson@us.elster.com Date: Fri, 31 Jul 2009 00:06:41 +0200 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5 HF460|May 15, 2009) at 07/30/2009 06:05:25 PM, Serialize complete at 07/30/2009 06:05:25 PM Content-Type: multipart/alternative; boundary="=_alternative 00797579C1257603_=" Subject: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 22:06:39 -0000 This is a multipart message in MIME format. --=_alternative 00797579C1257603_= Content-Type: text/plain; charset="US-ASCII" I think everyone acknowledges that there are areas (P2P, security) to resolve. But if adopting RPL as the WG document means that the WG as a whole can work together to design the best solution, I think that is the best course of action. I'm admittedly new to the IETF process but that's my understanding of what the goal of adopting RPL is - to provide a basis to work from as a working group and RPL version X may be very different than RPL version 1. Matt Anderson --=_alternative 00797579C1257603_= Content-Type: text/html; charset="US-ASCII" I think everyone acknowledges that there are areas (P2P, security) to resolve.  But if adopting RPL as the WG document means that the WG as a whole can work together to design the best solution, I think that is the best course of action.  I'm admittedly new to the IETF process but that's my understanding of what the goal of adopting RPL is - to provide a basis to work from as a working group and RPL version X may be very different than RPL version 1.

Matt Anderson
--=_alternative 00797579C1257603_=-- From privateanand@gmail.com Thu Jul 30 16:00:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CD13A6841 for ; Thu, 30 Jul 2009 16:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIrwtwY9Fjg9 for ; Thu, 30 Jul 2009 16:00:52 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id A43653A6CA2 for ; Thu, 30 Jul 2009 16:00:51 -0700 (PDT) Received: by yxe3 with SMTP id 3so1481633yxe.29 for ; Thu, 30 Jul 2009 16:00:51 -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; bh=dcJHQiSVgCnjTbgHhu/OS6ySEhEhk5L3SmaTGnuQiHw=; b=JlijGBCzrvtH3/LUmy9V+1E99hIUOXBdczlFazzZZ5jD7mzzPXe1G+xo5oRnI6eXnC LdGX4PY+x9XPcoFWPTzNoxZjm12ZTiiagn+FLNGXHA1D0A7YBeNT9bYtLZO2VoF/u0it lt9FhQFDouXPnbw7xnlXf2RJZiK4zKA3HH+WI= 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; b=SkJGICnmhpz/VI3Q4fFxrtBdT10z/hEeQHarEMvxJoedZYzQBHYY7VFyT1CNPRYKLh 9l84X3Ae/RjmJMzIXT5QMuBEsuQWt5VNDi2YL/R9ZgTzWNCqc77hhM0+6t6Bqu/ivQ4C HrEYp+fdk0MtuM+KcTSCuPQ8zSsWlRPRbyoPk= MIME-Version: 1.0 Received: by 10.231.11.130 with SMTP id t2mr469582ibt.51.1248994850743; Thu, 30 Jul 2009 16:00:50 -0700 (PDT) In-Reply-To: References: <4A721545.8060304@ekasystems.com> Date: Thu, 30 Jul 2009 19:00:50 -0400 Message-ID: From: M Anand To: roll@ietf.org Content-Type: multipart/alternative; boundary=000325574c9667a5bd046ff446b6 Subject: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 23:01:39 -0000 --000325574c9667a5bd046ff446b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would support adoption of draft-dt-roll-rpl-01 as a WG document based on the reasoning below. The one area of (I think quite valid) concern appears to be optimal P2P routing or lack thereof. I would make the following points with regard to this: 1. I think first there seems to be some misinterpretation because I see references to nodes within direct physical range, light switch/light etc. in the discussion. RPL as it stands would let a node in direct contact with another route directly to that node. No need to go up and down a DAG. I think this was in one of the examples in the slide presentation in the mtg. and, if I recall correctly, someone explcitly asked this question. 2. So, we are not talking about P2P route sub-optimality in RPL when there is a one-hop route. And I sure would hope that a light switch would be in direct physical range of its light. We can leave aside these cases when debating the possible P2P demerits of the present RPL. 3. The issue arises when there is a 2 or more edge shortest path between nodes in the base connectivity graph, but that path does not contain a parent common to the nodes in the induced DAG rooted at some node (LBR or other) that RPL would produce. *Significant* differences in the length of the path in the two cases, would really only arise when the base graph is very sparsely connected *and* of large diameter. I would suspect, certainly in the home, and in most cases in commercial buildings that the graphs are not like that. I am tempted to go out on a limb and leave out the "suspect" - it might be interesting to analyze a decent dataset of random graphs or actual connectivity graphs in the application scenarios if someone can produce them (oops...did I just volunteer for something ?) 4. If an application is interested in mutliple P2MP/MP2P rather than total P2P, RPL can take us there as well. 5. The DAG (or tree) formation out of the original graph is intended to simplify the routing problem and minimize state information. I would submit that the spectrum of things one can do, in order of increasing state and complexity would be: a. Induce a tree and route along it ----- suited for P2MP/MP2P b. Induce a DAG and route along it ----- same with more redundancy c. Induce multiple DAGs ----- multi - P2MP/MP2P d. Route along base graph ----- complete P2P RPL sits at b & c and occupies the solid middle ground. 5. If d is the desire, a couple of points to note (this one and #6 below). First, I think in that case there is a not a whole lot to do other than make every node maintain and disseminate routing state for every other node. Sure, we can play some tricks and prune some nodes that don't participate in the interesting paths, but all this will come with a price - and when it is paid the price will be steep - because intelligent decisions here will require global information and not local information. And it may change with time. Next thing we know, that one node that pruned itself out of the picture with regard to a certain flow, is the *the* guy for an optimal path five years later for a newly installed node and the alternative is vastly longer. Everyone can *see* there is a 2-hop path and wonder why it takes 5 hops. The point is, without knowledge of whole topology these local decisions can cause major trouble and defeat the original intent, which was optimal P2P. I would suggest that the best and only thing to do if we want to do d) is to go all the way and make sure the network can deal with the large state information. 6. I can fully understand Jerry's "diatribe", as he called it in a recent post. Rest assured Jerry, I, and I am sure many of us, have had occasion to say similar things. But I think it illustrates a point. If our radios were to do the equivalent of what the wire did for us, i.e., make every node reach every other node and create a complete graph, from a routing perspective RPL would be absolutely no worse than any P2P. If the radio did only somewhat worse in providing connectivity, RPL may correspondingly also do slightly worse. But. It would do vastly better for a several thousand node network spread over a city. 7. And that I think summarizes the argument for moving forward with RPL - not for stopping where it stands, just moving forward with it is a basis. It is not going to be everything for everyone, but I think it is going be a very large something for almost everyone, including home/bldg. control. Best regards, Anand. On Thu, Jul 30, 2009 at 5:48 PM, M. B. Anand wrote: > > > -------- Original Message -------- > Subject: [Roll] Moving forward with the protocol work > Date: Tue, 28 Jul 2009 18:34:24 +0200 > From: JP Vasseur > To: ROLL WG > > > > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation for > the ROLL routing protocol work", there was clearly a good consensus in the > WG meeting. It was also recognized there are still several open issues for > which we WILL need help from many WG contributors, including the authors of > other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as > a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > --000325574c9667a5bd046ff446b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would support adoptio= n of draft-dt-roll-rpl-01 =A0as a WG document based on the reasoning below.=

--000325574c9667a5bd046ff446b6-- From mischa.dohler@cttc.es Thu Jul 30 16:02:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A463A6C85 for ; Thu, 30 Jul 2009 16:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdagfPGziMsV for ; Thu, 30 Jul 2009 16:02:14 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 2F4823A68F0 for ; Thu, 30 Jul 2009 16:02:13 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n6UN0VO9025322; Fri, 31 Jul 2009 01:00:31 +0200 Received: from [127.0.0.1] (108.Red-88-3-40.dynamicIP.rima-tde.net [88.3.40.108]) by castor (Postfix) with ESMTP id 587E62FC282; Fri, 31 Jul 2009 01:00:29 +0200 (CEST) Message-ID: <4A72260C.3040005@cttc.es> Date: Fri, 31 Jul 2009 01:00:28 +0200 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090730-0, 30/07/2009), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Fri, 31 Jul 2009 01:00:31 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 23:02:16 -0000 Hi Jerry, my understanding of p2p was slightly different in that I thought you assumed a (flat) architecture where every node needs to talk to any other node. From your description - and what I also had in mind - it seems that some nodes (e.g. sensors) wish to communicate with an order of magnitude lower number of nodes (e.g. actuators, distributed central units). In my opinion, this difference in order of magnitude changes quite a bit in the protocol design. Mischa. Jerald.P.Martocci@jci.com wrote: > > > Hi Julien, > > Section 3 of the Building Requirements ID describes the typical devices > and device densities in a commercial building; Section 6 describes the > traffic flow. Let me try to reiterate here ... > > The building control application domain includes Heating Ventilation and > Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and > Fire control. While each has its nuances, they all fall roughly onto > the same topology. The leaf layer for these systems are the sensors. > There's a plethora of them including temperature sensors, humidity > sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, > occupancy sensors, light switches, and the list goes on. In a room, you > might expect a temp sensor, a humidity sensor, an occupancy sensor, > solar sensor, smoke detector and light switches. > > Now along with the room sensors, there are room actuators and room > controllers. The controllers receive the environmental data from the > sensors, and determine the necessary control based on conditions, system > overrides, time-of-day, etc and then control the environment by tweaking > the actuators accordingly. The HVAC system will modulate the airflow > and augment heating/cooling. The shade controller will sense solar load > and adjust the shades. The lighting will be adjusted as requested by > the presentation mode. When I talk about a room, I am not meaning > necessarily only a closed door meeting room. This would also apply to > public spaces such as an attria, hallways, ballrooms.etc. The key > ingredient in this is that each of these areas has a self contained > sensor/controller/actuator subsystem. > > Now, the next layer of controllers are the zone and area controllers. > These are higher level devices that supply the facility with more > global control systems. HVAC will have air handlers that supply fresh > air to the rooms. Chillers that support cold air to the rooms, boilers > that supply heat. Lighting panels will control whole floors rather than > simply rooms. The point being that these higher order devices are also > LLN devices incorporating another whole set of sensors such as outdoor > air temp, relative humidity, etc. > > With regards to your question about layer 2, at present these devices > are not IP devices. They typically reside on an EIA-485 network. > > Hope this helps, > > Jerry > > > > > *"Julien Abeille (jabeille)" * > > 07/30/2009 11:07 AM > > > To > , "Mischa Dohler" > cc > "ROLL WG" , > Subject > RE: [Roll] Moving forward with the protocol work > > > > > > > > > Hi Jerald, > > just to understand better the setup in commercial buildings: in a > typical scenario, which devices / how many are present in a room, what > is the layer 2 topology and the p2p application flows? > > Thank you, > Julien > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Jerald.P.Martocci@jci.com* > Sent:* jeudi 30 juillet 2009 17:58* > To:* Mischa Dohler* > Cc:* ROLL WG; roll-bounces@ietf.org* > Subject:* Re: [Roll] Moving forward with the protocol work > > > > Hi Mischa, > > Nearly all communication in a commercial building facility management > system is point to point. I'm surprised the other three requirements > don't also have a strong p2p requirement. Back in the early 80's prior > to processor based sensors, we deployed 'dumb sensors' that would simply > upload their current environmental information to a centralized > minicomputer. This centralized model was not scalable nor fault > tolerant. That is if the minicomputer 'blew a gasket', the entire > building went out of control. > > As soon as it was economically viable, we decentralized control by > moving it down into the rooms. Now each room was controlled > independently with an array of room sensors and room controllers. Now > if a controller failed, only the room might lose control, not the entire > complex. The room controllers were then further controlled by higher > level controllers. This distributed architecture has been in place for > 25 years and is the mainstay of building control. > > My point is that is the Commercial Market the LLN is not just a path for > moving data nortbound. Most of the packets sent on the LLN are destined > to other nodes on the LLN. They all require application ACKs. About > 20% of the packets are destined to the LBR and onwards. These are event > packets being sent to the higher layers for further analysis. > > If we don't support a robust p2p protocol option in ROLL, we will knock > out the Building Market in its entirety which means at best you will > only solve 75% of the need. > > > Jerry > > > > *Mischa Dohler * > Sent by: roll-bounces@ietf.org > > 07/29/2009 04:18 PM > > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] Moving forward with the protocol work > > > > > > > > > > > JP, all, > > We should use this early design stage to come up with one solution - one > solution which is not necessarily optimum for all cases but for the > (e.g.) 95% quantile. The PHY guys learned to live with such an approach. > The MAC folks are getting there and we should take our chance now. 95% > means clearly to concentrate on the core issues, of which loop > detection/avoidance, p2p and security are somehow still open. > > I do understand the concept of loops arising. I have doubts that with > the dynamics of typical ROLL networks, these will give us headaches > within this 95% application quantile. I have read tons of papers > produced in the last decade on routing in ROLL-type networks. Loop > detection and avoidance was clearly not something people (including > those doing practical rollouts and running their companies today) were > worried about too much. Unless somebody provides me with a convincing > study, I propose to merely adopt some simple and possibly sub-optimum > heuristics and then forget about it. > > P2P seems to worry some of us (sorry, Jerry, for having forgotten about > the p2p paragraph). However, again, are we talking about the 95% > quantile here? Furthermore, how much p2p exactly are you talking about? > Any node truly to any node? Are we back to pure ad hoc then? I guess if > IETF couldn't provide us with a magic ultra low power solution for ad > hoc networks in past years, then chances are slim that this will work > out now. Unless somebody provides me with a convincing study that > adopting a general p2p ROLL protocol will not jeopardize the efficiency > of the 95% quantile applications, I propose to adopt some simple and > possibly sub-optimum heuristics and then forget about it. > > Security is an important issue. > > Now that we are at it, I sampled quite a large number of companies at an > M2M event in Paris a few months ago organized by Orange where we met > with JP and others. The large majority of companies present there > explicitly told me that - for a very varying set of reasons - they would > never let IP run over their ROLL-type networks. The sheer majority did > suprise me. We still have a lot of work ahead. > > I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. > > Mischa. > > > > > > > JP Vasseur wrote: > > Dear WG, > > > > First of all, thanks for all the time and energy you all have devoted > > during the past few weeks on the protocol work. There was excellent > > followup discussion at the physical WG meeting. > > > > To the question "Do you think that RPL provides an adequate foundation > > for the ROLL routing protocol work", there was clearly a good consensus > > in the WG meeting. It was also recognized there are still several open > > issues for which we WILL need help from many WG contributors, including > > the authors of other documents. > > > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > > as a WG document ? > > > > Then we will of course move to the next step. > > > > Thanks, > > > > JP and David > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From dominique.barthel@orange-ftgroup.com Fri Jul 31 00:13:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8869E3A6EB4 for ; Fri, 31 Jul 2009 00:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_57=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+rftijs8m2k for ; Fri, 31 Jul 2009 00:13:05 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 495E53A6CBC for ; Fri, 31 Jul 2009 00:13:05 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 09:13:01 +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, 31 Jul 2009 09:10:35 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF492D14@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoRVfDQm+J1O6riSZK5PgLqDyi7DAAViSpQ References: From: To: X-OriginalArrivalTime: 31 Jul 2009 07:13:01.0664 (UTC) FILETIME=[5717CE00:01CA11AE] Cc: roll@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:13:06 -0000 Hi Jerry, all, Thanks for the detailed description of the Building Automation setting. I'm wondering if you could propose an estimate of how many multi-hop P2P routes an average node would sit on? So that we can gauge the consequences of potential P2P routing algorithms on nodes' memory/energy limits... As suggested by somebody else (sorry I lost track who it was), it would seem that many P2P flows in a given "room" are direct connections with no (control plane)routing involved. Am I totally mistaken on this? Regards, Dominique -----------------------=20 Date: Thu, 30 Jul 2009 14:12:10 -0500 From: Jerald.P.Martocci@jci.com Subject: Re: [Roll] Moving forward with the protocol work To: "Julien Abeille (jabeille)" Cc: ROLL WG , roll-bounces@ietf.org Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Julien, Section 3 of the Building Requirements ID describes the typical devices and device densities in a commercial building; Section 6 describes the traffic flow. Let me try to reiterate here ... The building control application domain includes Heating Ventilation and Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and Fire control. While each has its nuances, they all fall roughly onto the same topology. The leaf layer for these systems are the sensors. There's a plethora of them including temperature sensors, humidity sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, occupancy sensors, light switches, and the list goes on. In a room, you might expect a temp sensor, a humidity sensor, an occupancy sensor, solar sensor, smoke detector and light switches.=20 Now along with the room sensors, there are room actuators and room controllers. The controllers receive the environmental data from the sensors, and determine the necessary control based on conditions, system overrides, time-of-day, etc and then control the environment by tweaking the actuators accordingly. The HVAC system will modulate the airflow and augment heating/cooling. The shade controller will sense solar load and adjust the shades. The lighting will be adjusted as requested by the presentation mode. When I talk about a room, I am not meaning necessarily only a closed door meeting room. This would also apply to public spaces such as an attria, hallways, ballrooms.etc. The key ingredient in this is that each of these areas has a self contained sensor/controller/actuator subsystem. Now, the next layer of controllers are the zone and area controllers.=20 These are higher level devices that supply the facility with more global control systems. HVAC will have air handlers that supply fresh air to the rooms. Chillers that support cold air to the rooms, boilers that supply heat. Lighting panels will control whole floors rather than simply rooms.=20 The point being that these higher order devices are also LLN devices incorporating another whole set of sensors such as outdoor air temp, relative humidity, etc. With regards to your question about layer 2, at present these devices are not IP devices. They typically reside on an EIA-485 network. Hope this helps, Jerry From prvs=4562201ce=mukul@uwm.edu Fri Jul 31 04:27:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDEB3A6C60; Fri, 31 Jul 2009 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 mZ+FZDFJxK1Q; Fri, 31 Jul 2009 04:27:07 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 3C3453A6A1F; Fri, 31 Jul 2009 04:27:07 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 31 Jul 2009 06:26:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 20D4CC085AE; Fri, 31 Jul 2009 06:26:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIkKHesGp0gp; Fri, 31 Jul 2009 06:26:48 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C679AC085B1; Fri, 31 Jul 2009 06:26:46 -0500 (CDT) Date: Fri, 31 Jul 2009 06:26:46 -0500 (CDT) From: Mukul Goyal To: Jerald P Martocci Message-ID: <16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <551598593.6702601249038752130.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:30:09 -0000 I absolutely support the approach Jerry suggested: 1) The foundation should be as simple as possible - a simple distance vecto= r approach (I hope there is an agreement on this) describing next-hop selec= tion based on routing metrics defined in the routing metrics draft, constra= ints and strategies (OCP) and basic rules to decide when to generate RAs. T= he foundation should not include any mechanism to deal with loops (so, it s= hould not include DAGs unless DAGs can be shown to be critical in meeting o= ther essential requirements). 2) Additional document(s) suggesting solutions catered towards MP2P and/or = P2P routing using different mechanisms to deal with loops (including DAGs). Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Zach Shelby" Cc: "Mukul Goyal" , "ROLL WG" , roll-bounces@= ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Zach,=20 When the design team was formed it stated its plan was to develop a core ro= uting specification that met the needs of all the requirement specification= s and then ancillary specifications to meet the specific needs for each of = the requirements. =C2=A0RPL as currently written seems perfectly suitable f= or the MP2P requirement, yet not too suitable for P2P requirement. =C2=A0Co= uld we repackage RPL so that its base spec contains only the generic routin= g requirements such as 1) using varied metrics to define path preferences, = 2) OCP to advertise path strategy and 3) trickle to cleanly vary periodic r= equirements. =C2=A0Then RPL-1 could be then enhancements for MP2P applicati= ons and would include the DAG. =C2=A0This would allow us to define a differ= ent extension, RPL-2, for P2P requirements that need not be DAG based.=20 JP has promised that if I just shut-up and give the DT some time, they will= provide a solid P2P solution. =C2=A0I am willing to do that. =C2=A0However= , I would hate to start compromising the MP2P solution to wedge in a sub-op= timal P2P solution. =C2=A0Maybe we can have our cake and eat it too if we s= imply repackage the specs a bit.=20 Jerry=20 Zach Shelby =20 Sent by: roll-bounces@ietf.org=20 07/30/2009 10:02 AM =09 To =09Mukul Goyal =20 cc =09ROLL WG =20 Subject =09Re: [Roll] Moving forward with the protocol work=20 =09 Hi,=20 Mukul Goyal wrote:=20 > Mischa,=20 >=20 >> We should use this early design stage to come up with one solution - one= =20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an approach.= =20 > The MAC folks are getting there and we should take our chance now. 95%=20 > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open.=20 >=20 > When you say a solution, it seems that you want one particular protocol. = I am OK with RPL as a protocol even though it has deficiencies (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would=20 be based. I am not in support of the use of RPL as a framework unless it=20 eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism).=20 The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach.=20 >From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially.=20 Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop prevention.= =20 Zach=20 --=20 http://www.sensinode.com=20 http://zachshelby.org - My blog =E2=80=9COn the Internet of Things=E2=80=9D= =20 Mobile: +358 40 7796297=20 Zach Shelby=20 Head of Research=20 Sensinode Ltd.=20 Kidekuja 2=20 88610 Vuokatti, FINLAND=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From d.sturek@att.net Fri Jul 31 05:18:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9344B3A6D7B for ; Fri, 31 Jul 2009 05:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfeXDIgJRSh6 for ; Fri, 31 Jul 2009 05:18:22 -0700 (PDT) Received: from smtp116.sbc.mail.re3.yahoo.com (smtp116.sbc.mail.re3.yahoo.com [66.196.96.89]) by core3.amsl.com (Postfix) with SMTP id 243363A6DE6 for ; Fri, 31 Jul 2009 05:18:22 -0700 (PDT) Received: (qmail 61541 invoked from network); 31 Jul 2009 12:11:44 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp116.sbc.mail.re3.yahoo.com with SMTP; 31 Jul 2009 12:11:43 -0000 X-YMail-OSG: K8vZeZcVM1lLxT7eBguAO378F8a9igpabM8Hjms.3poQa5bWLF9YmyRlUGZo68rc6fiV42ES1ITiWxX8n6QMQo5MgOVqxlQfUOquZMafvckqkY9Lz0jGWfsdCbY_2m6EqM0hMyghqp8PD0LL8kT.F7vbMwC6BBpOfo7UFkjTkbc2EiO821JbDBNMnj_0GrKwNOCIliyEMZcAr8C6qcNFV1sjCa9YZXLaf.d2UXqbMfrlxxxGI9Vpfzrqx07s5sfmbYU6.ntSnA17b0z4V66t7rJLutSKr8eoi.kvNSU7_QIJMsHt6EEM0toGMJvhFOM- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" , "'Jerald P Martocci'" References: <551598593.6702601249038752130.JavaMail.root@mail02.pantherlink.uwm.edu> <16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 31 Jul 2009 05:11:38 -0700 Message-ID: <001101ca11d8$102811b0$30783510$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoR0kdFZlpe0P+IQSK2BFl6L+BKBgABT/ew Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:18:22 -0000 Hi Mukul, I don't agree that the alternate solutions proposed for ROLL scale and = could support requirements outside building controls. Specifically, I = believe that the non-DAG solutions will require state information = retention which will limit deployment beyond a modest number of nodes in = the network. I believe the opposite as to what is proposed below. I would propose = using the RPL proposal as the baseline and provide some mechanisms to = support optimization of P2P traffic. =20 Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mukul Goyal Sent: Friday, July 31, 2009 4:27 AM To: Jerald P Martocci Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work I absolutely support the approach Jerry suggested: 1) The foundation should be as simple as possible - a simple distance = vector approach (I hope there is an agreement on this) describing = next-hop selection based on routing metrics defined in the routing = metrics draft, constraints and strategies (OCP) and basic rules to = decide when to generate RAs. The foundation should not include any = mechanism to deal with loops (so, it should not include DAGs unless DAGs = can be shown to be critical in meeting other essential requirements). 2) Additional document(s) suggesting solutions catered towards MP2P = and/or P2P routing using different mechanisms to deal with loops = (including DAGs). Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Zach Shelby" Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Zach,=20 When the design team was formed it stated its plan was to develop a core = routing specification that met the needs of all the requirement = specifications and then ancillary specifications to meet the specific = needs for each of the requirements. RPL as currently written seems = perfectly suitable for the MP2P requirement, yet not too suitable for = P2P requirement. Could we repackage RPL so that its base spec contains = only the generic routing requirements such as 1) using varied metrics to = define path preferences, 2) OCP to advertise path strategy and 3) = trickle to cleanly vary periodic requirements. Then RPL-1 could be then = enhancements for MP2P applications and would include the DAG. This = would allow us to define a different extension, RPL-2, for P2P = requirements that need not be DAG based.=20 JP has promised that if I just shut-up and give the DT some time, they = will provide a solid P2P solution. I am willing to do that. However, I = would hate to start compromising the MP2P solution to wedge in a = sub-optimal P2P solution. Maybe we can have our cake and eat it too if = we simply repackage the specs a bit.=20 Jerry=20 Zach Shelby =20 Sent by: roll-bounces@ietf.org=20 07/30/2009 10:02 AM =09 To Mukul Goyal =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work=20 =09 Hi,=20 Mukul Goyal wrote:=20 > Mischa,=20 >=20 >> We should use this early design stage to come up with one solution - = one=20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an = approach.=20 > The MAC folks are getting there and we should take our chance now. 95% = > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open.=20 >=20 > When you say a solution, it seems that you want one particular = protocol. I am OK with RPL as a protocol even though it has deficiencies = (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would = be based. I am not in support of the use of RPL as a framework unless it = eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism).=20 The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach.=20 >From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially.=20 Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop = prevention.=20 Zach=20 --=20 http://www.sensinode.com=20 http://zachshelby.org - My blog =E2=80=9COn the Internet of = Things=E2=80=9D=20 Mobile: +358 40 7796297=20 Zach Shelby=20 Head of Research=20 Sensinode Ltd.=20 Kidekuja 2=20 88610 Vuokatti, FINLAND=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 31 05:26:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCA03A6847; Fri, 31 Jul 2009 05:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=1.050, 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 iE-Fusia17Mh; Fri, 31 Jul 2009 05:26:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A0ACA3A67B3; Fri, 31 Jul 2009 05:26:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAALd/ckqQ/uCLe2dsb2JhbACVZYMMgSoBARYkBp4tiCeQOAWEF4lw X-IronPort-AV: E=Sophos;i="4.43,302,1246838400"; d="scan'208";a="46205475" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2009 12:26:19 +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 n6VCQJqQ009387; Fri, 31 Jul 2009 14:26:19 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VCQJYh003037; Fri, 31 Jul 2009 12:26:19 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 14:26:19 +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: Fri, 31 Jul 2009 14:26:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E202F2@xmb-ams-337.emea.cisco.com> In-Reply-To: <001101ca11d8$102811b0$30783510$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoR0kdFZlpe0P+IQSK2BFl6L+BKBgABT/ewAACGo0A= References: <551598593.6702601249038752130.JavaMail.root@mail02.pantherlink.uwm.edu><16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> <001101ca11d8$102811b0$30783510$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Mukul Goyal" , "Jerald P Martocci" X-OriginalArrivalTime: 31 Jul 2009 12:26:19.0245 (UTC) FILETIME=[1B5309D0:01CA11DA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8560; t=1249043179; x=1249907179; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=k39fuQdXMuF3ljAkFtOyVrhOEEC6pnMO0s7vWfvXSto=; b=jB38MCc+fWxkKjMbE1j+dHvQ0UvZ0o21vBd3E1S5YZtklvQXu7Oe3U4jfx kyTR8gwa3QUJzfJaSSXOjynBD0wXHvNb4ulL4GrNgZajfo+EwRgrGAWrQ893 ENBGbn5L7m; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:26:20 -0000 SGkgRG9uOg0KDQpJJ20gYWxsIHdpdGggeW91IGhlcmUuIE9wdGltaXplZCBQMlAgZm9yIGFsbCBj b21lcyBhdCBhIGNvc3QsIGluIHBhcnRpY3VsYXIgaW4gdGVybXMgb2Ygc3RhdGVzIGluIHRoZSBu b2RlcywgYW5kIGlzIGNsZWFybHkgYSBzZWNvbmRhcnkgcHJpb3JpdHkgZm9yIFJPTEwuIE9UT0gs IGluIGEgdXNlIGNhc2Ugd2hlcmUgYWxsIG5vZGVzIGNhbiByZWFsbHkgYWZmb3JkIGFsbCB0aGUg c3RhdGVzIGludm9sdmVkLCB0aGUgcHJvYmxlbSBzZWVtcyB0byBkcmlmdCBvdXRzaWRlIHRoZSBS T0xMIGNoYXJ0ZXIgYW5kIGJhY2sgaW4gdGhlIE1BTkVUIHdvcmxkLg0KDQpST0xMIGRvZXMgbm90 IGNvbXBldGUgd2l0aCBNQU5FVCBhbmQgZGVmZXJzIHRvIHRoZSBNQU5FVCB3b3JrIHdoZXJlIGl0 IGFwcGxpZXMuDQoNClBhc2NhbA0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEb24gU3R1cmVrDQo+U2VudDogdmVuZHJlZGkgMzEganVpbGxldCAyMDA5IDE0 OjEyDQo+VG86ICdNdWt1bCBHb3lhbCc7ICdKZXJhbGQgUCBNYXJ0b2NjaScNCj5DYzogJ1JPTEwg V0cnOyByb2xsLWJvdW5jZXNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW1JvbGxdIE1vdmluZyBm b3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcmsNCj4NCj5IaSBNdWt1bCwNCj4NCj5JIGRvbid0 IGFncmVlIHRoYXQgdGhlIGFsdGVybmF0ZSBzb2x1dGlvbnMgcHJvcG9zZWQgZm9yIFJPTEwgc2Nh bGUgYW5kIGNvdWxkIHN1cHBvcnQgcmVxdWlyZW1lbnRzIG91dHNpZGUNCj5idWlsZGluZyBjb250 cm9scy4gIFNwZWNpZmljYWxseSwgSSBiZWxpZXZlIHRoYXQgdGhlIG5vbi1EQUcgc29sdXRpb25z IHdpbGwgcmVxdWlyZSBzdGF0ZSBpbmZvcm1hdGlvbg0KPnJldGVudGlvbiB3aGljaCB3aWxsIGxp bWl0IGRlcGxveW1lbnQgYmV5b25kIGEgbW9kZXN0IG51bWJlciBvZiBub2RlcyBpbiB0aGUgbmV0 d29yay4NCj4NCj5JIGJlbGlldmUgdGhlIG9wcG9zaXRlIGFzIHRvIHdoYXQgaXMgcHJvcG9zZWQg YmVsb3cuICBJIHdvdWxkIHByb3Bvc2UgdXNpbmcgdGhlIFJQTCBwcm9wb3NhbCBhcyB0aGUgYmFz ZWxpbmUNCj5hbmQgcHJvdmlkZSBzb21lIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBvcHRpbWl6YXRp b24gb2YgUDJQIHRyYWZmaWMuDQo+DQo+QmVzdCBSZWdhcmRzLA0KPg0KPkRvbiBTdHVyZWsNCj4N Cj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHJvbGwtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11a3VsIEdv eWFsDQo+U2VudDogRnJpZGF5LCBKdWx5IDMxLCAyMDA5IDQ6MjcgQU0NCj5UbzogSmVyYWxkIFAg TWFydG9jY2kNCj5DYzogUk9MTCBXRzsgcm9sbC1ib3VuY2VzQGlldGYub3JnDQo+U3ViamVjdDog UmU6IFtSb2xsXSBNb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBwcm90b2NvbCB3b3JrDQo+DQo+SSBh YnNvbHV0ZWx5IHN1cHBvcnQgdGhlIGFwcHJvYWNoIEplcnJ5IHN1Z2dlc3RlZDoNCj4NCj4xKSBU aGUgZm91bmRhdGlvbiBzaG91bGQgYmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlIC0gYSBzaW1wbGUg ZGlzdGFuY2UgdmVjdG9yIGFwcHJvYWNoIChJIGhvcGUgdGhlcmUgaXMgYW4NCj5hZ3JlZW1lbnQg b24gdGhpcykgZGVzY3JpYmluZyBuZXh0LWhvcCBzZWxlY3Rpb24gYmFzZWQgb24gcm91dGluZyBt ZXRyaWNzIGRlZmluZWQgaW4gdGhlIHJvdXRpbmcgbWV0cmljcw0KPmRyYWZ0LCBjb25zdHJhaW50 cyBhbmQgc3RyYXRlZ2llcyAoT0NQKSBhbmQgYmFzaWMgcnVsZXMgdG8gZGVjaWRlIHdoZW4gdG8g Z2VuZXJhdGUgUkFzLiBUaGUgZm91bmRhdGlvbiBzaG91bGQNCj5ub3QgaW5jbHVkZSBhbnkgbWVj aGFuaXNtIHRvIGRlYWwgd2l0aCBsb29wcyAoc28sIGl0IHNob3VsZCBub3QgaW5jbHVkZSBEQUdz IHVubGVzcyBEQUdzIGNhbiBiZSBzaG93biB0byBiZQ0KPmNyaXRpY2FsIGluIG1lZXRpbmcgb3Ro ZXIgZXNzZW50aWFsIHJlcXVpcmVtZW50cykuDQo+DQo+MikgQWRkaXRpb25hbCBkb2N1bWVudChz KSBzdWdnZXN0aW5nIHNvbHV0aW9ucyBjYXRlcmVkIHRvd2FyZHMgTVAyUCBhbmQvb3IgUDJQIHJv dXRpbmcgdXNpbmcgZGlmZmVyZW50DQo+bWVjaGFuaXNtcyB0byBkZWFsIHdpdGggbG9vcHMgKGlu Y2x1ZGluZyBEQUdzKS4NCj4NCj5UaGFua3MNCj5NdWt1bA0KPg0KPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCj5Gcm9tOiAiSmVyYWxkIFAgTWFydG9jY2kiIDxKZXJhbGQuUC5NYXJ0b2Nj aUBqY2kuY29tPg0KPlRvOiAiWmFjaCBTaGVsYnkiIDx6YWNoQHNlbnNpbm9kZS5jb20+DQo+Q2M6 ICJNdWt1bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+LCAiUk9MTCBXRyIgPHJvbGxAaWV0Zi5vcmc+ LCByb2xsLWJvdW5jZXNAaWV0Zi5vcmcNCj5TZW50OiBUaHVyc2RheSwgSnVseSAzMCwgMjAwOSAz OjU5OjMwIFBNIEdNVCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwNCj5TdWJqZWN0OiBSZTogW1Jv bGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcmsNCj4NCj4NCj4NCj5aYWNo LA0KPg0KPldoZW4gdGhlIGRlc2lnbiB0ZWFtIHdhcyBmb3JtZWQgaXQgc3RhdGVkIGl0cyBwbGFu IHdhcyB0byBkZXZlbG9wIGEgY29yZSByb3V0aW5nIHNwZWNpZmljYXRpb24gdGhhdCBtZXQgdGhl DQo+bmVlZHMgb2YgYWxsIHRoZSByZXF1aXJlbWVudCBzcGVjaWZpY2F0aW9ucyBhbmQgdGhlbiBh bmNpbGxhcnkgc3BlY2lmaWNhdGlvbnMgdG8gbWVldCB0aGUgc3BlY2lmaWMgbmVlZHMgZm9yDQo+ ZWFjaCBvZiB0aGUgcmVxdWlyZW1lbnRzLiAgUlBMIGFzIGN1cnJlbnRseSB3cml0dGVuIHNlZW1z IHBlcmZlY3RseSBzdWl0YWJsZSBmb3IgdGhlIE1QMlAgcmVxdWlyZW1lbnQsIHlldCBub3QNCj50 b28gc3VpdGFibGUgZm9yIFAyUCByZXF1aXJlbWVudC4gIENvdWxkIHdlIHJlcGFja2FnZSBSUEwg c28gdGhhdCBpdHMgYmFzZSBzcGVjIGNvbnRhaW5zIG9ubHkgdGhlIGdlbmVyaWMNCj5yb3V0aW5n IHJlcXVpcmVtZW50cyBzdWNoIGFzIDEpIHVzaW5nIHZhcmllZCBtZXRyaWNzIHRvIGRlZmluZSBw YXRoIHByZWZlcmVuY2VzLCAyKSBPQ1AgdG8gYWR2ZXJ0aXNlIHBhdGgNCj5zdHJhdGVneSBhbmQg MykgdHJpY2tsZSB0byBjbGVhbmx5IHZhcnkgcGVyaW9kaWMgcmVxdWlyZW1lbnRzLiAgVGhlbiBS UEwtMSBjb3VsZCBiZSB0aGVuIGVuaGFuY2VtZW50cyBmb3IgTVAyUA0KPmFwcGxpY2F0aW9ucyBh bmQgd291bGQgaW5jbHVkZSB0aGUgREFHLiAgVGhpcyB3b3VsZCBhbGxvdyB1cyB0byBkZWZpbmUg YSBkaWZmZXJlbnQgZXh0ZW5zaW9uLCBSUEwtMiwgZm9yIFAyUA0KPnJlcXVpcmVtZW50cyB0aGF0 IG5lZWQgbm90IGJlIERBRyBiYXNlZC4NCj4NCj5KUCBoYXMgcHJvbWlzZWQgdGhhdCBpZiBJIGp1 c3Qgc2h1dC11cCBhbmQgZ2l2ZSB0aGUgRFQgc29tZSB0aW1lLCB0aGV5IHdpbGwgcHJvdmlkZSBh IHNvbGlkIFAyUCBzb2x1dGlvbi4gIEkNCj5hbSB3aWxsaW5nIHRvIGRvIHRoYXQuICBIb3dldmVy LCBJIHdvdWxkIGhhdGUgdG8gc3RhcnQgY29tcHJvbWlzaW5nIHRoZSBNUDJQIHNvbHV0aW9uIHRv IHdlZGdlIGluIGEgc3ViLQ0KPm9wdGltYWwgUDJQIHNvbHV0aW9uLiAgTWF5YmUgd2UgY2FuIGhh dmUgb3VyIGNha2UgYW5kIGVhdCBpdCB0b28gaWYgd2Ugc2ltcGx5IHJlcGFja2FnZSB0aGUgc3Bl Y3MgYSBiaXQuDQo+DQo+SmVycnkNCj4NCj4NCj4NCj4NCj5aYWNoIFNoZWxieSA8emFjaEBzZW5z aW5vZGUuY29tPg0KPlNlbnQgYnk6IHJvbGwtYm91bmNlc0BpZXRmLm9yZw0KPg0KPjA3LzMwLzIw MDkgMTA6MDIgQU0NCj5UbyAJTXVrdWwgR295YWwgPG11a3VsQHV3bS5lZHU+DQo+DQo+Y2MgCVJP TEwgV0cgPHJvbGxAaWV0Zi5vcmc+DQo+DQo+U3ViamVjdCAJUmU6IFtSb2xsXSBNb3ZpbmcgZm9y d2FyZCB3aXRoIHRoZSBwcm90b2NvbCB3b3JrDQo+DQo+DQo+DQo+DQo+SGksDQo+DQo+TXVrdWwg R295YWwgd3JvdGU6DQo+PiBNaXNjaGEsDQo+Pg0KPj4+IFdlIHNob3VsZCB1c2UgdGhpcyBlYXJs eSBkZXNpZ24gc3RhZ2UgdG8gY29tZSB1cCB3aXRoIG9uZSBzb2x1dGlvbiAtIG9uZQ0KPj4gc29s dXRpb24gd2hpY2ggaXMgbm90IG5lY2Vzc2FyaWx5IG9wdGltdW0gZm9yIGFsbCBjYXNlcyBidXQg Zm9yIHRoZQ0KPj4gKGUuZy4pIDk1JSBxdWFudGlsZS4gVGhlIFBIWSBndXlzIGxlYXJuZWQgdG8g bGl2ZSB3aXRoIHN1Y2ggYW4gYXBwcm9hY2guDQo+PiBUaGUgTUFDIGZvbGtzIGFyZSBnZXR0aW5n IHRoZXJlIGFuZCB3ZSBzaG91bGQgdGFrZSBvdXIgY2hhbmNlIG5vdy4gOTUlDQo+PiBtZWFucyBj bGVhcmx5IHRvIGNvbmNlbnRyYXRlIG9uIHRoZSBjb3JlIGlzc3Vlcywgb2Ygd2hpY2ggbG9vcA0K Pj4gZGV0ZWN0aW9uL2F2b2lkYW5jZSwgcDJwIGFuZCBzZWN1cml0eSBhcmUgc29tZWhvdyBzdGls bCBvcGVuLg0KPj4NCj4+IFdoZW4geW91IHNheSBhIHNvbHV0aW9uLCBpdCBzZWVtcyB0aGF0IHlv dSB3YW50IG9uZSBwYXJ0aWN1bGFyIHByb3RvY29sLiBJIGFtIE9LIHdpdGggUlBMIGFzIGEgcHJv dG9jb2wgZXZlbg0KPnRob3VnaCBpdCBoYXMgZGVmaWNpZW5jaWVzIChzdWNoIGFzDQo+UDJQIHJv dXRpbmcpLiBCdXQsIHRoZSBpbXBsaWNhdGlvbiBvZiBnaXZpbmcgaXQgdGhlIFdHIHN0YXR1cyBz ZWVtcyB0bw0KPmJlIHRoYXQgUlBMIHdvdWxkIGJlIHRoZSBfZnJhbWV3b3JrXyBvbiB3aGljaCBh bGwgZnV0dXJlIFJPTEwgd29yayB3b3VsZA0KPmJlIGJhc2VkLiBJIGFtIG5vdCBpbiBzdXBwb3J0 IG9mIHRoZSB1c2Ugb2YgUlBMIGFzIGEgZnJhbWV3b3JrIHVubGVzcyBpdA0KPmVsaW1pbmF0ZXMg aXRzIGN1cnJlbnQgdGlnaHQgY291cGxpbmcgd2l0aCBEQUdzIChhLCByYXRoZXIgaGVhdnkgZHV0 eSwNCj5sb29wIHByZXZlbnRpb24gbWVjaGFuaXNtKS4NCj4NCj5UaGUgZ29hbCBvZiB0aGUgV0cg ZnJvbSBteSB1bmRlcnN0YW5kaW5nLCBpcyB0byBwcm9kdWNlICpvbmUqIHByb3RvY29sDQo+aW4g dGhlIGN1cnJlbnQgY2hhcnRlci4gUlBMIGlzIGRlZmluaXRlbHkgc3VpdGFibGUgYXMgYSBzdGFy dGluZyBwb2ludA0KPmZvciB0aGF0IHByb3RvY29sIChKUCBzYWlkIGZvdW5kYXRpb24sIG5vdCBm cmFtZXdvcmspLiBJIGNvbXBsZXRlbHkNCj5zdXBwb3J0IHRoaXMgYXBwcm9hY2guDQo+DQo+RnJv bSB0aGUgaW5kdXN0cnkgcG9pbnQgb2YgdmlldyB3ZSBuZWVkIGEgc2luZ2xlIHNvbHV0aW9uLCB3 aGljaA0KPmZ1bGZpbGxzIGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cyBzdWZmaWNpZW50bHkgYW5k IHRodXMgY2FuIGJlIHdpZGVseQ0KPmRlcGxveWVkIGNvbW1lcmNpYWxseS4NCj4NCj5SZWdhcmRp bmcgbG9vcCBwcmV2ZW50aW9uLCBzbyB3aGF0IGlmIFJQTCBkb2VzIGEgYmV0dGVyIGpvYiB0aGFu IGlzDQo+bmVjZXNzYXJ5PyBEb2VzIGl0IGJyZWFrIHNvbWUgcmVxdWlyZW1lbnQgZG9pbmcgdGhh dD8gSWYgc28sIHdlIHNob3VsZA0KPmZpeCBpdC4gVGhlcmUgYXJlIG90aGVyIHJlYXNvbnMgZm9y IHVzaW5nIERBR3MgdGhhbiBqdXN0IGxvb3AgcHJldmVudGlvbi4NCj4NCj5aYWNoDQo+DQo+LS0N Cj5odHRwOi8vd3d3LnNlbnNpbm9kZS5jb20NCj5odHRwOi8vemFjaHNoZWxieS5vcmcgLSBNeSBi bG9nIOKAnE9uIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3PigJ0NCj5Nb2JpbGU6ICszNTggNDAgNzc5 NjI5Nw0KPg0KPlphY2ggU2hlbGJ5DQo+SGVhZCBvZiBSZXNlYXJjaA0KPlNlbnNpbm9kZSBMdGQu DQo+S2lkZWt1amEgMg0KPjg4NjEwIFZ1b2thdHRpLCBGSU5MQU5EDQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Sb2xsIG1haWxpbmcgbGlzdA0KPlJv bGxAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwN Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlJv bGwgbWFpbGluZyBsaXN0DQo+Um9sbEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Um9sbCBtYWlsaW5nIGxpc3QNCj5Sb2xsQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From rstruik@certicom.com Fri Jul 31 05:51:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AD13A6BE2; Fri, 31 Jul 2009 05:51:59 -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 t-cJXecvNnBf; Fri, 31 Jul 2009 05:51:58 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id BE5403A69C7; Fri, 31 Jul 2009 05:51:57 -0700 (PDT) Received: from EX13-N04.exchserver.com ([10.7.5.66]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n6VCphNm008451; Fri, 31 Jul 2009 08:51:43 -0400 Received: from EX41.exchserver.com ([169.254.1.62]) by EX13-N04.exchserver.com ([10.7.40.180]) with mapi; Fri, 31 Jul 2009 08:51:42 -0400 From: Rene Struik To: "d.sturek@att.net" , "mukul@uwm.edu" , "jerald.p.martocci@jci.com" Date: Fri, 31 Jul 2009 08:51:42 -0400 Thread-Topic: [Roll] Moving forward with the protocol work Thread-Index: AcoR0kdFZlpe0P+IQSK2BFl6L+BKBgABT/ewAAGIA/g= Message-ID: <473C2CD540AC5141858AD4D50149C4B3020C4A00@EX41.exchserver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: "roll@ietf.org" , "roll-bounces@ietf.org" Subject: [Roll] (On keeping state) Re: Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:51:59 -0000 RGVhciBjb2xsZWFndWVzOg0KDQpQbGVhc2UgYmUgYXdhcmUgdGhhdCBpbmNvcnBvcmF0aW9uIG9m IHNlY3VyaXR5IHByb3Zpc2lvbnMgbWF5IG5lY2Vzc2l0YXRlIHJldGFpbmluZyBzb21lIHN0YXRl IGluZm9ybWF0aW9uIG9uIGVhY2ggZGV2aWNlLCB0aGUgZXh0ZW50IG9mIHdoaWNoIGRlcGVuZGlu ZyBvbiBzZWN1cml0eSBkZXNpZ24gb2JqZWN0aXZlcyB0aHJvdWdob3V0IHRoZSBsaWZlIGN5Y2xl IG9mIHRoZSBzeXN0ZW0gYW5kIGdyYW51bGFyaXR5IG9mIHNlY3VyaXR5IHBvbGljaWVzLCB3aGV0 aGVyIGZvciByb3V0aW5nIHNlY3VyaXR5IG9yIG90aGVyIHJlYXNvbnMuIFNvLCBldmVuIGlmIG9u ZSB3ZXJlIGFibGUgdG8gcmVtb3ZlIHN0YXRlIHdpdGggYSBwYXJ0aWN1bGFyIHJvdXRpbmcgZGVz aWduLCB0aGlzIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGltcGx5IG9uZSBjYW4gYXZvaWQgdGhpcyBh bHRvZ2V0aGVyIGZyb20gYW4gb3ZlcmFsbCBzeXN0ZW0gcGVyc3BlY3RpdmUuDQoNCkJlc3QgcmVn YXJkcywgUmVuZQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiByb2xsLWJv dW5jZXNAaWV0Zi5vcmcgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4NClRvOiAnTXVrdWwgR295YWwn IDxtdWt1bEB1d20uZWR1PjsgJ0plcmFsZCBQIE1hcnRvY2NpJyA8SmVyYWxkLlAuTWFydG9jY2lA amNpLmNvbT4NCkNjOiAnUk9MTCBXRycgPHJvbGxAaWV0Zi5vcmc+OyByb2xsLWJvdW5jZXNAaWV0 Zi5vcmcgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4NClNlbnQ6IEZyaSBKdWwgMzEgMDg6MTE6Mzgg MjAwOQpTdWJqZWN0OiBSZTogW1JvbGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29s IHdvcmsNCg0KSGkgTXVrdWwsCgpJIGRvbid0IGFncmVlIHRoYXQgdGhlIGFsdGVybmF0ZSBzb2x1 dGlvbnMgcHJvcG9zZWQgZm9yIFJPTEwgc2NhbGUgYW5kIGNvdWxkIHN1cHBvcnQgcmVxdWlyZW1l bnRzIG91dHNpZGUgYnVpbGRpbmcgY29udHJvbHMuICBTcGVjaWZpY2FsbHksIEkgYmVsaWV2ZSB0 aGF0IHRoZSBub24tREFHIHNvbHV0aW9ucyB3aWxsIHJlcXVpcmUgc3RhdGUgaW5mb3JtYXRpb24g cmV0ZW50aW9uIHdoaWNoIHdpbGwgbGltaXQgZGVwbG95bWVudCBiZXlvbmQgYSBtb2Rlc3QgbnVt YmVyIG9mIG5vZGVzIGluIHRoZSBuZXR3b3JrLgoKSSBiZWxpZXZlIHRoZSBvcHBvc2l0ZSBhcyB0 byB3aGF0IGlzIHByb3Bvc2VkIGJlbG93LiAgSSB3b3VsZCBwcm9wb3NlIHVzaW5nIHRoZSBSUEwg cHJvcG9zYWwgYXMgdGhlIGJhc2VsaW5lIGFuZCBwcm92aWRlIHNvbWUgbWVjaGFuaXNtcyB0byBz dXBwb3J0IG9wdGltaXphdGlvbiBvZiBQMlAgdHJhZmZpYy4gIAoKQmVzdCBSZWdhcmRzLAoKRG9u IFN0dXJlawoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IHJvbGwtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11a3Vs IEdveWFsClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAwOSA0OjI3IEFNClRvOiBKZXJhbGQgUCBN YXJ0b2NjaQpDYzogUk9MTCBXRzsgcm9sbC1ib3VuY2VzQGlldGYub3JnClN1YmplY3Q6IFJlOiBb Um9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgcHJvdG9jb2wgd29yawoKSSBhYnNvbHV0ZWx5 IHN1cHBvcnQgdGhlIGFwcHJvYWNoIEplcnJ5IHN1Z2dlc3RlZDoKCjEpIFRoZSBmb3VuZGF0aW9u IHNob3VsZCBiZSBhcyBzaW1wbGUgYXMgcG9zc2libGUgLSBhIHNpbXBsZSBkaXN0YW5jZSB2ZWN0 b3IgYXBwcm9hY2ggKEkgaG9wZSB0aGVyZSBpcyBhbiBhZ3JlZW1lbnQgb24gdGhpcykgZGVzY3Jp YmluZyBuZXh0LWhvcCBzZWxlY3Rpb24gYmFzZWQgb24gcm91dGluZyBtZXRyaWNzIGRlZmluZWQg aW4gdGhlIHJvdXRpbmcgbWV0cmljcyBkcmFmdCwgY29uc3RyYWludHMgYW5kIHN0cmF0ZWdpZXMg KE9DUCkgYW5kIGJhc2ljIHJ1bGVzIHRvIGRlY2lkZSB3aGVuIHRvIGdlbmVyYXRlIFJBcy4gVGhl IGZvdW5kYXRpb24gc2hvdWxkIG5vdCBpbmNsdWRlIGFueSBtZWNoYW5pc20gdG8gZGVhbCB3aXRo IGxvb3BzIChzbywgaXQgc2hvdWxkIG5vdCBpbmNsdWRlIERBR3MgdW5sZXNzIERBR3MgY2FuIGJl IHNob3duIHRvIGJlIGNyaXRpY2FsIGluIG1lZXRpbmcgb3RoZXIgZXNzZW50aWFsIHJlcXVpcmVt ZW50cykuCgoyKSBBZGRpdGlvbmFsIGRvY3VtZW50KHMpIHN1Z2dlc3Rpbmcgc29sdXRpb25zIGNh dGVyZWQgdG93YXJkcyBNUDJQIGFuZC9vciBQMlAgcm91dGluZyB1c2luZyBkaWZmZXJlbnQgbWVj aGFuaXNtcyB0byBkZWFsIHdpdGggbG9vcHMgKGluY2x1ZGluZyBEQUdzKS4KClRoYW5rcwpNdWt1 bAoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiAiSmVyYWxkIFAgTWFydG9jY2ki IDxKZXJhbGQuUC5NYXJ0b2NjaUBqY2kuY29tPgpUbzogIlphY2ggU2hlbGJ5IiA8emFjaEBzZW5z aW5vZGUuY29tPgpDYzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4sICJST0xMIFdHIiA8 cm9sbEBpZXRmLm9yZz4sIHJvbGwtYm91bmNlc0BpZXRmLm9yZwpTZW50OiBUaHVyc2RheSwgSnVs eSAzMCwgMjAwOSAzOjU5OjMwIFBNIEdNVCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwKU3ViamVj dDogUmU6IFtSb2xsXSBNb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBwcm90b2NvbCB3b3JrCgoKClph Y2gsIAoKV2hlbiB0aGUgZGVzaWduIHRlYW0gd2FzIGZvcm1lZCBpdCBzdGF0ZWQgaXRzIHBsYW4g d2FzIHRvIGRldmVsb3AgYSBjb3JlIHJvdXRpbmcgc3BlY2lmaWNhdGlvbiB0aGF0IG1ldCB0aGUg bmVlZHMgb2YgYWxsIHRoZSByZXF1aXJlbWVudCBzcGVjaWZpY2F0aW9ucyBhbmQgdGhlbiBhbmNp bGxhcnkgc3BlY2lmaWNhdGlvbnMgdG8gbWVldCB0aGUgc3BlY2lmaWMgbmVlZHMgZm9yIGVhY2gg b2YgdGhlIHJlcXVpcmVtZW50cy4gIFJQTCBhcyBjdXJyZW50bHkgd3JpdHRlbiBzZWVtcyBwZXJm ZWN0bHkgc3VpdGFibGUgZm9yIHRoZSBNUDJQIHJlcXVpcmVtZW50LCB5ZXQgbm90IHRvbyBzdWl0 YWJsZSBmb3IgUDJQIHJlcXVpcmVtZW50LiAgQ291bGQgd2UgcmVwYWNrYWdlIFJQTCBzbyB0aGF0 IGl0cyBiYXNlIHNwZWMgY29udGFpbnMgb25seSB0aGUgZ2VuZXJpYyByb3V0aW5nIHJlcXVpcmVt ZW50cyBzdWNoIGFzIDEpIHVzaW5nIHZhcmllZCBtZXRyaWNzIHRvIGRlZmluZSBwYXRoIHByZWZl cmVuY2VzLCAyKSBPQ1AgdG8gYWR2ZXJ0aXNlIHBhdGggc3RyYXRlZ3kgYW5kIDMpIHRyaWNrbGUg dG8gY2xlYW5seSB2YXJ5IHBlcmlvZGljIHJlcXVpcmVtZW50cy4gIFRoZW4gUlBMLTEgY291bGQg YmUgdGhlbiBlbmhhbmNlbWVudHMgZm9yIE1QMlAgYXBwbGljYXRpb25zIGFuZCB3b3VsZCBpbmNs dWRlIHRoZSBEQUcuICBUaGlzIHdvdWxkIGFsbG93IHVzIHRvIGRlZmluZSBhIGRpZmZlcmVudCBl eHRlbnNpb24sIFJQTC0yLCBmb3IgUDJQIHJlcXVpcmVtZW50cyB0aGF0IG5lZWQgbm90IGJlIERB RyBiYXNlZC4gCgpKUCBoYXMgcHJvbWlzZWQgdGhhdCBpZiBJIGp1c3Qgc2h1dC11cCBhbmQgZ2l2 ZSB0aGUgRFQgc29tZSB0aW1lLCB0aGV5IHdpbGwgcHJvdmlkZSBhIHNvbGlkIFAyUCBzb2x1dGlv bi4gIEkgYW0gd2lsbGluZyB0byBkbyB0aGF0LiAgSG93ZXZlciwgSSB3b3VsZCBoYXRlIHRvIHN0 YXJ0IGNvbXByb21pc2luZyB0aGUgTVAyUCBzb2x1dGlvbiB0byB3ZWRnZSBpbiBhIHN1Yi1vcHRp bWFsIFAyUCBzb2x1dGlvbi4gIE1heWJlIHdlIGNhbiBoYXZlIG91ciBjYWtlIGFuZCBlYXQgaXQg dG9vIGlmIHdlIHNpbXBseSByZXBhY2thZ2UgdGhlIHNwZWNzIGEgYml0LiAKCkplcnJ5IAoKCgoK WmFjaCBTaGVsYnkgPHphY2hAc2Vuc2lub2RlLmNvbT4gClNlbnQgYnk6IHJvbGwtYm91bmNlc0Bp ZXRmLm9yZyAKCjA3LzMwLzIwMDkgMTA6MDIgQU0gCQpUbyAJTXVrdWwgR295YWwgPG11a3VsQHV3 bS5lZHU+IAoKY2MgCVJPTEwgV0cgPHJvbGxAaWV0Zi5vcmc+IAoKU3ViamVjdCAJUmU6IFtSb2xs XSBNb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBwcm90b2NvbCB3b3JrIAoJCgoKCkhpLCAKCk11a3Vs IEdveWFsIHdyb3RlOiAKPiBNaXNjaGEsIAo+IAo+PiBXZSBzaG91bGQgdXNlIHRoaXMgZWFybHkg ZGVzaWduIHN0YWdlIHRvIGNvbWUgdXAgd2l0aCBvbmUgc29sdXRpb24gLSBvbmUgCj4gc29sdXRp b24gd2hpY2ggaXMgbm90IG5lY2Vzc2FyaWx5IG9wdGltdW0gZm9yIGFsbCBjYXNlcyBidXQgZm9y IHRoZSAKPiAoZS5nLikgOTUlIHF1YW50aWxlLiBUaGUgUEhZIGd1eXMgbGVhcm5lZCB0byBsaXZl IHdpdGggc3VjaCBhbiBhcHByb2FjaC4gCj4gVGhlIE1BQyBmb2xrcyBhcmUgZ2V0dGluZyB0aGVy ZSBhbmQgd2Ugc2hvdWxkIHRha2Ugb3VyIGNoYW5jZSBub3cuIDk1JSAKPiBtZWFucyBjbGVhcmx5 IHRvIGNvbmNlbnRyYXRlIG9uIHRoZSBjb3JlIGlzc3Vlcywgb2Ygd2hpY2ggbG9vcCAKPiBkZXRl Y3Rpb24vYXZvaWRhbmNlLCBwMnAgYW5kIHNlY3VyaXR5IGFyZSBzb21laG93IHN0aWxsIG9wZW4u IAo+IAo+IFdoZW4geW91IHNheSBhIHNvbHV0aW9uLCBpdCBzZWVtcyB0aGF0IHlvdSB3YW50IG9u ZSBwYXJ0aWN1bGFyIHByb3RvY29sLiBJIGFtIE9LIHdpdGggUlBMIGFzIGEgcHJvdG9jb2wgZXZl biB0aG91Z2ggaXQgaGFzIGRlZmljaWVuY2llcyAoc3VjaCBhcyAKUDJQIHJvdXRpbmcpLiBCdXQs IHRoZSBpbXBsaWNhdGlvbiBvZiBnaXZpbmcgaXQgdGhlIFdHIHN0YXR1cyBzZWVtcyB0byAKYmUg dGhhdCBSUEwgd291bGQgYmUgdGhlIF9mcmFtZXdvcmtfIG9uIHdoaWNoIGFsbCBmdXR1cmUgUk9M TCB3b3JrIHdvdWxkIApiZSBiYXNlZC4gSSBhbSBub3QgaW4gc3VwcG9ydCBvZiB0aGUgdXNlIG9m IFJQTCBhcyBhIGZyYW1ld29yayB1bmxlc3MgaXQgCmVsaW1pbmF0ZXMgaXRzIGN1cnJlbnQgdGln aHQgY291cGxpbmcgd2l0aCBEQUdzIChhLCByYXRoZXIgaGVhdnkgZHV0eSwgCmxvb3AgcHJldmVu dGlvbiBtZWNoYW5pc20pLiAKClRoZSBnb2FsIG9mIHRoZSBXRyBmcm9tIG15IHVuZGVyc3RhbmRp bmcsIGlzIHRvIHByb2R1Y2UgKm9uZSogcHJvdG9jb2wgCmluIHRoZSBjdXJyZW50IGNoYXJ0ZXIu IFJQTCBpcyBkZWZpbml0ZWx5IHN1aXRhYmxlIGFzIGEgc3RhcnRpbmcgcG9pbnQgCmZvciB0aGF0 IHByb3RvY29sIChKUCBzYWlkIGZvdW5kYXRpb24sIG5vdCBmcmFtZXdvcmspLiBJIGNvbXBsZXRl bHkgCnN1cHBvcnQgdGhpcyBhcHByb2FjaC4gCgpGcm9tIHRoZSBpbmR1c3RyeSBwb2ludCBvZiB2 aWV3IHdlIG5lZWQgYSBzaW5nbGUgc29sdXRpb24sIHdoaWNoIApmdWxmaWxscyBhcHBsaWNhdGlv biByZXF1aXJlbWVudHMgc3VmZmljaWVudGx5IGFuZCB0aHVzIGNhbiBiZSB3aWRlbHkgCmRlcGxv eWVkIGNvbW1lcmNpYWxseS4gCgpSZWdhcmRpbmcgbG9vcCBwcmV2ZW50aW9uLCBzbyB3aGF0IGlm IFJQTCBkb2VzIGEgYmV0dGVyIGpvYiB0aGFuIGlzIApuZWNlc3Nhcnk/IERvZXMgaXQgYnJlYWsg c29tZSByZXF1aXJlbWVudCBkb2luZyB0aGF0PyBJZiBzbywgd2Ugc2hvdWxkIApmaXggaXQuIFRo ZXJlIGFyZSBvdGhlciByZWFzb25zIGZvciB1c2luZyBEQUdzIHRoYW4ganVzdCBsb29wIHByZXZl bnRpb24uIAoKWmFjaCAKCi0tIApodHRwOi8vd3d3LnNlbnNpbm9kZS5jb20gCmh0dHA6Ly96YWNo c2hlbGJ5Lm9yZyAtIE15IGJsb2cg4oCcT24gdGhlIEludGVybmV0IG9mIFRoaW5nc+KAnSAKTW9i aWxlOiArMzU4IDQwIDc3OTYyOTcgCgpaYWNoIFNoZWxieSAKSGVhZCBvZiBSZXNlYXJjaCAKU2Vu c2lub2RlIEx0ZC4gCktpZGVrdWphIDIgCjg4NjEwIFZ1b2thdHRpLCBGSU5MQU5EIApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKUm9sbCBtYWlsaW5nIGxp c3QgClJvbGxAaWV0Zi5vcmcgCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbCAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClJv bGwgbWFpbGluZyBsaXN0ClJvbGxAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpSb2xsIG1haWxpbmcgbGlzdApSb2xsQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbAo= From prvs=4562201ce=mukul@uwm.edu Fri Jul 31 05:54:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E4F3A67AD; Fri, 31 Jul 2009 05:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 x9C8E+In2wr0; Fri, 31 Jul 2009 05:54:46 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id CB19E3A6E66; Fri, 31 Jul 2009 05:54:28 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 31 Jul 2009 07:54:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8FF5BC085A8; Fri, 31 Jul 2009 07:54:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffHwyBNTAD7Q; Fri, 31 Jul 2009 07:54:30 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4C75EC085A1; Fri, 31 Jul 2009 07:54:30 -0500 (CDT) Date: Fri, 31 Jul 2009 07:54:30 -0500 (CDT) From: Mukul Goyal To: d sturek Message-ID: <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <001101ca11d8$102811b0$30783510$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:54:48 -0000 Don I will get back to the list regarding the scalability and flooding (BTW, th= e solution I proposed does not involve flooding, which I abhore with same v= engeance as you) argument you made in favor of RPL and again the alternate = solutions. Also, I will wait for DT solution for good P2P routing in RPL, b= ut it seems to me that it has to involve some state maintenance in nodes. But, for a moment, lets forget about the alternate solutions. Lets just foc= us on RPL. All I am saying is that RPL, at present, is too tightly coupled with DAGs, = which is a loop prevention mechanism as I understand it. Putting a specific= loop prevention mechanism, a non-essential requirement, in the _foundation= _ does not sound like a good idea to me. Thanks Mukul =20 ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "Jerald P Martocci" Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Friday, July 31, 2009 7:11:38 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Moving forward with the protocol work Hi Mukul, I don't agree that the alternate solutions proposed for ROLL scale and coul= d support requirements outside building controls. Specifically, I believe = that the non-DAG solutions will require state information retention which w= ill limit deployment beyond a modest number of nodes in the network. I believe the opposite as to what is proposed below. I would propose using= the RPL proposal as the baseline and provide some mechanisms to support op= timization of P2P traffic. =20 Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Muk= ul Goyal Sent: Friday, July 31, 2009 4:27 AM To: Jerald P Martocci Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work I absolutely support the approach Jerry suggested: 1) The foundation should be as simple as possible - a simple distance vecto= r approach (I hope there is an agreement on this) describing next-hop selec= tion based on routing metrics defined in the routing metrics draft, constra= ints and strategies (OCP) and basic rules to decide when to generate RAs. T= he foundation should not include any mechanism to deal with loops (so, it s= hould not include DAGs unless DAGs can be shown to be critical in meeting o= ther essential requirements). 2) Additional document(s) suggesting solutions catered towards MP2P and/or = P2P routing using different mechanisms to deal with loops (including DAGs). Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Zach Shelby" Cc: "Mukul Goyal" , "ROLL WG" , roll-bounces@= ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Zach,=20 When the design team was formed it stated its plan was to develop a core ro= uting specification that met the needs of all the requirement specification= s and then ancillary specifications to meet the specific needs for each of = the requirements. RPL as currently written seems perfectly suitable for th= e MP2P requirement, yet not too suitable for P2P requirement. Could we rep= ackage RPL so that its base spec contains only the generic routing requirem= ents such as 1) using varied metrics to define path preferences, 2) OCP to = advertise path strategy and 3) trickle to cleanly vary periodic requirement= s. Then RPL-1 could be then enhancements for MP2P applications and would i= nclude the DAG. This would allow us to define a different extension, RPL-2= , for P2P requirements that need not be DAG based.=20 JP has promised that if I just shut-up and give the DT some time, they will= provide a solid P2P solution. I am willing to do that. However, I would = hate to start compromising the MP2P solution to wedge in a sub-optimal P2P = solution. Maybe we can have our cake and eat it too if we simply repackage= the specs a bit.=20 Jerry=20 Zach Shelby =20 Sent by: roll-bounces@ietf.org=20 07/30/2009 10:02 AM =09 To =09Mukul Goyal =20 cc =09ROLL WG =20 Subject =09Re: [Roll] Moving forward with the protocol work=20 =09 Hi,=20 Mukul Goyal wrote:=20 > Mischa,=20 >=20 >> We should use this early design stage to come up with one solution - one= =20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an approach.= =20 > The MAC folks are getting there and we should take our chance now. 95%=20 > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open.=20 >=20 > When you say a solution, it seems that you want one particular protocol. = I am OK with RPL as a protocol even though it has deficiencies (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would=20 be based. I am not in support of the use of RPL as a framework unless it=20 eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism).=20 The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach.=20 >From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially.=20 Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop prevention.= =20 Zach=20 --=20 http://www.sensinode.com=20 http://zachshelby.org - My blog =E2=80=9COn the Internet of Things=E2=80=9D= =20 Mobile: +358 40 7796297=20 Zach Shelby=20 Head of Research=20 Sensinode Ltd.=20 Kidekuja 2=20 88610 Vuokatti, FINLAND=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Fri Jul 31 06:06:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27A928C25A for ; Fri, 31 Jul 2009 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGVmnfF8XNka for ; Fri, 31 Jul 2009 06:06:42 -0700 (PDT) Received: from smtp123.sbc.mail.re3.yahoo.com (smtp123.sbc.mail.re3.yahoo.com [66.196.96.96]) by core3.amsl.com (Postfix) with SMTP id 3D2503A677C for ; Fri, 31 Jul 2009 06:06:42 -0700 (PDT) Received: (qmail 31669 invoked from network); 31 Jul 2009 13:00:04 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp123.sbc.mail.re3.yahoo.com with SMTP; 31 Jul 2009 13:00:02 -0000 X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Rene Struik'" , , References: <473C2CD540AC5141858AD4D50149C4B3020C4A00@EX41.exchserver.com> In-Reply-To: <473C2CD540AC5141858AD4D50149C4B3020C4A00@EX41.exchserver.com> Date: Fri, 31 Jul 2009 05:59:57 -0700 Message-ID: <003201ca11de$d01ace30$70506a90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoR0kdFZlpe0P+IQSK2BFl6L+BKBgABT/ewAAGIA/gAADq2MA== Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] (On keeping state) Re: Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:06:42 -0000 Hi Rene, I agree that security may require retention of state information. The issue in MANET protocols is that many scale retention of state = information according to the number of routable destination devices in = the network (or alternatively get around it by flooding the network = during route discovery). It is these facilities that don't scale...... Don -----Original Message----- From: Rene Struik [mailto:rstruik@certicom.com]=20 Sent: Friday, July 31, 2009 5:52 AM To: d.sturek@att.net; mukul@uwm.edu; jerald.p.martocci@jci.com Cc: roll@ietf.org; roll-bounces@ietf.org Subject: (On keeping state) Re: [Roll] Moving forward with the protocol = work Dear colleagues: Please be aware that incorporation of security provisions may = necessitate retaining some state information on each device, the extent = of which depending on security design objectives throughout the life = cycle of the system and granularity of security policies, whether for = routing security or other reasons. So, even if one were able to remove = state with a particular routing design, this does not necessarily imply = one can avoid this altogether from an overall system perspective. Best regards, Rene ----- Original Message ----- From: roll-bounces@ietf.org To: 'Mukul Goyal' ; 'Jerald P Martocci' = Cc: 'ROLL WG' ; roll-bounces@ietf.org = Sent: Fri Jul 31 08:11:38 2009 Subject: Re: [Roll] Moving forward with the protocol work Hi Mukul, I don't agree that the alternate solutions proposed for ROLL scale and = could support requirements outside building controls. Specifically, I = believe that the non-DAG solutions will require state information = retention which will limit deployment beyond a modest number of nodes in = the network. I believe the opposite as to what is proposed below. I would propose = using the RPL proposal as the baseline and provide some mechanisms to = support optimization of P2P traffic. =20 Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mukul Goyal Sent: Friday, July 31, 2009 4:27 AM To: Jerald P Martocci Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work I absolutely support the approach Jerry suggested: 1) The foundation should be as simple as possible - a simple distance = vector approach (I hope there is an agreement on this) describing = next-hop selection based on routing metrics defined in the routing = metrics draft, constraints and strategies (OCP) and basic rules to = decide when to generate RAs. The foundation should not include any = mechanism to deal with loops (so, it should not include DAGs unless DAGs = can be shown to be critical in meeting other essential requirements). 2) Additional document(s) suggesting solutions catered towards MP2P = and/or P2P routing using different mechanisms to deal with loops = (including DAGs). Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Zach Shelby" Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Zach,=20 When the design team was formed it stated its plan was to develop a core = routing specification that met the needs of all the requirement = specifications and then ancillary specifications to meet the specific = needs for each of the requirements. RPL as currently written seems = perfectly suitable for the MP2P requirement, yet not too suitable for = P2P requirement. Could we repackage RPL so that its base spec contains = only the generic routing requirements such as 1) using varied metrics to = define path preferences, 2) OCP to advertise path strategy and 3) = trickle to cleanly vary periodic requirements. Then RPL-1 could be then = enhancements for MP2P applications and would include the DAG. This = would allow us to define a different extension, RPL-2, for P2P = requirements that need not be DAG based.=20 JP has promised that if I just shut-up and give the DT some time, they = will provide a solid P2P solution. I am willing to do that. However, I = would hate to start compromising the MP2P solution to wedge in a = sub-optimal P2P solution. Maybe we can have our cake and eat it too if = we simply repackage the specs a bit.=20 Jerry=20 Zach Shelby =20 Sent by: roll-bounces@ietf.org=20 07/30/2009 10:02 AM =09 To Mukul Goyal =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work=20 =09 Hi,=20 Mukul Goyal wrote:=20 > Mischa,=20 >=20 >> We should use this early design stage to come up with one solution - = one=20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an = approach.=20 > The MAC folks are getting there and we should take our chance now. 95% = > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open.=20 >=20 > When you say a solution, it seems that you want one particular = protocol. I am OK with RPL as a protocol even though it has deficiencies = (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would = be based. I am not in support of the use of RPL as a framework unless it = eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism).=20 The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach.=20 >From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially.=20 Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop = prevention.=20 Zach=20 --=20 http://www.sensinode.com=20 http://zachshelby.org - My blog =E2=80=9COn the Internet of = Things=E2=80=9D=20 Mobile: +358 40 7796297=20 Zach Shelby=20 Head of Research=20 Sensinode Ltd.=20 Kidekuja 2=20 88610 Vuokatti, FINLAND=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4562201ce=mukul@uwm.edu Fri Jul 31 06:07:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D26428C270; Fri, 31 Jul 2009 06:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 0yRXojG7XqVI; Fri, 31 Jul 2009 06:07:14 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id B248E3A677C; Fri, 31 Jul 2009 06:07:13 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 31 Jul 2009 08:07:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 60C9EC085A7; Fri, 31 Jul 2009 08:07:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONzDheDBX-Gp; Fri, 31 Jul 2009 08:07:14 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E6D73C085A3; Fri, 31 Jul 2009 08:07:14 -0500 (CDT) Date: Fri, 31 Jul 2009 08:07:14 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <791602312.6714891249045509175.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:07:15 -0000 Pascal OK. This puts all the arguments to rest. Me, Jerry and JP (who has been ins= isting again and again that ROLL has to provide good P2P solution) had been= looking at the wrong WG all along. We should go bang the MANET WG door and= ask for a good P2P routing solution for LLNs. Thanks Mukul =20 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "d sturek" , "Mukul Goyal" , "Jerald P= Martocci" Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Moving forward with the protocol work Hi Don: I'm all with you here. Optimized P2P for all comes at a cost, in particular= in terms of states in the nodes, and is clearly a secondary priority for R= OLL. OTOH, in a use case where all nodes can really afford all the states i= nvolved, the problem seems to drift outside the ROLL charter and back in th= e MANET world. ROLL does not compete with MANET and defers to the MANET work where it appl= ies. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Do= n Sturek >Sent: vendredi 31 juillet 2009 14:12 >To: 'Mukul Goyal'; 'Jerald P Martocci' >Cc: 'ROLL WG'; roll-bounces@ietf.org >Subject: Re: [Roll] Moving forward with the protocol work > >Hi Mukul, > >I don't agree that the alternate solutions proposed for ROLL scale and cou= ld support requirements outside >building controls. Specifically, I believe that the non-DAG solutions wil= l require state information >retention which will limit deployment beyond a modest number of nodes in t= he network. > >I believe the opposite as to what is proposed below. I would propose usin= g the RPL proposal as the baseline >and provide some mechanisms to support optimization of P2P traffic. > >Best Regards, > >Don Sturek > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mu= kul Goyal >Sent: Friday, July 31, 2009 4:27 AM >To: Jerald P Martocci >Cc: ROLL WG; roll-bounces@ietf.org >Subject: Re: [Roll] Moving forward with the protocol work > >I absolutely support the approach Jerry suggested: > >1) The foundation should be as simple as possible - a simple distance vect= or approach (I hope there is an >agreement on this) describing next-hop selection based on routing metrics = defined in the routing metrics >draft, constraints and strategies (OCP) and basic rules to decide when to = generate RAs. The foundation should >not include any mechanism to deal with loops (so, it should not include DA= Gs unless DAGs can be shown to be >critical in meeting other essential requirements). > >2) Additional document(s) suggesting solutions catered towards MP2P and/or= P2P routing using different >mechanisms to deal with loops (including DAGs). > >Thanks >Mukul > >----- Original Message ----- >From: "Jerald P Martocci" >To: "Zach Shelby" >Cc: "Mukul Goyal" , "ROLL WG" , roll-bounces= @ietf.org >Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central >Subject: Re: [Roll] Moving forward with the protocol work > > > >Zach, > >When the design team was formed it stated its plan was to develop a core r= outing specification that met the >needs of all the requirement specifications and then ancillary specificati= ons to meet the specific needs for >each of the requirements. RPL as currently written seems perfectly suitab= le for the MP2P requirement, yet not >too suitable for P2P requirement. Could we repackage RPL so that its base= spec contains only the generic >routing requirements such as 1) using varied metrics to define path prefer= ences, 2) OCP to advertise path >strategy and 3) trickle to cleanly vary periodic requirements. Then RPL-1= could be then enhancements for MP2P >applications and would include the DAG. This would allow us to define a d= ifferent extension, RPL-2, for P2P >requirements that need not be DAG based. > >JP has promised that if I just shut-up and give the DT some time, they wil= l provide a solid P2P solution. I >am willing to do that. However, I would hate to start compromising the MP= 2P solution to wedge in a sub- >optimal P2P solution. Maybe we can have our cake and eat it too if we sim= ply repackage the specs a bit. > >Jerry > > > > >Zach Shelby >Sent by: roll-bounces@ietf.org > >07/30/2009 10:02 AM >To =09Mukul Goyal > >cc =09ROLL WG > >Subject =09Re: [Roll] Moving forward with the protocol work > > > > >Hi, > >Mukul Goyal wrote: >> Mischa, >> >>> We should use this early design stage to come up with one solution - on= e >> solution which is not necessarily optimum for all cases but for the >> (e.g.) 95% quantile. The PHY guys learned to live with such an approach. >> The MAC folks are getting there and we should take our chance now. 95% >> means clearly to concentrate on the core issues, of which loop >> detection/avoidance, p2p and security are somehow still open. >> >> When you say a solution, it seems that you want one particular protocol.= I am OK with RPL as a protocol even >though it has deficiencies (such as >P2P routing). But, the implication of giving it the WG status seems to >be that RPL would be the _framework_ on which all future ROLL work would >be based. I am not in support of the use of RPL as a framework unless it >eliminates its current tight coupling with DAGs (a, rather heavy duty, >loop prevention mechanism). > >The goal of the WG from my understanding, is to produce *one* protocol >in the current charter. RPL is definitely suitable as a starting point >for that protocol (JP said foundation, not framework). I completely >support this approach. > >From the industry point of view we need a single solution, which >fulfills application requirements sufficiently and thus can be widely >deployed commercially. > >Regarding loop prevention, so what if RPL does a better job than is >necessary? Does it break some requirement doing that? If so, we should >fix it. There are other reasons for using DAGs than just loop prevention. > >Zach > >-- >http://www.sensinode.com >http://zachshelby.org - My blog =E2=80=9COn the Internet of Things=E2=80= =9D >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Fri Jul 31 06:11:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1697A28C2F3 for ; Fri, 31 Jul 2009 06:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7jyV3zJF+fX for ; Fri, 31 Jul 2009 06:11:02 -0700 (PDT) Received: from smtp116.sbc.mail.re3.yahoo.com (smtp116.sbc.mail.re3.yahoo.com [66.196.96.89]) by core3.amsl.com (Postfix) with SMTP id 9FB5728C259 for ; Fri, 31 Jul 2009 06:11:02 -0700 (PDT) Received: (qmail 14649 invoked from network); 31 Jul 2009 13:11:01 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp116.sbc.mail.re3.yahoo.com with SMTP; 31 Jul 2009 13:11:01 -0000 X-YMail-OSG: HtHA1QkVM1lOYRe.UmPtJGQEgFpUjaKEAwePncKZxwxD5VeT17D4g92FEhaa_uhZfGdbXRozNnG_jOSO1syS7m7cCbeddtg2XMPw.y4JDZYJf1Fl4CwIrmiiW..dGRUUMt0C76SEbJE6RsmX__nl7dlHhwTojZiyPKdPQuPWkhQnC5co0350x2rnKq2C7PdglLE7BAjNCHOYkZdL27j.iezL4z1AHpWj_amZunwfq_yj10P6PLL9lr0j1DtE63Jc3FuVnnjzF4eq5Ezwjk0HVnQNGv7piiCy0V9cUaDSVEeZ6KMTjop0gUsS15LdYg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" References: <001101ca11d8$102811b0$30783510$@sturek@att.net> <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 31 Jul 2009 06:10:56 -0700 Message-ID: <003301ca11e0$58aa9040$09ffb0c0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoR3guw4WFt+5GvRlqqzvNAlQFppgAANGKg Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:11:04 -0000 Hi Mukul, The part of RPL that I liked is the P2MP support (where once a device is = part of a DAG, it need only promote packets upward to reach a = concentrator device denoted as the DAG-root). There seems to be little = requirement for any state information in RPL to get this feature (quite = nice). Also no flooding! There is clearly work to be done to get a usable P2P mechanism running = using RPL (and it is definitely needed even for Smart Metering). It = would be good to see if the RPL DAG feature could be retained and those = that want P2P would be provided that capability (understanding they may = be required to store state information in their devices to use P2P if = that is the solution we end up with). By the way, most Smart Metering applications are relatively few devices = (25 or so). The problem comes in when supporting Multi-dwelling units = (one of our use cases). There we could have thousands of devices but = with relatively few concentrators (really seems to map to RPL fairly = well!) We have been struggling for some time to come up with elegant routing = solutions over ad hoc networks and RPL seems to be the first one that = doesn't fall apart in scenarios like: many to one (MP2P), many = devices in the network (more than a couple hundred), etc. Best Regards, Don Sturek -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu]=20 Sent: Friday, July 31, 2009 5:55 AM To: d sturek Cc: ROLL WG; roll-bounces@ietf.org; Jerald P Martocci Subject: Re: [Roll] Moving forward with the protocol work Don I will get back to the list regarding the scalability and flooding (BTW, = the solution I proposed does not involve flooding, which I abhore with = same vengeance as you) argument you made in favor of RPL and again the = alternate solutions. Also, I will wait for DT solution for good P2P = routing in RPL, but it seems to me that it has to involve some state = maintenance in nodes. But, for a moment, lets forget about the alternate solutions. Lets just = focus on RPL. All I am saying is that RPL, at present, is too tightly coupled with = DAGs, which is a loop prevention mechanism as I understand it. Putting a = specific loop prevention mechanism, a non-essential requirement, in the = _foundation_ does not sound like a good idea to me. Thanks Mukul =20 ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "Jerald P Martocci" = Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Friday, July 31, 2009 7:11:38 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Moving forward with the protocol work Hi Mukul, I don't agree that the alternate solutions proposed for ROLL scale and = could support requirements outside building controls. Specifically, I = believe that the non-DAG solutions will require state information = retention which will limit deployment beyond a modest number of nodes in = the network. I believe the opposite as to what is proposed below. I would propose = using the RPL proposal as the baseline and provide some mechanisms to = support optimization of P2P traffic. =20 Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mukul Goyal Sent: Friday, July 31, 2009 4:27 AM To: Jerald P Martocci Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work I absolutely support the approach Jerry suggested: 1) The foundation should be as simple as possible - a simple distance = vector approach (I hope there is an agreement on this) describing = next-hop selection based on routing metrics defined in the routing = metrics draft, constraints and strategies (OCP) and basic rules to = decide when to generate RAs. The foundation should not include any = mechanism to deal with loops (so, it should not include DAGs unless DAGs = can be shown to be critical in meeting other essential requirements). 2) Additional document(s) suggesting solutions catered towards MP2P = and/or P2P routing using different mechanisms to deal with loops = (including DAGs). Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Zach Shelby" Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work Zach,=20 When the design team was formed it stated its plan was to develop a core = routing specification that met the needs of all the requirement = specifications and then ancillary specifications to meet the specific = needs for each of the requirements. RPL as currently written seems = perfectly suitable for the MP2P requirement, yet not too suitable for = P2P requirement. Could we repackage RPL so that its base spec contains = only the generic routing requirements such as 1) using varied metrics to = define path preferences, 2) OCP to advertise path strategy and 3) = trickle to cleanly vary periodic requirements. Then RPL-1 could be then = enhancements for MP2P applications and would include the DAG. This = would allow us to define a different extension, RPL-2, for P2P = requirements that need not be DAG based.=20 JP has promised that if I just shut-up and give the DT some time, they = will provide a solid P2P solution. I am willing to do that. However, I = would hate to start compromising the MP2P solution to wedge in a = sub-optimal P2P solution. Maybe we can have our cake and eat it too if = we simply repackage the specs a bit.=20 Jerry=20 Zach Shelby =20 Sent by: roll-bounces@ietf.org=20 07/30/2009 10:02 AM =09 To Mukul Goyal =20 cc ROLL WG =20 Subject Re: [Roll] Moving forward with the protocol work=20 =09 Hi,=20 Mukul Goyal wrote:=20 > Mischa,=20 >=20 >> We should use this early design stage to come up with one solution - = one=20 > solution which is not necessarily optimum for all cases but for the=20 > (e.g.) 95% quantile. The PHY guys learned to live with such an = approach.=20 > The MAC folks are getting there and we should take our chance now. 95% = > means clearly to concentrate on the core issues, of which loop=20 > detection/avoidance, p2p and security are somehow still open.=20 >=20 > When you say a solution, it seems that you want one particular = protocol. I am OK with RPL as a protocol even though it has deficiencies = (such as=20 P2P routing). But, the implication of giving it the WG status seems to=20 be that RPL would be the _framework_ on which all future ROLL work would = be based. I am not in support of the use of RPL as a framework unless it = eliminates its current tight coupling with DAGs (a, rather heavy duty,=20 loop prevention mechanism).=20 The goal of the WG from my understanding, is to produce *one* protocol=20 in the current charter. RPL is definitely suitable as a starting point=20 for that protocol (JP said foundation, not framework). I completely=20 support this approach.=20 >From the industry point of view we need a single solution, which=20 fulfills application requirements sufficiently and thus can be widely=20 deployed commercially.=20 Regarding loop prevention, so what if RPL does a better job than is=20 necessary? Does it break some requirement doing that? If so, we should=20 fix it. There are other reasons for using DAGs than just loop = prevention.=20 Zach=20 --=20 http://www.sensinode.com=20 http://zachshelby.org - My blog =E2=80=9COn the Internet of = Things=E2=80=9D=20 Mobile: +358 40 7796297=20 Zach Shelby=20 Head of Research=20 Sensinode Ltd.=20 Kidekuja 2=20 88610 Vuokatti, FINLAND=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Jul 31 06:14:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C54E3A698E; Fri, 31 Jul 2009 06:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.270, 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 7pUDyMcYNPED; Fri, 31 Jul 2009 06:14:36 -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 E225D3A6DAC; Fri, 31 Jul 2009 06:14:27 -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 n6VDEREn009801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2009 15:14:27 +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 n6VDEQlD009137; Fri, 31 Jul 2009 15:14:27 +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 n6VDEQFT003089; Fri, 31 Jul 2009 15:14:26 +0200 Message-ID: <4A72EE32.1010207@gmail.com> Date: Fri, 31 Jul 2009 15:14:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: d.sturek@att.net References: <551598593.6702601249038752130.JavaMail.root@mail02.pantherlink.uwm.edu> <16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> <001101ca11d8$102811b0$30783510$@sturek@att.net> In-Reply-To: <001101ca11d8$102811b0$30783510$@sturek@att.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:14:37 -0000 Don Sturek a écrit : > Hi Mukul, > > I don't agree that the alternate solutions proposed for ROLL scale > and could support requirements outside building controls. > Specifically, I believe that the non-DAG solutions will require state > information retention which will limit deployment beyond a modest > number of nodes in the network. > > I believe the opposite as to what is proposed below. I would propose > using the RPL proposal as the baseline and provide some mechanisms > to support optimization of P2P traffic. I'm neutral on many points, but let me present a parallel from the Mobile IP world, parallel to the incentive to do a baseline first followed by optimizations for P2P. In Mobile IP, NEMO and PMIP there was/is a similar tendency - unoptimal paths first and optimizations later; the basis happened quickly yet the optimizations part doesn't seem to take off despite existence of solid deployed basis[*]. I suggest myself to better have P2P right in the spec from the beginning, with security; but that's just me, one never knows. Just a rant, Alex [*] For Mobile IP, incentive was given to build first the base protocol using three entities MN-HA-CN and leave the straight MN-CN communication for later ("Route Optimization"), similar to P2P. It did get specified in that order but the RO part never deployed. In PMIP there is a similar tendency that I personally think is happening now. In RO for NEMO also too - RO for NEMO is not taking off, even if the basis un-optimized protocol works ok, 3 NEMO RO requirements drafts are WG items, 2 RFCs describe the need, and more. > > Best Regards, > > Don Sturek > > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Friday, > July 31, 2009 4:27 AM To: Jerald P Martocci Cc: ROLL WG; > roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the > protocol work > > I absolutely support the approach Jerry suggested: > > 1) The foundation should be as simple as possible - a simple distance > vector approach (I hope there is an agreement on this) describing > next-hop selection based on routing metrics defined in the routing > metrics draft, constraints and strategies (OCP) and basic rules to > decide when to generate RAs. The foundation should not include any > mechanism to deal with loops (so, it should not include DAGs unless > DAGs can be shown to be critical in meeting other essential > requirements). > > 2) Additional document(s) suggesting solutions catered towards MP2P > and/or P2P routing using different mechanisms to deal with loops > (including DAGs). > > Thanks Mukul > > ----- Original Message ----- From: "Jerald P Martocci" > To: "Zach Shelby" > Cc: "Mukul Goyal" , "ROLL WG" , > roll-bounces@ietf.org Sent: Thursday, July 30, 2009 3:59:30 PM GMT > -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the > protocol work > > > > Zach, > > When the design team was formed it stated its plan was to develop a > core routing specification that met the needs of all the requirement > specifications and then ancillary specifications to meet the > specific needs for each of the requirements. RPL as currently > written seems perfectly suitable for the MP2P requirement, yet not > too suitable for P2P requirement. Could we repackage RPL so that its > base spec contains only the generic routing requirements such as 1) > using varied metrics to define path preferences, 2) OCP to advertise > path strategy and 3) trickle to cleanly vary periodic requirements. > Then RPL-1 could be then enhancements for MP2P applications and would > include the DAG. This would allow us to define a different > extension, RPL-2, for P2P requirements that need not be DAG based. > > JP has promised that if I just shut-up and give the DT some time, > they will provide a solid P2P solution. I am willing to do that. > However, I would hate to start compromising the MP2P solution to > wedge in a sub-optimal P2P solution. Maybe we can have our cake and > eat it too if we simply repackage the specs a bit. > > Jerry > > > > > Zach Shelby Sent by: roll-bounces@ietf.org > > 07/30/2009 10:02 AM To Mukul Goyal > > cc ROLL WG > > Subject Re: [Roll] Moving forward with the protocol work > > > > Hi, > > Mukul Goyal wrote: >> Mischa, >> >>> We should use this early design stage to come up with one >>> solution - one >> solution which is not necessarily optimum for all cases but for the >> (e.g.) 95% quantile. The PHY guys learned to live with such an >> approach. The MAC folks are getting there and we should take our >> chance now. 95% means clearly to concentrate on the core issues, of >> which loop detection/avoidance, p2p and security are somehow still >> open. >> >> When you say a solution, it seems that you want one particular >> protocol. I am OK with RPL as a protocol even though it has >> deficiencies (such as > P2P routing). But, the implication of giving it the WG status seems > to be that RPL would be the _framework_ on which all future ROLL work > would be based. I am not in support of the use of RPL as a framework > unless it eliminates its current tight coupling with DAGs (a, rather > heavy duty, loop prevention mechanism). > > The goal of the WG from my understanding, is to produce *one* > protocol in the current charter. RPL is definitely suitable as a > starting point for that protocol (JP said foundation, not framework). > I completely support this approach. > > From the industry point of view we need a single solution, which > fulfills application requirements sufficiently and thus can be widely > deployed commercially. > > Regarding loop prevention, so what if RPL does a better job than is > necessary? Does it break some requirement doing that? If so, we > should fix it. There are other reasons for using DAGs than just loop > prevention. > > Zach > From d.sturek@att.net Fri Jul 31 06:29:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CEA3A68EA for ; Fri, 31 Jul 2009 06:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzbDkoB0-lZ2 for ; Fri, 31 Jul 2009 06:29:38 -0700 (PDT) Received: from smtp118.sbc.mail.re3.yahoo.com (smtp118.sbc.mail.re3.yahoo.com [66.196.96.91]) by core3.amsl.com (Postfix) with SMTP id E7FAF3A6EC0 for ; Fri, 31 Jul 2009 06:29:20 -0700 (PDT) Received: (qmail 57002 invoked from network); 31 Jul 2009 13:22:42 -0000 Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp118.sbc.mail.re3.yahoo.com with SMTP; 31 Jul 2009 13:22:42 -0000 X-YMail-OSG: l8DHICUVM1mgGA1altTBe7hIdn8xuTu6cQhrDbUYWaDUss1x.ylRQ2ltbv7OPT8vMVF0ttPOD5A5UkdrHNf9eZXZ6_kGWJSRyEcxPA4ZEvQj7NW1LJrN8tJi4IXMo_lOSA1uVXpqQ.e0HLRQq208u9WQb9wtHr4nsIATXhEtpXDPl3WF1vFfHDIJPwYU_hgqZuUM_r1mqHi3Cn06PAx91PBLz74XgpRKXH16LjpKaEiSrw8JfdDo2AB4ChYCcxRvJGuUihbUFmtuL3kSJ9LwD4qMIaSxmRvAKnxILh2cHwWm76F6U1sZ8uMtAMC56w-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" , "'Pascal Thubert \(pthubert\)'" References: <791602312.6714891249045509175.JavaMail.root@mail02.pantherlink.uwm.edu> <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 31 Jul 2009 06:22:36 -0700 Message-ID: <003c01ca11e1$fa5fb310$ef1f1930$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoR39MRXSJ9yWdGSFeR/h5yKs/4HQAAZFcg Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:29:38 -0000 Hi Mukul, Could we please see if ROLL can address the P2P requirement to meet your = requirements (and Jerry's building controls requirements)? = Alternatively, if you do elect to take up the issue in MANET, I am also = interested since as I mentioned Smart Metering has a P2P requirement as = well. In general, I think the P2P issue is unavoidable in ROLL (and assuming = we don't lose the DAG for low resource transport of P2MP/MP2P traffic) Don -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu]=20 Sent: Friday, July 31, 2009 6:07 AM To: Pascal Thubert (pthubert) Cc: ROLL WG; roll-bounces@ietf.org; d sturek; Jerald P Martocci Subject: Re: [Roll] Moving forward with the protocol work Pascal OK. This puts all the arguments to rest. Me, Jerry and JP (who has been = insisting again and again that ROLL has to provide good P2P solution) = had been looking at the wrong WG all along. We should go bang the MANET = WG door and ask for a good P2P routing solution for LLNs. Thanks Mukul =20 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "d sturek" , "Mukul Goyal" , = "Jerald P Martocci" Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Moving forward with the protocol work Hi Don: I'm all with you here. Optimized P2P for all comes at a cost, in = particular in terms of states in the nodes, and is clearly a secondary = priority for ROLL. OTOH, in a use case where all nodes can really afford = all the states involved, the problem seems to drift outside the ROLL = charter and back in the MANET world. ROLL does not compete with MANET and defers to the MANET work where it = applies. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Don Sturek >Sent: vendredi 31 juillet 2009 14:12 >To: 'Mukul Goyal'; 'Jerald P Martocci' >Cc: 'ROLL WG'; roll-bounces@ietf.org >Subject: Re: [Roll] Moving forward with the protocol work > >Hi Mukul, > >I don't agree that the alternate solutions proposed for ROLL scale and = could support requirements outside >building controls. Specifically, I believe that the non-DAG solutions = will require state information >retention which will limit deployment beyond a modest number of nodes = in the network. > >I believe the opposite as to what is proposed below. I would propose = using the RPL proposal as the baseline >and provide some mechanisms to support optimization of P2P traffic. > >Best Regards, > >Don Sturek > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mukul Goyal >Sent: Friday, July 31, 2009 4:27 AM >To: Jerald P Martocci >Cc: ROLL WG; roll-bounces@ietf.org >Subject: Re: [Roll] Moving forward with the protocol work > >I absolutely support the approach Jerry suggested: > >1) The foundation should be as simple as possible - a simple distance = vector approach (I hope there is an >agreement on this) describing next-hop selection based on routing = metrics defined in the routing metrics >draft, constraints and strategies (OCP) and basic rules to decide when = to generate RAs. The foundation should >not include any mechanism to deal with loops (so, it should not include = DAGs unless DAGs can be shown to be >critical in meeting other essential requirements). > >2) Additional document(s) suggesting solutions catered towards MP2P = and/or P2P routing using different >mechanisms to deal with loops (including DAGs). > >Thanks >Mukul > >----- Original Message ----- >From: "Jerald P Martocci" >To: "Zach Shelby" >Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org >Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central >Subject: Re: [Roll] Moving forward with the protocol work > > > >Zach, > >When the design team was formed it stated its plan was to develop a = core routing specification that met the >needs of all the requirement specifications and then ancillary = specifications to meet the specific needs for >each of the requirements. RPL as currently written seems perfectly = suitable for the MP2P requirement, yet not >too suitable for P2P requirement. Could we repackage RPL so that its = base spec contains only the generic >routing requirements such as 1) using varied metrics to define path = preferences, 2) OCP to advertise path >strategy and 3) trickle to cleanly vary periodic requirements. Then = RPL-1 could be then enhancements for MP2P >applications and would include the DAG. This would allow us to define = a different extension, RPL-2, for P2P >requirements that need not be DAG based. > >JP has promised that if I just shut-up and give the DT some time, they = will provide a solid P2P solution. I >am willing to do that. However, I would hate to start compromising the = MP2P solution to wedge in a sub- >optimal P2P solution. Maybe we can have our cake and eat it too if we = simply repackage the specs a bit. > >Jerry > > > > >Zach Shelby >Sent by: roll-bounces@ietf.org > >07/30/2009 10:02 AM >To Mukul Goyal > >cc ROLL WG > >Subject Re: [Roll] Moving forward with the protocol work > > > > >Hi, > >Mukul Goyal wrote: >> Mischa, >> >>> We should use this early design stage to come up with one solution - = one >> solution which is not necessarily optimum for all cases but for the >> (e.g.) 95% quantile. The PHY guys learned to live with such an = approach. >> The MAC folks are getting there and we should take our chance now. = 95% >> means clearly to concentrate on the core issues, of which loop >> detection/avoidance, p2p and security are somehow still open. >> >> When you say a solution, it seems that you want one particular = protocol. I am OK with RPL as a protocol even >though it has deficiencies (such as >P2P routing). But, the implication of giving it the WG status seems to >be that RPL would be the _framework_ on which all future ROLL work = would >be based. I am not in support of the use of RPL as a framework unless = it >eliminates its current tight coupling with DAGs (a, rather heavy duty, >loop prevention mechanism). > >The goal of the WG from my understanding, is to produce *one* protocol >in the current charter. RPL is definitely suitable as a starting point >for that protocol (JP said foundation, not framework). I completely >support this approach. > >From the industry point of view we need a single solution, which >fulfills application requirements sufficiently and thus can be widely >deployed commercially. > >Regarding loop prevention, so what if RPL does a better job than is >necessary? Does it break some requirement doing that? If so, we should >fix it. There are other reasons for using DAGs than just loop = prevention. > >Zach > >-- >http://www.sensinode.com >http://zachshelby.org - My blog =E2=80=9COn the Internet of = Things=E2=80=9D >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Fri Jul 31 08:00:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302E43A6D8C; Fri, 31 Jul 2009 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, 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 AZo-ptgk38PT; Fri, 31 Jul 2009 08:00:12 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id CEF4828C351; Fri, 31 Jul 2009 08:00:12 -0700 (PDT) Received: from [10.10.40.28] (cust-67-203-88-62.static.o1.com [67.203.88.62]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n6VF0BWV018612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2009 08:00:12 -0700 (PDT) Message-ID: <4A7306FA.4070603@eecs.berkeley.edu> Date: Fri, 31 Jul 2009 08:00:10 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Mukul Goyal References: <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 15:00:14 -0000 Mukul - I'm trying to understand your concern with DAGs. Is it the "A" that bothers you? A requirement from industrial is that the protocol allow graphs not just trees (it's difficult for me to refrain from using words like insist and abhor here), so the G is important. Directed is equivalent to "routing". Acyclic by some mechanism seems like a good idea, but not something that the design team was fanatic about. What am I missing? ksjp Mukul Goyal wrote: > Don > > I will get back to the list regarding the scalability and flooding (BTW, the solution I proposed does not involve flooding, which I abhore with same vengeance as you) argument you made in favor of RPL and again the alternate solutions. Also, I will wait for DT solution for good P2P routing in RPL, but it seems to me that it has to involve some state maintenance in nodes. > > But, for a moment, lets forget about the alternate solutions. Lets just focus on RPL. > > All I am saying is that RPL, at present, is too tightly coupled with DAGs, which is a loop prevention mechanism as I understand it. Putting a specific loop prevention mechanism, a non-essential requirement, in the _foundation_ does not sound like a good idea to me. > > Thanks > Mukul > > ----- Original Message ----- > From: "Don Sturek" > To: "Mukul Goyal" , "Jerald P Martocci" > Cc: "ROLL WG" , roll-bounces@ietf.org > Sent: Friday, July 31, 2009 7:11:38 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] Moving forward with the protocol work > > Hi Mukul, > > I don't agree that the alternate solutions proposed for ROLL scale and could support requirements outside building controls. Specifically, I believe that the non-DAG solutions will require state information retention which will limit deployment beyond a modest number of nodes in the network. > > I believe the opposite as to what is proposed below. I would propose using the RPL proposal as the baseline and provide some mechanisms to support optimization of P2P traffic. > > Best Regards, > > Don Sturek > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal > Sent: Friday, July 31, 2009 4:27 AM > To: Jerald P Martocci > Cc: ROLL WG; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > I absolutely support the approach Jerry suggested: > > 1) The foundation should be as simple as possible - a simple distance vector approach (I hope there is an agreement on this) describing next-hop selection based on routing metrics defined in the routing metrics draft, constraints and strategies (OCP) and basic rules to decide when to generate RAs. The foundation should not include any mechanism to deal with loops (so, it should not include DAGs unless DAGs can be shown to be critical in meeting other essential requirements). > > 2) Additional document(s) suggesting solutions catered towards MP2P and/or P2P routing using different mechanisms to deal with loops (including DAGs). > > Thanks > Mukul > > ----- Original Message ----- > From: "Jerald P Martocci" > To: "Zach Shelby" > Cc: "Mukul Goyal" , "ROLL WG" , roll-bounces@ietf.org > Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > > > Zach, > > When the design team was formed it stated its plan was to develop a core routing specification that met the needs of all the requirement specifications and then ancillary specifications to meet the specific needs for each of the requirements. RPL as currently written seems perfectly suitable for the MP2P requirement, yet not too suitable for P2P requirement. Could we repackage RPL so that its base spec contains only the generic routing requirements such as 1) using varied metrics to define path preferences, 2) OCP to advertise path strategy and 3) trickle to cleanly vary periodic requirements. Then RPL-1 could be then enhancements for MP2P applications and would include the DAG. This would allow us to define a different extension, RPL-2, for P2P requirements that need not be DAG based. > > JP has promised that if I just shut-up and give the DT some time, they will provide a solid P2P solution. I am willing to do that. However, I would hate to start compromising the MP2P solution to wedge in a sub-optimal P2P solution. Maybe we can have our cake and eat it too if we simply repackage the specs a bit. > > Jerry > > > > > Zach Shelby > Sent by: roll-bounces@ietf.org > > 07/30/2009 10:02 AM > To Mukul Goyal > > cc ROLL WG > > Subject Re: [Roll] Moving forward with the protocol work > > > > > Hi, > > Mukul Goyal wrote: > >> Mischa, >> >> >>> We should use this early design stage to come up with one solution - one >>> >> solution which is not necessarily optimum for all cases but for the >> (e.g.) 95% quantile. The PHY guys learned to live with such an approach. >> The MAC folks are getting there and we should take our chance now. 95% >> means clearly to concentrate on the core issues, of which loop >> detection/avoidance, p2p and security are somehow still open. >> >> When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as >> > P2P routing). But, the implication of giving it the WG status seems to > be that RPL would be the _framework_ on which all future ROLL work would > be based. I am not in support of the use of RPL as a framework unless it > eliminates its current tight coupling with DAGs (a, rather heavy duty, > loop prevention mechanism). > > The goal of the WG from my understanding, is to produce *one* protocol > in the current charter. RPL is definitely suitable as a starting point > for that protocol (JP said foundation, not framework). I completely > support this approach. > > From the industry point of view we need a single solution, which > fulfills application requirements sufficiently and thus can be widely > deployed commercially. > > Regarding loop prevention, so what if RPL does a better job than is > necessary? Does it break some requirement doing that? If so, we should > fix it. There are other reasons for using DAGs than just loop prevention. > > Zach > > From jvasseur@cisco.com Fri Jul 31 09:09:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C8628C333 for ; Fri, 31 Jul 2009 09:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.677 X-Spam-Level: X-Spam-Status: No, score=-7.677 tagged_above=-999 required=5 tests=[AWL=-1.078, 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 gGgxjM66lLzH for ; Fri, 31 Jul 2009 09:09:38 -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 C3B4C28C33F for ; Fri, 31 Jul 2009 09:09:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAHAPuzckqrR7PE/2dsb2JhbACVZqU9iCmQQAWEGA X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208";a="221917489" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2009 16:09:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6VG9Dpa002394; Fri, 31 Jul 2009 09:09:13 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6VG8FdI000493; Fri, 31 Jul 2009 16:09:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:09:12 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:09:11 +0200 Message-Id: <55202946-5545-4A0C-B957-9B25F058E913@cisco.com> From: JP Vasseur To: Zach Shelby , "Jerald.P.Martocci@jci.com Martocci" In-Reply-To: <4A7216D2.8040304@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 v935.3) Date: Fri, 31 Jul 2009 18:09:11 +0200 References: <4A7216D2.8040304@sensinode.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:09:12.0314 (UTC) FILETIME=[3E4B6DA0:01CA11F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5326; t=1249056553; x=1249920553; c=relaxed/simple; s=sjdkim4002; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=A779aIuE5KekxULxuqWYH4hc9pvIGr7SoAm8+OYRkXM=; b=nTUfqgI66K/2WteahiB1PYXkG9KaAbQmDVQ7Bw+EwGKKwRXNo66Fu99q3j pDQOKYsQJzS9/JE3SsqHBN86iECE0jdhlKvhs19zWtiw7Yxv1HCBVTikH0mr cTrYkCNcoG; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:09:40 -0000 On Jul 30, 2009, at 11:55 PM, Zach Shelby wrote: > Jerry, > > Jerald.P.Martocci@jci.com wrote: >> Zach, >> When the design team was formed it stated its plan was to develop a =20= >> core routing specification that met the needs of all the =20 >> requirement specifications and then ancillary specifications to =20 >> meet the specific needs for each of the requirements. RPL as =20 >> currently written seems perfectly suitable for the MP2P =20 >> requirement, yet not too suitable for P2P requirement. Could we =20 >> repackage RPL so that its base spec contains only the generic =20 >> routing requirements such as 1) using varied metrics to define path =20= >> preferences, 2) OCP to advertise path strategy and 3) trickle to =20 >> cleanly vary periodic requirements. Then RPL-1 could be then =20 >> enhancements for MP2P applications and would include the DAG. This =20= >> would allow us to define a different extension, RPL-2, for P2P =20 >> requirements that need not be DAG based. > > We all agree that RPL currently only contains basic P2P support =20 > using the DV state built up on the DAG. I also agree with you that =20 > the wording on keeping DV state in routers (within memory =20 > constraints) should be fixed (easy). There is definitely consensus =20 > that the next version needs a solid P2P mechanism. There is no =20 > reason that an additional P2P feature would be suboptimal with the =20 > DAG - I see them as being complimentary. Correct. > >> JP has promised that if I just shut-up and give the DT some time, =20 >> they will provide a solid P2P solution. I am willing to do that. =20= >> However, I would hate to start compromising the MP2P solution to =20 >> wedge in a sub-optimal P2P solution. Maybe we can have our cake =20 >> and eat it too if we simply repackage the specs a bit. > > This is just -01 of this draft, so JP is right ;-) The DT was clear =20= > this is an early draft and that P2P is coming. So... on the P2P =20 > front, it would be great to see contributions to the WG on how to =20 > include suitable P2P support to RPL. The thing about a WG document - =20= > is that we work together on it. > This is perfectly correct. JP. > Zach > >> Jerry >> *Zach Shelby * >> Sent by: roll-bounces@ietf.org >> 07/30/2009 10:02 AM >> =09 >> To >> Mukul Goyal >> cc >> ROLL WG >> Subject >> Re: [Roll] Moving forward with the protocol work >> =09 >> Hi, >> Mukul Goyal wrote: >> > Mischa, >> > >> >> We should use this early design stage to come up with one =20 >> solution - one >> > solution which is not necessarily optimum for all cases but for the >> > (e.g.) 95% quantile. The PHY guys learned to live with such an =20 >> approach. >> > The MAC folks are getting there and we should take our chance =20 >> now. 95% >> > means clearly to concentrate on the core issues, of which loop >> > detection/avoidance, p2p and security are somehow still open. >> > >> > When you say a solution, it seems that you want one particular =20 >> protocol. I am OK with RPL as a protocol even though it has =20 >> deficiencies (such as >> P2P routing). But, the implication of giving it the WG status seems =20= >> to >> be that RPL would be the _framework_ on which all future ROLL work =20= >> would >> be based. I am not in support of the use of RPL as a framework =20 >> unless it >> eliminates its current tight coupling with DAGs (a, rather heavy =20 >> duty, >> loop prevention mechanism). >> The goal of the WG from my understanding, is to produce *one* =20 >> protocol >> in the current charter. RPL is definitely suitable as a starting =20 >> point >> for that protocol (JP said foundation, not framework). I completely >> support this approach. >> =46rom the industry point of view we need a single solution, which >> fulfills application requirements sufficiently and thus can be widely >> deployed commercially. >> Regarding loop prevention, so what if RPL does a better job than is >> necessary? Does it break some requirement doing that? If so, we =20 >> should >> fix it. There are other reasons for using DAGs than just loop =20 >> prevention. >> Zach >> --=20 >> http://www.sensinode.com >> 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 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > --=20 > http://www.sensinode.com > 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. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Jul 31 09:13:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C9E28C23E for ; Fri, 31 Jul 2009 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.6 X-Spam-Level: X-Spam-Status: No, score=-7.6 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1F-Oj3JlWp7 for ; Fri, 31 Jul 2009 09:13:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 96BB33A6AAB for ; Fri, 31 Jul 2009 09:13:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACe1ckpAZnmf/2dsb2JhbACCVbhFiCmQQAWEGA X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208,217";a="52463695" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2009 16:13:09 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6VGD9Lf006105; Fri, 31 Jul 2009 12:13:09 -0400 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6VGD8aM027482; Fri, 31 Jul 2009 16:13:08 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:13:08 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:13:07 +0200 Message-Id: <4E8F74BF-BD1F-416B-A415-71AF2D176456@cisco.com> From: JP Vasseur To: Matthew.Anderson@us.elster.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-31-166646724 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 18:13:06 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:13:07.0809 (UTC) FILETIME=[CAA91D10:01CA11F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3316; t=1249056789; x=1249920789; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20 |To:=20Matthew.Anderson@us.elster.com; bh=6WTmS9rmxEhWjOs3UZO6S0TLd5tJvkfvKMEjAGLMJqA=; b=LrnHIV6it/4f1vSnpLx4+BM4j4ePUktm6wxLv7VrpjN01cbTtZeD8PI1Tq g2WWKUPXNqlV325Z48TsFfjUSkO8B5P8y4WSsNFm+3yxzyXW57MA6l6mmpJ/ sFZUlsSkbO; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:13:10 -0000 --Apple-Mail-31-166646724 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 31, 2009, at 12:06 AM, Matthew.Anderson@us.elster.com wrote: > I think everyone acknowledges that there are areas (P2P, security) > to resolve. But if adopting RPL as the WG document means that the > WG as a whole can work together to design the best solution, I think > that is the best course of action. I'm admittedly new to the IETF > process but that's my understanding of what the goal of adopting RPL > is - to provide a basis to work from as a working group and RPL > version X may be very different than RPL version 1. Clarifications are needed considering the number of people new to IETF process. Adopting a document as WG document is again not an end, thus my question on whether you all think that RPL provides a good foundation. Of course, this also means that people agrees with the main foundations, which so far seems to be the case. So there is no RPL version 1 or 2, but an RPL that needs to be improved in several areas of course and I do see many people willing to help there, which is great. Thanks. JP. > > Matt Anderson > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-31-166646724 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 31, 2009, = at 12:06 AM, Matthew.Anderson@us.elster.= com wrote:

I think everyone = acknowledges that there are areas (P2P, security) to resolve.  But = if adopting RPL as the WG document means that the WG as a whole can work = together to design the best solution, I think that is the best course of = action.  I'm admittedly new to the IETF process but that's my = understanding of what the goal of adopting RPL is - to provide a basis = to work from as a working group and RPL version X may be very different = than RPL version 1. =

Clarifications are needed = considering the number of people new to IETF process. Adopting a = document as WG document is again not an end, thus my question on whether = you all think that RPL provides a good foundation. Of course, this also = means that people agrees with the main foundations, which so far seems = to be the case. So there is no RPL version 1 or 2, but an RPL that needs = to be improved in several areas of course and I do see many people = willing to help there, which is = great.

Thanks.

JP.
=

Matt Anderson =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-31-166646724-- From jvasseur@cisco.com Fri Jul 31 09:20:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418043A6CDC for ; Fri, 31 Jul 2009 09:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.933 X-Spam-Level: X-Spam-Status: No, score=-8.933 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, J_CHICKENPOX_93=0.6, 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 NZZE6i4zrXWA for ; Fri, 31 Jul 2009 09:20:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 563133A67D9 for ; Fri, 31 Jul 2009 09:20:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYAAMu2ckqQ/uCKe2dsb2JhbACCJhcYl0cBARYkBqA5iCmQQQWCLYFr X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208,217";a="46221582" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2009 16:20:55 +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 n6VGKs4s022362 for ; Fri, 31 Jul 2009 18:20:54 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VGKswJ003064 for ; Fri, 31 Jul 2009 16:20:54 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:20:55 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:20:53 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-32-167113929 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 18:20:53 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF492D14@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:20:54.0400 (UTC) FILETIME=[E0C54000:01CA11FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10837; t=1249057255; x=1249921255; 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:=20Fwd=3A=20[Roll]=20Moving=20forward=20with=20the =20protocol=20work |Sender:=20; bh=XbMirg8k6lC02cnoYNqjB92fKIb+ZabURbf+Xcx6mho=; b=s9xqPGYonuDuzkpvLcrsVc38Z58JabuicsJOw2PlKnuKnil4fueE9+jGEj YjeYL64KyLx/BgbifM6Gp4IjsTk79pf6GzgqUicgHgwViRoqndkdGXQoH8jP aPEZyreMWC; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Fwd: Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:20:56 -0000 --Apple-Mail-32-167113929 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I do not want to stop that excellent discussion. Just please change the thread title. Begin forwarded message: > From: > Date: July 31, 2009 9:10:35 AM CEDT > To: > Cc: roll@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > Hi Jerry, all, > > Thanks for the detailed description of the Building Automation > setting. > I'm wondering if you could propose an estimate of how many multi-hop > P2P > routes an average node would sit on? So that we can gauge the > consequences of potential P2P routing algorithms on nodes' memory/ > energy > limits... > As suggested by somebody else (sorry I lost track who it was), it > would > seem that many P2P flows in a given "room" are direct connections with > no (control plane)routing involved. Am I totally mistaken on this? > Regards, > > Dominique > > ----------------------- > Date: Thu, 30 Jul 2009 14:12:10 -0500 > From: Jerald.P.Martocci@jci.com > Subject: Re: [Roll] Moving forward with the protocol work > To: "Julien Abeille (jabeille)" > Cc: ROLL WG , roll-bounces@ietf.org > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > Hi Julien, > > Section 3 of the Building Requirements ID describes the typical > devices > and device densities in a commercial building; Section 6 describes the > traffic flow. Let me try to reiterate here ... > > The building control application domain includes Heating Ventilation > and > Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and > Fire control. While each has its nuances, they all fall roughly onto > the same topology. The leaf layer for these systems are the sensors. > There's a plethora of them including temperature sensors, humidity > sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, > occupancy sensors, light switches, and the list goes on. In a room, > you > might expect a temp sensor, a humidity sensor, an occupancy sensor, > solar sensor, smoke detector and light switches. > > Now along with the room sensors, there are room actuators and room > controllers. The controllers receive the environmental data from the > sensors, and determine the necessary control based on conditions, > system > overrides, time-of-day, etc and then control the environment by > tweaking > the actuators accordingly. The HVAC system will modulate the airflow > and augment heating/cooling. The shade controller will sense solar > load > and adjust the shades. The lighting will be adjusted as requested by > the presentation mode. When I talk about a room, I am not meaning > necessarily only a closed door meeting room. This would also apply to > public spaces such as an attria, hallways, ballrooms.etc. The key > ingredient in this is that each of these areas has a self contained > sensor/controller/actuator subsystem. > > Now, the next layer of controllers are the zone and area controllers. > These are higher level devices that supply the facility with more > global > control systems. HVAC will have air handlers that supply fresh air to > the rooms. Chillers that support cold air to the rooms, boilers that > supply heat. Lighting panels will control whole floors rather than > simply rooms. > The point being that these higher order devices are also LLN devices > incorporating another whole set of sensors such as outdoor air temp, > relative humidity, etc. > > With regards to your question about layer 2, at present these devices > are not IP devices. They typically reside on an EIA-485 network. > > Hope this helps, > > Jerry > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-32-167113929 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I do not want to stop that = excellent discussion. Just please change the thread = title.

Begin forwarded message:

Date: July 31, 2009 9:10:35 AM = CEDT
Subject: = Re: [Roll] Moving forward with the protocol = work

=
Hi Jerry, all,

Thanks for the detailed description of = the Building Automation setting.
I'm wondering if you could propose = an estimate of how many multi-hop P2P
routes an average node would = sit on? So that we can gauge the
consequences of potential P2P = routing algorithms on nodes' memory/energy
limits...
As suggested = by somebody else (sorry I lost track who it was), it would
seem that = many P2P flows in a given "room" are direct connections with
no = (control plane)routing involved. Am I totally mistaken on = this?
Regards,

Dominique

----------------------- =
Date: Thu, 30 Jul 2009 14:12:10 -0500
From: Jerald.P.Martocci@jci.comSubject: Re: [Roll] Moving forward with the protocol work
To: = "Julien Abeille (jabeille)" <jabeille@cisco.com>
Cc: = ROLL WG <roll@ietf.org>, roll-bounces@ietf.org
Message= -ID:
=
<OF1728BA87.3BFA9AB9-ON86257603.005C71F1-86257603.00697C0E@jci.com<= /a>>
Content-Type: text/plain; charset=3D"us-ascii"

Hi = Julien,

Section 3 of the Building Requirements ID describes the = typical devices
and device densities in a commercial building; = Section 6 describes the
traffic flow.  Let me try to reiterate = here ...

The building control application domain includes Heating = Ventilation and
Air Conditioning (aka HVAC), Physical Security, = Lighting, Elevator and
Fire control.  While each has its = nuances, they all fall roughly onto
the same topology.  The leaf = layer for these systems are the sensors.
There's a plethora of them = including temperature sensors, humidity
sensors, pressure sensors, = tamper switches, C02, C0, smoke detectors,
occupancy sensors, light = switches, and the list goes on.  In a room, you
might expect a = temp sensor, a humidity sensor, an occupancy sensor,
solar sensor, = smoke detector and light switches.

Now along with the room = sensors, there are room actuators and room
controllers.  The = controllers receive the environmental data from the
sensors, and = determine the necessary control based on conditions, = system
overrides, time-of-day, etc and then control the environment = by tweaking
the actuators accordingly.  The HVAC system will = modulate the airflow
and augment heating/cooling.  The shade = controller will sense solar load
and adjust the shades.  The = lighting will be adjusted as requested by
the presentation mode. =  When I talk about a room, I am not meaning
necessarily only a = closed door meeting room.  This would also apply to
public = spaces such as an attria, hallways, ballrooms.etc.  The = key
ingredient in this is that each of these areas has a self = contained
sensor/controller/actuator subsystem.

Now, the next = layer of controllers are the zone and area controllers.
These are = higher level devices that supply the facility with more = global
control systems.  HVAC will have air handlers that supply = fresh air to
the rooms.  Chillers that support cold air to the = rooms, boilers that
supply heat.  Lighting panels will control = whole floors rather than
simply rooms.
The point being that = these higher order devices are also LLN devices
incorporating another = whole set of sensors such as outdoor air temp,
relative humidity, = etc.

With regards to your question about layer 2, at present = these devices
are not IP devices.  They typically reside on an = EIA-485 network.

Hope this = helps,

Jerry

_______________________________________________=
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-32-167113929-- From jvasseur@cisco.com Fri Jul 31 09:22:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4F3A6D56 for ; Fri, 31 Jul 2009 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.563 X-Spam-Level: X-Spam-Status: No, score=-7.563 tagged_above=-999 required=5 tests=[AWL=-0.964, 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 atAjW2SaCTHg for ; Fri, 31 Jul 2009 09:22:16 -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 8B3793A6D75 for ; Fri, 31 Jul 2009 09:22:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAHAAi3ckqrR7MV/2dsb2JhbACVZqU4iCmQQQWEGA X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208";a="357918409" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2009 16:22:12 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6VGMCJP028245 for ; Fri, 31 Jul 2009 09:22:12 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6VGMBfW014203 for ; Fri, 31 Jul 2009 16:22:11 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:22:11 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:22:10 +0200 Message-Id: <06831E32-76B8-4CE3-9D3A-DAACD5C806B1@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07E202F2@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 18:22:09 +0200 References: <551598593.6702601249038752130.JavaMail.root@mail02.pantherlink.uwm.edu><16981251.6703121249039606520.JavaMail.root@mail02.pantherlink.uwm.edu> <001101ca11d8$102811b0$30783510$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07E202F2@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:22:10.0859 (UTC) FILETIME=[0E57F7B0:01CA11FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7084; t=1249057332; x=1249921332; c=relaxed/simple; s=sjdkim1004; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=nBZU6O1VwCMZ3J/A7P39istsvT2/5OXXHLLFYBnQr9E=; b=BYGyycdTXb/qEtkWpF+CqbqF/tyCnqsHxzr7thzrJAzNzv2oio4096cDsQ ui/V1/YJYDVPUfbtvFLcaEQ5U7UWFuy/Zgf0cGIURkz7rG6+fqex90JaqIrB M+CY4u11gBpRrQtR93MITC32ieI0GT1fJKTYRZd+/LIjDZu6hGp/s=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:22:17 -0000 Please change the thread title. On Jul 31, 2009, at 2:26 PM, Pascal Thubert (pthubert) wrote: > Hi Don: > > I'm all with you here. Optimized P2P for all comes at a cost, in =20 > particular in terms of states in the nodes, and is clearly a =20 > secondary priority for ROLL. OTOH, in a use case where all nodes can =20= > really afford all the states involved, the problem seems to drift =20 > outside the ROLL charter and back in the MANET world. > > ROLL does not compete with MANET and defers to the MANET work where =20= > it applies. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of Don Sturek >> Sent: vendredi 31 juillet 2009 14:12 >> To: 'Mukul Goyal'; 'Jerald P Martocci' >> Cc: 'ROLL WG'; roll-bounces@ietf.org >> Subject: Re: [Roll] Moving forward with the protocol work >> >> Hi Mukul, >> >> I don't agree that the alternate solutions proposed for ROLL scale =20= >> and could support requirements outside >> building controls. Specifically, I believe that the non-DAG =20 >> solutions will require state information >> retention which will limit deployment beyond a modest number of =20 >> nodes in the network. >> >> I believe the opposite as to what is proposed below. I would =20 >> propose using the RPL proposal as the baseline >> and provide some mechanisms to support optimization of P2P traffic. >> >> Best Regards, >> >> Don Sturek >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of Mukul Goyal >> Sent: Friday, July 31, 2009 4:27 AM >> To: Jerald P Martocci >> Cc: ROLL WG; roll-bounces@ietf.org >> Subject: Re: [Roll] Moving forward with the protocol work >> >> I absolutely support the approach Jerry suggested: >> >> 1) The foundation should be as simple as possible - a simple =20 >> distance vector approach (I hope there is an >> agreement on this) describing next-hop selection based on routing =20 >> metrics defined in the routing metrics >> draft, constraints and strategies (OCP) and basic rules to decide =20 >> when to generate RAs. The foundation should >> not include any mechanism to deal with loops (so, it should not =20 >> include DAGs unless DAGs can be shown to be >> critical in meeting other essential requirements). >> >> 2) Additional document(s) suggesting solutions catered towards MP2P =20= >> and/or P2P routing using different >> mechanisms to deal with loops (including DAGs). >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Jerald P Martocci" >> To: "Zach Shelby" >> Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org >> Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central >> Subject: Re: [Roll] Moving forward with the protocol work >> >> >> >> Zach, >> >> When the design team was formed it stated its plan was to develop a =20= >> core routing specification that met the >> needs of all the requirement specifications and then ancillary =20 >> specifications to meet the specific needs for >> each of the requirements. RPL as currently written seems perfectly =20= >> suitable for the MP2P requirement, yet not >> too suitable for P2P requirement. Could we repackage RPL so that =20 >> its base spec contains only the generic >> routing requirements such as 1) using varied metrics to define path =20= >> preferences, 2) OCP to advertise path >> strategy and 3) trickle to cleanly vary periodic requirements. =20 >> Then RPL-1 could be then enhancements for MP2P >> applications and would include the DAG. This would allow us to =20 >> define a different extension, RPL-2, for P2P >> requirements that need not be DAG based. >> >> JP has promised that if I just shut-up and give the DT some time, =20 >> they will provide a solid P2P solution. I >> am willing to do that. However, I would hate to start compromising =20= >> the MP2P solution to wedge in a sub- >> optimal P2P solution. Maybe we can have our cake and eat it too if =20= >> we simply repackage the specs a bit. >> >> Jerry >> >> >> >> >> Zach Shelby >> Sent by: roll-bounces@ietf.org >> >> 07/30/2009 10:02 AM >> To Mukul Goyal >> >> cc ROLL WG >> >> Subject Re: [Roll] Moving forward with the protocol work >> >> >> >> >> Hi, >> >> Mukul Goyal wrote: >>> Mischa, >>> >>>> We should use this early design stage to come up with one =20 >>>> solution - one >>> solution which is not necessarily optimum for all cases but for the >>> (e.g.) 95% quantile. The PHY guys learned to live with such an =20 >>> approach. >>> The MAC folks are getting there and we should take our chance now. =20= >>> 95% >>> means clearly to concentrate on the core issues, of which loop >>> detection/avoidance, p2p and security are somehow still open. >>> >>> When you say a solution, it seems that you want one particular =20 >>> protocol. I am OK with RPL as a protocol even >> though it has deficiencies (such as >> P2P routing). But, the implication of giving it the WG status seems =20= >> to >> be that RPL would be the _framework_ on which all future ROLL work =20= >> would >> be based. I am not in support of the use of RPL as a framework =20 >> unless it >> eliminates its current tight coupling with DAGs (a, rather heavy =20 >> duty, >> loop prevention mechanism). >> >> The goal of the WG from my understanding, is to produce *one* =20 >> protocol >> in the current charter. RPL is definitely suitable as a starting =20 >> point >> for that protocol (JP said foundation, not framework). I completely >> support this approach. >> >> =46rom the industry point of view we need a single solution, which >> fulfills application requirements sufficiently and thus can be widely >> deployed commercially. >> >> Regarding loop prevention, so what if RPL does a better job than is >> necessary? Does it break some requirement doing that? If so, we =20 >> should >> fix it. There are other reasons for using DAGs than just loop =20 >> prevention. >> >> Zach >> >> -- >> http://www.sensinode.com >> 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 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Jul 31 09:28:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDDF3A6B26; Fri, 31 Jul 2009 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.505 X-Spam-Level: X-Spam-Status: No, score=-7.505 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbPQj1mMgfKi; Fri, 31 Jul 2009 09:28:20 -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 D0E153A6807; Fri, 31 Jul 2009 09:28:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4IALW4ckqrR7O6/2dsb2JhbACCJy6TEaUXiCmQRQWEGIl4 X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208,217";a="221926501" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2009 16:28:22 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6VGSMuH026640; Fri, 31 Jul 2009 09:28:22 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6VGSLem021271; Fri, 31 Jul 2009 16:28:21 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:28:21 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:28:20 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-33-167559935 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 18:28:19 +0200 References: <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:28:20.0520 (UTC) FILETIME=[EAADC280:01CA11FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25089; t=1249057702; x=1249921702; c=relaxed/simple; s=sjdkim2002; 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[Roll]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=FJ5QMXo5KCfFCvZrTUaOAnGujp2gdHtajeYuYnovtJQ=; b=I26SeXBUWemf5jtrdQL2d9PP/vxIquItlNYeDwaMG8fq/X9QPKGEkc7atG ce1Tnv0kfy8hBWygldRyRyDXmijisk2Z7cncXQnmfipG1akyvK3t+4/B9b/D L6/Hhgn8lb; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:28:22 -0000 --Apple-Mail-33-167559935 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Mukul, On Jul 31, 2009, at 3:07 PM, Mukul Goyal wrote: > Pascal > > OK. This puts all the arguments to rest. Me, Jerry and JP (who has =20 > been insisting again and again that ROLL has to provide good P2P =20 > solution) had been looking at the wrong WG all along. We should go =20 > bang the MANET WG door and ask for a good P2P routing solution for =20 > LLNs. Hold on please. You expressed your opinion, we fully respect it and do =20= appreciate the comments. Also needless to say that as a chair I hope =20 that you will anyway continue to express your opinion and provide =20 input and ideas. I did say that RPL has to provide a good solution for P2P, simply =20 because this is clearly spelled out in the requirements documents. Please just do not add my name to statements that you made in your =20 last two sentences. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "d sturek" , "Mukul Goyal" , =20 > "Jerald P Martocci" > Cc: "ROLL WG" , roll-bounces@ietf.org > Sent: Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] Moving forward with the protocol work > > Hi Don: > > I'm all with you here. Optimized P2P for all comes at a cost, in =20 > particular in terms of states in the nodes, and is clearly a =20 > secondary priority for ROLL. OTOH, in a use case where all nodes can =20= > really afford all the states involved, the problem seems to drift =20 > outside the ROLL charter and back in the MANET world. > > ROLL does not compete with MANET and defers to the MANET work where =20= > it applies. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of Don Sturek >> Sent: vendredi 31 juillet 2009 14:12 >> To: 'Mukul Goyal'; 'Jerald P Martocci' >> Cc: 'ROLL WG'; roll-bounces@ietf.org >> Subject: Re: [Roll] Moving forward with the protocol work >> >> Hi Mukul, >> >> I don't agree that the alternate solutions proposed for ROLL scale =20= >> and could support requirements outside >> building controls. Specifically, I believe that the non-DAG =20 >> solutions will require state information >> retention which will limit deployment beyond a modest number of =20 >> nodes in the network. >> >> I believe the opposite as to what is proposed below. I would =20 >> propose using the RPL proposal as the baseline >> and provide some mechanisms to support optimization of P2P traffic. >> >> Best Regards, >> >> Don Sturek >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of Mukul Goyal >> Sent: Friday, July 31, 2009 4:27 AM >> To: Jerald P Martocci >> Cc: ROLL WG; roll-bounces@ietf.org >> Subject: Re: [Roll] Moving forward with the protocol work >> >> I absolutely support the approach Jerry suggested: >> >> 1) The foundation should be as simple as possible - a simple =20 >> distance vector approach (I hope there is an >> agreement on this) describing next-hop selection based on routing =20 >> metrics defined in the routing metrics >> draft, constraints and strategies (OCP) and basic rules to decide =20 >> when to generate RAs. The foundation should >> not include any mechanism to deal with loops (so, it should not =20 >> include DAGs unless DAGs can be shown to be >> critical in meeting other essential requirements). >> >> 2) Additional document(s) suggesting solutions catered towards MP2P =20= >> and/or P2P routing using different >> mechanisms to deal with loops (including DAGs). >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Jerald P Martocci" >> To: "Zach Shelby" >> Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org >> Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central >> Subject: Re: [Roll] Moving forward with the protocol work >> >> >> >> Zach, >> >> When the design team was formed it stated its plan was to develop a =20= >> core routing specification that met the >> needs of all the requirement specifications and then ancillary =20 >> specifications to meet the specific needs for >> each of the requirements. RPL as currently written seems perfectly =20= >> suitable for the MP2P requirement, yet not >> too suitable for P2P requirement. Could we repackage RPL so that =20 >> its base spec contains only the generic >> routing requirements such as 1) using varied metrics to define path =20= >> preferences, 2) OCP to advertise path >> strategy and 3) trickle to cleanly vary periodic requirements. =20 >> Then RPL-1 could be then enhancements for MP2P >> applications and would include the DAG. This would allow us to =20 >> define a different extension, RPL-2, for P2P >> requirements that need not be DAG based. >> >> JP has promised that if I just shut-up and give the DT some time, =20 >> they will provide a solid P2P solution. I >> am willing to do that. However, I would hate to start compromising =20= >> the MP2P solution to wedge in a sub- >> optimal P2P solution. Maybe we can have our cake and eat it too if =20= >> we simply repackage the specs a bit. >> >> Jerry >> >> >> >> >> Zach Shelby >> Sent by: roll-bounces@ietf.org >> >> 07/30/2009 10:02 AM >> To Mukul Goyal >> >> cc ROLL WG >> >> Subject Re: [Roll] Moving forward with the protocol work >> >> >> >> >> Hi, >> >> Mukul Goyal wrote: >>> Mischa, >>> >>>> We should use this early design stage to come up with one =20 >>>> solution - one >>> solution which is not necessarily optimum for all cases but for the >>> (e.g.) 95% quantile. The PHY guys learned to live with such an =20 >>> approach. >>> The MAC folks are getting there and we should take our chance now. =20= >>> 95% >>> means clearly to concentrate on the core issues, of which loop >>> detection/avoidance, p2p and security are somehow still open. >>> >>> When you say a solution, it seems that you want one particular =20 >>> protocol. I am OK with RPL as a protocol even >> though it has deficiencies (such as >> P2P routing). But, the implication of giving it the WG status seems =20= >> to >> be that RPL would be the _framework_ on which all future ROLL work =20= >> would >> be based. I am not in support of the use of RPL as a framework =20 >> unless it >> eliminates its current tight coupling with DAGs (a, rather heavy =20 >> duty, >> loop prevention mechanism). >> >> The goal of the WG from my understanding, is to produce *one* =20 >> protocol >> in the current charter. RPL is definitely suitable as a starting =20 >> point >> for that protocol (JP said foundation, not framework). I completely >> support this approach. >> >> =46rom the industry point of view we need a single solution, which >> fulfills application requirements sufficiently and thus can be widely >> deployed commercially. >> >> Regarding loop prevention, so what if RPL does a better job than is >> necessary? Does it break some requirement doing that? If so, we =20 >> should >> fix it. There are other reasons for using DAGs than just loop =20 >> prevention. >> >> Zach >> >> -- >> http://www.sensinode.com >> 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 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-33-167559935 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Mukul,

On = Jul 31, 2009, at 3:07 PM, Mukul Goyal wrote:

Pascal

OK. This puts all the arguments to = rest. Me, Jerry and JP (who has been insisting again and again that ROLL = has to provide good P2P solution) had been looking at the wrong WG all = along. We should go bang the MANET WG door and ask for a good P2P = routing solution for = LLNs.

Hold on please. You = expressed your opinion, we fully respect it and do appreciate the = comments. Also needless to say that as a chair I hope that you will = anyway continue to express your opinion and provide input and = ideas. 
I did say that RPL has to provide a good solution = for P2P, simply because this is clearly spelled out in the requirements = documents.

Please just do not add my name to = statements that you made in your last two = sentences.

Thanks.

J= P.


Thanks
Mukul

----- Original Message = -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "d = sturek" <d.sturek@att.net>, = "Mukul Goyal" <mukul@uwm.edu>, = "Jerald P Martocci" <Jerald.P.Martocci@jci.com>= ;
Cc: "ROLL WG" <roll@ietf.org>, roll-bounces@ietf.org
Sent: = Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] Moving forward with the protocol = work

Hi Don:

I'm all with you here. Optimized P2P for all = comes at a cost, in particular in terms of states in the nodes, and is = clearly a secondary priority for ROLL. OTOH, in a use case where all = nodes can really afford all the states involved, the problem seems to = drift outside the ROLL charter and back in the MANET world.

ROLL = does not compete with MANET and defers to the MANET work where it = applies.

Pascal

-----Original = Message-----
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Don Sturek
Sent: = vendredi 31 juillet 2009 14:12
To: 'Mukul Goyal'; 'Jerald P = Martocci'
Cc: 'ROLL WG'; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with = the protocol work

Hi = Mukul,

I don't agree = that the alternate solutions proposed for ROLL scale and could support = requirements outside
building = controls.  Specifically, I believe that the non-DAG solutions will = require state information
retention which will limit deployment beyond a modest = number of nodes in the network.

I believe the = opposite as to what is proposed below.  I would propose using the = RPL proposal as the baseline
and= provide some mechanisms to support optimization of P2P = traffic.

Best = Regards,

Don = Sturek


-----Original = Message-----
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Mukul Goyal
Sent: = Friday, July 31, 2009 4:27 AM
To: Jerald P Martocci
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Moving forward with = the protocol work

I absolutely = support the approach Jerry suggested:

1) The = foundation should be as simple as possible - a simple distance vector = approach (I hope there is an
agreement on this) describing next-hop selection based on = routing metrics defined in the routing = metrics
draft, constraints and = strategies (OCP) and basic rules to decide when to generate RAs. The = foundation should
not include = any mechanism to deal with loops (so, it should not include DAGs unless = DAGs can be shown to be
critical= in meeting other essential requirements).

2) Additional = document(s) suggesting solutions catered towards MP2P and/or P2P routing = using different
mechanisms to = deal with loops (including DAGs).

Thanks
Mukul

----- Original = Message -----
From: "Jerald P = Martocci" <Jerald.P.Martocci@jci.com>= ;
To: "Zach Shelby" <zach@sensinode.com>
Cc: "Mukul Goyal" <mukul@uwm.edu>, "ROLL WG" <roll@ietf.org>, roll-bounces@ietf.org
Sent: Thursday, July 30, 2009 3:59:30 PM = GMT -06:00 US/Canada Central
Subject: Re: [Roll] Moving forward with the protocol = work



Zach,

When the design = team was formed it stated its plan was to develop a core routing = specification that met the
needs= of all the requirement specifications and then ancillary specifications = to meet the specific needs for
each of the requirements.  RPL as currently written = seems perfectly suitable for the MP2P requirement, yet = not
too suitable for P2P = requirement.  Could we repackage RPL so that its base spec contains = only the generic
routing = requirements such as 1) using varied metrics to define path preferences, = 2) OCP to advertise path
strategy and 3) trickle to cleanly vary periodic = requirements.  Then RPL-1 could be then enhancements for = MP2P
applications and would = include the DAG.  This would allow us to define a different = extension, RPL-2, for P2P
requirements that need not be DAG = based.

JP has promised = that if I just shut-up and give the DT some time, they will provide a = solid P2P solution.  I
am = willing to do that.  However, I would hate to start compromising = the MP2P solution to wedge in a sub-
optimal P2P solution.  Maybe we can have our cake and = eat it too if we simply repackage the specs a = bit.

Jerry




Zach Shelby = <zach@sensinode.com>
Sent by: roll-bounces@ietf.org

07/30/2009 10:02 AM
To = Mukul Goyal <mukul@uwm.edu>

cc ROLL WG = <roll@ietf.org>

Subject = = Re: [Roll] Moving forward with the protocol = work




Hi,

Mukul Goyal = wrote:
Mischa,

We = should use this early design stage to come up with one solution - = one
solution which is not = necessarily optimum for all cases but for = the
(e.g.) 95% quantile. The PHY guys learned to live with = such an approach.
The MAC folks are getting there = and we should take our chance now. = 95%
means clearly to concentrate on the core issues, of which = loop
detection/avoidance, p2p and security are somehow still = open.

When you say a solution, it = seems that you want one particular protocol. I am OK with RPL as a = protocol even
though it has deficiencies (such = as
P2P routing). But, the = implication of giving it the WG status seems = to
be that RPL would be the = _framework_ on which all future ROLL work = would
be based. I am not in = support of the use of RPL as a framework unless = it
eliminates its current = tight coupling with DAGs (a, rather heavy = duty,
loop prevention = mechanism).

The goal of the = WG from my understanding, is to produce *one* = protocol
in the current = charter. RPL is definitely suitable as a starting = point
for that protocol (JP = said foundation, not framework). I = completely
support this = approach.

=46rom the = industry point of view we need a single solution, = which
fulfills application = requirements sufficiently and thus can be = widely
deployed = commercially.

Regarding loop = prevention, so what if RPL does a better job than = is
necessary? Does it break = some requirement doing that? If so, we = should
fix it. There are other = reasons for using DAGs than just loop = prevention.

Zach

--
http://www.sensinode.com
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
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
_________________________________= ______________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-33-167559935-- From jvasseur@cisco.com Fri Jul 31 09:36:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863B13A6D2B for ; Fri, 31 Jul 2009 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.455 X-Spam-Level: X-Spam-Status: No, score=-9.455 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yi5HOdlWJpx7 for ; Fri, 31 Jul 2009 09:36:28 -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 D41F93A6CFC for ; Fri, 31 Jul 2009 09:36:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUAAE+6ckqQ/uCLe2dsb2JhbACCVZdHAQEWJAagIogpkEYFhBg X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208,217";a="46222741" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2009 16:36:24 +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 n6VGaOlE003199; Fri, 31 Jul 2009 18:36:24 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VGaOS2006807; Fri, 31 Jul 2009 16:36:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 18:36:24 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 18:36:23 +0200 Message-Id: <81E95D2B-7C7F-4A2C-97ED-9D7657A45A0E@cisco.com> From: JP Vasseur To: M Anand In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-36-168043883 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 18:36:23 +0200 References: <4A721545.8060304@ekasystems.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Jul 2009 16:36:24.0058 (UTC) FILETIME=[0AE3CDA0:01CA11FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17860; t=1249058184; x=1249922184; 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[Roll]=20=20Moving=20forward=20with=20t he=20protocol=20work |Sender:=20; bh=CgImBMZm+ua+cHxx2KPexKvkVRPJbvLsXF0w2JlJcuE=; b=pGCGT2tJc8hKPvzFwLDD86OGYzqt23crRFqb9o7kAfjsZHZ5sSi7SsiPWJ YUP7AFj83OmlIKlvdpQZY9rlwmNur342lO1k6/72kk2g+1Il5WQll/T+VxgG 07VCAQgPGO; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:36:30 -0000 --Apple-Mail-36-168043883 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Anand, On Jul 31, 2009, at 1:00 AM, M Anand wrote: > I would support adoption of draft-dt-roll-rpl-01 as a WG document > based on the reasoning below. > > The one area of (I think quite valid) concern appears to be optimal > P2P routing or lack thereof. I would make the following points with > regard to this: > > 1. I think first there seems to be some misinterpretation because I > see references to nodes within direct physical range, light switch/ > light etc. in the discussion. > RPL as it stands would let a node in direct contact with another > route directly to that node. No need to go up and down a DAG. I > think this was in one of the examples in the slide presentation in > the mtg. and, if I recall correctly, someone explcitly asked this > question. > This is perfectly correct, > 2. So, we are not talking about P2P route sub-optimality in RPL when > there is a one-hop route. And I sure would hope that a light switch > would be in direct physical range of its light. We can leave aside > these cases when debating the possible P2P demerits of the present > RPL. > > 3. The issue arises when there is a 2 or more edge shortest path > between nodes in the base connectivity graph, but that path does not > contain a parent common to the nodes in the induced DAG rooted at > some node (LBR or other) that RPL would produce. *Significant* > differences in the length of the path in the two cases, would really > only arise when the base graph is very sparsely connected *and* of > large diameter. I would suspect, certainly in the home, and in most > cases in commercial buildings that the graphs are not like that. I > am tempted to go out on a limb and leave out the "suspect" - it > might be interesting to analyze a decent dataset of random graphs or > actual connectivity graphs in the application scenarios if someone > can produce them (oops...did I just volunteer for something ?) > I think so .... and thanks ;-) You are perfectly correct in your analysis and we will need to do this analysis indeed to find out how much must be added/changed to address these cases. I also think that clarifications must be provided to make sure that there is no understanding. The DT did an outstanding job but I also understand that some part of the ID may lead to confusion, that must be clarified. > 4. If an application is interested in mutliple P2MP/MP2P rather than > total P2P, RPL can take us there as well. > Correct. > 5. The DAG (or tree) formation out of the original graph is intended > to simplify the routing problem and minimize state information. I > would submit that the spectrum of things one can do, in order of > increasing state and complexity would be: > a. Induce a tree and route along it ----- suited for P2MP/MP2P > b. Induce a DAG and route along it ----- same with more redundancy > c. Induce multiple DAGs ----- multi - P2MP/MP2P > d. Route along base graph ----- complete P2P > > RPL sits at b & c and occupies the solid middle ground. > > 5. If d is the desire, a couple of points to note (this one and #6 > below). First, I think in that case there is a not a whole lot to do > other than make every node maintain and disseminate routing state > for every other node. Yes, this is no "free lunch". > Sure, we can play some tricks and prune some nodes that don't > participate in the interesting paths, but all this will come with a > price - and when it is paid the price will be steep - because > intelligent decisions here will require global information and not > local information. And it may change with time. Next thing we know, > that one node that pruned itself out of the picture with regard to a > certain flow, is the *the* guy for an optimal path five years later > for a newly installed node and the alternative is vastly longer. > Everyone can *see* there is a 2-hop path and wonder why it takes 5 > hops. The point is, without knowledge of whole topology these local > decisions can cause major trouble and defeat the original intent, > which was optimal P2P. I would suggest that the best and only thing > to do if we want to do d) is to go all the way and make sure the > network can deal with the large state information. > Right, furthermore, there might be ways to optimize some flows between specific pairs of nodes, with specific constraints, for example using different DAGs. To be discussed ... > 6. I can fully understand Jerry's "diatribe", as he called it in a > recent post. Rest assured Jerry, I, and I am sure many of us, have > had occasion to say similar things. But I think it illustrates a > point. If our radios were to do the equivalent of what the wire did > for us, i.e., make every node reach every other node and create a > complete graph, from a routing perspective RPL would be absolutely > no worse than any P2P. If the radio did only somewhat worse in > providing connectivity, RPL may correspondingly also do slightly > worse. But. It would do vastly better for a several thousand node > network spread over a city. > > 7. And that I think summarizes the argument for moving forward with > RPL - not for stopping where it stands, just moving forward with it > is a basis. It is not going to be everything for everyone, but I > think it is going be a very large something for almost everyone, > including home/bldg. control. > Thanks for the detailed feed-back. JP. > Best regards, > Anand. > > > > On Thu, Jul 30, 2009 at 5:48 PM, M. B. Anand > wrote: > > > -------- Original Message -------- > Subject: [Roll] Moving forward with the protocol work > Date: Tue, 28 Jul 2009 18:34:24 +0200 > From: JP Vasseur > To: ROLL WG > > > > Dear WG, > > First of all, thanks for all the time and energy you all have > devoted during the past few weeks on the protocol work. There was > excellent followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate > foundation for the ROLL routing protocol work", there was clearly a > good consensus in the WG meeting. It was also recognized there are > still several open issues for which we WILL need help from many WG > contributors, including the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll- > rpl-01 as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-36-168043883 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Anand,

On = Jul 31, 2009, at 1:00 AM, M Anand wrote:

I would support adoption = of draft-dt-roll-rpl-01  as a WG document based on the reasoning = below.

The = one area of (I think quite valid) concern appears to be optimal P2P = routing or lack thereof. I would make the following points with regard = to this:

1. I think first there seems to be some = misinterpretation because I see references to nodes within direct = physical range, light switch/light etc. in the discussion.
RPL as it stands would let a node in direct = contact with another route directly to that node. No need to go up and = down a DAG. I think this was in one of the examples in the slide = presentation in the mtg. and, if I recall correctly, someone explcitly = asked this question.


This is perfectly = correct,

2. So, we are not talking about P2P route sub-optimality = in RPL when there is a one-hop route. And I sure would hope that a light = switch would be in direct physical range of its light. We can leave = aside these cases when debating the possible P2P demerits of the present = RPL.

3. The issue arises when there is a 2 or more = edge shortest path between nodes in the base connectivity graph, but = that path does not contain a parent common to the nodes in the induced = DAG rooted at some node (LBR or other) that RPL would produce. = *Significant* differences in the length of the path in the two cases, = would really only arise when the base graph is very sparsely connected = *and* of large diameter. I would suspect, certainly in the home, and in = most cases in commercial buildings that the graphs are not like that. I = am tempted to go out on a limb and leave out the "suspect" - it might be = interesting to analyze a decent dataset of random graphs or actual = connectivity graphs in the application scenarios if someone can produce = them (oops...did I just volunteer for something ?)
=

I think so .... and = thanks ;-) You are perfectly correct in your analysis and we will need = to do this analysis indeed to find out how much must be added/changed to = address these cases. I also think that clarifications must be provided = to make sure that there is no understanding. The DT did an outstanding = job but I also understand that some part of the ID may lead to = confusion, that must be clarified.

4. If an = application is interested in mutliple P2MP/MP2P rather than total P2P, = RPL can take us there as well.


Correct.

<= blockquote type=3D"cite">
5. The DAG (or tree) = formation out of the original graph is intended to simplify the routing = problem and minimize state information. I would submit that the spectrum = of things one can do, in order of increasing state and complexity would = be:
a. Induce a tree and route = along it  ----- suited for P2MP/MP2P
b. Induce a DAG and route along it   ----- = same with more redundancy
c. Induce multiple DAGs     =          ----- multi - P2MP/MP2P
d. Route = along base graph            ----- complete = P2P

RPL sits at b & c and occupies the solid middle = ground.

5. If d is the desire, a couple of points to note (this = one and #6 below). First, I think in that case there is a not a whole = lot to do other than make every node maintain and disseminate routing = state for every other = node.

Yes, this is no = "free lunch".

Sure, we can play some tricks and prune some nodes = that don't participate in the interesting paths, but all this will come = with a price - and when it is paid the price will be steep - because = intelligent decisions here will require global information and not local = information. And it may change with time. Next thing we know, that one = node that pruned itself out of the picture with regard to a certain = flow, is the *the* guy for an optimal path five years later for a newly = installed node and the alternative is vastly longer. Everyone can *see* = there is a 2-hop path and wonder why it takes 5 hops. The point is, = without knowledge of whole topology these local decisions can cause = major trouble and defeat the original intent, which was optimal P2P. I = would suggest that the best and only thing to do if we want to do d) is = to go all the way and make sure the network can deal with the large = state information.
=

Right, furthermore, = there might be ways to optimize some flows between specific pairs of = nodes, with specific constraints, for example using different DAGs. To = be discussed ... 

6. I can fully understand Jerry's "diatribe", as he = called it in a recent post. Rest assured Jerry, I, and I am sure many of = us, have had occasion to say similar things. But I think it illustrates = a point. If our radios were to do the equivalent of what the wire did = for us, i.e., make every node reach every other node and create a = complete graph, from a routing perspective RPL would be absolutely no = worse than any P2P. If the radio did only somewhat worse in providing = connectivity, RPL may correspondingly also do slightly worse. But. It = would do vastly better for a several thousand node network spread over a = city.

7. And that I think summarizes the argument for moving = forward with RPL - not for stopping where it stands, just moving forward = with it is a basis. It is not going to be everything for everyone, but I = think it is going be a very large something for almost everyone, = including home/bldg. control.
=

Thanks for the = detailed feed-back.

JP.

Best regards,
Anand.



On Thu, Jul 30, 2009 at 5:48 = PM, M. B. Anand <anand@ekasystems.com> wrote:
=


= -------- Original Message --------
Subject:       =  [Roll] Moving forward with the protocol work
Date:   Tue, = 28 Jul 2009 18:34:24 +0200
From:   JP Vasseur <jvasseur@cisco.com>
To:     ROLL = WG <roll@ietf.org>



Dear WG,
=
First of all, thanks for all the time and energy you all have = devoted  during the past few weeks on the protocol work. There was = excellent  followup discussion at the physical WG meeting.

= To the question "Do you think that RPL provides an adequate foundation =  for the ROLL routing protocol work", there was clearly a good =  consensus in the WG meeting. It was also recognized there are = still  several open issues for which we WILL need help from many WG =  contributors, including the authors of other documents.

= Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 =  as a WG document ?

Then we will of course move to the = next step.

Thanks,

JP and David


= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=



= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-36-168043883-- From jhui@archrock.com Fri Jul 31 10:24:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86C73A6D72; Fri, 31 Jul 2009 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 BYck7BTxw3z2; Fri, 31 Jul 2009 10:24:37 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5892C3A6B7D; Fri, 31 Jul 2009 10:23:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 39751AF905; Fri, 31 Jul 2009 10:23: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 3mTN2Hw5qjyl; Fri, 31 Jul 2009 10:23:34 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-50.dsl.pltn13.pacbell.net [71.142.86.50]) by mail.sf.archrock.com (Postfix) with ESMTP id 7A91DAF865; Fri, 31 Jul 2009 10:23:33 -0700 (PDT) Message-Id: <271F493C-F591-49D6-B658-841388DAA3F6@archrock.com> From: Jonathan Hui To: d.sturek@att.net In-Reply-To: <003301ca11e0$58aa9040$09ffb0c0$@sturek@att.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 10:23:32 -0700 References: <001101ca11d8$102811b0$30783510$@sturek@att.net> <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> <003301ca11e0$58aa9040$09ffb0c0$@sturek@att.net> X-Mailer: Apple Mail (2.935.3) Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: [Roll] Why a DAG? (was Re: Moving forward with the protocol work) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:24:38 -0000 Don correctly highlights and important reasons for the DAG that I want =20= to expand a bit more. A DAG is necessary in resource constrained environments. Using a DAG =20 allows us the LLN to provide basic P2P connectivity while maintaining =20= hard bounds on the amount of memory each LLN node can maintain. It has =20= been mentioned many times that a DAG does not provide an "optimal" P2P =20= solution. If memory is constrained such that each LLN node is only =20 capable of maintaining a few routes at any time, then a DAG does =20 provide an "optimal" P2P solution given the state constraints. This is =20= fundamental and a protocol should allow for operation under such =20 memory constraints. Using a DAG allows us to guide and constrain the communication of =20 routing information as well. It ensures that state maintenance and =20 exchange only occurs on a small subgraph of nodes toward the DAG root =20= - rather than and unstructured "flooding" of the entire DAG with such =20= information. While DAG construction uses broadcast RAs to =20 communication information, establishing routes that flow away from the =20= root need only rely on unicast communication. I'd like to stress the =20 importance of broadcast vs. unicast communication. While both are =20 logically one transmission, the two have very different costs in =20 environments where the radio is duty cycled. Depending on the duty-=20 cycled link protocol, broadcast can by orders of magnitude more =20 expensive in channel utilization, energy consumption, and =20 communication delay. Again, this is fundamental and a protocol should =20= allow for operation under severe channel capacity and energy =20 constraints. These fundamental limits require the use a hierarchical structure - a =20= DAG. A common misconception is that we chose a DAG because of the MP2P =20= and P2MP requirement. The real reason is that a DAG allows for =20 operation under severe resource constraints - not because traffic =20 typically flows through some edge router. A DAG orients the =20 connectivity graph in a way to constrain the routing problem. It's =20 just a nice-to-have if the DAG is rooted at the "edge router" when you =20= do have MP2P and P2MP flows. Of course, we have mentioned that a DAG can be used for avoiding and =20 detecting cycles, but that is not the fundamental reason for using the =20= DAG. The need for attending to loops and the count-to-infinity problem =20= is an important side effect of using the DV class of protocols. Again, people need to be more concrete when saying "optimal", because =20= such a notion is not well defined without clarity in the problem's =20 constraints and goals. What people seem to mean when they say they =20 want more "optimal" mechanisms is really to be able to make use of =20 more resources when they are available. Specifically, if a node can =20 maintain more routes and communicate more routing information, it =20 should be able to reduce overall routing stretch. That I strongly =20 agree with. But the protocol needs to have a baseline to allow operation with =20 severe resource constraints and for that reason, I'd argue that the =20 reliance on a DAG provides that capability. -- Jonathan Hui On Jul 31, 2009, at 6:10 AM, Don Sturek wrote: > Hi Mukul, > > The part of RPL that I liked is the P2MP support (where once a =20 > device is part of a DAG, it need only promote packets upward to =20 > reach a concentrator device denoted as the DAG-root). There seems =20= > to be little requirement for any state information in RPL to get =20 > this feature (quite nice). Also no flooding! > > There is clearly work to be done to get a usable P2P mechanism =20 > running using RPL (and it is definitely needed even for Smart =20 > Metering). It would be good to see if the RPL DAG feature could be =20= > retained and those that want P2P would be provided that capability =20 > (understanding they may be required to store state information in =20 > their devices to use P2P if that is the solution we end up with). > > By the way, most Smart Metering applications are relatively few =20 > devices (25 or so). The problem comes in when supporting Multi-=20 > dwelling units (one of our use cases). There we could have =20 > thousands of devices but with relatively few concentrators (really =20 > seems to map to RPL fairly well!) > > We have been struggling for some time to come up with elegant =20 > routing solutions over ad hoc networks and RPL seems to be the first =20= > one that doesn't fall apart in scenarios like: many to one =20 > (MP2P), many devices in the network (more than a couple hundred), etc. > > Best Regards, > > Don Sturek > > -----Original Message----- > From: Mukul Goyal [mailto:mukul@uwm.edu] > Sent: Friday, July 31, 2009 5:55 AM > To: d sturek > Cc: ROLL WG; roll-bounces@ietf.org; Jerald P Martocci > Subject: Re: [Roll] Moving forward with the protocol work > > Don > > I will get back to the list regarding the scalability and flooding =20 > (BTW, the solution I proposed does not involve flooding, which I =20 > abhore with same vengeance as you) argument you made in favor of RPL =20= > and again the alternate solutions. Also, I will wait for DT solution =20= > for good P2P routing in RPL, but it seems to me that it has to =20 > involve some state maintenance in nodes. > > But, for a moment, lets forget about the alternate solutions. Lets =20 > just focus on RPL. > > All I am saying is that RPL, at present, is too tightly coupled with =20= > DAGs, which is a loop prevention mechanism as I understand it. =20 > Putting a specific loop prevention mechanism, a non-essential =20 > requirement, in the _foundation_ does not sound like a good idea to =20= > me. > > Thanks > Mukul > > ----- Original Message ----- > From: "Don Sturek" > To: "Mukul Goyal" , "Jerald P Martocci" = > > Cc: "ROLL WG" , roll-bounces@ietf.org > Sent: Friday, July 31, 2009 7:11:38 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] Moving forward with the protocol work > > Hi Mukul, > > I don't agree that the alternate solutions proposed for ROLL scale =20 > and could support requirements outside building controls. =20 > Specifically, I believe that the non-DAG solutions will require =20 > state information retention which will limit deployment beyond a =20 > modest number of nodes in the network. > > I believe the opposite as to what is proposed below. I would =20 > propose using the RPL proposal as the baseline and provide some =20 > mechanisms to support optimization of P2P traffic. > > Best Regards, > > Don Sturek > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Mukul Goyal > Sent: Friday, July 31, 2009 4:27 AM > To: Jerald P Martocci > Cc: ROLL WG; roll-bounces@ietf.org > Subject: Re: [Roll] Moving forward with the protocol work > > I absolutely support the approach Jerry suggested: > > 1) The foundation should be as simple as possible - a simple =20 > distance vector approach (I hope there is an agreement on this) =20 > describing next-hop selection based on routing metrics defined in =20 > the routing metrics draft, constraints and strategies (OCP) and =20 > basic rules to decide when to generate RAs. The foundation should =20 > not include any mechanism to deal with loops (so, it should not =20 > include DAGs unless DAGs can be shown to be critical in meeting =20 > other essential requirements). > > 2) Additional document(s) suggesting solutions catered towards MP2P =20= > and/or P2P routing using different mechanisms to deal with loops =20 > (including DAGs). > > Thanks > Mukul > > ----- Original Message ----- > From: "Jerald P Martocci" > To: "Zach Shelby" > Cc: "Mukul Goyal" , "ROLL WG" , = roll-bounces@ietf.org > Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > > > Zach, > > When the design team was formed it stated its plan was to develop a =20= > core routing specification that met the needs of all the requirement =20= > specifications and then ancillary specifications to meet the =20 > specific needs for each of the requirements. RPL as currently =20 > written seems perfectly suitable for the MP2P requirement, yet not =20 > too suitable for P2P requirement. Could we repackage RPL so that =20 > its base spec contains only the generic routing requirements such as =20= > 1) using varied metrics to define path preferences, 2) OCP to =20 > advertise path strategy and 3) trickle to cleanly vary periodic =20 > requirements. Then RPL-1 could be then enhancements for MP2P =20 > applications and would include the DAG. This would allow us to =20 > define a different extension, RPL-2, for P2P requirements that need =20= > not be DAG based. > > JP has promised that if I just shut-up and give the DT some time, =20 > they will provide a solid P2P solution. I am willing to do that. =20 > However, I would hate to start compromising the MP2P solution to =20 > wedge in a sub-optimal P2P solution. Maybe we can have our cake and =20= > eat it too if we simply repackage the specs a bit. > > Jerry > > > > > Zach Shelby > Sent by: roll-bounces@ietf.org > > 07/30/2009 10:02 AM =09 > To Mukul Goyal > > cc ROLL WG > > Subject Re: [Roll] Moving forward with the protocol work > =09 > > > > Hi, > > Mukul Goyal wrote: >> Mischa, >> >>> We should use this early design stage to come up with one solution =20= >>> - one >> solution which is not necessarily optimum for all cases but for the >> (e.g.) 95% quantile. The PHY guys learned to live with such an =20 >> approach. >> The MAC folks are getting there and we should take our chance now. =20= >> 95% >> means clearly to concentrate on the core issues, of which loop >> detection/avoidance, p2p and security are somehow still open. >> >> When you say a solution, it seems that you want one particular =20 >> protocol. I am OK with RPL as a protocol even though it has =20 >> deficiencies (such as > P2P routing). But, the implication of giving it the WG status seems to > be that RPL would be the _framework_ on which all future ROLL work =20 > would > be based. I am not in support of the use of RPL as a framework =20 > unless it > eliminates its current tight coupling with DAGs (a, rather heavy duty, > loop prevention mechanism). > > The goal of the WG from my understanding, is to produce *one* protocol > in the current charter. RPL is definitely suitable as a starting point > for that protocol (JP said foundation, not framework). I completely > support this approach. > > =46rom the industry point of view we need a single solution, which > fulfills application requirements sufficiently and thus can be widely > deployed commercially. > > Regarding loop prevention, so what if RPL does a better job than is > necessary? Does it break some requirement doing that? If so, we should > fix it. There are other reasons for using DAGs than just loop =20 > prevention. > > Zach > > --=20 > http://www.sensinode.com > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Fri Jul 31 10:25:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12823A6D72 for ; Fri, 31 Jul 2009 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 duU6lCMB7jxN for ; Fri, 31 Jul 2009 10:25:51 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 1B08C3A6CDE for ; Fri, 31 Jul 2009 10:25:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5C1A3AF91E; Fri, 31 Jul 2009 10:25: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 U-CKvxgnxKwa; Fri, 31 Jul 2009 10:25:49 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-86-50.dsl.pltn13.pacbell.net [71.142.86.50]) by mail.sf.archrock.com (Postfix) with ESMTP id 0CED3AF865; Fri, 31 Jul 2009 10:25:48 -0700 (PDT) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@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 v935.3) Date: Fri, 31 Jul 2009 10:25:48 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC07DC2944@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:25:51 -0000 +1. The working group needs something to work with if we want to make forward progress... -- Jonathan Hui On Jul 29, 2009, at 6:37 AM, Pascal Thubert (pthubert) wrote: > +1. > > There are certainly a number of issues on this draft, but they only > can > be solved properly by the WG if the doc belongs to the WG in the first > place. > > I've sensed a degree of frustration from people outside the design > team > and it's time to open the door for comments and improvements > originated > from the WG. > > It's also time to use the formal process to track issues and get WG > consensus on how to deal with them. So I think it's fair to transfer > ownership to the WG and apply the appropriate processes to fix what > need > fixing, add what must be added etc... > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > JP Vasseur (jvasseur) >> Sent: mardi 28 juillet 2009 18:34 >> To: ROLL WG >> Subject: [Roll] Moving forward with the protocol work >> >> Dear WG, >> >> First of all, thanks for all the time and energy you all have devoted >> during the past few weeks on the protocol work. There was excellent >> followup discussion at the physical WG meeting. >> >> To the question "Do you think that RPL provides an adequate >> foundation >> for the ROLL routing protocol work", there was clearly a good >> consensus in the WG meeting. It was also recognized there are still >> several open issues for which we WILL need help from many WG >> contributors, including the authors of other documents. >> >> Could you please confirm (or not) the adoption of draft-dt-roll- >> rpl-01 >> as a WG document ? >> >> Then we will of course move to the next step. >> >> Thanks, >> >> JP and David >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Pete.Stpierre@sun.com Fri Jul 31 12:12:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B463A6974 for ; Fri, 31 Jul 2009 12:12:08 -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 Of4fxpyiiDAg for ; Fri, 31 Jul 2009 12:12:07 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 53FF83A67B7 for ; Fri, 31 Jul 2009 12:12:07 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNN00EJCUNVQA10@mail-mta.sfvic.sunlabs.com> for roll@ietf.org; Fri, 31 Jul 2009 12:11:55 -0700 (PDT) Received: from dhcp-umpk16-79-236.SFBay.Sun.COM (sca-ea-fw-1.Sun.COM [192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNN00IPBUNU4SD2@mail.sunlabs.com> for roll@ietf.org; Fri, 31 Jul 2009 12:11:55 -0700 (PDT) Date: Fri, 31 Jul 2009 12:11:54 -0700 From: "Pete St. Pierre" In-reply-to: <4A7216D2.8040304@sensinode.com> To: ROLL WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.935.3) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable References: <4A7216D2.8040304@sensinode.com> Subject: Re: [Roll] Moving forward with the protocol work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:12:08 -0000 ROLL-ers - I'd also like to throw my support behind accepting the RPL draft as a =20= WG document. It is very clearly an -01 draft and has areas that have =20= been acknowledged by the DT and many on this list as needing work. The fact that there has already been a wealth of discussion within =20 this list of how to address these deficiencies gives me the feeling =20 there is pretty wide felt support for the basic design represented =20 within the draft. When the DT was formed, there was some concern expressed on the list =20 that a small group was being "sub-chartered" to go work on the =20 problem. Now that the individual submission document has been =20 completed by this "tiger team", we've had the opportunity to review =20 the work as a group. Thanks to Pascal and Jonathan for the =20 presentation this week at the WG meeting. Now that the initial DT has completed a first pass, I think the time =20 is right to close up work on the DT mailing list and move forward as a =20= group, continuing the discussions on this list, with appropriate =20 subject lines as JP has suggested/requested. I also don't believe that this closes the door on a second protocol =20 that may be weighted toward addressing the P2P scenario more =20 efficiently. However, think we need to fully explore 1 solution =20 before we become fractured and run off in too many different directions. Clearly it's the responsibility of JP and David as co-chairs to decide =20= where the consensus lies, but I look forward to work moving forward =20 quickly on at least one solution to address the routing needs required =20= by this unique class of applications. Just my $.02 (or very small fraction of a Kroner) ...Pete On Jul 30, 2009, at 2:55 PM, Zach Shelby wrote: > Jerry, > > Jerald.P.Martocci@jci.com wrote: >> Zach, >> When the design team was formed it stated its plan was to develop a =20= >> core routing specification that met the needs of all the =20 >> requirement specifications and then ancillary specifications to =20 >> meet the specific needs for each of the requirements. RPL as =20 >> currently written seems perfectly suitable for the MP2P =20 >> requirement, yet not too suitable for P2P requirement. Could we =20 >> repackage RPL so that its base spec contains only the generic =20 >> routing requirements such as 1) using varied metrics to define path =20= >> preferences, 2) OCP to advertise path strategy and 3) trickle to =20 >> cleanly vary periodic requirements. Then RPL-1 could be then =20 >> enhancements for MP2P applications and would include the DAG. This =20= >> would allow us to define a different extension, RPL-2, for P2P =20 >> requirements that need not be DAG based. > > We all agree that RPL currently only contains basic P2P support =20 > using the DV state built up on the DAG. I also agree with you that =20 > the wording on keeping DV state in routers (within memory =20 > constraints) should be fixed (easy). There is definitely consensus =20 > that the next version needs a solid P2P mechanism. There is no =20 > reason that an additional P2P feature would be suboptimal with the =20 > DAG - I see them as being complimentary. > >> JP has promised that if I just shut-up and give the DT some time, =20 >> they will provide a solid P2P solution. I am willing to do that. =20= >> However, I would hate to start compromising the MP2P solution to =20 >> wedge in a sub-optimal P2P solution. Maybe we can have our cake =20 >> and eat it too if we simply repackage the specs a bit. > > This is just -01 of this draft, so JP is right ;-) The DT was clear =20= > this is an early draft and that P2P is coming. So... on the P2P =20 > front, it would be great to see contributions to the WG on how to =20 > include suitable P2P support to RPL. The thing about a WG document - =20= > is that we work together on it. > > Zach > >> Jerry >> *Zach Shelby * >> Sent by: roll-bounces@ietf.org >> 07/30/2009 10:02 AM >> =09 >> To >> Mukul Goyal >> cc >> ROLL WG >> Subject >> Re: [Roll] Moving forward with the protocol work >> =09 >> Hi, >> Mukul Goyal wrote: >> > Mischa, >> > >> >> We should use this early design stage to come up with one =20 >> solution - one >> > solution which is not necessarily optimum for all cases but for the >> > (e.g.) 95% quantile. The PHY guys learned to live with such an =20 >> approach. >> > The MAC folks are getting there and we should take our chance =20 >> now. 95% >> > means clearly to concentrate on the core issues, of which loop >> > detection/avoidance, p2p and security are somehow still open. >> > >> > When you say a solution, it seems that you want one particular =20 >> protocol. I am OK with RPL as a protocol even though it has =20 >> deficiencies (such as >> P2P routing). But, the implication of giving it the WG status seems =20= >> to >> be that RPL would be the _framework_ on which all future ROLL work =20= >> would >> be based. I am not in support of the use of RPL as a framework =20 >> unless it >> eliminates its current tight coupling with DAGs (a, rather heavy =20 >> duty, >> loop prevention mechanism). >> The goal of the WG from my understanding, is to produce *one* =20 >> protocol >> in the current charter. RPL is definitely suitable as a starting =20 >> point >> for that protocol (JP said foundation, not framework). I completely >> support this approach. >> =46rom the industry point of view we need a single solution, which >> fulfills application requirements sufficiently and thus can be widely >> deployed commercially. >> Regarding loop prevention, so what if RPL does a better job than is >> necessary? Does it break some requirement doing that? If so, we =20 >> should >> fix it. There are other reasons for using DAGs than just loop =20 >> prevention. >> Zach >> --=20 >> http://www.sensinode.com >> 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 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > --=20 > http://www.sensinode.com > 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. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mikko.saarnivala@sensinode.com Fri Jul 31 14:19:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6543A6CCD for ; Fri, 31 Jul 2009 14:19:36 -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 RLptopKwx1gp for ; Fri, 31 Jul 2009 14:19:35 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp-68.nebula.fi [83.145.220.68]) by core3.amsl.com (Postfix) with ESMTP id A574F3A6DBD for ; Fri, 31 Jul 2009 14:18:59 -0700 (PDT) Received: from webmail2.nebula.fi (webmail2.nebula.fi [217.30.180.73]) by smtp-68.nebula.fi (Postfix) with ESMTP id B6CAC43F0750 for ; Sat, 1 Aug 2009 00:19:00 +0300 (EEST) Received: from 87.93.0.129 (SquirrelMail authenticated user sensinodecom4) by webmail2.nebula.fi with HTTP; Sat, 1 Aug 2009 00:19:00 +0300 (EEST) Message-ID: <35544.87.93.0.129.1249075140.squirrel@webmail2.nebula.fi> Date: Sat, 1 Aug 2009 00:19:00 +0300 (EEST) From: "Mikko Saarnivala" To: roll@ietf.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal References: In-Reply-To: Subject: [Roll] Supporting RPL as WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 21:19:36 -0000 Rollers, As the subject line already reveals, I'm in favour of accepting the RPL as an official WG document as I feel that it is the most promising one of the individual submissions. I'm certain that the WG can work out a very good solution for the P2P routing as well. -- Mikko Saarnivala

The one area of (I thin= k quite valid) concern appears to be optimal P2P routing or lack thereof. I= would make the following points with regard to this:

1. I think first there seems to be some misinter= pretation because I see references to nodes within direct physical range, l= ight switch/light etc. in the discussion.
RPL as it stands would = let a node in direct contact with another route directly to that node. No n= eed to go up and down a DAG. I think this was in one of the examples in the= slide presentation in the mtg. and, if I recall correctly, someone explcit= ly asked this question.

2. So, we are not talking about P2P route sub-op= timality in RPL when there is a one-hop route. And I sure would hope that a= light switch would be in direct physical range of its light. We can leave = aside these cases when debating the possible P2P demerits of the present RP= L.

3. The issue arises when there is a 2 or more ed= ge shortest path between nodes in the base connectivity graph, but that pat= h does not contain a parent common to the nodes in the induced DAG rooted a= t some node (LBR or other) that RPL would produce. *Significant* difference= s in the length of the path in the two cases, would really only arise when = the base graph is very sparsely connected *and* of large diameter. I would = suspect, certainly in the home, and in most cases in commercial buildings t= hat the graphs are not like that. I am tempted to go out on a limb and leav= e out the "suspect" - it might be interesting to analyze a decent= dataset of random graphs or actual connectivity graphs in the application = scenarios if someone can produce them (oops...did I just volunteer for some= thing ?)

4. If an application is interested in mutliple P2MP/MP2P rather than to= tal P2P, RPL can take us there as well.

5. The DAG (or tree) format= ion out of the original graph is intended to simplify the routing problem a= nd minimize state information. I would submit that the spectrum of things o= ne can do, in order of increasing state and complexity would be:
a. Induce a tree and ro= ute along it=A0 ----- suited for P2MP/MP2P
b. Induce a DAG and route along it=A0=A0 ----- same with more redundancy c. Induce multiple DAGs =A0 =A0 =A0 =A0 =A0 =A0=A0 ----- multi - P2MP/MP2P<= br>d. Route along base graph =A0 =A0 =A0 =A0 =A0=A0 ----- complete P2P
<= br>RPL sits at b & c and occupies the solid middle ground.

5. If= d is the desire, a couple of points to note (this one and #6 below). First= , I think in that case there is a not a whole lot to do other than make eve= ry node maintain and disseminate routing state for every other node.
Sure, we can play some tricks an= d prune some nodes that don't participate in the interesting paths, but= all this will come with a price - and when it is paid the price will be st= eep - because intelligent decisions here will require global information an= d not local information. And it may change with time. Next thing we know, t= hat one node that pruned itself out of the picture with regard to a certain= flow, is the *the* guy for an optimal path five years later for a newly in= stalled node and the alternative is vastly longer. Everyone can *see* there= is a 2-hop path and wonder why it takes 5 hops. The point is, without know= ledge of whole topology these local decisions can cause major trouble and d= efeat the original intent, which was optimal P2P. I would suggest that the = best and only thing to do if we want to do d) is to go all the way and make= sure the network can deal with the large state information.

6. I can fully understand Jerry's "diatribe", as he calle= d it in a recent post. Rest assured Jerry, I, and I am sure many of us, hav= e had occasion to say similar things. But I think it illustrates a point. I= f our radios were to do the equivalent of what the wire did for us, i.e., m= ake every node reach every other node and create a complete graph, from a r= outing perspective RPL would be absolutely no worse than any P2P. If the ra= dio did only somewhat worse in providing connectivity, RPL may correspondin= gly also do slightly worse. But. It would do vastly better for a several th= ousand node network spread over a city.

7. And that I think summarizes the argument for moving forward with RPL= - not for stopping where it stands, just moving forward with it is a basis= . It is not going to be everything for everyone, but I think it is going be= a very large something for almost everyone, including home/bldg. control.<= br>
Best regards,
Anand.



On Thu, = Jul 30, 2009 at 5:48 PM, M. B. Anand <anand@ekasystems.com> wrote:


-------- Original Message --------
Subject: =A0 =A0 =A0 =A0[Roll] Moving forward with the protocol work
Date: =A0 Tue, 28 Jul 2009 18:34:24 +0200
From: =A0 JP Vasseur <jvasseur@cisco.com>
To: =A0 =A0 ROLL WG <= roll@ietf.org>



Dear WG,

First of all, thanks for all the time and energy you all have devoted =A0du= ring the past few weeks on the protocol work. There was excellent =A0follow= up discussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation= =A0for the ROLL routing protocol work", there was clearly a good =A0c= onsensus in the WG meeting. It was also recognized there are still =A0sever= al open issues for which we WILL need help from many WG =A0contributors, in= cluding the authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 =A0a= s a WG document ?

Then we will of course move to the next step.

Thanks,

JP and David


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll