From pthubert@cisco.com Sat Aug 1 00:50: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 0D5A43A680D; Sat, 1 Aug 2009 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 uWfhb8inCaOW; Sat, 1 Aug 2009 00:50: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 AFD923A67EC; Sat, 1 Aug 2009 00:50:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAAMKQc0qQ/uCKe2dsb2JhbACVaYMMgSkBARYkBp41iCmQLQWEGIl4 X-IronPort-AV: E=Sophos;i="4.43,306,1246838400"; d="scan'208";a="46250308" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2009 07:50: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 n717oTdS021765; Sat, 1 Aug 2009 09:50:29 +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 n717oTvG022047; Sat, 1 Aug 2009 07:50:29 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); Sat, 1 Aug 2009 09:50:29 +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: Sat, 1 Aug 2009 09:50:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E2044E@xmb-ams-337.emea.cisco.com> In-Reply-To: <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: good vs perfect and best and the rest. was: RE: [Roll] Moving forward with the protocol work Thread-Index: AcoR392y1TuUSyinR4Oo3bGblucAQwAmSQnw References: <791602312.6714891249045509175.JavaMail.root@mail02.pantherlink.uwm.edu> <587296011.6715541249045634668.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 01 Aug 2009 07:50:29.0240 (UTC) FILETIME=[BD2A6F80:01CA127C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11622; t=1249113029; x=1249977029; 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:=20good=20vs=20perfect=20and=20best=20and=20the=20 rest.=20was=3A=20RE=3A=20[Roll]=20Moving=20forward=20with=20 the=20protocol=20work |Sender:=20; bh=XZvIsUayI34x80pltB3OF6eo+6Rh3AzLSXiD6y70Chk=; b=KIW08xbXvEVYoEEpkxYtm0xb+nRkeElCrYmtJ3fknDGAQZhsgJaBri8QDW RRN0Hon/+TXA9zqisvSAImcDIhAc2izIy5uBo5BvSTTVuxmrsmol2AzRMiT/ 3+LXZf5jG3; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , roll-bounces@ietf.org Subject: [Roll] good vs perfect and best and the rest. 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: Sat, 01 Aug 2009 07:50:31 -0000 SGkgTXVrdWw6DQoNCkFGQUlLLCBSUEwgYWxyZWFkeSBoYXMgYSBnb29kIHNvbHV0aW9uIGZvciBQ MlAuDQoNClJQTCB3YXMgZGVzaWduZWQgdG8gZW5hYmxlIHRyYWRlb2ZmcyB3aGVyZSBub2RlcyBr ZWVwIGEgbG90IGxlc3Mgc3RhdGVzIHRoYW4gaW4gb3RoZXIgd2VsbC1rbm93biBzaXR1YXRpb25z LCBhbmQgd2hlcmUgdGhlIGNvbmNlcHQgb2YgdG9wb2xvZ3kgaXMgYSBsb3QgbW9yZSBmdXp6eSB0 aGFuIHVzdWFsLiBVbnN1cnByaXNpbmdseSwgUlBMIHByaW1hcmlseSBhZGRyZXNzZXMgdGhlIG1v c3QgdXN1YWwgZmxvd3MsIHN0YXlzIHdpdGhpbiBvdXIgdW51c3VhbGx5IHRpZ2h0IGNvbnN0cmFp bnRzIChzdGF0ZXMsIGNvbnRyb2wgb3ZlcmhlYWQpIGFuZCB5ZXQgZW5hYmxlcyBQMlAgcmVhY2hh YmlsaXR5IGZvciBtb3N0IG5vZGVzLCBtb3N0IG9mIHRoZSB0aW1lLg0KDQpUaGlzIGlzIHF1aXRl IGEgYml0IGluIGEgZG9tYWluIHdoZXJlIHdvcmRzIGxpa2UgJ2xpbmsnIGFuZCAnY29udmVyZ2Vu Y2UnIGFyZSBtb3N0bHkgbm9uc2Vuc2ljYWwgYW5kIG9ubHkgdXNlZCBpbiBhIHdpZGVseSBzdHJl dGNoZWQgYWNjZXB0YXRpb24gdG8gZW5hYmxlIGRpc2N1c3Npb25zLiBJdCBtaWdodCBub3QgYmUg Z29vZCBlbm91Z2ggZm9yIGFsbCBpbiBhbGwgY2FzZXMuIFRoaXMgaGFzIHRvIGJlIHF1YW50aWZp ZWQgdGhvdWdoLCB0byBtYWtlIHN1cmUgd2UgbWFrZSBmb3J3YXJkIHByb2dyZXNzIHdpdGhpbiBv dXIgY29uc3RyYWludHMuDQoNClJQTCBoYXMgdGhlIG1lcml0IHRvIGV4aXN0cyBhbmQgZml0IGEg bGFyZ2UgbnVtYmVyIG9mIHdlbGwgdW5kZXJzdG9vZCByZXF1aXJlbWVudHMuIEZyb20gdGhlIHN0 YXJ0aW5nIHBvaW50IHRoYXQgdGhlIGRyYWZ0IGlzIHByb3Bvc2luZywgd2UgY2FuIGVsYWJvcmF0 ZSBpbXByb3ZlbWVudHMsIGFuZCwgYmFzZWQgb24gYSBwcm92ZW4gY29zdC92YWx1ZSByYXRpbyBk ZWNpZGUgdG8gbWFrZSB0aGVtIG9wdGlvbmFsIG9yIG1hbmRhdG9yeS4gVGhlcmUgYXJlIGEgbnVt YmVyIG9mIHRoZW0gb24gdGhlIHRhYmxlLCBJJ20gbm90IHRvbyBjb25jZXJuZWQgYWJvdXQgdGhh dC4NCg0KUGFzY2FsDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IE11a3Vs IEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0NCj5TZW50OiB2ZW5kcmVkaSAzMSBqdWlsbGV0 IDIwMDkgMTU6MDcNCj5UbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPkNjOiBST0xMIFdH OyByb2xsLWJvdW5jZXNAaWV0Zi5vcmc7IGQgc3R1cmVrOyBKZXJhbGQgUCBNYXJ0b2NjaQ0KPlN1 YmplY3Q6IFJlOiBbUm9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgcHJvdG9jb2wgd29yaw0K Pg0KPlBhc2NhbA0KPg0KPk9LLiBUaGlzIHB1dHMgYWxsIHRoZSBhcmd1bWVudHMgdG8gcmVzdC4g TWUsIEplcnJ5IGFuZCBKUCAod2hvIGhhcyBiZWVuIGluc2lzdGluZyBhZ2FpbiBhbmQgYWdhaW4g dGhhdCBST0xMDQo+aGFzIHRvIHByb3ZpZGUgZ29vZCBQMlAgc29sdXRpb24pIGhhZCBiZWVuIGxv b2tpbmcgYXQgdGhlIHdyb25nIFdHIGFsbCBhbG9uZy4gV2Ugc2hvdWxkIGdvIGJhbmcgdGhlIE1B TkVUIFdHDQo+ZG9vciBhbmQgYXNrIGZvciBhIGdvb2QgUDJQIHJvdXRpbmcgc29sdXRpb24gZm9y IExMTnMuDQo+DQo+VGhhbmtzDQo+TXVrdWwNCj4NCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+RnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5j b20+DQo+VG86ICJkIHN0dXJlayIgPGQuc3R1cmVrQGF0dC5uZXQ+LCAiTXVrdWwgR295YWwiIDxt dWt1bEB1d20uZWR1PiwgIkplcmFsZCBQIE1hcnRvY2NpIg0KPjxKZXJhbGQuUC5NYXJ0b2NjaUBq Y2kuY29tPg0KPkNjOiAiUk9MTCBXRyIgPHJvbGxAaWV0Zi5vcmc+LCByb2xsLWJvdW5jZXNAaWV0 Zi5vcmcNCj5TZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMDkgNzoyNjowNCBBTSBHTVQgLTA2OjAw IFVTL0NhbmFkYSBDZW50cmFsDQo+U3ViamVjdDogUkU6IFtSb2xsXSBNb3ZpbmcgZm9yd2FyZCB3 aXRoIHRoZSBwcm90b2NvbCB3b3JrDQo+DQo+SGkgRG9uOg0KPg0KPkknbSBhbGwgd2l0aCB5b3Ug aGVyZS4gT3B0aW1pemVkIFAyUCBmb3IgYWxsIGNvbWVzIGF0IGEgY29zdCwgaW4gcGFydGljdWxh ciBpbiB0ZXJtcyBvZiBzdGF0ZXMgaW4gdGhlIG5vZGVzLA0KPmFuZCBpcyBjbGVhcmx5IGEgc2Vj b25kYXJ5IHByaW9yaXR5IGZvciBST0xMLiBPVE9ILCBpbiBhIHVzZSBjYXNlIHdoZXJlIGFsbCBu b2RlcyBjYW4gcmVhbGx5IGFmZm9yZCBhbGwgdGhlDQo+c3RhdGVzIGludm9sdmVkLCB0aGUgcHJv YmxlbSBzZWVtcyB0byBkcmlmdCBvdXRzaWRlIHRoZSBST0xMIGNoYXJ0ZXIgYW5kIGJhY2sgaW4g dGhlIE1BTkVUIHdvcmxkLg0KPg0KPlJPTEwgZG9lcyBub3QgY29tcGV0ZSB3aXRoIE1BTkVUIGFu ZCBkZWZlcnMgdG8gdGhlIE1BTkVUIHdvcmsgd2hlcmUgaXQgYXBwbGllcy4NCj4NCj5QYXNjYWwN Cj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogcm9sbC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRG9uIFN0 dXJlaw0KPj5TZW50OiB2ZW5kcmVkaSAzMSBqdWlsbGV0IDIwMDkgMTQ6MTINCj4+VG86ICdNdWt1 bCBHb3lhbCc7ICdKZXJhbGQgUCBNYXJ0b2NjaScNCj4+Q2M6ICdST0xMIFdHJzsgcm9sbC1ib3Vu Y2VzQGlldGYub3JnDQo+PlN1YmplY3Q6IFJlOiBbUm9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0 aGUgcHJvdG9jb2wgd29yaw0KPj4NCj4+SGkgTXVrdWwsDQo+Pg0KPj5JIGRvbid0IGFncmVlIHRo YXQgdGhlIGFsdGVybmF0ZSBzb2x1dGlvbnMgcHJvcG9zZWQgZm9yIFJPTEwgc2NhbGUgYW5kIGNv dWxkIHN1cHBvcnQgcmVxdWlyZW1lbnRzIG91dHNpZGUNCj4+YnVpbGRpbmcgY29udHJvbHMuICBT cGVjaWZpY2FsbHksIEkgYmVsaWV2ZSB0aGF0IHRoZSBub24tREFHIHNvbHV0aW9ucyB3aWxsIHJl cXVpcmUgc3RhdGUgaW5mb3JtYXRpb24NCj4+cmV0ZW50aW9uIHdoaWNoIHdpbGwgbGltaXQgZGVw bG95bWVudCBiZXlvbmQgYSBtb2Rlc3QgbnVtYmVyIG9mIG5vZGVzIGluIHRoZSBuZXR3b3JrLg0K Pj4NCj4+SSBiZWxpZXZlIHRoZSBvcHBvc2l0ZSBhcyB0byB3aGF0IGlzIHByb3Bvc2VkIGJlbG93 LiAgSSB3b3VsZCBwcm9wb3NlIHVzaW5nIHRoZSBSUEwgcHJvcG9zYWwgYXMgdGhlIGJhc2VsaW5l DQo+PmFuZCBwcm92aWRlIHNvbWUgbWVjaGFuaXNtcyB0byBzdXBwb3J0IG9wdGltaXphdGlvbiBv ZiBQMlAgdHJhZmZpYy4NCj4+DQo+PkJlc3QgUmVnYXJkcywNCj4+DQo+PkRvbiBTdHVyZWsNCj4+ DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiByb2xsLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdWt1 bCBHb3lhbA0KPj5TZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMDkgNDoyNyBBTQ0KPj5UbzogSmVy YWxkIFAgTWFydG9jY2kNCj4+Q2M6IFJPTEwgV0c7IHJvbGwtYm91bmNlc0BpZXRmLm9yZw0KPj5T dWJqZWN0OiBSZTogW1JvbGxdIE1vdmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcmsN Cj4+DQo+PkkgYWJzb2x1dGVseSBzdXBwb3J0IHRoZSBhcHByb2FjaCBKZXJyeSBzdWdnZXN0ZWQ6 DQo+Pg0KPj4xKSBUaGUgZm91bmRhdGlvbiBzaG91bGQgYmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxl IC0gYSBzaW1wbGUgZGlzdGFuY2UgdmVjdG9yIGFwcHJvYWNoIChJIGhvcGUgdGhlcmUgaXMgYW4N Cj4+YWdyZWVtZW50IG9uIHRoaXMpIGRlc2NyaWJpbmcgbmV4dC1ob3Agc2VsZWN0aW9uIGJhc2Vk IG9uIHJvdXRpbmcgbWV0cmljcyBkZWZpbmVkIGluIHRoZSByb3V0aW5nIG1ldHJpY3MNCj4+ZHJh ZnQsIGNvbnN0cmFpbnRzIGFuZCBzdHJhdGVnaWVzIChPQ1ApIGFuZCBiYXNpYyBydWxlcyB0byBk ZWNpZGUgd2hlbiB0byBnZW5lcmF0ZSBSQXMuIFRoZSBmb3VuZGF0aW9uIHNob3VsZA0KPj5ub3Qg aW5jbHVkZSBhbnkgbWVjaGFuaXNtIHRvIGRlYWwgd2l0aCBsb29wcyAoc28sIGl0IHNob3VsZCBu b3QgaW5jbHVkZSBEQUdzIHVubGVzcyBEQUdzIGNhbiBiZSBzaG93biB0byBiZQ0KPj5jcml0aWNh bCBpbiBtZWV0aW5nIG90aGVyIGVzc2VudGlhbCByZXF1aXJlbWVudHMpLg0KPj4NCj4+MikgQWRk aXRpb25hbCBkb2N1bWVudChzKSBzdWdnZXN0aW5nIHNvbHV0aW9ucyBjYXRlcmVkIHRvd2FyZHMg TVAyUCBhbmQvb3IgUDJQIHJvdXRpbmcgdXNpbmcgZGlmZmVyZW50DQo+Pm1lY2hhbmlzbXMgdG8g ZGVhbCB3aXRoIGxvb3BzIChpbmNsdWRpbmcgREFHcykuDQo+Pg0KPj5UaGFua3MNCj4+TXVrdWwN Cj4+DQo+Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+RnJvbTogIkplcmFsZCBQIE1h cnRvY2NpIiA8SmVyYWxkLlAuTWFydG9jY2lAamNpLmNvbT4NCj4+VG86ICJaYWNoIFNoZWxieSIg PHphY2hAc2Vuc2lub2RlLmNvbT4NCj4+Q2M6ICJNdWt1bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+ LCAiUk9MTCBXRyIgPHJvbGxAaWV0Zi5vcmc+LCByb2xsLWJvdW5jZXNAaWV0Zi5vcmcNCj4+U2Vu dDogVGh1cnNkYXksIEp1bHkgMzAsIDIwMDkgMzo1OTozMCBQTSBHTVQgLTA2OjAwIFVTL0NhbmFk YSBDZW50cmFsDQo+PlN1YmplY3Q6IFJlOiBbUm9sbF0gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUg cHJvdG9jb2wgd29yaw0KPj4NCj4+DQo+Pg0KPj5aYWNoLA0KPj4NCj4+V2hlbiB0aGUgZGVzaWdu IHRlYW0gd2FzIGZvcm1lZCBpdCBzdGF0ZWQgaXRzIHBsYW4gd2FzIHRvIGRldmVsb3AgYSBjb3Jl IHJvdXRpbmcgc3BlY2lmaWNhdGlvbiB0aGF0IG1ldCB0aGUNCj4+bmVlZHMgb2YgYWxsIHRoZSBy ZXF1aXJlbWVudCBzcGVjaWZpY2F0aW9ucyBhbmQgdGhlbiBhbmNpbGxhcnkgc3BlY2lmaWNhdGlv bnMgdG8gbWVldCB0aGUgc3BlY2lmaWMgbmVlZHMgZm9yDQo+PmVhY2ggb2YgdGhlIHJlcXVpcmVt ZW50cy4gIFJQTCBhcyBjdXJyZW50bHkgd3JpdHRlbiBzZWVtcyBwZXJmZWN0bHkgc3VpdGFibGUg Zm9yIHRoZSBNUDJQIHJlcXVpcmVtZW50LCB5ZXQNCj5ub3QNCj4+dG9vIHN1aXRhYmxlIGZvciBQ MlAgcmVxdWlyZW1lbnQuICBDb3VsZCB3ZSByZXBhY2thZ2UgUlBMIHNvIHRoYXQgaXRzIGJhc2Ug c3BlYyBjb250YWlucyBvbmx5IHRoZSBnZW5lcmljDQo+PnJvdXRpbmcgcmVxdWlyZW1lbnRzIHN1 Y2ggYXMgMSkgdXNpbmcgdmFyaWVkIG1ldHJpY3MgdG8gZGVmaW5lIHBhdGggcHJlZmVyZW5jZXMs IDIpIE9DUCB0byBhZHZlcnRpc2UgcGF0aA0KPj5zdHJhdGVneSBhbmQgMykgdHJpY2tsZSB0byBj bGVhbmx5IHZhcnkgcGVyaW9kaWMgcmVxdWlyZW1lbnRzLiAgVGhlbiBSUEwtMSBjb3VsZCBiZSB0 aGVuIGVuaGFuY2VtZW50cyBmb3INCj5NUDJQDQo+PmFwcGxpY2F0aW9ucyBhbmQgd291bGQgaW5j bHVkZSB0aGUgREFHLiAgVGhpcyB3b3VsZCBhbGxvdyB1cyB0byBkZWZpbmUgYSBkaWZmZXJlbnQg ZXh0ZW5zaW9uLCBSUEwtMiwgZm9yIFAyUA0KPj5yZXF1aXJlbWVudHMgdGhhdCBuZWVkIG5vdCBi ZSBEQUcgYmFzZWQuDQo+Pg0KPj5KUCBoYXMgcHJvbWlzZWQgdGhhdCBpZiBJIGp1c3Qgc2h1dC11 cCBhbmQgZ2l2ZSB0aGUgRFQgc29tZSB0aW1lLCB0aGV5IHdpbGwgcHJvdmlkZSBhIHNvbGlkIFAy UCBzb2x1dGlvbi4gIEkNCj4+YW0gd2lsbGluZyB0byBkbyB0aGF0LiAgSG93ZXZlciwgSSB3b3Vs ZCBoYXRlIHRvIHN0YXJ0IGNvbXByb21pc2luZyB0aGUgTVAyUCBzb2x1dGlvbiB0byB3ZWRnZSBp biBhIHN1Yi0NCj4+b3B0aW1hbCBQMlAgc29sdXRpb24uICBNYXliZSB3ZSBjYW4gaGF2ZSBvdXIg Y2FrZSBhbmQgZWF0IGl0IHRvbyBpZiB3ZSBzaW1wbHkgcmVwYWNrYWdlIHRoZSBzcGVjcyBhIGJp dC4NCj4+DQo+PkplcnJ5DQo+Pg0KPj4NCj4+DQo+Pg0KPj5aYWNoIFNoZWxieSA8emFjaEBzZW5z aW5vZGUuY29tPg0KPj5TZW50IGJ5OiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcNCj4+DQo+PjA3LzMw LzIwMDkgMTA6MDIgQU0NCj4+VG8gCU11a3VsIEdveWFsIDxtdWt1bEB1d20uZWR1Pg0KPj4NCj4+ Y2MgCVJPTEwgV0cgPHJvbGxAaWV0Zi5vcmc+DQo+Pg0KPj5TdWJqZWN0IAlSZTogW1JvbGxdIE1v dmluZyBmb3J3YXJkIHdpdGggdGhlIHByb3RvY29sIHdvcmsNCj4+DQo+Pg0KPj4NCj4+DQo+Pkhp LA0KPj4NCj4+TXVrdWwgR295YWwgd3JvdGU6DQo+Pj4gTWlzY2hhLA0KPj4+DQo+Pj4+IFdlIHNo b3VsZCB1c2UgdGhpcyBlYXJseSBkZXNpZ24gc3RhZ2UgdG8gY29tZSB1cCB3aXRoIG9uZSBzb2x1 dGlvbiAtIG9uZQ0KPj4+IHNvbHV0aW9uIHdoaWNoIGlzIG5vdCBuZWNlc3NhcmlseSBvcHRpbXVt IGZvciBhbGwgY2FzZXMgYnV0IGZvciB0aGUNCj4+PiAoZS5nLikgOTUlIHF1YW50aWxlLiBUaGUg UEhZIGd1eXMgbGVhcm5lZCB0byBsaXZlIHdpdGggc3VjaCBhbiBhcHByb2FjaC4NCj4+PiBUaGUg TUFDIGZvbGtzIGFyZSBnZXR0aW5nIHRoZXJlIGFuZCB3ZSBzaG91bGQgdGFrZSBvdXIgY2hhbmNl IG5vdy4gOTUlDQo+Pj4gbWVhbnMgY2xlYXJseSB0byBjb25jZW50cmF0ZSBvbiB0aGUgY29yZSBp c3N1ZXMsIG9mIHdoaWNoIGxvb3ANCj4+PiBkZXRlY3Rpb24vYXZvaWRhbmNlLCBwMnAgYW5kIHNl Y3VyaXR5IGFyZSBzb21laG93IHN0aWxsIG9wZW4uDQo+Pj4NCj4+PiBXaGVuIHlvdSBzYXkgYSBz b2x1dGlvbiwgaXQgc2VlbXMgdGhhdCB5b3Ugd2FudCBvbmUgcGFydGljdWxhciBwcm90b2NvbC4g SSBhbSBPSyB3aXRoIFJQTCBhcyBhIHByb3RvY29sDQo+ZXZlbg0KPj50aG91Z2ggaXQgaGFzIGRl ZmljaWVuY2llcyAoc3VjaCBhcw0KPj5QMlAgcm91dGluZykuIEJ1dCwgdGhlIGltcGxpY2F0aW9u IG9mIGdpdmluZyBpdCB0aGUgV0cgc3RhdHVzIHNlZW1zIHRvDQo+PmJlIHRoYXQgUlBMIHdvdWxk IGJlIHRoZSBfZnJhbWV3b3JrXyBvbiB3aGljaCBhbGwgZnV0dXJlIFJPTEwgd29yayB3b3VsZA0K Pj5iZSBiYXNlZC4gSSBhbSBub3QgaW4gc3VwcG9ydCBvZiB0aGUgdXNlIG9mIFJQTCBhcyBhIGZy YW1ld29yayB1bmxlc3MgaXQNCj4+ZWxpbWluYXRlcyBpdHMgY3VycmVudCB0aWdodCBjb3VwbGlu ZyB3aXRoIERBR3MgKGEsIHJhdGhlciBoZWF2eSBkdXR5LA0KPj5sb29wIHByZXZlbnRpb24gbWVj aGFuaXNtKS4NCj4+DQo+PlRoZSBnb2FsIG9mIHRoZSBXRyBmcm9tIG15IHVuZGVyc3RhbmRpbmcs IGlzIHRvIHByb2R1Y2UgKm9uZSogcHJvdG9jb2wNCj4+aW4gdGhlIGN1cnJlbnQgY2hhcnRlci4g UlBMIGlzIGRlZmluaXRlbHkgc3VpdGFibGUgYXMgYSBzdGFydGluZyBwb2ludA0KPj5mb3IgdGhh dCBwcm90b2NvbCAoSlAgc2FpZCBmb3VuZGF0aW9uLCBub3QgZnJhbWV3b3JrKS4gSSBjb21wbGV0 ZWx5DQo+PnN1cHBvcnQgdGhpcyBhcHByb2FjaC4NCj4+DQo+PkZyb20gdGhlIGluZHVzdHJ5IHBv aW50IG9mIHZpZXcgd2UgbmVlZCBhIHNpbmdsZSBzb2x1dGlvbiwgd2hpY2gNCj4+ZnVsZmlsbHMg YXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIHN1ZmZpY2llbnRseSBhbmQgdGh1cyBjYW4gYmUgd2lk ZWx5DQo+PmRlcGxveWVkIGNvbW1lcmNpYWxseS4NCj4+DQo+PlJlZ2FyZGluZyBsb29wIHByZXZl bnRpb24sIHNvIHdoYXQgaWYgUlBMIGRvZXMgYSBiZXR0ZXIgam9iIHRoYW4gaXMNCj4+bmVjZXNz YXJ5PyBEb2VzIGl0IGJyZWFrIHNvbWUgcmVxdWlyZW1lbnQgZG9pbmcgdGhhdD8gSWYgc28sIHdl IHNob3VsZA0KPj5maXggaXQuIFRoZXJlIGFyZSBvdGhlciByZWFzb25zIGZvciB1c2luZyBEQUdz IHRoYW4ganVzdCBsb29wIHByZXZlbnRpb24uDQo+Pg0KPj5aYWNoDQo+Pg0KPj4tLQ0KPj5odHRw Oi8vd3d3LnNlbnNpbm9kZS5jb20NCj4+aHR0cDovL3phY2hzaGVsYnkub3JnIC0gTXkgYmxvZyDi gJxPbiB0aGUgSW50ZXJuZXQgb2YgVGhpbmdz4oCdDQo+Pk1vYmlsZTogKzM1OCA0MCA3Nzk2Mjk3 DQo+Pg0KPj5aYWNoIFNoZWxieQ0KPj5IZWFkIG9mIFJlc2VhcmNoDQo+PlNlbnNpbm9kZSBMdGQu DQo+PktpZGVrdWphIDINCj4+ODg2MTAgVnVva2F0dGksIEZJTkxBTkQNCj4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Um9sbCBtYWlsaW5nIGxpc3QN Cj4+Um9sbEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PlJvbGwgbWFpbGluZyBsaXN0DQo+PlJvbGxAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Sb2xsIG1haWxpbmcgbGlzdA0KPj5Sb2xs QGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From jvasseur@cisco.com Mon Aug 3 00:23: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 1F5763A6D6C for ; Mon, 3 Aug 2009 00:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.516 X-Spam-Level: X-Spam-Status: No, score=-9.516 tagged_above=-999 required=5 tests=[AWL=1.083, 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 NeO1Xyhv6qiZ for ; Mon, 3 Aug 2009 00:23:08 -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 B3C793A6999 for ; Mon, 3 Aug 2009 00:23:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEAALosdkqQ/uCKe2dsb2JhbACaJAEBFiQGnjyIKY4RBYQY X-IronPort-AV: E=Sophos;i="4.43,312,1246838400"; d="scan'208";a="46308411" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2009 07:23:08 +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 n737N8Er008304 for ; Mon, 3 Aug 2009 09:23:08 +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 n737N84p000066 for ; Mon, 3 Aug 2009 07:23:08 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:23:08 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:23:08 +0200 Message-Id: <06AC44C1-A238-4763-8782-BD8D25526A67@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: Mon, 3 Aug 2009 09:23:07 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Aug 2009 07:23:08.0375 (UTC) FILETIME=[3FF5CE70:01CA140B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16802.005 X-TM-AS-Result: No--15.761700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1337; t=1249284188; x=1250148188; 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:=20New=20ROLL=20WG=20document=3A=20draft-ietf-roll -rpl-00.txt |Sender:=20; bh=xnCi5pGVtCNBg3nCwAR+t/Ajxpdr2eqOdHn55RIiObY=; b=Kt/dmMhA22upEMKj8Tyg4GYd8KekFHJCg7JaRf57pA5w+V3pqz46WmAXiN bhcPe17vT50YnUr9SHPfniwIZ/DDZFBzeUu2UfYrjvCkychBUYvr+yWumLJ8 Le7g7GRmMc; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] New ROLL WG document: draft-ietf-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, 03 Aug 2009 07:23:09 -0000 Dear All, Many thanks for so much feed-back and fruitful discussions. We had a very good consensus during the WG meeting (very quickly) confirmed on the mailing list for adopting draft-dt-roll-rpl as a WG document. Authors, please resubmit draft-dt-roll-rpl-01.txt as draft-ietf-roll- rpl-00.txt with no other changes other than date and title. As expressed by several of you and acknowledged by the DT, there are still several open issues and items to discuss. As reminded on the mailing list and during the meeting, adopting an I-D as a WG document is by all means not an end (!!) and we still have substantial work ahead of us, but at least we have an excellent foundation and principles for which we have a very good consensus. In the list of items (with no particular order of importance): * Point to point routing, * Binding to ND, * Loss of RA-DIO, * Loop detection (to also be discussed in light of the solution proposed by DADR), * Source routing, * Address compression/label switching, * Security (let's just wait until we move on (soon) with the security framework document), * ... Very pleased to see that the WG is moving forward fast with excellent consensus and contributions. Stay tuned, I will propose a plan in term of next steps. Thanks. JP. From jvasseur@cisco.com Mon Aug 3 00:26: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 7EE283A683F for ; Mon, 3 Aug 2009 00:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[AWL=-0.971, 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 7ABCmzYQFOnl for ; Mon, 3 Aug 2009 00:26:56 -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 B278628B797 for ; Mon, 3 Aug 2009 00:26:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACMudkqrR7MV/2dsb2JhbAC5GogpjhIFhBg X-IronPort-AV: E=Sophos;i="4.43,312,1246838400"; d="scan'208";a="359082640" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 07:26:59 +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 n737Qxfw022652 for ; Mon, 3 Aug 2009 00:26:59 -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 n737QSlb022240 for ; Mon, 3 Aug 2009 07:26:58 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:26:35 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:26:34 +0200 Message-Id: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@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: Mon, 3 Aug 2009 09:26:34 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Aug 2009 07:26:35.0063 (UTC) FILETIME=[BB27E470:01CA140B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=879; t=1249284419; x=1250148419; 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:=20Next=20items=20... |Sender:=20; bh=YDTNFLwrsp0zw0OGfCoFOAEHzejpva8hSoFtzG3Zi/8=; b=r/cO2xWjWoFFQX4WQnRwGeagPZSqi23mUfivmsZNnphvH54XOFquyokGEu 7laI9Lr/Obg3aO/YEMZhB1sTPgmswsu2JRHHQ2lxLxdgn8YWnhv9/+UBLvMJ 2N/08ahee+LKr/fifSeRuFqjlNWqsVacOdrpQPnG60jG+Yq2obKwU=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 07:26:57 -0000 Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address all open items in some unstructured way, I would like to propose the following. It clearly appeared that there were some misunderstandings on how RPL works. The DT did an outstanding job but I also understand that several areas must be clarified. So before changing RPL, adding new mechanisms (e.g. to optimize P2P, support source routing, loop detection, ... ), I would first want you to list your questions on the mailing list on each area for which you would like to get clarification. This will help make sure that everybody is indeed on the same page. From there, we will continue to quickly move forward, I will track the list of open items via the issue tracker. Many Thanks. JP. From jvasseur@cisco.com Mon Aug 3 00:28: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 70B7628C0ED for ; Mon, 3 Aug 2009 00:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.524 X-Spam-Level: X-Spam-Status: No, score=-9.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 qNbh63eepGaB for ; Mon, 3 Aug 2009 00:28: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 342233A6D80 for ; Mon, 3 Aug 2009 00:28:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEAAOctdkqQ/uCKe2dsb2JhbACaJAEBFiQGnjOIKY4SBYQY X-IronPort-AV: E=Sophos;i="4.43,312,1246838400"; d="scan'208";a="46308806" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2009 07:28:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n737SBVf009414; Mon, 3 Aug 2009 09:28:11 +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 n737SBaC001289; Mon, 3 Aug 2009 07:28:11 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:28:11 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:28:10 +0200 Message-Id: <73B1EF18-AC29-4A8A-B7F4-3EC601508E9F@cisco.com> From: JP Vasseur To: ryusuke.masuoka@us.fujitsu.com In-Reply-To: <014601ca115b$b0629fb0$1127df10$@masuoka@us.fujitsu.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, 3 Aug 2009 09:28:10 +0200 References: <4A71B613.7000504@sensinode.com> <014601ca115b$b0629fb0$1127df10$@masuoka@us.fujitsu.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Aug 2009 07:28:11.0051 (UTC) FILETIME=[F45E7FB0:01CA140B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2753; t=1249284491; x=1250148491; 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]=20Determining=20DADR=20Contribut ions |Sender:=20; bh=7e7Kkc563cq20dw7ApBxaGyTQdvBoSZRVKFdCE+V+Bw=; b=IQQRlK3GPiXVDdgPF6olC1ZyraPYYfRRlsyimyMjLhfalwbBY0UrTaa2V9 ZpAsZrEOSd86S7uuFu6C+8bceqX+Ysi5xMnououqDmLlJYoQxuw6V7MyxBWz j1v+Scg2/a; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 'ROLL WG' Subject: Re: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 07:28:11 -0000 Hi Ryu, Thanks for your contribution. Sharing this kind of data is extremely valuable for the WG. Just a short note to stress the fact that RPL is of course L2 agnostic since ROLL operates at L3. Thus, there is no preference or attempt to optimize the routing protocol for a specific L2, which would defeat one of the main reasons for using IP. On the other hand, capturing L2 characteristic(s) as L3 routing protocol metric(s) is perfectly in the scope. Thanks for your help, we are looking forward to having your data. JP. On Jul 30, 2009, at 11:21 PM, Ryusuke Masuoka wrote: > 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 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Aug 3 00:30: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 8955A3A6C14; Mon, 3 Aug 2009 00:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.572 X-Spam-Level: X-Spam-Status: No, score=-7.572 tagged_above=-999 required=5 tests=[AWL=-0.973, 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 kcRvdQPiLmzd; Mon, 3 Aug 2009 00:30: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 3146C3A68D1; Mon, 3 Aug 2009 00:30:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgGABMvdkqrR7O6/2dsb2JhbACVb6MriCmOEQWEGA X-IronPort-AV: E=Sophos;i="4.43,312,1246838400"; d="scan'208";a="191856156" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2009 07:30:08 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n737U9Y4013919; Mon, 3 Aug 2009 00:30:09 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n737TtKX018535; Mon, 3 Aug 2009 07:30:09 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:29:52 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:29:52 +0200 Message-Id: <270BADAB-0945-4E19-AB83-76A2B4570AE8@cisco.com> From: JP Vasseur To: Rene Struik In-Reply-To: <473C2CD540AC5141858AD4D50149C4B3020C4A00@EX41.exchserver.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: Mon, 3 Aug 2009 09:29:51 +0200 References: <473C2CD540AC5141858AD4D50149C4B3020C4A00@EX41.exchserver.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Aug 2009 07:29:52.0116 (UTC) FILETIME=[309BCB40:01CA140C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7175; t=1249284609; x=1250148609; 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]=20(On=20keeping=20state)=20Re=3A =20Moving=20forward=20with=20the=20protocol=20work |Sender:=20; bh=CEdVdbtUU5HZGs/pWYE4mYEHnkmvqyPDY60n+jCCiio=; b=UiZRCG88mJe+nLDi6+g6mz1NQC2J9wN+1kA+2h+XRnvvl9Wt6M+qMPbcLh KSQwKOjTXk5t5yQvONxb+7G3TI70+6UK0hbuA/hF2uwivEi4bhYQHTM/Etr4 VA/chgyzLp; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "roll-bounces@ietf.org" , "jerald.p.martocci@jci.com" , "roll@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 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:30:08 -0000 Hi Rene, On Jul 31, 2009, at 2:51 PM, Rene Struik wrote: > Dear colleagues: > > Please be aware that incorporation of security provisions may =20 > necessitate retaining some state information on each device, the =20 > extent of which depending on security design objectives throughout =20 > the life cycle of the system and granularity of security policies, =20 > whether for routing security or other reasons. So, even if one were =20= > able to remove state with a particular routing design, this does not =20= > necessarily imply one can avoid this altogether from an overall =20 > system perspective. > Absolutely, this is the sort of trade-off that will be discussed =20 during routing design. Thanks. JP. > 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 =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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Aug 3 02:06: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 3BFBB3A6C80 for ; Mon, 3 Aug 2009 02:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.263, 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 HBfusBf03Gsz for ; Mon, 3 Aug 2009 02:06:54 -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 3A97E3A6C22 for ; Mon, 3 Aug 2009 02:06:53 -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 n7396QNp021932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Aug 2009 11:06:26 +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 n7396QZr011716; Mon, 3 Aug 2009 11:06:26 +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 n7396PkC022035; Mon, 3 Aug 2009 11:06:26 +0200 Message-ID: <4A76A891.6070506@gmail.com> Date: Mon, 03 Aug 2009 11:06:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: JP Vasseur References: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> In-Reply-To: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] addressing architecture and subnet structure for RPL (was: Next items ...) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 09:06:55 -0000 JP, Thank you for requesting questions. I would like to get clarification on the IPv6 addressing architecture and subnet structure considered in RPL. -is it the AUTOCONF addressing model? -is it the 6LoWPAN route over or mesh-under? -how many physical interfaces does a node have? -if a node has several interfaces then does it have only one physical interface? -what is the default route behaviour? Does each node have default route? -are there IPv6 prefix subnets /64? Here is a DAG excerpt from 01 draft: (A) |\ | `-----. | \ (B) \ \ | `-----. | \| (C) Does that mean the IPv6 addressing arechitecture is this: (A) |\ 2001:db8:1::/64 | `-----. | \ 2001:db8:2::/64 (B) \ \ | `-----. | 2001:db8:3::/64 \| (C) ? Thanks for clarification, Alex JP Vasseur a écrit : > Dear all, > > As a reminder, RPL being a WG ID, it now "belongs" to the WG. > > Several working items have been listed but before starting to address > all open items in some unstructured way, I would like to propose the > following. > > It clearly appeared that there were some misunderstandings on how RPL > works. The DT did an outstanding job but I also understand that several > areas must be clarified. So before changing RPL, adding new mechanisms > (e.g. to optimize P2P, support source routing, loop detection, ... ), I > would first want you to list your questions on the mailing list on each > area for which you would like to get clarification. This will help make > sure that everybody is indeed on the same page. > > From there, we will continue to quickly move forward, I will track the > list of open items via the issue tracker. > > Many Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Mon Aug 3 02:12: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 D56B228C103 for ; Mon, 3 Aug 2009 02:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.257, 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 6Nv3L5jTzMP4 for ; Mon, 3 Aug 2009 02:12: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 A09033A6900 for ; Mon, 3 Aug 2009 02:12:09 -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 n739C5sP024321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Aug 2009 11:12:05 +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 n739C5hY013115; Mon, 3 Aug 2009 11:12:05 +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 n739C4lF023663; Mon, 3 Aug 2009 11:12:05 +0200 Message-ID: <4A76A9E4.5060703@gmail.com> Date: Mon, 03 Aug 2009 11:12:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jonathan Hui References: <001101ca11d8$102811b0$30783510$@sturek@att.net> <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> <003301ca11e0$58aa9040$09ffb0c0$@sturek@att.net> <271F493C-F591-49D6-B658-841388DAA3F6@archrock.com> In-Reply-To: <271F493C-F591-49D6-B658-841388DAA3F6@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 'ROLL WG' Subject: Re: [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: Mon, 03 Aug 2009 09:12:15 -0000 Jonathan, Could it be that the physical topology on which RPL acted were an arbitrary graph, but the view of that topology (view maintained at each node) were a DAG? Or is it a MUST that the topology and interface directionality to be a physical DAG? Alex Jonathan Hui a écrit : > > Don correctly highlights and important reasons for the DAG that I want > to expand a bit more. > > A DAG is necessary in resource constrained environments. Using a DAG > allows us the LLN to provide basic P2P connectivity while maintaining > hard bounds on the amount of memory each LLN node can maintain. It has > been mentioned many times that a DAG does not provide an "optimal" P2P > solution. If memory is constrained such that each LLN node is only > capable of maintaining a few routes at any time, then a DAG does provide > an "optimal" P2P solution given the state constraints. This is > fundamental and a protocol should allow for operation under such memory > constraints. > > Using a DAG allows us to guide and constrain the communication of > routing information as well. It ensures that state maintenance and > exchange only occurs on a small subgraph of nodes toward the DAG root - > rather than and unstructured "flooding" of the entire DAG with such > information. While DAG construction uses broadcast RAs to communication > information, establishing routes that flow away from the root need only > rely on unicast communication. I'd like to stress the importance of > broadcast vs. unicast communication. While both are logically one > transmission, the two have very different costs in environments where > the radio is duty cycled. Depending on the duty-cycled link protocol, > broadcast can by orders of magnitude more expensive in channel > utilization, energy consumption, and communication delay. Again, this is > fundamental and a protocol should allow for operation under severe > channel capacity and energy constraints. > > These fundamental limits require the use a hierarchical structure - a > DAG. A common misconception is that we chose a DAG because of the MP2P > and P2MP requirement. The real reason is that a DAG allows for operation > under severe resource constraints - not because traffic typically flows > through some edge router. A DAG orients the connectivity graph in a way > to constrain the routing problem. It's just a nice-to-have if the DAG is > rooted at the "edge router" when you do have MP2P and P2MP flows. > > Of course, we have mentioned that a DAG can be used for avoiding and > detecting cycles, but that is not the fundamental reason for using the > DAG. The need for attending to loops and the count-to-infinity problem > is an important side effect of using the DV class of protocols. > > Again, people need to be more concrete when saying "optimal", because > such a notion is not well defined without clarity in the problem's > constraints and goals. What people seem to mean when they say they want > more "optimal" mechanisms is really to be able to make use of more > resources when they are available. Specifically, if a node can maintain > more routes and communicate more routing information, it should be able > to reduce overall routing stretch. That I strongly agree with. > > But the protocol needs to have a baseline to allow operation with severe > resource constraints and for that reason, I'd argue that the 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 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] >> 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 >> >> ----- 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 >> >> -- >> 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 >> >> _______________________________________________ >> 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 Mon Aug 3 04:23: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 0C4F63A6CD9 for ; Mon, 3 Aug 2009 04:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[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 kP-qd9AswibU for ; Mon, 3 Aug 2009 04:23:07 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id 2FAE43A6C9B for ; Mon, 3 Aug 2009 04:23:07 -0700 (PDT) Received: (qmail 78452 invoked from network); 3 Aug 2009 11:23:08 -0000 Received: from unknown (HELO Studio) (d.sturek@69.224.126.38 with login) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 3 Aug 2009 11:23:07 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: 3NnL5OoVM1lSfzGQSv9OXgWjx2JSVKDlWrW2C6X2SLuiMF0jjAeqav8lAsdByG_N1cUdSu_PNnUxHK6z7cKT42iZI0yAOBVW5KuVOR_egOotMiycMMPJ1pAYH6Ixw1lcibZ23y8xWiqooZWnaX1WTzcYQhjWXkmNRKblSqqYziQn6sYRnTHe5LsMOGXeMNffcHMkbrK2U8dH9GK3Gp26oC1Yn75Pg0S.qC4rG5LefpreoYyEX7Bh_AVYKWHHIgaiOfDXA871.6smj0C08AigOCWwmoGVT3fHm_vDZegwJRLfxqTm.ZeDB2AtE1DZ8DF9FA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> In-Reply-To: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> Date: Mon, 3 Aug 2009 04:23:06 -0700 Message-ID: <005501ca142c$c63ca460$52b5ed20$@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: AcoUC8vO0WHZ7MzGQ8+7DJByPjKBgAAHM/Yg Content-Language: en-us Subject: Re: [Roll] Next items ... P2P Support Clarification 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, 03 Aug 2009 11:23:08 -0000 Hi JP, Here are some points that I would like to see the design team clarify with respect to the current RPL draft: 1) P2P support a. I believe the P2P feature uses Destination Address advertisements from the device wishing to receive P2P traffic: i. What are the requirements for the receiving device advertising via Destination Address Advertisements assuming it is not the DAG-root (eg, What is the rate of Destination Address advertisements, How does the device (or does it/can it) notify devices of lower rank/depth that it has detached from the DAG). If there is no mechanism for the receiving device to notify devices of lower rank/depth it if detaches, how is maintenance of the Destination Address advertisement caching within the DAG performed. ii. What are the requirements for devices with lower rank/depth in the same DAG when receiving a Destination Address advertisement (eg, does it store the Destination Address advertisements of its children, Does it further re-propagate the Destination Address advertisements to devices of lower rank/depth, How long should devices of lower rank/depth store these destination address advertisements) b. Routing of P2P traffic i. I assume that the DAG-root holds the address of all Destination Address Advertisements it has received from devices in its DAG. Is this true? ii. I assume that other devices in the DAG of higher rank/depth from the DAG-root but still lower in rank than the final destination routes packets down the DAG. It seems possible for the destination to receive multiple copies (is this correct) and more importantly it also seems possible for an Unreachable notification to be generated by some device in the DAG when in fact the packet reached its destination through another path (did I read the proposal wrong?) c. Sibling routing seems to be not supported (though I saw discussion of this on the reflector). It seems problematic to have Siblings processing Destination Address advertisements within the same DAG. We should leave this out of the clarification if my reading is correct and only add it back as part of support for optimized P2P if that is where the optimization leads. I also have some questions on the freezing of DAGs and ungrounded DAGs but I think that is a separate issue and I will put out a note later in the week on this. Thanks, Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Monday, August 03, 2009 12:27 AM To: ROLL WG Subject: [Roll] Next items ... Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address all open items in some unstructured way, I would like to propose the following. It clearly appeared that there were some misunderstandings on how RPL works. The DT did an outstanding job but I also understand that several areas must be clarified. So before changing RPL, adding new mechanisms (e.g. to optimize P2P, support source routing, loop detection, ... ), I would first want you to list your questions on the mailing list on each area for which you would like to get clarification. This will help make sure that everybody is indeed on the same page. From there, we will continue to quickly move forward, I will track the list of open items via the issue tracker. Many Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Mon Aug 3 04:47: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 3F8053A6D59 for ; Mon, 3 Aug 2009 04:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_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 a+KPY0nxgUeQ for ; Mon, 3 Aug 2009 04:47:40 -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 50CCD3A694C for ; Mon, 3 Aug 2009 04:47:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB1rdkqrR7MV/2dsb2JhbAC5CIgpjicFhBg X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="359206129" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 11:47:42 +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 n73BlgAV006082 for ; Mon, 3 Aug 2009 04:47:42 -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 n73Bl2FU024654 for ; Mon, 3 Aug 2009 11:47:42 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:47: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 13:47:39 +0200 Message-ID: In-Reply-To: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Next items ... Metric, siblings, and timers Thread-Index: AcoUC9xPexbEtSzqRSyP2gEALx+2/QAIz/FQ References: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 03 Aug 2009 11:47:40.0399 (UTC) FILETIME=[346C77F0:01CA1430] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2101; t=1249300062; x=1250164062; c=relaxed/simple; s=sjdkim1004; 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]=20Next=20items=20...=20Metric,=2 0siblings,=20and=20timers |Sender:=20; bh=zwqIcAul8REm6h+pKG1vprvIgxjHju/+V5Nnn+SgwqM=; b=GhWHJfQlfKVGORPoyha16JLxw7Dq83MUWhBk0Z3HGjtdv7ziBJq7iZxBRY yybVKT9L9METRIbW38zYxysxh6KBY428EexVbr792nZGRTlu8bgKinHAFTil f/XQXDcg5YjwuPvjZ6EXz+QJZS5exc/babne9mC0rnOfKxrAGRE3A=; Authentication-Results: sj-dkim-1; header.From=mdurvy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Roll] Next items ... Metric, siblings, and timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 11:47:41 -0000 Hi JP, DT, I would personally want to see more discussion on 3 topics where I'm = still not fully convinced: [SIBLINGS] The role of siblings: this adds quite some extra complexity = to the routing but what does it really bring in practice? Should = siblings be part of the foundation layer? My opinion is no. [METRICS] 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? [TIMERS] 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 during the IETF meeting 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: lundi, 3. ao=FBt 2009 09:27 To: ROLL WG Subject: [Roll] Next items ... Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address = all open items in some unstructured way, I would like to propose the = following. It clearly appeared that there were some misunderstandings on how RPL = works. The DT did an outstanding job but I also understand that several = areas must be clarified. So before changing RPL, adding new mechanisms = (e.g. to optimize P2P, support source routing, loop detection, ... ), I = would first want you to list your questions on the mailing list on each = area for which you would like to get clarification. This will help make = sure that everybody is indeed on the same page. From there, we will continue to quickly move forward, I will track the = list of open items via the issue tracker. Many Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Aug 3 06:04: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 7E1593A69DA for ; Mon, 3 Aug 2009 06:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.811 X-Spam-Level: X-Spam-Status: No, score=-7.811 tagged_above=-999 required=5 tests=[AWL=-1.212, 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 XSUWmTML06+e for ; Mon, 3 Aug 2009 06:04:56 -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 6DB7A3A694C for ; Mon, 3 Aug 2009 06:04:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJZ9dkqrR7PD/2dsb2JhbAC5aIgpjioFhBg X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="191926354" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2009 13:04:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n73D4wFf019599; Mon, 3 Aug 2009 06:04:58 -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 n73D4spw010070; Mon, 3 Aug 2009 13:04:58 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); Mon, 3 Aug 2009 15:04: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: Mon, 3 Aug 2009 15:04:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E206BB@xmb-ams-337.emea.cisco.com> In-Reply-To: <005501ca142c$c63ca460$52b5ed20$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Next items ... P2P Support Clarification Thread-Index: AcoUC8vO0WHZ7MzGQ8+7DJByPjKBgAAHM/YgAAEXeTA= References: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> <005501ca142c$c63ca460$52b5ed20$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 03 Aug 2009 13:04:56.0299 (UTC) FILETIME=[FFA2ABB0:01CA143A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5377; t=1249304698; x=1250168698; c=relaxed/simple; s=sjdkim3002; 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]=20Next=20items=20...=20=20P2P=20 Support=20Clarification |Sender:=20; bh=xxslfeyP1E3KpSAIlMSQHz3GlFHjk6oq0WNjC/eTM80=; b=apOjKjY7NvNmHkgWbXphGjGDpDsgpbGIpedQT/taR0oUDwYs5eM2d8ZuVL lutkVld2aWAq0IFZ5Drov7EhUxdVpPxnHH4UoLnh53lVbZQtX5bnB/UV0/om 5KZS+Taukg; Authentication-Results: sj-dkim-3; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Roll] Next items ... P2P Support Clarification X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 13:04:57 -0000 Hi Don >Here are some points that I would like to see the design team clarify with >respect to the current RPL draft: >1) P2P support > a. I believe the P2P feature uses Destination Address >advertisements from the device wishing to receive P2P traffic: > i. What are the requirements for the receiving device >advertising via Destination Address Advertisements assuming it is not the >DAG-root (eg, What is the rate of Destination Address advertisements, How >does the device (or does it/can it) notify devices of lower rank/depth that >it has detached from the DAG). If there is no mechanism for the receiving A DAO of lifetime 0 is used to indicate that the reachability is lost (5.4.1.1). If the Node has a chance to leave gracefully, it could send that about itself.=20 I trust that the most common case is timing out a child though. >device to notify devices of lower rank/depth it if detaches, how is >maintenance of the Destination Address advertisement caching within the DAG >performed. > ii. What are the requirements for devices with lower >rank/depth in the same DAG when receiving a Destination Address >advertisement (eg, does it store the Destination Address advertisements of >its children, Does it further re-propagate the Destination Address >advertisements to devices of lower rank/depth, How long should devices of >lower rank/depth store these destination address advertisement The idea is that the no-DAO (lifetime 0) are propagated immediately and unreliably. This another instance where a loop is easily created and thus requires detection. This is a case where CTP's approach to loop detection would be enough. s) > b. Routing of P2P traffic > i. I assume that the DAG-root holds the address of all >Destination Address Advertisements it has received from devices in its DAG. >Is this true? If DAO is used at all that would be true. I suspect that this is something that should circulate in DIO. Our approach to autonomicity is that a lot of the config applies for a whole DAG and is pushed by the root in DIO. > ii. I assume that other devices in the DAG of higher >rank/depth from the DAG-root but still lower in rank than the final >destination routes packets down the DAG. It seems possible for the >destination to receive multiple copies (is this correct) and more >importantly it also seems possible for an Unreachable notification to be >generated by some device in the DAG when in fact the packet reached its >destination through another path (did I read the proposal wrong?) The no-DOA should be absorbed by a parent that still has an alternate solution. I'm not sure I get/answer what you really mean here? > c. Sibling routing seems to be not supported (though I saw >discussion of this on the reflector). It seems problematic to have Siblings >processing Destination Address advertisements within the same DAG. We >should leave this out of the clarification if my reading is correct and only >add it back as part of support for optimized P2P if that is where the >optimization leads. Right. No sibling DAO at the moment. You go through parents. We need to multicast the DAO about connected routes (owned prefix) to enable line of sight connectivity. That's at the beginning of the list of stuff we look at to improve P2P. I think we is now the whole WG... We need a inter-sibling routing protocol to enable what I called boulevard routing aka beltlines. The idea would be to redistribute DAOs into beltlines but not beltlines into DAOs, so you'd learn a prefix through either but not both, effectively offloading the core of the mesh near the sink like belts and boulevards do around cities. That's a bit deeper in the list :) Cheers, Pascal > >I also have some questions on the freezing of DAGs and ungrounded DAGs but I >think that is a separate issue and I will put out a note later in the week >on this. > >Thanks, > >Don > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP >Vasseur >Sent: Monday, August 03, 2009 12:27 AM >To: ROLL WG >Subject: [Roll] Next items ... > >Dear all, > >As a reminder, RPL being a WG ID, it now "belongs" to the WG. > >Several working items have been listed but before starting to address >all open items in some unstructured way, I would like to propose the >following. > >It clearly appeared that there were some misunderstandings on how RPL >works. The DT did an outstanding job but I also understand that >several areas must be clarified. So before changing RPL, adding new >mechanisms (e.g. to optimize P2P, support source routing, loop >detection, ... ), I would first want you to list your questions on the >mailing list on each area for which you would like to get >clarification. This will help make sure that everybody is indeed on >the same page. > > From there, we will continue to quickly move forward, I will track >the list of open items via the issue tracker. > >Many Thanks. > >JP. >_______________________________________________ >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 Mon Aug 3 07:45: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 A01F83A6DF7 for ; Mon, 3 Aug 2009 07:45: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 EIqqBFpyz3yw for ; Mon, 3 Aug 2009 07:45:32 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6B35328C17B for ; Mon, 3 Aug 2009 07:43:59 -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, 3 Aug 2009 10:44:13 -0400 Date: Mon, 03 Aug 2009 10:44:22 -0400 Message-Id: <87r5vt3qk9.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 03 Aug 2009 14:44:14.0138 (UTC) FILETIME=[DEC8C1A0:01CA1448] Subject: [Roll] cost of incrementing the DAG sequence number X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 14:45:32 -0000 ROLLers, At the session in Stockholm both Jonathan and Pascal described incrementing the DAG sequence number as a costly operation. I don't think that this is necessarily the case. The cost of incrementing the sequence number depends on whether or not seeing a new sequence number resets the trickle timer. If it does, then the cost may indeed be high. If not, there is essentially no cost to incrementing the sequence number. With the exception possibly resetting the trickle timer, no action is required upon receiving a new sequence number in a DIO. I would argue that seeing a new sequence number in a parent's DIO should not reset the trickle timer. In addition to reducing the cost of incrementing, it also increases the utility of doing so. The sequence numbers are more useful if they propagate slowly than if they propagate quickly. Incrementing the sequence number reasonably often increases nodes' ability to react to topography changes. At the extreme, once all nodes in the DAG have the same sequence number the sequence number is no help at all. We shouldn't be in a hurry to get there. -Richard Kelsey From richard.kelsey@ember.com Mon Aug 3 08:49: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 C18D93A6AA0 for ; Mon, 3 Aug 2009 08:49:40 -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 7wGumjILPBeV for ; Mon, 3 Aug 2009 08:49:40 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id CA98F3A6AC1 for ; Mon, 3 Aug 2009 08:49:38 -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, 3 Aug 2009 11:50:01 -0400 Date: Mon, 03 Aug 2009 11:50:10 -0400 Message-Id: <87prbc5231.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 03 Aug 2009 15:50:01.0702 (UTC) FILETIME=[0FB73860:01CA1452] Subject: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 15:49:40 -0000 ROLLers, In the section on RA-DIO reception, draft-dt-roll-rpl-01 says that a RA-DIO from a neighbor that is not a potential parent or a sibling should be ignored. Is it permissable to remember the neighbor in order to route messages to it directly? In other words, can a packet whose destination is a neighbor with a greater depth be sent directly to that neighbor? -Richard Kelsey From Jerald.P.Martocci@jci.com Mon Aug 3 11:09: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 BEFFB3A6D6E for ; Mon, 3 Aug 2009 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fOdp5H+CA5Kd for ; Mon, 3 Aug 2009 11:09:35 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by core3.amsl.com (Postfix) with ESMTP id 108263A6828 for ; Mon, 3 Aug 2009 11:09:32 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKSncn344AR2AoFJoit4DaK18dhEPeU3n4@postini.com; Mon, 03 Aug 2009 11:09:36 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009080313094189-1249738 ; Mon, 3 Aug 2009 13:09:41 -0500 In-Reply-To: <22522DD8-D8E8-467F-87D5-38A1A2EE2432@cisco.com> 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: Mon, 3 Aug 2009 13:09:19 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/03/2009 01:09:29 PM, Serialize complete at 08/03/2009 01:09:29 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/03/2009 01:09:41 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/03/2009 01:09:47 PM, Serialize complete at 08/03/2009 01:09:47 PM Content-Type: multipart/alternative; boundary="=_alternative 0063BA9986257607_=" Cc: ROLL WG Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 18:09:36 -0000 This is a multipart message in MIME format. --=_alternative 0063BA9986257607_= Content-Type: text/plain; charset="US-ASCII" I would like the following questions answered on subsequent revisions of the draft: a) What is the roll of 'siblings'? They are in the current RPL document, yet seem to be demoted from parental links. As I read the draft, one cannot use a sibling link unless the parental links are exhausted. The nodes don't seem to explicitly define sibling links. b) What is the plan on communication to devices within direct radio range? As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with. However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices. Unfortunately, I couldn't attend the meeting. c) What are the approximate timer values for RPL? The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network. In a real-time facility management control system, all nodes are monitored for falling off-line. If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer. d) What is the plan for security? RPL doesn't currently weigh in on the topic. Are security policies optional or mandatory? Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network? Will security require nodes to keep state info as Rene suggests? e) What requirements from the 4 requirement drafts are being considered? When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement. This hasn't occurred and may be adding to the email angst. As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered. f) What is the expected frame overhead size based on all the above criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP. We need to add in the encryption and authentication overhead; and now maybe source routing. I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town. It only carries a 128 by packet size. The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol. g) What routing data must persist a warmstart/coldstart? The overhead to establish a DAG is significant. We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks. As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision. That may indeed be true, but RPL should state its case explicitly. In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot. Thanks, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 08/03/2009 02:27 AM To ROLL WG cc Subject [Roll] Next items ... Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address all open items in some unstructured way, I would like to propose the following. It clearly appeared that there were some misunderstandings on how RPL works. The DT did an outstanding job but I also understand that several areas must be clarified. So before changing RPL, adding new mechanisms (e.g. to optimize P2P, support source routing, loop detection, ... ), I would first want you to list your questions on the mailing list on each area for which you would like to get clarification. This will help make sure that everybody is indeed on the same page. From there, we will continue to quickly move forward, I will track the list of open items via the issue tracker. Many Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0063BA9986257607_= Content-Type: text/html; charset="US-ASCII"
I would like the following questions answered on subsequent revisions of the draft:


a) What is the roll of 'siblings'?  They are in the current RPL document, yet seem to be demoted from parental links.  As I read the draft, one cannot use a sibling link unless the parental links are exhausted.  The nodes don't seem to explicitly define sibling links.  

b) What is the plan on communication to devices within direct radio range?  As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with.  However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices.  Unfortunately, I couldn't attend the meeting.

c) What are the approximate timer values for RPL?  The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network.  In a real-time facility management control system, all nodes are monitored for falling off-line.  If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer.

d) What is the plan for security?  RPL doesn't currently weigh in on the topic.  Are security policies optional or mandatory?  Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network?  Will security require nodes to keep state info as Rene suggests?

e) What requirements from the 4 requirement drafts are being considered?  When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement.  This hasn't occurred and may be adding to the email angst.  As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered.

f) What is the expected frame overhead size based on all the above criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP.  We need to add in the encryption and authentication overhead; and now maybe source routing.  I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town.  It only carries a 128 by packet size.  The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol.

g) What routing data must persist a warmstart/coldstart?  The overhead to establish a DAG is significant.  We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks.

As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision.  That may indeed be true, but RPL should state its case explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor.  Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot.

Thanks,

Jerry




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

08/03/2009 02:27 AM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] Next items ...





Dear all,

As a reminder, RPL being a WG ID, it now "belongs" to the WG.

Several working items have been listed but before starting to address  
all open items in some unstructured way, I would like to propose the  
following.

It clearly appeared that there were some misunderstandings on how RPL  
works. The DT did an outstanding job but I also understand that  
several areas must be clarified. So before changing RPL, adding new  
mechanisms (e.g. to optimize P2P, support source routing, loop  
detection, ... ), I would first want you to list your questions on the  
mailing list on each area for which you would like to get  
clarification. This will help make sure that everybody is indeed on  
the same page.

From there, we will continue to quickly move forward, I will track  
the list of open items via the issue tracker.

Many Thanks.

JP.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0063BA9986257607_=-- From jhui@archrock.com Mon Aug 3 12:37: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 4E4923A6EA2 for ; Mon, 3 Aug 2009 12:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, 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 iCSa86mALTBf for ; Mon, 3 Aug 2009 12:37:36 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3EA2C3A6E25 for ; Mon, 3 Aug 2009 12:37:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 46511AF879; Mon, 3 Aug 2009 12:37: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 NT6mN720Nw8y; Mon, 3 Aug 2009 12:37:32 -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 97EB7AF859; Mon, 3 Aug 2009 12:37:32 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87prbc5231.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, 3 Aug 2009 12:37:31 -0700 References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 19:37:37 -0000 Hi Richard, On Aug 3, 2009, at 8:50 AM, Richard Kelsey wrote: > In the section on RA-DIO reception, draft-dt-roll-rpl-01 > says that a RA-DIO from a neighbor that is not a potential > parent or a sibling should be ignored. Is it permissable > to remember the neighbor in order to route messages to > it directly? In other words, can a packet whose > destination is a neighbor with a greater depth be sent > directly to that neighbor? Let me speak to your comment directly, rather than the draft. I don't see any problem using the RA-DIO to figure out what neighbors are around you. One issue is that if the RA-DIO source address is a link-local address, it may not be so useful if you're trying to talk to that node using its global address. What is more useful is to allow including some kind of DAO in the same RA so that you know what addresses (other than the source address) are assigned to that node's interface. -- Jonathan Hui From jhui@archrock.com Mon Aug 3 12:58: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 190C028C23C for ; Mon, 3 Aug 2009 12:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 W93EMc2Brlpr for ; Mon, 3 Aug 2009 12:58: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 49FF528C23B for ; Mon, 3 Aug 2009 12:58:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 179DAAF879; Mon, 3 Aug 2009 12:58:29 -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 E5+vxXsytggM; Mon, 3 Aug 2009 12:58:24 -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 355C0AF859; Mon, 3 Aug 2009 12:58:24 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87r5vt3qk9.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, 3 Aug 2009 12:58:23 -0700 References: <87r5vt3qk9.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] cost of incrementing the DAG sequence number X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Aug 2009 19:58:27 -0000 Hi Richard, On Aug 3, 2009, at 7:44 AM, Richard Kelsey wrote: > I would argue that seeing a new sequence number in a > parent's DIO should not reset the trickle timer. In > addition to reducing the cost of incrementing, it also > increases the utility of doing so. The sequence numbers are > more useful if they propagate slowly than if they propagate > quickly. Incrementing the sequence number reasonably often > increases nodes' ability to react to topography changes. At > the extreme, once all nodes in the DAG have the same > sequence number the sequence number is no help at all. We > shouldn't be in a hurry to get there. Being able to use the sequence number to cause more frequent RAs is a useful mechanism for network management or for other protocol-specific reasons down the line. There is also benefit to have the new sequence number propagate quickly throughout the network. While the sequence number is propagating, special care needs to be taken as to when a node should actually make the flip from the old topology to the new topology - once you flip to new, you can only use routes in the new topology and you cannot go back. Flip too early, and the node may advertise higher costs and other routing information carried in DAOs - causing additional unneeded churn in the routing structure later in time. Taking longer to flip obviously impacts the time it takes to react to topological changes. This issue is well-known with DSDV. Specifying actual values for the time delays is difficult because they depend on link-layer parameters, etc. The actual cost of sending an RA and propagating new sequence numbers will depend on the specific link-layer being used and the application requirements. I imagine some scenarios where it is completely fine to send RAs every 10s of seconds all the time (broadcasts are cheap and energy is relatively plentiful). I also imagine some scenarios where you really want to keep the RA transmission to 10s of minutes if possible (broadcasts are extremely expensive and energy is scarce). In the latter case, you'd really like to have some mechanisms for increasing the RA transmission frequency when topology changes do occur - in other words, spend some extra resources when changes occur, but otherwise spend as little as possible. When there is this tradeoff in resource consumption vs. responsiveness, then it's beneficial to utilize mechanisms that only require actions by the affected nodes - rather than mechanisms that affect all nodes within the network. This is my rationale for providing both sequence number and DAG detatching mechanisms for resolving topology changes. They each have their pros/cons - how they are used is, ideally, guided by the specific application. -- Jonathan Hui From jhui@archrock.com Mon Aug 3 13:00: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 A289E3A684C for ; Mon, 3 Aug 2009 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 Z8OUG81+ZWvX for ; Mon, 3 Aug 2009 13:00: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 5B21F3A6BFE for ; Mon, 3 Aug 2009 13:00:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2ADA8AF94B; Mon, 3 Aug 2009 13:00: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 4T3Ut4B96fni; Mon, 3 Aug 2009 13:00:13 -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 21531AF859; Mon, 3 Aug 2009 13:00:13 -0700 (PDT) Message-Id: <4E4134B2-F62F-4C42-8B94-C4C361E79292@archrock.com> From: Jonathan Hui To: Alexandru Petrescu In-Reply-To: <4A76A9E4.5060703@gmail.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: Mon, 3 Aug 2009 13:00:12 -0700 References: <001101ca11d8$102811b0$30783510$@sturek@att.net> <1223920668.6712181249044870026.JavaMail.root@mail02.pantherlink.uwm.edu> <003301ca11e0$58aa9040$09ffb0c0$@sturek@att.net> <271F493C-F591-49D6-B658-841388DAA3F6@archrock.com> <4A76A9E4.5060703@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: 'ROLL WG' Subject: Re: [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: Mon, 03 Aug 2009 20:00:26 -0000 Hi Alex, On Aug 3, 2009, at 2:12 AM, Alexandru Petrescu wrote: > Could it be that the physical topology on which RPL acted were an =20 > arbitrary graph, but the view of that topology (view maintained at =20 > each node) were a DAG? Yes. This is my view as well. > Or is it a MUST that the topology and interface directionality to be =20= > a physical DAG? This is not a MUST in my mind. -- Jonathan Hui > > Alex > > Jonathan Hui a =E9crit : >> Don correctly highlights and important reasons for the DAG that I =20 >> want to expand a bit more. >> A DAG is necessary in resource constrained environments. Using a =20 >> DAG allows us the LLN to provide basic P2P connectivity while =20 >> maintaining hard bounds on the amount of memory each LLN node can =20 >> maintain. It has been mentioned many times that a DAG does not =20 >> provide an "optimal" P2P solution. If memory is constrained such =20 >> that each LLN node is only capable of maintaining a few routes at =20 >> any time, then a DAG does provide an "optimal" P2P solution given =20 >> the state constraints. This is fundamental and a protocol should =20 >> allow for operation under such 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 =20 >> root - rather than and unstructured "flooding" of the entire DAG =20 >> with such information. While DAG construction uses broadcast RAs to =20= >> communication information, establishing routes that flow away from =20= >> the root need only rely on unicast communication. I'd like to =20 >> stress the importance of broadcast vs. unicast communication. While =20= >> both are logically one transmission, the two have very different =20 >> costs in environments where the radio is duty cycled. Depending on =20= >> the duty-cycled link protocol, broadcast can by orders of magnitude =20= >> more expensive in channel utilization, energy consumption, and =20 >> communication delay. Again, this is fundamental and a protocol =20 >> should allow for operation under severe channel capacity and energy =20= >> constraints. >> These fundamental limits require the use a hierarchical structure - =20= >> a DAG. A common misconception is that we chose a DAG because of the =20= >> MP2P 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 =20= >> you do have MP2P and P2MP flows. >> Of course, we have mentioned that a DAG can be used for avoiding =20 >> and detecting cycles, but that is not the fundamental reason for =20 >> using the DAG. The need for attending to loops and the count-to-=20 >> infinity problem is an important side effect of using the DV class =20= >> of protocols. >> Again, people need to be more concrete when saying "optimal", =20 >> because such a notion is not well defined without clarity in the =20 >> problem's constraints and goals. What people seem to mean when they =20= >> say they want more "optimal" mechanisms is really to be able to =20 >> make use of more resources when they are available. Specifically, =20 >> if a node can maintain more routes and communicate more routing =20 >> information, it should be able to reduce overall routing stretch. =20 >> That I strongly 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. >> --=20 >> 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 =20 >>> seems to be little requirement for any state information in RPL to =20= >>> get 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 =20 >>> be retained and those that want P2P would be provided that =20 >>> capability (understanding they may be required to store state =20 >>> information in their devices to use P2P if that is the solution we =20= >>> 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 =20 >>> first one that doesn't fall apart in scenarios like: many to =20 >>> one (MP2P), many devices in the network (more than a couple =20 >>> 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 =20 >>> RPL and again the alternate solutions. Also, I will wait for DT =20 >>> solution for good P2P routing in RPL, but it seems to me that it =20 >>> has to 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 =20 >>> with DAGs, which is a loop prevention mechanism as I understand =20 >>> it. Putting a specific loop prevention mechanism, a non-essential =20= >>> requirement, in the _foundation_ does not sound like a good idea =20 >>> 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 =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 =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) =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 =20 >>> MP2P and/or P2P routing using different mechanisms to deal with =20 >>> 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 =20 >>> Central >>> Subject: Re: [Roll] Moving forward with the protocol work >>> >>> >>> >>> Zach, >>> >>> When the design team was formed it stated its plan was to develop =20= >>> a 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 =20 >>> path preferences, 2) OCP to advertise path strategy and 3) trickle =20= >>> to cleanly vary periodic requirements. Then RPL-1 could be then =20 >>> enhancements for MP2P applications and would include the DAG. =20 >>> This would allow us to define a different extension, RPL-2, for =20 >>> 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. =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. >>> >>> 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 =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 =20 >>> 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 =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 =20 >>> 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 >>> >>> _______________________________________________ >>> 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 root@core3.amsl.com Mon Aug 3 16:00:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CC5643A6DA6; Mon, 3 Aug 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090803230001.CC5643A6DA6@core3.amsl.com> Date: Mon, 3 Aug 2009 16:00:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-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, 03 Aug 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: Routing Protocol for Low Power and Lossy Networks Author(s) : T. Winter, R. Team Filename : draft-ietf-roll-rpl-00.txt Pages : 69 Date : 2009-08-03 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-ietf-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-03155105.I-D@ietf.org> --NextPart-- From wintert@acm.org Mon Aug 3 16:16: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 DAC843A6D95 for ; Mon, 3 Aug 2009 16:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=0.541, 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 WWNEJjPLCX6A for ; Mon, 3 Aug 2009 16:16:09 -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 0344F3A6AAD for ; Mon, 3 Aug 2009 16:16:08 -0700 (PDT) Received: (qmail 99249 invoked from network); 3 Aug 2009 23:16: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; 03 Aug 2009 16:16:06 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 9iLz.v0VM1mBKwRZRIulPc1biz8JUYIPGQaelvBjpt6Z7R2jlOyS4C34yKnn8RYxh.DYMEDnejfhlrZYeXCBTgnUB644PW7SxPHcvAFeSavof3HAndcERy7ZuK.OPRpCh30XSk_2v9zZKaUpf1xWKGaatwj0gA2m.dOphSx7pwoYELPm1fK8qMPCVm98GICyhXw2EWqkwPMvrb11nk4vzPl2u62GVED4f4f3u0.Brg0QdJ4e5Mj2vuSd2_bib8zlsL.uGYoQZsIW0C.r5sYf5U45ndOyvizX1OohntuLujSX4L4pkmgcv4ajzarOSPXzxnx94U3o X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A776FAE.7090203@acm.org> Date: Mon, 03 Aug 2009 19:15:58 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: roll@ietf.org References: <20090803230001.CC5643A6DA6@core3.amsl.com> In-Reply-To: <20090803230001.CC5643A6DA6@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-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, 03 Aug 2009 23:16:09 -0000 WG, We have re-submitted draft-dt-roll-rpl-01.txt as draft-ietf-roll-rpl-00.txt. No changes have been made other than title and date. Thanks, -DT Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: Routing Protocol for Low Power and Lossy Networks > Author(s) : T. Winter, R. Team > Filename : draft-ietf-roll-rpl-00.txt > Pages : 69 > Date : 2009-08-03 > > 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-ietf-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=459bc194d=mukul@uwm.edu Mon Aug 3 16:50: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 237B83A6DDA; Mon, 3 Aug 2009 16:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 aXCAY9VH171E; Mon, 3 Aug 2009 16:50:20 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 3B5AB3A6864; Mon, 3 Aug 2009 16:50:20 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 03 Aug 2009 18:50:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 70A7E2C382C6; Mon, 3 Aug 2009 18:50:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-a1nPpvvNn; Mon, 3 Aug 2009 18:50:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id BAEB12C382C2; Mon, 3 Aug 2009 18:50:21 -0500 (CDT) Date: Mon, 3 Aug 2009 18:50:20 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <854211809.381171249343420902.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1416617912.380371249342961682.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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Mon, 03 Aug 2009 23:50:42 -0000 Hi Jonathan Again a very well-crafted explanation. My compliments. > 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. So, I conjure the image of a network of RFDs (borrowing 802.15.4 terminolog= y). An RFD, rather than having an FFD in its radio range, has the nearest F= FD several hops away. Now, the FFD can serve as the DAG root and the RFDs a= round it can join this DAG. This allows the RFDs to reach the FFD which can= do the further routing. For these RFDs, DAG is indeed a good way to reach = the FFD. But why _force_ the FFDs to also become part of the DAGs to some o= ther roots when they can participate in more stateful routing. If the intent is that RPL provides default routing mechanism for resource c= ontrained nodes, I support RPL. But, for not-so-resource-constrained nodes,= there is no critical reason to participate in DAGs. =20 >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. Jonathan, don't you think that this argument again applies to extreme resou= rce-constrained devices only? For other devices, that can maintain much mor= e state and perhaps have abundant battery power as well, isn't it that the = broadcast of infrequent RAs is much more desirable than spread along possib= ly broken DAG? Again it seems to me that having local DAGs of (may be a few dozen) RFDs ar= ound an FFD makes sense for the reasons you described. But requiring thousa= nds of FFDs as well as RFDs to arrange themselves in a few global DAGs seem= s inefficient. I guess one needs to analyze mathematically performance under DAGs as they = become deeper. Performance parameters being: 1. the stretch introduced in P2P routes due to the need to travel along the= DAG, especially when nodes at higher rank (lower depth) have memory constr= aints. 2. conversely, the amount of state nodes at higher ranks need to maintain t= o support optimal (within the DAG) P2P and P2MP routing. (note that if the = closest DAG ancestor of a source and destination does not maintain state ab= out the destination the packets will have to travel longer than necessary) 3. the latency to perform DAG operations, such as re-joining a DAG at a hig= her depth. > 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. Great. Again the question is: why force global DAGs? I think that you have = made strong arguments in favor of local DAGs. I still am not convinced abou= t the need to have global DAGs. I think resourceful nodes should be allowed= to participate in more stateful routing that does not involve DAGs. Thanks Mukul =20 =20 >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-bounce= s@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 =09Mukul Goyal > > cc =09ROLL WG > > Subject =09Re: [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. > > 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 =20 > 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 > _______________________________________________ > 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 Mon Aug 3 17:03: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 6487F28C1FA; Mon, 3 Aug 2009 17:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 StqwYLtwthby; Mon, 3 Aug 2009 17:03:01 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B56A228C0FB; Mon, 3 Aug 2009 17:03:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 54B4DAF896; Mon, 3 Aug 2009 17:03:04 -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 DQCBzUBNJHu7; Mon, 3 Aug 2009 17:03:00 -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 E7BB6AF861; Mon, 3 Aug 2009 17:02:59 -0700 (PDT) Message-Id: <1717B041-B023-4AAC-8FE7-C5AF1400655D@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <854211809.381171249343420902.JavaMail.root@mail02.pantherlink.uwm.edu> 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: Mon, 3 Aug 2009 17:02:58 -0700 References: <854211809.381171249343420902.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Tue, 04 Aug 2009 00:03:03 -0000 Hi Mukul, We don't force the use of RPL globally. If we did, we'd force the =20 entire Internet to run RPL - that's just not how successful IP =20 networks operate. If you want, you can always run multiple routing =20 protocols and redistribute routes across routing domains if you need =20 to. That's common place with IP networks today. In fact, I'd expect that the DAG root, in some configurations, will be =20= a heavyweight device (linux, mains-powered, ethernet on the other =20 side). While RPL may be used to communicate with LLN nodes, RPL does =20 not necessarily have to be used to provide connectivity to other =20 networks. That's fairly common with edge routers today. -- Jonathan Hui On Aug 3, 2009, at 4:50 PM, Mukul Goyal wrote: > Hi Jonathan > > Again a very well-crafted explanation. My compliments. > >> A DAG is necessary in resource constrained environments. Using a DAG > allows us the LLN to provide basic P2P connectivity while maintaining > hard bounds on the amount of memory each LLN node can maintain. It has > been mentioned many times that a DAG does not provide an "optimal" P2P > solution. If memory is constrained such that each LLN node is only > capable of maintaining a few routes at any time, then a DAG does > provide an "optimal" P2P solution given the state constraints. This is > fundamental and a protocol should allow for operation under such > memory constraints. > > So, I conjure the image of a network of RFDs (borrowing 802.15.4 =20 > terminology). An RFD, rather than having an FFD in its radio range, =20= > has the nearest FFD several hops away. Now, the FFD can serve as the =20= > DAG root and the RFDs around it can join this DAG. This allows the =20 > RFDs to reach the FFD which can do the further routing. For these =20 > RFDs, DAG is indeed a good way to reach the FFD. But why _force_ the =20= > FFDs to also become part of the DAGs to some other roots when they =20 > can participate in more stateful routing. > > If the intent is that RPL provides default routing mechanism for =20 > resource contrained nodes, I support RPL. But, for not-so-resource-=20 > constrained nodes, there is no critical reason to participate in DAGs. > >> Using a DAG allows us to guide and constrain the communication of > routing information as well. It ensures that state maintenance and > exchange only occurs on a small subgraph of nodes toward the DAG root > - rather than and unstructured "flooding" of the entire DAG with such > information. While DAG construction uses broadcast RAs to > communication information, establishing routes that flow away from the > root need only rely on unicast communication. I'd like to stress the > importance of broadcast vs. unicast communication. While both are > logically one transmission, the two have very different costs in > environments where the radio is duty cycled. Depending on the duty- > cycled link protocol, broadcast can by orders of magnitude more > expensive in channel utilization, energy consumption, and > communication delay. Again, this is fundamental and a protocol should > allow for operation under severe channel capacity and energy > constraints. > > Jonathan, don't you think that this argument again applies to =20 > extreme resource-constrained devices only? For other devices, that =20 > can maintain much more state and perhaps have abundant battery power =20= > as well, isn't it that the broadcast of infrequent RAs is much more =20= > desirable than spread along possibly broken DAG? > > Again it seems to me that having local DAGs of (may be a few dozen) =20= > RFDs around an FFD makes sense for the reasons you described. But =20 > requiring thousands of FFDs as well as RFDs to arrange themselves in =20= > a few global DAGs seems inefficient. > > I guess one needs to analyze mathematically performance under DAGs =20 > as they become deeper. Performance parameters being: > > 1. the stretch introduced in P2P routes due to the need to travel =20 > along the DAG, especially when nodes at higher rank (lower depth) =20 > have memory constraints. > 2. conversely, the amount of state nodes at higher ranks need to =20 > maintain to support optimal (within the DAG) P2P and P2MP routing. =20 > (note that if the closest DAG ancestor of a source and destination =20 > does not maintain state about the destination the packets will have =20= > to travel longer than necessary) > 3. the latency to perform DAG operations, such as re-joining a DAG =20 > at a higher depth. > >> Again, people need to be more concrete when saying "optimal", because > such a notion is not well defined without clarity in the problem's > constraints and goals. What people seem to mean when they say they > want more "optimal" mechanisms is really to be able to make use of > more resources when they are available. Specifically, if a node can > maintain more routes and communicate more routing information, it > should be able to reduce overall routing stretch. That I strongly > agree with. > > Great. Again the question is: why force global DAGs? I think that =20 > you have made strong arguments in favor of local DAGs. I still am =20 > not convinced about the need to have global DAGs. I think =20 > resourceful nodes should be allowed to participate in more stateful =20= > routing that does not involve DAGs. > > Thanks > Mukul > > >> But the protocol needs to have a baseline to allow operation with > severe resource constraints and for that reason, I'd argue that the > 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 >> 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), =20 >> 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 >> (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 =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 >>>> - 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 =20= >> 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 =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 >> 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 d.sturek@att.net Mon Aug 3 17:29: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 7E0013A68DA for ; Mon, 3 Aug 2009 17:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 mVt8SoMCJM3D for ; Mon, 3 Aug 2009 17:29:33 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 27BFF28C252 for ; Mon, 3 Aug 2009 17:29:33 -0700 (PDT) Received: (qmail 23292 invoked from network); 4 Aug 2009 00:22:53 -0000 Received: from unknown (HELO Studio) (d.sturek@69.224.126.38 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2009 00:22:52 -0000 X-YMail-OSG: peVUGloVM1nteRdxM3fE2JkyNe4noNx8DxSoIseJFvcaJdAW2n2AjtTn_FaWmY.bhJLKz3izHz5.t0ZtTTViZYiCzDubByDoA8FF01jeS59UwtoYVa1ULnd.V.ljq.wlrvqFMXQIeyRpC_RVap3y1kdBox_7oOovXk2Qlbb6oDvoY9zdCcNfAsHcUXqPoedhpkvA5xdq4ICmIA2upjhVbnacmTN6lp1EEWQhcLCWBZh1bVjznphjYEfSfEpl2prziPPHtMUnmN_a_eXYzz4P3ggwSLXWGJQkntr7_mRt3RvQnY2PjEvEZCeIlTanTQRC X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mukul Goyal'" , "'Jonathan Hui'" References: <1416617912.380371249342961682.JavaMail.root@mail02.pantherlink.uwm.edu> <854211809.381171249343420902.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <854211809.381171249343420902.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 3 Aug 2009 17:22:49 -0700 Message-ID: <008001ca1499$b3997190$1acc54b0$@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: AcoUlSqMqwo/fa2OQNmBOgrW+67n5AAAbDWw Content-Language: en-us Cc: 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [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 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, 04 Aug 2009 00:29:33 -0000 Hi Mukul, I would propose the opposite conjecture as well: 1) Why should devices that predominantly communicate multi-point to = point (many examples in LLNs where there is a central concentrator = solution) need to try to employ a P2P solution for this communication? = The MANET distance vector routing solutions have historically not = handled this communication in a way that avoids non-scalable resource = requirements on devices in the routing path. 2) Similarly, when responses are needed to MP2P messaging, the reverse = path has proven to be problematic as well using MANET distance vector = solutions. I think DAGs handle both the MP2P and P2MP in a scalable way. By = scalable, I believe a wide range of network sizes are supported without = scaling the resources in these devices according to the size of the = network and sizing all routing devices in the network for the worst = case. The assumption below that we are designing for resource constrained RFDs = with DAGs and not taking advantage of added processing resources in FFDs = is really not true. The real problem is that the FFDs need to be = resourced in a manner tied to the worst case routing requirements for a = network with assumed device membership size. =20 Don =20 -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu]=20 Sent: Monday, August 03, 2009 4:50 PM To: Jonathan Hui Cc: ROLL WG; roll-bounces@ietf.org; d sturek Subject: Re: Why a DAG? (was Re: [Roll] Moving forward with the protocol = work) Hi Jonathan Again a very well-crafted explanation. My compliments. > 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. So, I conjure the image of a network of RFDs (borrowing 802.15.4 = terminology). An RFD, rather than having an FFD in its radio range, has = the nearest FFD several hops away. Now, the FFD can serve as the DAG = root and the RFDs around it can join this DAG. This allows the RFDs to = reach the FFD which can do the further routing. For these RFDs, DAG is = indeed a good way to reach the FFD. But why _force_ the FFDs to also = become part of the DAGs to some other roots when they can participate in = more stateful routing. If the intent is that RPL provides default routing mechanism for = resource contrained nodes, I support RPL. But, for = not-so-resource-constrained nodes, there is no critical reason to = participate in DAGs. =20 >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. Jonathan, don't you think that this argument again applies to extreme = resource-constrained devices only? For other devices, that can maintain = much more state and perhaps have abundant battery power as well, isn't = it that the broadcast of infrequent RAs is much more desirable than = spread along possibly broken DAG? Again it seems to me that having local DAGs of (may be a few dozen) RFDs = around an FFD makes sense for the reasons you described. But requiring = thousands of FFDs as well as RFDs to arrange themselves in a few global = DAGs seems inefficient. I guess one needs to analyze mathematically performance under DAGs as = they become deeper. Performance parameters being: 1. the stretch introduced in P2P routes due to the need to travel along = the DAG, especially when nodes at higher rank (lower depth) have memory = constraints. 2. conversely, the amount of state nodes at higher ranks need to = maintain to support optimal (within the DAG) P2P and P2MP routing. (note = that if the closest DAG ancestor of a source and destination does not = maintain state about the destination the packets will have to travel = longer than necessary) 3. the latency to perform DAG operations, such as re-joining a DAG at a = higher depth. > Again, people need to be more concrete when saying "optimal", because = 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. Great. Again the question is: why force global DAGs? I think that you = have made strong arguments in favor of local DAGs. I still am not = convinced about the need to have global DAGs. I think resourceful nodes = should be allowed to participate in more stateful routing that does not = involve DAGs. Thanks Mukul =20 =20 >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. > > 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 =20 > 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 > _______________________________________________ > 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 prvs=4607f775e=mukul@uwm.edu Mon Aug 3 17:48: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 DAF213A6BFE; Mon, 3 Aug 2009 17:48:15 -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 ZkXNCBqTafZT; Mon, 3 Aug 2009 17:48:14 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id B73F13A6882; Mon, 3 Aug 2009 17:48:13 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta2.uwm.edu with ESMTP; 03 Aug 2009 19:48:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C2D5E2C382EA; Mon, 3 Aug 2009 19:48:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdmHY2b7omIV; Mon, 3 Aug 2009 19:48:15 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F1EA12C382ED; Mon, 3 Aug 2009 19:48:14 -0500 (CDT) Date: Mon, 3 Aug 2009 19:48:14 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1017994834.389021249346894894.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1717B041-B023-4AAC-8FE7-C5AF1400655D@archrock.com> 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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Tue, 04 Aug 2009 00:49:48 -0000 Hi Jonathan By globally I meant globally within the LLN. LLN will consist of resourcefu= l and resource-constrained devices. I think local DAGs connecting some reso= urce-constrained devices to one or more resourceful devices makes sense. Bu= t requiring resourceful LLN nodes to also use RPL/DAGs for communication wi= th each other seems unnecessary (to me so far). Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "ROLL WG" , roll-bounces@ietf.org, "d sturek" Sent: Monday, August 3, 2009 7:02:58 PM GMT -06:00 US/Canada Central Subject: Re: Why a DAG? (was Re: [Roll] Moving forward with the protocol wo= rk) Hi Mukul, We don't force the use of RPL globally. If we did, we'd force the =20 entire Internet to run RPL - that's just not how successful IP =20 networks operate. If you want, you can always run multiple routing =20 protocols and redistribute routes across routing domains if you need =20 to. That's common place with IP networks today. In fact, I'd expect that the DAG root, in some configurations, will be =20 a heavyweight device (linux, mains-powered, ethernet on the other =20 side). While RPL may be used to communicate with LLN nodes, RPL does =20 not necessarily have to be used to provide connectivity to other =20 networks. That's fairly common with edge routers today. -- Jonathan Hui On Aug 3, 2009, at 4:50 PM, Mukul Goyal wrote: > Hi Jonathan > > Again a very well-crafted explanation. My compliments. > >> A DAG is necessary in resource constrained environments. Using a DAG > allows us the LLN to provide basic P2P connectivity while maintaining > hard bounds on the amount of memory each LLN node can maintain. It has > been mentioned many times that a DAG does not provide an "optimal" P2P > solution. If memory is constrained such that each LLN node is only > capable of maintaining a few routes at any time, then a DAG does > provide an "optimal" P2P solution given the state constraints. This is > fundamental and a protocol should allow for operation under such > memory constraints. > > So, I conjure the image of a network of RFDs (borrowing 802.15.4 =20 > terminology). An RFD, rather than having an FFD in its radio range, =20 > has the nearest FFD several hops away. Now, the FFD can serve as the =20 > DAG root and the RFDs around it can join this DAG. This allows the =20 > RFDs to reach the FFD which can do the further routing. For these =20 > RFDs, DAG is indeed a good way to reach the FFD. But why _force_ the =20 > FFDs to also become part of the DAGs to some other roots when they =20 > can participate in more stateful routing. > > If the intent is that RPL provides default routing mechanism for =20 > resource contrained nodes, I support RPL. But, for not-so-resource-=20 > constrained nodes, there is no critical reason to participate in DAGs. > >> Using a DAG allows us to guide and constrain the communication of > routing information as well. It ensures that state maintenance and > exchange only occurs on a small subgraph of nodes toward the DAG root > - rather than and unstructured "flooding" of the entire DAG with such > information. While DAG construction uses broadcast RAs to > communication information, establishing routes that flow away from the > root need only rely on unicast communication. I'd like to stress the > importance of broadcast vs. unicast communication. While both are > logically one transmission, the two have very different costs in > environments where the radio is duty cycled. Depending on the duty- > cycled link protocol, broadcast can by orders of magnitude more > expensive in channel utilization, energy consumption, and > communication delay. Again, this is fundamental and a protocol should > allow for operation under severe channel capacity and energy > constraints. > > Jonathan, don't you think that this argument again applies to =20 > extreme resource-constrained devices only? For other devices, that =20 > can maintain much more state and perhaps have abundant battery power =20 > as well, isn't it that the broadcast of infrequent RAs is much more =20 > desirable than spread along possibly broken DAG? > > Again it seems to me that having local DAGs of (may be a few dozen) =20 > RFDs around an FFD makes sense for the reasons you described. But =20 > requiring thousands of FFDs as well as RFDs to arrange themselves in =20 > a few global DAGs seems inefficient. > > I guess one needs to analyze mathematically performance under DAGs =20 > as they become deeper. Performance parameters being: > > 1. the stretch introduced in P2P routes due to the need to travel =20 > along the DAG, especially when nodes at higher rank (lower depth) =20 > have memory constraints. > 2. conversely, the amount of state nodes at higher ranks need to =20 > maintain to support optimal (within the DAG) P2P and P2MP routing. =20 > (note that if the closest DAG ancestor of a source and destination =20 > does not maintain state about the destination the packets will have =20 > to travel longer than necessary) > 3. the latency to perform DAG operations, such as re-joining a DAG =20 > at a higher depth. > >> Again, people need to be more concrete when saying "optimal", because > such a notion is not well defined without clarity in the problem's > constraints and goals. What people seem to mean when they say they > want more "optimal" mechanisms is really to be able to make use of > more resources when they are available. Specifically, if a node can > maintain more routes and communicate more routing information, it > should be able to reduce overall routing stretch. That I strongly > agree with. > > Great. Again the question is: why force global DAGs? I think that =20 > you have made strong arguments in favor of local DAGs. I still am =20 > not convinced about the need to have global DAGs. I think =20 > resourceful nodes should be allowed to participate in more stateful =20 > routing that does not involve DAGs. > > Thanks > Mukul > > >> But the protocol needs to have a baseline to allow operation with > severe resource constraints and for that reason, I'd argue that the > 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 >> 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), =20 >> 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 >> (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-bounc= es@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 =20 >> To Mukul Goyal >> >> cc ROLL WG >> >> Subject Re: [Roll] Moving forward with the protocol work >> =20 >> >> >> >> 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 =20 >> 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 =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. >> >> 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 =20 >> should >> 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 >> _______________________________________________ >> 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 Mon Aug 3 17:50: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 4A7983A6973 for ; Mon, 3 Aug 2009 17:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.361, 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 A6HoIR9cZ+bk for ; Mon, 3 Aug 2009 17:50:54 -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 E409F3A6ACD for ; Mon, 3 Aug 2009 17:50:53 -0700 (PDT) Received: (qmail 22055 invoked from network); 4 Aug 2009 00:50:50 -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; 03 Aug 2009 17:50:50 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: B8UKyxgVM1kai9ezvDjS.CBfAPeYT1hyKyt1q3sP7fd6lWWjjFAwoTm3JeDJBxcnVlKgtpJw3a81FpdtY.sNr5PXaAqzXq4NNprB00N7TQBekVeu2.7C9L_I7n42zlKmTa3Ze43Eusegoh7NbEyMnsKPZyvxVZ60Hoe2PDYFf6PJAoovtMajYBixreWEQskVJlj_bCDEA0PMbZxp.RzGkkMCDfLNUjvRu.y_jsn.zuoBYFmKJfvtbNQ9yQrtqo5BgEJZWYkJdMz2SbbUt6QydZslqmM5HJNmA0hbLc61N2SOIy8.YLbnF9B0CEc5cGdMmHtY44PYbW5.Sh9mhyb1ZHxjUtXfs_UPU6D5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7785E9.6070901@acm.org> Date: Mon, 03 Aug 2009 20:50:49 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 00:50:55 -0000 Hi Jerry, I have a few supplemental points to your questions inline: Jerald.P.Martocci@jci.com wrote: > > I would like the following questions answered on subsequent revisions of > the draft: > > > a) What is the roll of 'siblings'? They are in the current RPL > document, yet seem to be demoted from parental links. As I read the > draft, one cannot use a sibling link unless the parental links are > exhausted. The nodes don't seem to explicitly define sibling links. > > b) What is the plan on communication to devices within direct radio > range? As I read the draft unless a node is made a 'parent', or > possibly a 'sibling' it cannot be communicated with. However, Anand > mentions in his memo that at the Stockholm meeting there was discussion > on directly connected devices. Unfortunately, I couldn't attend the > meeting. > > c) What are the approximate timer values for RPL? The document gives no > indication as to these timers, hence I can't calculate how long a > floating DAG may be dislodged from its network. In a real-time facility > management control system, all nodes are monitored for falling off-line. > If the convergence time is too long (more than 1 minute), the devices > will be flagged off-line and reported to the customer. In general the suggestion is that parameterization of RPL should occur in application-specific applicability statements. So the RPL specification might not end up including specific numbers, but a Building Applicability Statement may give an implementer further guidance in how to setup timers, etc. in order that RPL can be operated in a manner to meet the requirements of that application domain. The applicability statements can help to bridge the gap between the protocol specification and the implementation. Also, in the current proposal some precedence is given to communicate key parameters (e.g. DAGDelay) in the DIO- so some flexibility could be given even within an implementation if the WG believes it to be desirable. > > d) What is the plan for security? RPL doesn't currently weigh in on the > topic. Are security policies optional or mandatory? Must the policy be > consistent with the rest of the enterprise's IT security on other parts > of the network? Will security require nodes to keep state info as Rene > suggests? > > e) What requirements from the 4 requirement drafts are being considered? > When the DT first was engaged, it said it would publish the list of > requirements as an appendix and note if the current draft supported > which requirement. This hasn't occurred and may be adding to the email > angst. As a requirement's author, I would rather know up front that > some of my MUST requirements are not being considered. All requirements. Here is the list that the DT worked with as extracted from the drafts: http://www.ietf.org/mail-archive/web/roll/current/msg01291.html The intention is not to re-declare the requirements in an appendix of RPL- the requirements drafts give a lot better background/context in presenting the requirements. Instead, the suggestion is that at the end of this process, if we (WG) find that any requirement is lacking in the final version of the protocol, we should then clearly document such and why in the appendix. As the WG takes up the process of further developing RPL I do hope that you, other requirements authors, and any other interested parties do make the WG aware if a requirement is in jeopardy of not being satisfied (and helping to work out the alternatives ;) ). > > f) What is the expected frame overhead size based on all the above > criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, > UDP/TCP. We need to add in the encryption and authentication overhead; > and now maybe source routing. I realize ROLL is trying to be agnostic > to L2, however in practice 802.15.4 is the only game in town. It only > carries a 128 by packet size. The DT/WG should at least give an > accounting of the expected frame overhead so we can determine what L2s > are feasible for the protocol. > > g) What routing data must persist a warmstart/coldstart? The overhead > to establish a DAG is significant. We should consider what data might > be able to transcend a network reboot to minimize communication startup > bottlenecks. > > As Pascal has noted in previous emails, some of these issues may be > considered out-of bounds for the protocol and should be an > implementation decision. That may indeed be true, but RPL should state > its case explicitly. In the Building Market, it is multi-disciplined > (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority > prescribes operation, the chances of LLN node-to-node interoperability > are moot. > > Thanks, > > Jerry > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 08/03/2009 02:27 AM > > > To > ROLL WG > cc > > Subject > [Roll] Next items ... > > > > > > > > > Dear all, > > As a reminder, RPL being a WG ID, it now "belongs" to the WG. > > Several working items have been listed but before starting to address > all open items in some unstructured way, I would like to propose the > following. > > It clearly appeared that there were some misunderstandings on how RPL > works. The DT did an outstanding job but I also understand that > several areas must be clarified. So before changing RPL, adding new > mechanisms (e.g. to optimize P2P, support source routing, loop > detection, ... ), I would first want you to list your questions on the > mailing list on each area for which you would like to get > clarification. This will help make sure that everybody is indeed on > the same page. > > From there, we will continue to quickly move forward, I will track > the list of open items via the issue tracker. > > Many Thanks. > > JP. > _______________________________________________ > 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 Mon Aug 3 19:01: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 337043A677E; Mon, 3 Aug 2009 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 EvHzDDx9bL4t; Mon, 3 Aug 2009 19:01:32 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 57CDF3A6B75; Mon, 3 Aug 2009 19:01:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CFA8BAF879; Mon, 3 Aug 2009 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nts8BDms3vpx; Mon, 3 Aug 2009 19:01:31 -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 7E6B6AF896; Mon, 3 Aug 2009 19:01:30 -0700 (PDT) Message-Id: <7E3F288D-1A61-433C-B562-5ADC031568E2@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1017994834.389021249346894894.JavaMail.root@mail02.pantherlink.uwm.edu> 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: Mon, 3 Aug 2009 19:01:29 -0700 References: <1017994834.389021249346894894.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Tue, 04 Aug 2009 02:01:34 -0000 Hi Mukul, I understood what you were trying to get at. My basic point was that =20 RPL, like any other routing protocol, does not preclude you from using =20= additional routing protocols to provide connectivity between networks. =20= Now there are two cases: 1) More privileged nodes that can communicate with each other through =20= a network other than the LLN network. In this case, run whatever routing protocol that best fits your needs =20= outside the LLN network - redistribute routes across the LLN boundaries. 2) More privileged nodes in memory or energy that can only communicate =20= with each other through the LLN network. In this case, what you're really trying to get at is some style of =20 landmark routing. But the very fact that these more privileged nodes =20 must communicate through the LLN places constraints on how they can =20 communicate with each other. Just because some nodes are privileged =20 doesn't mean they can freely communicate without worrying about =20 resource constraints within the network. Running some RIP-like or DSDV-=20= like protocol is not much different than building DAGs rooted at each =20= of these more privileged nodes. Two feasible solutions are (a) build =20 completely overlapping DAGs rooted at each landmark or (b) utilize a =20 "primary" DAG to help guide and constrain the construction of routes =20 between "landmarks". For (a), you reduce the amount of state each LLN =20= node maintains by pushing state to the landmarks, but it is still =20 dependent on the number of landmarks you have. For (b), that is just =20 an extension of "routing-along-a-DAG". One nice property of routing =20 along a DAG is that you can place hard bounds on the state =20 requirements of LLN nodes. Note that any DV-style protocol is equivalent to building DAGs. RIP =20 builds a DAG rooted at every node within the network. DSDV builds a =20 DAG rooted at each destination in the network. Every DAG incurs some =20 amount of state and control overhead. RPL proposes a solution that =20 requires building only a single DAG and mechanisms to avoid and detect =20= loops that are well-known problems with DV-style protocols. -- Jonathan Hui On Aug 3, 2009, at 5:48 PM, Mukul Goyal wrote: > Hi Jonathan > > By globally I meant globally within the LLN. LLN will consist of =20 > resourceful and resource-constrained devices. I think local DAGs =20 > connecting some resource-constrained devices to one or more =20 > resourceful devices makes sense. But requiring resourceful LLN nodes =20= > to also use RPL/DAGs for communication with each other seems =20 > unnecessary (to me so far). > > Thanks > Mukul > > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "ROLL WG" , roll-bounces@ietf.org, "d sturek" = > > Sent: Monday, August 3, 2009 7:02:58 PM GMT -06:00 US/Canada Central > Subject: Re: Why a DAG? (was Re: [Roll] Moving forward with the =20 > protocol work) > > > Hi Mukul, > > We don't force the use of RPL globally. If we did, we'd force the > entire Internet to run RPL - that's just not how successful IP > networks operate. If you want, you can always run multiple routing > protocols and redistribute routes across routing domains if you need > to. That's common place with IP networks today. > > In fact, I'd expect that the DAG root, in some configurations, will be > a heavyweight device (linux, mains-powered, ethernet on the other > side). While RPL may be used to communicate with LLN nodes, RPL does > not necessarily have to be used to provide connectivity to other > networks. That's fairly common with edge routers today. > > -- > Jonathan Hui > > On Aug 3, 2009, at 4:50 PM, Mukul Goyal wrote: > >> Hi Jonathan >> >> Again a very well-crafted explanation. My compliments. >> >>> A DAG is necessary in resource constrained environments. Using a DAG >> allows us the LLN to provide basic P2P connectivity while maintaining >> hard bounds on the amount of memory each LLN node can maintain. It =20= >> has >> been mentioned many times that a DAG does not provide an "optimal" =20= >> P2P >> solution. If memory is constrained such that each LLN node is only >> capable of maintaining a few routes at any time, then a DAG does >> provide an "optimal" P2P solution given the state constraints. This =20= >> is >> fundamental and a protocol should allow for operation under such >> memory constraints. >> >> So, I conjure the image of a network of RFDs (borrowing 802.15.4 >> terminology). An RFD, rather than having an FFD in its radio range, >> has the nearest FFD several hops away. Now, the FFD can serve as the >> DAG root and the RFDs around it can join this DAG. This allows the >> RFDs to reach the FFD which can do the further routing. For these >> RFDs, DAG is indeed a good way to reach the FFD. But why _force_ the >> FFDs to also become part of the DAGs to some other roots when they >> can participate in more stateful routing. >> >> If the intent is that RPL provides default routing mechanism for >> resource contrained nodes, I support RPL. But, for not-so-resource- >> constrained nodes, there is no critical reason to participate in =20 >> DAGs. >> >>> Using a DAG allows us to guide and constrain the communication of >> routing information as well. It ensures that state maintenance and >> exchange only occurs on a small subgraph of nodes toward the DAG root >> - rather than and unstructured "flooding" of the entire DAG with such >> information. While DAG construction uses broadcast RAs to >> communication information, establishing routes that flow away from =20= >> the >> root need only rely on unicast communication. I'd like to stress the >> importance of broadcast vs. unicast communication. While both are >> logically one transmission, the two have very different costs in >> environments where the radio is duty cycled. Depending on the duty- >> cycled link protocol, broadcast can by orders of magnitude more >> expensive in channel utilization, energy consumption, and >> communication delay. Again, this is fundamental and a protocol should >> allow for operation under severe channel capacity and energy >> constraints. >> >> Jonathan, don't you think that this argument again applies to >> extreme resource-constrained devices only? For other devices, that >> can maintain much more state and perhaps have abundant battery power >> as well, isn't it that the broadcast of infrequent RAs is much more >> desirable than spread along possibly broken DAG? >> >> Again it seems to me that having local DAGs of (may be a few dozen) >> RFDs around an FFD makes sense for the reasons you described. But >> requiring thousands of FFDs as well as RFDs to arrange themselves in >> a few global DAGs seems inefficient. >> >> I guess one needs to analyze mathematically performance under DAGs >> as they become deeper. Performance parameters being: >> >> 1. the stretch introduced in P2P routes due to the need to travel >> along the DAG, especially when nodes at higher rank (lower depth) >> have memory constraints. >> 2. conversely, the amount of state nodes at higher ranks need to >> maintain to support optimal (within the DAG) P2P and P2MP routing. >> (note that if the closest DAG ancestor of a source and destination >> does not maintain state about the destination the packets will have >> to travel longer than necessary) >> 3. the latency to perform DAG operations, such as re-joining a DAG >> at a higher depth. >> >>> Again, people need to be more concrete when saying "optimal", =20 >>> because >> such a notion is not well defined without clarity in the problem's >> constraints and goals. What people seem to mean when they say they >> want more "optimal" mechanisms is really to be able to make use of >> more resources when they are available. Specifically, if a node can >> maintain more routes and communicate more routing information, it >> should be able to reduce overall routing stretch. That I strongly >> agree with. >> >> Great. Again the question is: why force global DAGs? I think that >> you have made strong arguments in favor of local DAGs. I still am >> not convinced about the need to have global DAGs. I think >> resourceful nodes should be allowed to participate in more stateful >> routing that does not involve DAGs. >> >> Thanks >> Mukul >> >> >>> But the protocol needs to have a baseline to allow operation with >> severe resource constraints and for that reason, I'd argue that the >> 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 >>> 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] >>> 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 >>> >>> ----- 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 =20 >>> 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. >>> >>> =46rom the industry point of view we need a single solution, which >>> fulfills application requirements sufficiently and thus can be =20 >>> 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 >>> >>> --=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 jabeille@cisco.com Tue Aug 4 00:25: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 DA4323A6AFA for ; Tue, 4 Aug 2009 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.869 X-Spam-Level: X-Spam-Status: No, score=-7.869 tagged_above=-999 required=5 tests=[AWL=-1.270, 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 wl90XjrXYR6a for ; Tue, 4 Aug 2009 00:25:25 -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 D376D3A6A45 for ; Tue, 4 Aug 2009 00:25:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN5/d0qrR7O6/2dsb2JhbAC8HIgpjz8FhBg X-IronPort-AV: E=Sophos;i="4.43,320,1246838400"; d="scan'208";a="359900228" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 07:25:23 +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 n747PNaF024587; Tue, 4 Aug 2009 00:25:23 -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 n747PJWJ024853; Tue, 4 Aug 2009 07:25:23 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); Tue, 4 Aug 2009 09:25:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 09:25:19 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86036E7CAF@xmb-ams-33d.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RA-DIOs and next-door destinations Thread-Index: AcoUcelqvuFqDxVSS4+oOrKpKVH0RAAYpWsg References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 04 Aug 2009 07:25:21.0328 (UTC) FILETIME=[B99E9300:01CA14D4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1715; t=1249370723; x=1250234723; c=relaxed/simple; s=sjdkim2002; 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]=20RA-DIOs=20and=20next-door=20de stinations |Sender:=20; bh=3U8zI6SFOSTs0ZTS60vknfQqFGawpq23MHKAGY76O3k=; b=pmlU1VZq1hi2nW7xzSOHYAguABtSXMYaCrcfIhksMAW6dmwtDU6on1hYQC XSnYxErEkted0v3OPd4HMlbE0ijQ0Eudd231e9HcG139LFifnSx4cl9QaFB/ XbxmAwa0eK; Authentication-Results: sj-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 07:25:26 -0000 Hi Jonthan, To me learning what global addresses are assigned to neighbors is not of = great help for routing, hence looks like (layer 5) service discovery. = Not sure ROLL should care about this. Cheers, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Jonathan Hui > Sent: lundi 3 ao=FBt 2009 21:38 > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] RA-DIOs and next-door destinations >=20 >=20 > Hi Richard, >=20 > On Aug 3, 2009, at 8:50 AM, Richard Kelsey wrote: > > In the section on RA-DIO reception, draft-dt-roll-rpl-01=20 > says that a=20 > > RA-DIO from a neighbor that is not a potential parent or a sibling=20 > > should be ignored. Is it permissable to remember the neighbor in=20 > > order to route messages to it directly? In other words,=20 > can a packet=20 > > whose destination is a neighbor with a greater depth be=20 > sent directly=20 > > to that neighbor? >=20 >=20 > Let me speak to your comment directly, rather than the draft. >=20 > I don't see any problem using the RA-DIO to figure out what=20 > neighbors are around you. One issue is that if the RA-DIO=20 > source address is a link-local address, it may not be so=20 > useful if you're trying to talk to that node using its global=20 > address. What is more useful is to allow including some kind=20 > of DAO in the same RA so that you know what addresses (other=20 > than the source address) are assigned to that node's interface. >=20 > -- > Jonathan Hui >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From zach@sensinode.com Tue Aug 4 00:45: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 95EDB3A68B8 for ; Tue, 4 Aug 2009 00:45:56 -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 RbUTKUTX71BA for ; Tue, 4 Aug 2009 00:45:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 088E33A6A45 for ; Tue, 4 Aug 2009 00:45:54 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n747jqxB022432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Aug 2009 10:45:52 +0300 Message-ID: <4A77E731.90204@sensinode.com> Date: Tue, 04 Aug 2009 10:45:53 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: roll@ietf.org References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> <38F26F36EAA981478A49D1F37F474A86036E7CAF@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86036E7CAF@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 07:45:56 -0000 Hi, I think what many people are a bit confused about is just the concept of neighbor communication vs. using a router to forward traffic. In IPv6 a node can always communicate directly with its on-link neighbors of course! The sending node makes the decision whether to send a packet directly to a neighbor or to send it through a router. This is independent of the routing algorithm (and a host e.g. isn't even aware of routing). In IPv6 this is called next-hop determination, i.e., is this destination on-link (get the link-layer address of the destination and send it to L2) or off-link (send it to a router, which is where it is forwarded based on the routing table). Next-hop determination is a function of Neighbor Discovery. If you are using full IPv6 then see RFC4861, if using 6LoWPAN see draft-ietf-6lowpan-nd. Routing protocol control traffic could of course help in the maintenance of the neighbor cache in IPv6, which is what Jonathan is pointing out. - Zach Julien Abeille (jabeille) wrote: > Hi Jonthan, > > To me learning what global addresses are assigned to neighbors is not of great help for routing, hence looks like (layer 5) service discovery. Not sure ROLL should care about this. > > Cheers, > Julien > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Jonathan Hui >> Sent: lundi 3 août 2009 21:38 >> To: Richard Kelsey >> Cc: roll@ietf.org >> Subject: Re: [Roll] RA-DIOs and next-door destinations >> >> >> Hi Richard, >> >> On Aug 3, 2009, at 8:50 AM, Richard Kelsey wrote: >>> In the section on RA-DIO reception, draft-dt-roll-rpl-01 >> says that a >>> RA-DIO from a neighbor that is not a potential parent or a sibling >>> should be ignored. Is it permissable to remember the neighbor in >>> order to route messages to it directly? In other words, >> can a packet >>> whose destination is a neighbor with a greater depth be >> sent directly >>> to that neighbor? >> >> Let me speak to your comment directly, rather than the draft. >> >> I don't see any problem using the RA-DIO to figure out what >> neighbors are around you. One issue is that if the RA-DIO >> source address is a link-local address, it may not be so >> useful if you're trying to talk to that node using its global >> address. What is more useful is to allow including some kind >> of DAO in the same RA so that you know what addresses (other >> than the source address) are assigned to that node's interface. >> >> -- >> 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 -- 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 prvs=4607f775e=mukul@uwm.edu Tue Aug 4 05:36: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 4F2603A7040; Tue, 4 Aug 2009 05:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 dHBFnn4ShdPh; Tue, 4 Aug 2009 05:36:11 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 2EF593A6D7C; Tue, 4 Aug 2009 05:36:10 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta2.uwm.edu with ESMTP; 04 Aug 2009 07:36:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3BD592C38331; Tue, 4 Aug 2009 07:36:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDjDS2zevWJv; Tue, 4 Aug 2009 07:36:13 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 5F87D2C3830F; Tue, 4 Aug 2009 07:35:47 -0500 (CDT) Date: Tue, 4 Aug 2009 07:35:47 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <203916426.437141249389347253.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <83575498.436751249389227640.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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Tue, 04 Aug 2009 12:36:12 -0000 Hi Jonathan Please see inline. >I understood what you were trying to get at. My basic point was that RPL, like any other routing protocol, does not preclude you from using additional routing protocols to provide connectivity between networks. Now there are two cases: >1) More privileged nodes that can communicate with each other through a network other than the LLN network. >In this case, run whatever routing protocol that best fits your needs outside the LLN network - redistribute routes across the LLN boundaries. But these nodes belong to the LLN. The LLN may have been designed to have a backbone of such nodes. These nodes are not as constrained resource-wise but they use 802.15.4 (or similar) low-power, low-data rate protocol for communication among themselves and with constrained devices around them. This is often the case in atleast some of the commercial building networks I am aware of. I imagine home environment also has a similar situation. Can ROLL specify a more stateful, more general routing solution for this backbone? Or folks think that this backbone should simply not be part of the LLN? Note that these nodes are not really MANET nodes. They generally dont move (or their movement does not change the underlying logical connectivity significantly). They can't handle network-wide (or backbone-wide) broadcasts because they use a low data rate protocol (like 802.15.4). But they need general point-to-point routing, which needs to be (close to) optimal. >2) More privileged nodes in memory or energy that can only communicate with each other through the LLN network. >In this case, what you're really trying to get at is some style of landmark routing. But the very fact that these more privileged nodes must communicate through the LLN places constraints on how they can communicate with each other. Just because some nodes are privileged doesn't mean they can freely communicate without worrying about resource constraints within the network. Running some RIP-like or DSDV- like protocol is not much different than building DAGs rooted at each of these more privileged nodes. Two feasible solutions are (a) build completely overlapping DAGs rooted at each landmark or (b) utilize a "primary" DAG to help guide and constrain the construction of routes between "landmarks". For (a), you reduce the amount of state each LLN node maintains by pushing state to the landmarks, but it is still dependent on the number of landmarks you have. For (b), that is just an extension of "routing-along-a-DAG". One nice property of routing along a DAG is that you can place hard bounds on the state requirements of LLN nodes. I agree with this argument. Again thanks for this explanation. Thanks Mukul >Note that any DV-style protocol is equivalent to building DAGs. RIP builds a DAG rooted at every node within the network. DSDV builds a DAG rooted at each destination in the network. Every DAG incurs some amount of state and control overhead. RPL proposes a solution that requires building only a single DAG and mechanisms to avoid and detect loops that are well-known problems with DV-style protocols. -- Jonathan Hui From prvs=4607f775e=mukul@uwm.edu Tue Aug 4 05:56: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 A2AFD3A68DC; Tue, 4 Aug 2009 05:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 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 6XVWuDVIb6ge; Tue, 4 Aug 2009 05:56:21 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 5141D3A68BB; Tue, 4 Aug 2009 05:56:21 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 04 Aug 2009 07:56:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id BB84B2C38311; Tue, 4 Aug 2009 07:56:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqSRjUuk-151; Tue, 4 Aug 2009 07:56:23 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E16ED2C382D2; Tue, 4 Aug 2009 07:56:16 -0500 (CDT) Date: Tue, 4 Aug 2009 07:56:16 -0500 (CDT) From: Mukul Goyal To: d sturek Message-ID: <1197382132.441661249390576834.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <008001ca1499$b3997190$1acc54b0$@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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [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: Tue, 04 Aug 2009 12:56:23 -0000 Don I agree with suitability of RPL for MP2P and P2MP routing. I also agree wit= h the argument that RPL allows hard bounds on state. Thanks Mukul =20 ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "Jonathan Hui" Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Monday, August 3, 2009 7:22:49 PM GMT -06:00 US/Canada Central Subject: RE: Why a DAG? (was Re: [Roll] Moving forward with the protocol wo= rk) Hi Mukul, I would propose the opposite conjecture as well: 1) Why should devices that predominantly communicate multi-point to point = (many examples in LLNs where there is a central concentrator solution) need= to try to employ a P2P solution for this communication? The MANET distan= ce vector routing solutions have historically not handled this communicatio= n in a way that avoids non-scalable resource requirements on devices in the= routing path. 2) Similarly, when responses are needed to MP2P messaging, the reverse pat= h has proven to be problematic as well using MANET distance vector solution= s. I think DAGs handle both the MP2P and P2MP in a scalable way. By scalable,= I believe a wide range of network sizes are supported without scaling the = resources in these devices according to the size of the network and sizing = all routing devices in the network for the worst case. The assumption below that we are designing for resource constrained RFDs wi= th DAGs and not taking advantage of added processing resources in FFDs is r= eally not true. The real problem is that the FFDs need to be resourced in= a manner tied to the worst case routing requirements for a network with as= sumed device membership size. =20 Don =20 -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu]=20 Sent: Monday, August 03, 2009 4:50 PM To: Jonathan Hui Cc: ROLL WG; roll-bounces@ietf.org; d sturek Subject: Re: Why a DAG? (was Re: [Roll] Moving forward with the protocol wo= rk) Hi Jonathan Again a very well-crafted explanation. My compliments. > 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. So, I conjure the image of a network of RFDs (borrowing 802.15.4 terminolog= y). An RFD, rather than having an FFD in its radio range, has the nearest F= FD several hops away. Now, the FFD can serve as the DAG root and the RFDs a= round it can join this DAG. This allows the RFDs to reach the FFD which can= do the further routing. For these RFDs, DAG is indeed a good way to reach = the FFD. But why _force_ the FFDs to also become part of the DAGs to some o= ther roots when they can participate in more stateful routing. If the intent is that RPL provides default routing mechanism for resource c= ontrained nodes, I support RPL. But, for not-so-resource-constrained nodes,= there is no critical reason to participate in DAGs. =20 >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. Jonathan, don't you think that this argument again applies to extreme resou= rce-constrained devices only? For other devices, that can maintain much mor= e state and perhaps have abundant battery power as well, isn't it that the = broadcast of infrequent RAs is much more desirable than spread along possib= ly broken DAG? Again it seems to me that having local DAGs of (may be a few dozen) RFDs ar= ound an FFD makes sense for the reasons you described. But requiring thousa= nds of FFDs as well as RFDs to arrange themselves in a few global DAGs seem= s inefficient. I guess one needs to analyze mathematically performance under DAGs as they = become deeper. Performance parameters being: 1. the stretch introduced in P2P routes due to the need to travel along the= DAG, especially when nodes at higher rank (lower depth) have memory constr= aints. 2. conversely, the amount of state nodes at higher ranks need to maintain t= o support optimal (within the DAG) P2P and P2MP routing. (note that if the = closest DAG ancestor of a source and destination does not maintain state ab= out the destination the packets will have to travel longer than necessary) 3. the latency to perform DAG operations, such as re-joining a DAG at a hig= her depth. > 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. Great. Again the question is: why force global DAGs? I think that you have = made strong arguments in favor of local DAGs. I still am not convinced abou= t the need to have global DAGs. I think resourceful nodes should be allowed= to participate in more stateful routing that does not involve DAGs. Thanks Mukul =20 =20 >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-bounce= s@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 =20 > To Mukul Goyal > > cc ROLL WG > > Subject Re: [Roll] Moving forward with the protocol work > =20 > > > > 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. > > 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 =20 > 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 > _______________________________________________ > 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 Tue Aug 4 06:07: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 7BE6128C342 for ; Tue, 4 Aug 2009 06:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.719 X-Spam-Level: X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=0.880, 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 8Nv6ns+D3kTs for ; Tue, 4 Aug 2009 06:07: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 1CF9C28C3D3 for ; Tue, 4 Aug 2009 06:07:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkAABfPd0qQ/uCKe2dsb2JhbACaKwEBFiQGoVmIKY9mBYQY X-IronPort-AV: E=Sophos;i="4.43,321,1246838400"; d="scan'208";a="46425412" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2009 13:07: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 n74D7sn5014399; Tue, 4 Aug 2009 15:07: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 n74D7stk016068; Tue, 4 Aug 2009 13:07:54 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, 4 Aug 2009 15:07:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 15:07:49 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E20A2C@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RA-DIOs and next-door destinations Thread-Index: AcoUceaG2akn2vZaTb+QPgnVp04jiAAkVLfg References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 04 Aug 2009 13:07:54.0490 (UTC) FILETIME=[944235A0:01CA1504] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2264; t=1249391274; x=1250255274; 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]=20RA-DIOs=20and=20next-door=20de stinations |Sender:=20; bh=R4mVegi9NRvK8Rp2Tu2dgsgzpZXiR3uSJ1RWROOGvoA=; b=e5vy6SpOHIYeCYm/IJD71ACzpX5/aq5pbREET/04mPhFsQGwSCUa+Rt1OI Z2YMh211UAXuyDEY+Wid5LR9ywJ82Uxv53flVEYy9peaNfY5DHfs46Scy7SW PUn1bXzeDJ; 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] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 13:07:54 -0000 Hi Jonathan: If a node is a router A that owns a prefix A::/64 is near to router B = that owns B::/64. With the current text in the draft, A will advertise A::/64 to its = parent using ND-DAO, and B will do the same for B::/64. If they are lucky and are siblings sharing a same parent, then A::1 = (might be A's address on A::/64) could ping B::1 via that parent. But = the DAG might provide a path that's a lot worse than that. An easy addition to the draft is to allow A to also multicast its NA-DAO = to all nodes. That way, if B is in line of sight from A, B could install = a route to A::/64 via A's link local regardless of their DAG = relationship and forward the packets directly. This is an easy way to address local communication between nodes. Note = that if A is a host, A would advertise a host route A::1/128.=20 What do you think? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jonathan Hui >Sent: lundi 3 ao=FBt 2009 21:38 >To: Richard Kelsey >Cc: roll@ietf.org >Subject: Re: [Roll] RA-DIOs and next-door destinations > > >Hi Richard, > >On Aug 3, 2009, at 8:50 AM, Richard Kelsey wrote: >> In the section on RA-DIO reception, draft-dt-roll-rpl-01 >> says that a RA-DIO from a neighbor that is not a potential >> parent or a sibling should be ignored. Is it permissable >> to remember the neighbor in order to route messages to >> it directly? In other words, can a packet whose >> destination is a neighbor with a greater depth be sent >> directly to that neighbor? > > >Let me speak to your comment directly, rather than the draft. > >I don't see any problem using the RA-DIO to figure out what neighbors >are around you. One issue is that if the RA-DIO source address is a >link-local address, it may not be so useful if you're trying to talk >to that node using its global address. What is more useful is to allow >including some kind of DAO in the same RA so that you know what >addresses (other than the source address) are assigned to that node's >interface. > >-- >Jonathan Hui > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Aug 4 07:02: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 4010C28C3FD for ; Tue, 4 Aug 2009 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 1gMih2Gm0WA6 for ; Tue, 4 Aug 2009 07:02:40 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id 040B828C3FB for ; Tue, 4 Aug 2009 07:02:39 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKSng/e3QT+8XXSvIYnmQodkVD2MfqBK+Y@postini.com; Tue, 04 Aug 2009 07:02:43 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009080409031654-1324631 ; Tue, 4 Aug 2009 09:03:16 -0500 In-Reply-To: <4A7785E9.6070901@acm.org> MIME-Version: 1.0 To: Tim Winter X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 4 Aug 2009 09:02:16 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/04/2009 09:02:32 AM, Serialize complete at 08/04/2009 09:02:32 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/04/2009 09:03:16 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/04/2009 09:03:26 AM, Serialize complete at 08/04/2009 09:03:26 AM Content-Type: multipart/alternative; boundary="=_alternative 004D1C6D86257608_=" Cc: ROLL WG Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 14:02:42 -0000 This is a multipart message in MIME format. --=_alternative 004D1C6D86257608_= Content-Type: text/plain; charset="US-ASCII" Thanks Tim. I realize that setting timer values is the province of the application in the long run. However, I was trying to look into the DTs head as to what it thinks the timer values should be. If we select 802.15.4 as the radio technology, it has certain preordained parameters (e.g. 250kbps. 128 byte packets, CSMA-CA backoffs) that at least sets the lower bound as to how fast convergence can happen. I would think we would want to at least understand the unstability of an LLN and the convergence time if a high ranked node in the DAG decides to reposition itself. I am not too worried about that breakaway node itself as much as all its sub-DAG nodes that are affected by the move. Tim Winter 08/03/2009 07:51 PM To Jerald.P.Martocci@jci.com cc ROLL WG Subject Re: [Roll] Next items ... Hi Jerry, I have a few supplemental points to your questions inline: Jerald.P.Martocci@jci.com wrote: > > I would like the following questions answered on subsequent revisions of > the draft: > > > a) What is the roll of 'siblings'? They are in the current RPL > document, yet seem to be demoted from parental links. As I read the > draft, one cannot use a sibling link unless the parental links are > exhausted. The nodes don't seem to explicitly define sibling links. > > b) What is the plan on communication to devices within direct radio > range? As I read the draft unless a node is made a 'parent', or > possibly a 'sibling' it cannot be communicated with. However, Anand > mentions in his memo that at the Stockholm meeting there was discussion > on directly connected devices. Unfortunately, I couldn't attend the > meeting. > > c) What are the approximate timer values for RPL? The document gives no > indication as to these timers, hence I can't calculate how long a > floating DAG may be dislodged from its network. In a real-time facility > management control system, all nodes are monitored for falling off-line. > If the convergence time is too long (more than 1 minute), the devices > will be flagged off-line and reported to the customer. In general the suggestion is that parameterization of RPL should occur in application-specific applicability statements. So the RPL specification might not end up including specific numbers, but a Building Applicability Statement may give an implementer further guidance in how to setup timers, etc. in order that RPL can be operated in a manner to meet the requirements of that application domain. The applicability statements can help to bridge the gap between the protocol specification and the implementation. Also, in the current proposal some precedence is given to communicate key parameters (e.g. DAGDelay) in the DIO- so some flexibility could be given even within an implementation if the WG believes it to be desirable. > > d) What is the plan for security? RPL doesn't currently weigh in on the > topic. Are security policies optional or mandatory? Must the policy be > consistent with the rest of the enterprise's IT security on other parts > of the network? Will security require nodes to keep state info as Rene > suggests? > > e) What requirements from the 4 requirement drafts are being considered? > When the DT first was engaged, it said it would publish the list of > requirements as an appendix and note if the current draft supported > which requirement. This hasn't occurred and may be adding to the email > angst. As a requirement's author, I would rather know up front that > some of my MUST requirements are not being considered. All requirements. Here is the list that the DT worked with as extracted from the drafts: http://www.ietf.org/mail-archive/web/roll/current/msg01291.html The intention is not to re-declare the requirements in an appendix of RPL- the requirements drafts give a lot better background/context in presenting the requirements. Instead, the suggestion is that at the end of this process, if we (WG) find that any requirement is lacking in the final version of the protocol, we should then clearly document such and why in the appendix. As the WG takes up the process of further developing RPL I do hope that you, other requirements authors, and any other interested parties do make the WG aware if a requirement is in jeopardy of not being satisfied (and helping to work out the alternatives ;) ). > > f) What is the expected frame overhead size based on all the above > criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, > UDP/TCP. We need to add in the encryption and authentication overhead; > and now maybe source routing. I realize ROLL is trying to be agnostic > to L2, however in practice 802.15.4 is the only game in town. It only > carries a 128 by packet size. The DT/WG should at least give an > accounting of the expected frame overhead so we can determine what L2s > are feasible for the protocol. > > g) What routing data must persist a warmstart/coldstart? The overhead > to establish a DAG is significant. We should consider what data might > be able to transcend a network reboot to minimize communication startup > bottlenecks. > > As Pascal has noted in previous emails, some of these issues may be > considered out-of bounds for the protocol and should be an > implementation decision. That may indeed be true, but RPL should state > its case explicitly. In the Building Market, it is multi-disciplined > (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority > prescribes operation, the chances of LLN node-to-node interoperability > are moot. > > Thanks, > > Jerry > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 08/03/2009 02:27 AM > > > To > ROLL WG > cc > > Subject > [Roll] Next items ... > > > > > > > > > Dear all, > > As a reminder, RPL being a WG ID, it now "belongs" to the WG. > > Several working items have been listed but before starting to address > all open items in some unstructured way, I would like to propose the > following. > > It clearly appeared that there were some misunderstandings on how RPL > works. The DT did an outstanding job but I also understand that > several areas must be clarified. So before changing RPL, adding new > mechanisms (e.g. to optimize P2P, support source routing, loop > detection, ... ), I would first want you to list your questions on the > mailing list on each area for which you would like to get > clarification. This will help make sure that everybody is indeed on > the same page. > > From there, we will continue to quickly move forward, I will track > the list of open items via the issue tracker. > > Many Thanks. > > JP. > _______________________________________________ > 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 004D1C6D86257608_= Content-Type: text/html; charset="US-ASCII"

Thanks Tim.

I realize that setting timer values is the province of the application in the long run.  However, I was trying to look into the DTs head as to what it thinks the timer values should be.  If we select 802.15.4 as the radio technology, it has certain preordained parameters (e.g. 250kbps. 128 byte packets, CSMA-CA backoffs) that at least sets the lower bound as to how fast convergence can happen.  I would think we would want to at least understand the unstability of an LLN and the convergence time if a high ranked node in the DAG decides to reposition itself.  I am not too worried about that breakaway node itself as much as all its sub-DAG nodes that are affected by the move.  






Tim Winter <wintert@acm.org>

08/03/2009 07:51 PM

To
Jerald.P.Martocci@jci.com
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Next items ...





Hi Jerry,

I have a few supplemental points to your questions inline:

Jerald.P.Martocci@jci.com wrote:
>
> I would like the following questions answered on subsequent revisions of
> the draft:
>
>
> a) What is the roll of 'siblings'?  They are in the current RPL
> document, yet seem to be demoted from parental links.  As I read the
> draft, one cannot use a sibling link unless the parental links are
> exhausted.  The nodes don't seem to explicitly define sibling links.  
>
> b) What is the plan on communication to devices within direct radio
> range?  As I read the draft unless a node is made a 'parent', or
> possibly a 'sibling' it cannot be communicated with.  However, Anand
> mentions in his memo that at the Stockholm meeting there was discussion
> on directly connected devices.  Unfortunately, I couldn't attend the
> meeting.
>
> c) What are the approximate timer values for RPL?  The document gives no
> indication as to these timers, hence I can't calculate how long a
> floating DAG may be dislodged from its network.  In a real-time facility
> management control system, all nodes are monitored for falling off-line.
>  If the convergence time is too long (more than 1 minute), the devices
> will be flagged off-line and reported to the customer.
In general the suggestion is that parameterization of RPL should occur in
application-specific applicability statements.  So the RPL specification
might not end up including specific numbers, but a Building Applicability
Statement may give an implementer further guidance in how to setup timers,
etc. in order that RPL can be operated in a manner to meet the requirements
of that application domain.  The applicability statements can help to bridge
the gap between the protocol specification and the implementation.
Also, in the current proposal some precedence is given to communicate key
parameters (e.g. DAGDelay) in the DIO- so some flexibility could be given
even within an implementation if the WG believes it to be desirable.


>
> d) What is the plan for security?  RPL doesn't currently weigh in on the
> topic.  Are security policies optional or mandatory?  Must the policy be
> consistent with the rest of the enterprise's IT security on other parts
> of the network?  Will security require nodes to keep state info as Rene
> suggests?
>
> e) What requirements from the 4 requirement drafts are being considered?
>  When the DT first was engaged, it said it would publish the list of
> requirements as an appendix and note if the current draft supported
> which requirement.  This hasn't occurred and may be adding to the email
> angst.  As a requirement's author, I would rather know up front that
> some of my MUST requirements are not being considered.
All requirements.  Here is the list that the DT worked with as extracted
from the drafts:
http://www.ietf.org/mail-archive/web/roll/current/msg01291.html
The intention is not to re-declare the requirements in an appendix of RPL-
the requirements drafts give a lot better background/context in presenting
the requirements.  Instead, the suggestion is that at the end of this
process, if we (WG) find that any requirement is lacking in the final
version of the protocol, we should then clearly document such and why in the
appendix.  As the WG takes up the process of further developing RPL I do
hope that you, other requirements authors, and any other interested parties
do make the WG aware if a requirement is in jeopardy of not being satisfied
(and helping to work out the alternatives ;)  ).

>
> f) What is the expected frame overhead size based on all the above
> criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation,
> UDP/TCP.  We need to add in the encryption and authentication overhead;
> and now maybe source routing.  I realize ROLL is trying to be agnostic
> to L2, however in practice 802.15.4 is the only game in town.  It only
> carries a 128 by packet size.  The DT/WG should at least give an
> accounting of the expected frame overhead so we can determine what L2s
> are feasible for the protocol.
>
> g) What routing data must persist a warmstart/coldstart?  The overhead
> to establish a DAG is significant.  We should consider what data might
> be able to transcend a network reboot to minimize communication startup
> bottlenecks.
>
> As Pascal has noted in previous emails, some of these issues may be
> considered out-of bounds for the protocol and should be an
> implementation decision.  That may indeed be true, but RPL should state
> its case explicitly.  In the Building Market, it is multi-disciplined
> (HVAC, Fire, Lighting) and multi-vendor.  Unless some higher authority
> prescribes operation, the chances of LLN node-to-node interoperability
> are moot.
>
> Thanks,
>
> Jerry
>
>
>
>
> *JP Vasseur <jvasseur@cisco.com>*
> Sent by: roll-bounces@ietf.org
>
> 08/03/2009 02:27 AM
>
>                  
> To
>                  ROLL WG <roll@ietf.org>
> cc
>                  
> Subject
>                  [Roll] Next items ...
>
>
>                  
>
>
>
>
>
> Dear all,
>
> As a reminder, RPL being a WG ID, it now "belongs" to the WG.
>
> Several working items have been listed but before starting to address  
> all open items in some unstructured way, I would like to propose the  
> following.
>
> It clearly appeared that there were some misunderstandings on how RPL  
> works. The DT did an outstanding job but I also understand that  
> several areas must be clarified. So before changing RPL, adding new  
> mechanisms (e.g. to optimize P2P, support source routing, loop  
> detection, ... ), I would first want you to list your questions on the  
> mailing list on each area for which you would like to get  
> clarification. This will help make sure that everybody is indeed on  
> the same page.
>
> From there, we will continue to quickly move forward, I will track  
> the list of open items via the issue tracker.
>
> Many Thanks.
>
> JP.
> _______________________________________________
> 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 004D1C6D86257608_=-- From richard.kelsey@ember.com Tue Aug 4 07: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 3E46E3A6B93 for ; Tue, 4 Aug 2009 07:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ5BYkm61zDq for ; Tue, 4 Aug 2009 07: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 494073A6BA8 for ; Tue, 4 Aug 2009 07:21:14 -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, 4 Aug 2009 10:21:25 -0400 Date: Tue, 04 Aug 2009 10:21:35 -0400 Message-Id: <87ocqv4q34.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Mon, 3 Aug 2009 12:58:23 -0700) From: Richard Kelsey References: <87r5vt3qk9.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 04 Aug 2009 14:21:25.0767 (UTC) FILETIME=[D995A970:01CA150E] Cc: roll@ietf.org Subject: Re: [Roll] cost of incrementing the DAG sequence number X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 14:21:15 -0000 From: Jonathan Hui Date: Mon, 3 Aug 2009 12:58:23 -0700 Jonathan, On Aug 3, 2009, at 7:44 AM, Richard Kelsey wrote: > I would argue that seeing a new sequence number in a > parent's DIO should not reset the trickle timer. In > addition to reducing the cost of incrementing, it also > increases the utility of doing so. The sequence numbers are > more useful if they propagate slowly than if they propagate > quickly. Incrementing the sequence number reasonably often > increases nodes' ability to react to topography changes. At > the extreme, once all nodes in the DAG have the same > sequence number the sequence number is no help at all. We > shouldn't be in a hurry to get there. Being able to use the sequence number to cause more frequent RAs is a useful mechanism for network management or for other protocol-specific reasons down the line. Can you be more specific? There is also benefit to have the new sequence number propagate quickly throughout the network. While the sequence number is propagating, special care needs to be taken as to when a node should actually make the flip from the old topology to the new topology - once you flip to new, you can only use routes in the new topology and you cannot go back. Propagating a new sequence number doesn't necessitate any change in the topology. There is no requirement, or even suggestion, that a new sequence number alone cause any changes in routes. The new sequence number gives nodes the opporunity to pick better routes; there is no need for them to pick worse ones. Flip too early, and the node may advertise higher costs and other routing information carried in DAOs - causing additional unneeded churn in the routing structure later in time. Taking longer to flip obviously impacts the time it takes to react to topological changes. As does taking longer to increment the sequence number. You can have infrequent fast propagation or frequent slow propagation. The latter seems less disruptive and no worse at reacting to changes. [...] When there is this tradeoff in resource consumption vs. responsiveness, then it's beneficial to utilize mechanisms that only require actions by the affected nodes - rather than mechanisms that affect all nodes within the network. Exactly. If incrementing the sequence number does not reset the trickle timer, then a new sequence number allows regions that need route improvements to make those improvements while allowing everyone else to keep their current routes at no additional cost. -Richard Kelsey From jhui@archrock.com Tue Aug 4 08:22: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 8C27E28C3E0 for ; Tue, 4 Aug 2009 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 IyhNQKawtU2Q for ; Tue, 4 Aug 2009 08:22: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 A71FF3A67A7 for ; Tue, 4 Aug 2009 08:22:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AABF6AF896; Tue, 4 Aug 2009 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLjm4SCnb1Zp; Tue, 4 Aug 2009 08:21:43 -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 DDE99AF859; Tue, 4 Aug 2009 08:21:42 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87ocqv4q34.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, 4 Aug 2009 08:21:41 -0700 References: <87r5vt3qk9.fsf@kelsey-ws.hq.ember.com> <87ocqv4q34.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] cost of incrementing the DAG sequence number X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 15:22:38 -0000 Hi Richard, On Aug 4, 2009, at 7:21 AM, Richard Kelsey wrote: > Being able to use the sequence number to cause more > frequent RAs is a useful mechanism for network management > or for other protocol-specific reasons down the line. > > Can you be more specific? If the network generally operates with a slow RA transmission period, speeding it up can help convergence times. We've found it useful for when something in the network changes more quickly than expected (e.g. unexpected node movement, unexpected network failures, network maintenance, etc.). Sequence number is also useful for building routing state from a clean slate - which is what it does by building a new DAG. > There is also benefit to have the new sequence > number propagate quickly throughout the network. While the sequence > number is propagating, special care needs to be taken as to when a > node should actually make the flip from the old topology to the new > topology - once you flip to new, you can only use routes in the new > topology and you cannot go back. > > Propagating a new sequence number doesn't necessitate > any change in the topology. There is no requirement, > or even suggestion, that a new sequence number alone > cause any changes in routes. The new sequence number > gives nodes the opporunity to pick better routes; there > is no need for them to pick worse ones. A nice property of propagating a new sequence number is that it can move deeper in the DAG if it wishes without forming cycles. The problem is that, in many cases, the first nodes you hear advertising a new sequence number will have higher cost than your current cost in the existing (soon-to-be deprecated) DAG. RAs propagate quicker along paths with shorter hops - not necessarily ones with lower cost. If the node uses routes from the new DAG, it can no longer use routes from the old DAG (otherwise there is no guarantee of loop freedom). So the question is - when does a node decide to use the new DAG and when can it start advertising routes for the new DAG? How long does it wait if some of the old routes have not yet communicated a new sequence number? And does the loss of a few broadcast transmissions provide a good indicator that unicast transmissions is also failing to the same degree? > Flip too early, and the node may advertise higher costs > and other routing information carried in DAOs - causing > additional unneeded churn in the routing structure later > in time. Taking longer to flip obviously impacts the time > it takes to react to topological changes. > > As does taking longer to increment the sequence number. > You can have infrequent fast propagation or frequent > slow propagation. The latter seems less disruptive > and no worse at reacting to changes. Right - but if you can provide other mechanisms that can fix the majority of problems locally while using the sequence number to fix harder problems globally - then we can move towards a nice tradeoff between slow and fast. My wish is to have a protocol that operates well while transmitting RAs every 10s of minutes the majority of the time - while allowing local adaptations to occur in only a few minutes at most. If I'm missing something, please elaborate. > [...] When there is this tradeoff > in resource consumption vs. responsiveness, then it's beneficial to > utilize mechanisms that only require actions by the affected nodes - > rather than mechanisms that affect all nodes within the network. > > Exactly. If incrementing the sequence number does not reset > the trickle timer, then a new sequence number allows regions > that need route improvements to make those improvements > while allowing everyone else to keep their current routes at > no additional cost. It seems that you are arguing for a fixed RA transmission period for all nodes. What are some cases where you would reset the Trickle timer? or more generally transmit RAs more frequently than you would like for a limited period of time? -- Jonathan Hui From jhui@archrock.com Tue Aug 4 08:27: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 130563A702D for ; Tue, 4 Aug 2009 08:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 cpdxq+QM22Ym for ; Tue, 4 Aug 2009 08:27:55 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 58D7528C3E9 for ; Tue, 4 Aug 2009 08:27:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 78E9AAF859; Tue, 4 Aug 2009 08:27: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 kSt5UdF9V44G; Tue, 4 Aug 2009 08:27:25 -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 98ADCAF861; Tue, 4 Aug 2009 08:27:25 -0700 (PDT) Message-Id: <822470B0-A92F-4BC9-882E-9FE47FB48961@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07E20A2C@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, 4 Aug 2009 08:27:24 -0700 References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07E20A2C@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: roll@ietf.org Subject: Re: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 15:27:56 -0000 Hi Pascal, On Aug 4, 2009, at 6:07 AM, Pascal Thubert (pthubert) wrote: > An easy addition to the draft is to allow A to also multicast its NA- > DAO to all nodes. That way, if B is in line of sight from A, B could > install a route to A::/64 via A's link local regardless of their DAG > relationship and forward the packets directly. > > This is an easy way to address local communication between nodes. > Note that if A is a host, A would advertise a host route A::1/128. > > What do you think? This is definitely an easy addition. I was also thinking of including DAOs in RAs since RAs are already sent using link-local multicast. Doing so would definitely reduce transmission overhead for multicast traffic that can be significant with some link protocols. -- Jonathan Hui From Jerald.P.Martocci@jci.com Tue Aug 4 09:56: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 E94213A6915 for ; Tue, 4 Aug 2009 09:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 js8vIpTRR2Fb for ; Tue, 4 Aug 2009 09:56:30 -0700 (PDT) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id 0123B3A6B6C for ; Tue, 4 Aug 2009 09:56:29 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKSnhoPUvWqRx62L2VBtgkoNjhHNe8f7Lo@postini.com; Tue, 04 Aug 2009 09:56:33 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009080411570529-1346102 ; Tue, 4 Aug 2009 11:57:05 -0500 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, 4 Aug 2009 11:56:02 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/04/2009 11:56:19 AM, Serialize complete at 08/04/2009 11:56:19 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/04/2009 11:57:05 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/04/2009 11:57:17 AM, Serialize complete at 08/04/2009 11:57:17 AM Content-Type: multipart/alternative; boundary="=_alternative 005D053886257608_=" Cc: ROLL WG Subject: [Roll] Fw: Next items ... (amended list) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 16:56:32 -0000 This is a multipart message in MIME format. --=_alternative 005D053886257608_= Content-Type: text/plain; charset="US-ASCII" JP, RPL currently makes no mention of sleepy devices. These will be very commonplace in WSNs. I would like to amend my list below and add sleepy device management. RPL needs to state what happens to packets routed to sleepy devices while they are asleep. Are they dropped? Will a proxy manage the packet until the device awakens? Will the last router return an error to the source? ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 11:43 AM ----- Jerald.P.Martocci@jci.com Sent by: roll-bounces@ietf.org 08/03/2009 01:09 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] Next items ... I would like the following questions answered on subsequent revisions of the draft: a) What is the roll of 'siblings'? They are in the current RPL document, yet seem to be demoted from parental links. As I read the draft, one cannot use a sibling link unless the parental links are exhausted. The nodes don't seem to explicitly define sibling links. b) What is the plan on communication to devices within direct radio range? As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with. However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices. Unfortunately, I couldn't attend the meeting. c) What are the approximate timer values for RPL? The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network. In a real-time facility management control system, all nodes are monitored for falling off-line. If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer. d) What is the plan for security? RPL doesn't currently weigh in on the topic. Are security policies optional or mandatory? Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network? Will security require nodes to keep state info as Rene suggests? e) What requirements from the 4 requirement drafts are being considered? When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement. This hasn't occurred and may be adding to the email angst. As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered. f) What is the expected frame overhead size based on all the above criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP. We need to add in the encryption and authentication overhead; and now maybe source routing. I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town. It only carries a 128 by packet size. The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol. g) What routing data must persist a warmstart/coldstart? The overhead to establish a DAG is significant. We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks. h) How will packets routed to asleep devices be handled? will they be dropped? buffered by a proxy? will a router return an 'asleep' error to the source? As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision. That may indeed be true, but RPL should state its case explicitly. In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot. Thanks, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 08/03/2009 02:27 AM To ROLL WG cc Subject [Roll] Next items ... Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address all open items in some unstructured way, I would like to propose the following. It clearly appeared that there were some misunderstandings on how RPL works. The DT did an outstanding job but I also understand that several areas must be clarified. So before changing RPL, adding new mechanisms (e.g. to optimize P2P, support source routing, loop detection, ... ), I would first want you to list your questions on the mailing list on each area for which you would like to get clarification. This will help make sure that everybody is indeed on the same page. >From there, we will continue to quickly move forward, I will track the list of open items via the issue tracker. Many Thanks. JP. _______________________________________________ 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 005D053886257608_= Content-Type: text/html; charset="US-ASCII"

JP,

RPL currently makes no mention of sleepy devices.  These will be very commonplace in WSNs.  I would like to amend my list below and add sleepy device management.  RPL needs to state what happens to packets routed to sleepy devices while they are asleep.  Are they dropped?  Will a proxy manage the packet until the device awakens? Will the last router return an error to the source?


----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 11:43 AM -----
Jerald.P.Martocci@jci.com
Sent by: roll-bounces@ietf.org

08/03/2009 01:09 PM

To
JP Vasseur <jvasseur@cisco.com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Next items ...






I would like the following questions answered on subsequent revisions of the draft:


a) What is the roll of 'siblings'?  They are in the current RPL document, yet seem to be demoted from parental links.  As I read the draft, one cannot use a sibling link unless the parental links are exhausted.  The nodes don't seem to explicitly define sibling links.  

b) What is the plan on communication to devices within direct radio range?  As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with.  However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices.  Unfortunately, I couldn't attend the meeting.

c) What are the approximate timer values for RPL?  The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network.  In a real-time facility management control system, all nodes are monitored for falling off-line.  If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer.

d) What is the plan for security?  RPL doesn't currently weigh in on the topic.  Are security policies optional or mandatory?  Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network?  Will security require nodes to keep state info as Rene suggests?

e) What requirements from the 4 requirement drafts are being considered?  When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement.  This hasn't occurred and may be adding to the email angst.  As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered.

f) What is the expected frame overhead size based on all the above criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP.  We need to add in the encryption and authentication overhead; and now maybe source routing.  I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town.  It only carries a 128 by packet size.  The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol.

g) What routing data must persist a warmstart/coldstart?  The overhead to establish a DAG is significant.  We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks.

h) How will packets routed to asleep devices be handled?  will they be dropped? buffered by a proxy? will a router return an 'asleep' error to the source?  

As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision.  That may indeed be true, but RPL should state its case explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor.  Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot.

Thanks,

Jerry



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

08/03/2009 02:27 AM


To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] Next items ...







Dear all,

As a reminder, RPL being a WG ID, it now "belongs" to the WG.

Several working items have been listed but before starting to address  
all open items in some unstructured way, I would like to propose the  
following.

It clearly appeared that there were some misunderstandings on how RPL  
works. The DT did an outstanding job but I also understand that  
several areas must be clarified. So before changing RPL, adding new  
mechanisms (e.g. to optimize P2P, support source routing, loop  
detection, ... ), I would first want you to list your questions on the  
mailing list on each area for which you would like to get  
clarification. This will help make sure that everybody is indeed on  
the same page.

>From there, we will continue to quickly move forward, I will track  
the list of open items via the issue tracker.

Many Thanks.

JP.
_______________________________________________
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 005D053886257608_=-- From richard.kelsey@ember.com Tue Aug 4 12:31: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 4CA973A707B for ; Tue, 4 Aug 2009 12:31:21 -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 R8SIoRrCFJ9O for ; Tue, 4 Aug 2009 12:31:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1C3133A6F71 for ; Tue, 4 Aug 2009 12:31:20 -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, 4 Aug 2009 15:31:43 -0400 Date: Tue, 04 Aug 2009 15:31:53 -0400 Message-Id: <87hbwn4bpy.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Tue, 4 Aug 2009 08:21:41 -0700) From: Richard Kelsey References: <87r5vt3qk9.fsf@kelsey-ws.hq.ember.com> <87ocqv4q34.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 04 Aug 2009 19:31:43.0438 (UTC) FILETIME=[3294CEE0:01CA153A] Cc: roll@ietf.org Subject: Re: [Roll] cost of incrementing the DAG sequence number X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Aug 2009 19:31:21 -0000 From: Jonathan Hui Date: Tue, 4 Aug 2009 08:21:41 -0700 Jonathan, First off, I want to make it clear that I am not sold on the desirability of slowing down the propagation of sequence numbers. I do think it is worth a bit of examination. If the network generally operates with a slow RA transmission period, speeding it up can help convergence times. We've found it useful for when something in the network changes more quickly than expected (e.g. unexpected node movement, unexpected network failures, network maintenance, etc.). Sequence number is also useful for building routing state from a clean slate - which is what it does by building a new DAG. I agree with you on this. On startup, or when things are really broken, you have to reset the trickle timer. If we were to slow down sequence number propagation there would have to be a mechanism for speeding up the propagation when required. > Propagating a new sequence number doesn't necessitate > any change in the topology. There is no requirement, > or even suggestion, that a new sequence number alone > cause any changes in routes. The new sequence number > gives nodes the opporunity to pick better routes; there > is no need for them to pick worse ones. A nice property of propagating a new sequence number is that it can move deeper in the DAG if it wishes without forming cycles. Exactly. The problem is that, in many cases, the first nodes you hear advertising a new sequence number will have higher cost than your current cost in the existing (soon-to-be deprecated) DAG. I think that one of our differences is that you see a new sequence number as creating a new DAG. It doesn't have to. With a slow propagation of sequence numbers there may be several sequence numbers in use at the same time. The root and nearby nodes will have the highest number, with previous numbers used by nodes in bands more-or-less ordered by depth. Most of the time this all has no effect on anything, as nodes wait until all of their parents' have updated before updating themselves. The routes stay the same. If a node's parents become unreachable, then there may already be, or may soon appear, alternate parents available that have a higher sequence number. RAs propagate quicker along paths with shorter hops - not necessarily ones with lower cost. If the node uses routes from the new DAG, it can no longer use routes from the old DAG (otherwise there is no guarantee of loop freedom). So the question is - when does a node decide to use the new DAG and when can it start advertising routes for the new DAG? How long does it wait if some of the old routes have not yet communicated a new sequence number? Use a timer similar to the DAG Hop timer in the current draft. If you first hear a new sequence number from node N, then you wait (local_depth - node_N_depth) * some_delay. The delay should be long enough to allow for occasional missed RAs. And does the loss of a few broadcast transmissions provide a good indicator that unicast transmissions is also failing to the same degree? The goal would be to set the delay long enough to allow for some missed broadcast transmissions without forcing routes to change. Right - but if you can provide other mechanisms that can fix the majority of problems locally while using the sequence number to fix harder problems globally - then we can move towards a nice tradeoff between slow and fast. My wish is to have a protocol that operates well while transmitting RAs every 10s of minutes the majority of the time - while allowing local adaptations to occur in only a few minutes at most. If I'm missing something, please elaborate. I agree with you. Slow propagation of DAG sequence numbers isn't a replacement for fast local repair, it is an improvement on bursty global repair. The two advantages of slow propagation are: A) Reducing the peak bandwidth used for DAG maintenance. Fast construction of a new DAG can consume a lot of bandwidth, leaving little for application traffic. B) Eliminating the need to report routing problems back to the root in order to trigger a new sequence number. By reducing the cost of new sequence numbers the root can produce them on a continual basis rather than as needed. It seems that you are arguing for a fixed RA transmission period for all nodes. What are some cases where you would reset the Trickle timer? or more generally transmit RAs more frequently than you would like for a limited period of time? Joining or leaving a DAG would definitely still need to reset the trickle timer. There may be other cases as well. -Richard Kelsey From prvs=461799d11=mukul@uwm.edu Tue Aug 4 18:24: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 568FD3A6D2B for ; Tue, 4 Aug 2009 18:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 FS9iTRw8zGlG for ; Tue, 4 Aug 2009 18:24:36 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 7522A3A712B for ; Tue, 4 Aug 2009 18:24:19 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta2.uwm.edu with ESMTP; 04 Aug 2009 20:24:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D6B7B2C382AB; Tue, 4 Aug 2009 20:24:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkElM+4ejJMd; Tue, 4 Aug 2009 20:24:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 913D02C382A6; Tue, 4 Aug 2009 20:24:21 -0500 (CDT) Date: Tue, 4 Aug 2009 20:24:21 -0500 (CDT) From: Mukul Goyal To: Kris Pister Message-ID: <1075074897.739581249435461473.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2076327410.738611249434810195.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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll 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, 05 Aug 2009 01:24:58 -0000 Hi Kris, Sorry for the delay in getting back. Since the DAG mechanism seems a fait accompli now, my objections to DAGs are irrelevant. In light of the recent email exchange I had with Jonathan, I view DAGs as a mechanism that: 1) provides default routing paths to RFDs; 2) allows hard bounds on routing state a node has to maintain irrespective of the number of destinations in the network and the number of nodes in the neighborhood; 3) constrains the LLN topology so that the spread of routing costs can avoid broadcast; 4) provides loop prevention; 5) provides good MP2P and OK P2MP routing. In the LLN scenarios, where there is no FFD backbone available, RPL seems like a good choice. I am hoping that future P2P optimizations in RPL would allow: 1) more stateful routing to take place along the FFD backbone (if such a backbone exists in the LLN), where the topology need not be constrained along DAGs; 2) provide options regarding how to deals with loops. There are 4 choices for these options: prevention, avoidance, detection+correction and not dealing with loops at all; 3) allow some sort of source-initiated route discovery. Right now, a non-DAG-root destination can be reached only if it advertizes itself via a DAO. Thanks Mukul ----- Original Message ----- From: "Kris Pister" To: "Mukul Goyal" Cc: "d sturek" , "ROLL WG" , roll-bounces@ietf.org Sent: Friday, July 31, 2009 10:00:10 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Moving forward with the protocol work 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 Tue Aug 4 22:35: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 CA7893A7088 for ; Tue, 4 Aug 2009 22:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.53 X-Spam-Level: X-Spam-Status: No, score=-7.53 tagged_above=-999 required=5 tests=[AWL=-0.931, 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 ilrOKZu18whf for ; Tue, 4 Aug 2009 22:35:47 -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 93C293A716A for ; Tue, 4 Aug 2009 22:35:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOK2eEqrR7PD/2dsb2JhbAC8CYgpkEwFhBiKBg X-IronPort-AV: E=Sophos;i="4.43,326,1246838400"; d="scan'208";a="223562495" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2009 05:35:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n755ZPsi017724; Tue, 4 Aug 2009 22:35:25 -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 n755ZNM9020831; Wed, 5 Aug 2009 05:35:25 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 07:35:24 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 07:35:23 +0200 Message-Id: <926411E1-42A5-4654-91D7-2C083FF12EED@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1075074897.739581249435461473.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, 5 Aug 2009 07:35:22 +0200 References: <1075074897.739581249435461473.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 05 Aug 2009 05:35:23.0137 (UTC) FILETIME=[87344710:01CA158E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16806.004 X-TM-AS-Result: No--23.134500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9593; t=1249450525; x=1250314525; 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]=20Moving=20forward=20with=20the= 20protocol=20work |Sender:=20; bh=sd1lHpoy5Jt5L4iSo/hYqPNBzn0P9K2tA7ikr+RogyQ=; b=FzmoASoO1kpasFr55WZFa/Y5g4dzzrdWqs3Kw03bT3KbQbLKoBo8ynf0QZ 6mKBjGY4+98qEPil7LCZ4Wu12ApyRrzAOzbP0nqApA3+KG8G223b7e3iDTLU JImQk1vfu2; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: roll 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, 05 Aug 2009 05:35:51 -0000 Hi Mukul, Just one quick comment. I would just rather say that it is primarily optimized for P2MP and MP2P (the good and OK are debatable) while supporting P2P - we now need to discuss whether this is good enough. I would certainly argue on the distinction between constrained and non constrained devices (by the way please avoid the terms RFD, FFD and Backbone here). See below On Aug 5, 2009, at 3:24 AM, Mukul Goyal wrote: > Hi Kris, > > Sorry for the delay in getting back. > > Since the DAG mechanism seems a fait accompli now, my objections to > DAGs are irrelevant. > > In light of the recent email exchange I had with Jonathan, I view > DAGs as a mechanism that: > > 1) provides default routing paths to RFDs; > 2) allows hard bounds on routing state a node has to maintain > irrespective of the number of destinations in the network and the > number of nodes in the neighborhood; > 3) constrains the LLN topology so that the spread of routing costs > can avoid broadcast; > 4) provides loop prevention; > 5) provides good MP2P and OK P2MP routing. > > In the LLN scenarios, where there is no FFD backbone available, RPL > seems like a good choice. > > I am hoping that future P2P optimizations in RPL would allow: > 1) more stateful routing to take place along the FFD backbone (if > such a backbone exists in the LLN), where the topology need not be > constrained along DAGs; > 2) provide options regarding how to deals with loops. There are 4 > choices for these options: prevention, avoidance, detection > +correction and not dealing with loops at all; We need to be careful here not to come up with a protocol having a number of options, this is the best way to break interoperability. > 3) allow some sort of source-initiated route discovery. Right now, a > non-DAG-root destination can be reached only if it advertizes itself > via a DAO. > Requires discussion .... Could you elaborate on your requirements ? Thanks. JP. > Thanks > Mukul > > > ----- Original Message ----- > From: "Kris Pister" > To: "Mukul Goyal" > Cc: "d sturek" , "ROLL WG" , roll-bounces@ietf.org > Sent: Friday, July 31, 2009 10:00:10 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Moving forward with the protocol work > > 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 >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Aug 5 00:59: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 AC4523A717F for ; Wed, 5 Aug 2009 00:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 T5j3fOW5wyOi for ; Wed, 5 Aug 2009 00:59:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B37C828C518 for ; Wed, 5 Aug 2009 00:59:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYAABvZeEqQ/uCKe2dsb2JhbACCKC2XZAEBFiQGoE2IKZBUBYQY X-IronPort-AV: E=Sophos;i="4.43,327,1246838400"; d="scan'208,217";a="46477460" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2009 07:59:07 +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 n757x56u008920; Wed, 5 Aug 2009 09:59:05 +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 n757x6vx026722; Wed, 5 Aug 2009 07:59:07 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); Wed, 5 Aug 2009 09:59:07 +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_01CA15A2.9B2117D6" Date: Wed, 5 Aug 2009 09:59:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E20C1B@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fw: Next items ... (amended list) Thread-Index: AcoVJIk23/y16mhcRXalNkxPILEzowAfEDNA References: From: "Pascal Thubert (pthubert)" To: , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 05 Aug 2009 07:59:07.0254 (UTC) FILETIME=[9B941960:01CA15A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=29684; t=1249459145; x=1250323145; 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]=20Fw=3A=20=20Next=20items=20...= 20(amended=20list) |Sender:=20; bh=eXwcsEB+8ZlhYlzxp8dYTls7gSJaRXz4TYH/QSlHrbs=; b=INiTHrbrSq5r3VOkZNN3ijqpV/WmHuCeFFCbTSmNTcQEiioOCbaMz1dU3x OGWMzpDQFsl8i3dhXkqL2Y8O8fVuajOa/KUuXPDd6jVth+jU59T3ZhEB59c6 K+QvhRxiib; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Fw: Next items ... (amended list) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Aug 2009 07:59:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15A2.9B2117D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jerry: =20 This is a very good point. Long debated at 6LoWPAN, I suggest you dig = into the ML'logs on the web to find out what people said. =20 My own conclusion: - This is an adaptation layer problem, not a L3 problem o Some MACs are time synchronized or scheduled so it's not an issue = there o Some MACs use long preamble to wait for sleeping nodes and the = methed appears to do well too. =20 - Yet L3 has to be designed intelligently to cope with that, in = particular by reducing the need of multicast o This is what 6LoWPAN ND does with the whiteboard mechanism o This is what RPL does with the DAGs and DAOs as Jonathan explained = so well in the "why a DAG" discussion =20 The way I see it, some adaptation layers might want to make multicast a = bit more reliable and such an adaptation layer could actually transform = multicast in a series of unicast that is adapted to the sleep sequence = of the devices. In fact, it makes a lot more sense to cache RAs in a = router than it does in a WIFI access point. =20 DAOs can (and should) be used to advertise mcast listeners. I'm pretty = sure this will end up properly spelled out in the spec. The same process = could also be used to ask a router to store and forward FF02::1 between = its attached nodes. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com Sent: mardi 4 ao=FBt 2009 18:56 To: JP Vasseur (jvasseur) Cc: ROLL WG Subject: [Roll] Fw: Next items ... (amended list) =20 JP,=20 RPL currently makes no mention of sleepy devices. These will be very = commonplace in WSNs. I would like to amend my list below and add sleepy = device management. RPL needs to state what happens to packets routed to = sleepy devices while they are asleep. Are they dropped? Will a proxy = manage the packet until the device awakens? Will the last router return = an error to the source?=20 ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 = 11:43 AM -----=20 Jerald.P.Martocci@jci.com=20 Sent by: roll-bounces@ietf.org=20 08/03/2009 01:09 PM=20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Next items ... =20 =09 I would like the following questions answered on subsequent revisions of = the draft:=20 a) What is the roll of 'siblings'? They are in the current RPL = document, yet seem to be demoted from parental links. As I read the = draft, one cannot use a sibling link unless the parental links are = exhausted. The nodes don't seem to explicitly define sibling links. =20 b) What is the plan on communication to devices within direct radio = range? As I read the draft unless a node is made a 'parent', or = possibly a 'sibling' it cannot be communicated with. However, Anand = mentions in his memo that at the Stockholm meeting there was discussion = on directly connected devices. Unfortunately, I couldn't attend the = meeting.=20 c) What are the approximate timer values for RPL? The document gives no = indication as to these timers, hence I can't calculate how long a = floating DAG may be dislodged from its network. In a real-time facility = management control system, all nodes are monitored for falling off-line. = If the convergence time is too long (more than 1 minute), the devices = will be flagged off-line and reported to the customer.=20 d) What is the plan for security? RPL doesn't currently weigh in on the = topic. Are security policies optional or mandatory? Must the policy be = consistent with the rest of the enterprise's IT security on other parts = of the network? Will security require nodes to keep state info as Rene = suggests?=20 e) What requirements from the 4 requirement drafts are being considered? = When the DT first was engaged, it said it would publish the list of = requirements as an appendix and note if the current draft supported = which requirement. This hasn't occurred and may be adding to the email = angst. As a requirement's author, I would rather know up front that = some of my MUST requirements are not being considered.=20 f) What is the expected frame overhead size based on all the above = criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, = UDP/TCP. We need to add in the encryption and authentication overhead; = and now maybe source routing. I realize ROLL is trying to be agnostic = to L2, however in practice 802.15.4 is the only game in town. It only = carries a 128 by packet size. The DT/WG should at least give an = accounting of the expected frame overhead so we can determine what L2s = are feasible for the protocol.=20 g) What routing data must persist a warmstart/coldstart? The overhead = to establish a DAG is significant. We should consider what data might = be able to transcend a network reboot to minimize communication startup = bottlenecks.=20 h) How will packets routed to asleep devices be handled? will they be = dropped? buffered by a proxy? will a router return an 'asleep' error to = the source? =20 As Pascal has noted in previous emails, some of these issues may be = considered out-of bounds for the protocol and should be an = implementation decision. That may indeed be true, but RPL should state = its case explicitly. In the Building Market, it is multi-disciplined = (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority = prescribes operation, the chances of LLN node-to-node interoperability = are moot.=20 Thanks,=20 Jerry=20 JP Vasseur =20 Sent by: roll-bounces@ietf.org=20 08/03/2009 02:27 AM=20 =20 To ROLL WG =20 cc =09 Subject [Roll] Next items ... =20 =09 Dear all, As a reminder, RPL being a WG ID, it now "belongs" to the WG. Several working items have been listed but before starting to address =20 all open items in some unstructured way, I would like to propose the =20 following. It clearly appeared that there were some misunderstandings on how RPL =20 works. The DT did an outstanding job but I also understand that =20 several areas must be clarified. So before changing RPL, adding new =20 mechanisms (e.g. to optimize P2P, support source routing, loop =20 detection, ... ), I would first want you to list your questions on the =20 mailing list on each area for which you would like to get =20 clarification. This will help make sure that everybody is indeed on =20 the same page. >From there, we will continue to quickly move forward, I will track =20 the list of open items via the issue tracker. Many Thanks. JP. _______________________________________________ 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_01CA15A2.9B2117D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jerry:

 

This is a very good point. Long debated at 6LoWPAN, I = suggest you dig into the ML’logs on the web to find out what people = said.

 

My own conclusion:

-          This is an adaptation layer problem, not a L3 = problem

o   = Some MACs are time synchronized or scheduled so it’s not an issue = there

o   = Some MACs use long preamble to wait for sleeping nodes and the methed appears to = do well too.

 

-          Yet L3 has to be designed intelligently to cope with = that, in particular by reducing the need of multicast

o   = This is what 6LoWPAN ND does with the whiteboard = mechanism

o   = This is what RPL does with the DAGs and DAOs as Jonathan explained so well in = the “why a DAG” discussion

 

The way I see it, some adaptation layers might want to = make multicast a bit more reliable and such an adaptation layer could = actually transform multicast in a series of unicast that is adapted to the sleep sequence of the devices. In fact, it makes a lot more sense to cache RAs = in a router than it does in a WIFI access point.

 

DAOs can (and should) be used to advertise mcast = listeners. I’m pretty sure this will end up properly spelled out in the spec. The same = process could also be used to ask a router to store and forward FF02::1 between = its attached nodes.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: mardi 4 ao=FBt 2009 18:56
To: JP Vasseur (jvasseur)
Cc: ROLL WG
Subject: [Roll] Fw: Next items ... (amended = list)

 



JP,

RPL = currently makes no mention of sleepy devices.  These will be very commonplace = in WSNs.  I would like to amend my list below and add sleepy device management.  RPL needs to state what happens to packets routed to = sleepy devices while they are asleep.  Are they dropped?  Will a = proxy manage the packet until the device awakens? Will the last router return = an error to the source?


-= ---- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 11:43 = AM -----

Jerald.P.Marto= cci@jci.com =
Sent = by: roll-bounces@ietf.org

08/03/2009 01:09 PM

To=

JP Vasseur <jvasseur@cisco.com>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Next items ...

 





I would like the following questions answered on subsequent revisions of = the draft:


a) What is the roll of 'siblings'?  They are in the current RPL = document, yet seem to be demoted from parental links.  As I read the draft, = one cannot use a sibling link unless the parental links are exhausted. =  The nodes don't seem to explicitly define sibling links.  

b) What is the plan on communication to devices within direct radio = range?  As I read the draft unless a node is made a 'parent', or possibly = a 'sibling' it cannot be communicated with.  However, Anand mentions = in his memo that at the Stockholm meeting there was discussion on directly = connected devices.  Unfortunately, I couldn't attend the meeting.

c) What are the approximate timer values for RPL?  The document = gives no indication as to these timers, hence I can't calculate how long a = floating DAG may be dislodged from its network.  In a real-time facility = management control system, all nodes are monitored for falling off-line.  If = the convergence time is too long (more than 1 minute), the devices will be = flagged off-line and reported to the customer.

d) What is the plan for security?  RPL doesn't currently weigh in = on the topic.  Are security policies optional or mandatory?  Must the = policy be consistent with the rest of the enterprise's IT security on other = parts of the network?  Will security require nodes to keep state info as = Rene suggests?

e) What requirements from the 4 requirement drafts are being considered?  When the DT first was engaged, it said it would publish the list = of requirements as an appendix and note if the current draft supported = which requirement.  This hasn't occurred and may be adding to the email = angst.  As a requirement's author, I would rather know up front that some = of my MUST requirements are not being considered.

f) What is the expected frame overhead size based on all the above = criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, = UDP/TCP.  We need to add in the encryption and authentication overhead; and = now maybe source routing.  I realize ROLL is trying to be agnostic to = L2, however in practice 802.15.4 is the only game in town.  It only = carries a 128 by packet size.  The DT/WG should at least give an accounting = of the expected frame overhead so we can determine what L2s are feasible for = the protocol.

g) What routing data must persist a warmstart/coldstart?  The = overhead to establish a DAG is significant.  We should consider what data might = be able to transcend a network reboot to minimize communication startup bottlenecks.

h) = How will packets routed to asleep devices be handled?  will = they be dropped? buffered by a proxy? will a router return an 'asleep' error to = the source?  

As Pascal has noted in previous emails, some of these issues may be = considered out-of bounds for the protocol and should be an implementation decision.  That may indeed be true, but RPL should state its case explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, = Lighting) and multi-vendor.  Unless some higher authority prescribes = operation, the chances of LLN node-to-node interoperability are moot.

Thanks,

Jerry


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

08/03/2009 02:27 AM

 

To=

ROLL WG <roll@ietf.org>

cc=

Subject=

[Roll] Next items ...

 





Dear all,

As a reminder, RPL being a WG ID, it now "belongs" to the = WG.

Several working items have been listed but before starting to = address  
all open items in some unstructured way, I would like to propose the =  
following.

It clearly appeared that there were some misunderstandings on how = RPL  
works. The DT did an outstanding job but I also understand that =  
several areas must be clarified. So before changing RPL, adding new =  
mechanisms (e.g. to optimize P2P, support source routing, loop =  
detection, ... ), I would first want you to list your questions on = the  
mailing list on each area for which you would like to get =  
clarification. This will help make sure that everybody is indeed on =  
the same page.

From there, we will continue to quickly move forward, I will track =  
the list of open items via the issue tracker.

Many Thanks.

JP.
_______________________________________________
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_01CA15A2.9B2117D6-- From pthubert@cisco.com Wed Aug 5 01:09: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 7D94928C529 for ; Wed, 5 Aug 2009 01:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.84 X-Spam-Level: X-Spam-Status: No, score=-7.84 tagged_above=-999 required=5 tests=[AWL=-1.241, 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 5CtBKXpbjdE6 for ; Wed, 5 Aug 2009 01:09:41 -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 82D5B28C524 for ; Wed, 5 Aug 2009 01:09:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAILaeEqrR7MV/2dsb2JhbAC7LYgpkFQFhBg X-IronPort-AV: E=Sophos;i="4.43,327,1246838400"; d="scan'208";a="360742992" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 08:09:43 +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 n7589h42002241; Wed, 5 Aug 2009 01:09:43 -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 n7589fUK007418; Wed, 5 Aug 2009 08:09:43 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, 5 Aug 2009 10:09:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 10:09:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E20C28@xmb-ams-337.emea.cisco.com> In-Reply-To: <822470B0-A92F-4BC9-882E-9FE47FB48961@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RA-DIOs and next-door destinations Thread-Index: AcoVGBkRO4R5QFFPRyOM1/XjgAIRqQAiBOCA References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07E20A2C@xmb-ams-337.emea.cisco.com> <822470B0-A92F-4BC9-882E-9FE47FB48961@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Aug 2009 08:09:42.0057 (UTC) FILETIME=[15F35990:01CA15A4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2056; t=1249459783; x=1250323783; c=relaxed/simple; s=sjdkim1004; 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]=20RA-DIOs=20and=20next-door=20de stinations |Sender:=20; bh=MvFRWdUkKOFy4DiRZzDKw5DCI9drwI1Ob3Bv861xjZk=; b=KnYlLuY4eDOnpbCfzY6Dzrl7qCeGRINSN22fueBxUimAafHN28CQXRyVL9 6Z3GbwaJS33Y7Yho7mxHO8lXv5ptEmJAcfD3j4FIN/b5YalGYn1lna/zDKiv 1H3KGcOTuJhdgUixXr37H8EO81yucLSSYboJQWUz/9ijhTLTM/SGs=; Authentication-Results: sj-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] RA-DIOs and next-door destinations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Aug 2009 08:09:42 -0000 Hi Jonathan: I can see the benefit in terms of power of piggy backing things in RAs = as your recent mail on DAG explained so well. OTOH, a DAO can be used by all nodes, routers and hosts, and simplicity = would suggest to leave the DAOs in NAs.=20 Also, the shortcut that this proposal enables is not required in all = cases, and when it is required, then there's usually the power that goes = with it. For instance a high priority close control loop cannot be = sleeping for eons, and thus there must be some accepted cost about it.=20 Also, a deployment might really need a set of unicast link scope DAOs as = opposed to a multicast. For instance, a switch and a light bulb need to = talk to one another but the stereo gear does not care. IOW, when energy = is the real constraint, the service discovery might be multicast but the = maintenance and in particular the DAOs could be unicast. Need more digging but there seems to be a direction there... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 4 ao=FBt 2009 17:27 >To: Pascal Thubert (pthubert) >Cc: Richard Kelsey; roll@ietf.org >Subject: Re: [Roll] RA-DIOs and next-door destinations > > >Hi Pascal, > >On Aug 4, 2009, at 6:07 AM, Pascal Thubert (pthubert) wrote: >> An easy addition to the draft is to allow A to also multicast its NA- >> DAO to all nodes. That way, if B is in line of sight from A, B could >> install a route to A::/64 via A's link local regardless of their DAG >> relationship and forward the packets directly. >> >> This is an easy way to address local communication between nodes. >> Note that if A is a host, A would advertise a host route A::1/128. >> >> What do you think? > > >This is definitely an easy addition. I was also thinking of including >DAOs in RAs since RAs are already sent using link-local multicast. >Doing so would definitely reduce transmission overhead for multicast >traffic that can be significant with some link protocols. > >-- >Jonathan Hui From dominique.barthel@orange-ftgroup.com Wed Aug 5 04:11: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 C19A53A715B for ; Wed, 5 Aug 2009 04:11:27 -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.663, 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 kQrNoQEHV+aj for ; Wed, 5 Aug 2009 04:11:27 -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 9FCC83A691A for ; Wed, 5 Aug 2009 04:11:26 -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, 5 Aug 2009 13:11: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, 5 Aug 2009 13:08:22 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL preferred vs. alternate parents Thread-Index: AcoVvQvlNi8EsQXiRFC3zwgr3esYfw== From: To: X-OriginalArrivalTime: 05 Aug 2009 11:11:27.0471 (UTC) FILETIME=[7A1577F0:01CA15BD] Subject: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Aug 2009 11:11:27 -0000 Hello all, I have a question regarding the preferred vs. alternate parents in the RPL draft. The RPL draft consistently states : - 3.3.1.5 "It is recommended that a node maintain its DAG Parent set such that its most preferred parent from the OCP goals also has the greatest depth value in the DAG parent set." - 3.4.1 "For a node N, and its most preferred parent M, .... all parents in the DAG parent set must be of a depth less than or equal to DAGDepth(M)." - 5.2.1 "All nodes in the DAG Parent set should be of a depth less than or equal to the most preferred DAG parent." However, the rationale offered in 3.4.1 isn't quite clear to me. "This mechanism serves to avoid loops in the case where an alternate parent is used- if no alternate parent is deeper than the preferred parent then loops are avoided." It seems to me that once the packet has been forwarded by node N to an alternate parent, it's _that_ parent's responsability to forward it further up the DAG without loop, not node N's. What has the ordering of node N's preferred parent vs node N's alternate parents to do with it? Further, the whole text of 3.4.1 ("more optimum", "same optimality", "less optimum") leads one to think that higher in the DAG is better. Something sounds wrong to me if node N's preferred parent should precisely be the "worse" of its parents. Can anybody offer a substantiated explanation? Thanks Dominique From prvs=461799d11=mukul@uwm.edu Wed Aug 5 06:01: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 9B2433A6BD4 for ; Wed, 5 Aug 2009 06:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 5IjnWA6wpqDG for ; Wed, 5 Aug 2009 06:01:21 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id CB2FD3A6814 for ; Wed, 5 Aug 2009 06:01:20 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 05 Aug 2009 08:01:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3BFA52C382C9; Wed, 5 Aug 2009 08:01:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA6x3oLlOcAS; Wed, 5 Aug 2009 08:01:23 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 101302C382D5; Wed, 5 Aug 2009 08:01:23 -0500 (CDT) Date: Wed, 5 Aug 2009 08:01:23 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1556764272.783351249477282979.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <410596380.782771249477115165.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.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] Source-initiated route discovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Aug 2009 13:01:21 -0000 Hi JP, >> 3) allow some sort of source-initiated route discovery. Right now, a >> non-DAG-root destination can be reached only if it advertizes itself >> via a DAO. >> >Requires discussion .... Could you elaborate on your requirements ? Rather than requiring all possible destinations to originate DAOs, it should be possible for a source to say that it needs a route to a particular destination and ultimately discover such a route. The destination need not send out a DAO until it realizes that some source(s) want to reach it. Thanks Mukul From privateanand@gmail.com Wed Aug 5 18:16: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 F1E843A6ADF for ; Wed, 5 Aug 2009 18:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.197, 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 HOUsr7agQrry for ; Wed, 5 Aug 2009 18:16:14 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id CB3083A67A3 for ; Wed, 5 Aug 2009 18:16:13 -0700 (PDT) Received: by ywh4 with SMTP id 4so871314ywh.17 for ; Wed, 05 Aug 2009 18:16:14 -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=0H8fEyFvgiwqVcZUnwaqp5HwLeEoxTKq86LqyzXE+Ns=; b=H3fq14gUd7qvbguZoSH8/GOuHt4a+IOTbKq22jj4mZEFAXRPmNGXLFNNrZ5rlLkGiY wcT8rzmp9zpjoikvNwSN2WRrDgL04ky2OWfJz9fA43n59pI05I3yuMAc1zIhQlSqJ7wn e3w7u6MC4h3j8W1FO1P9cHRMhbveJ4VNFUKFc= 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=wfSliRQWdajdD2pXqo4x8+Zta4+GA6HYolyoYaW2VYYZX6MrxteSnu8PfPP/l+qTyc MJQACI9jMVXV3xz48+/TUw/YeJkH+AmJLIqZ6u0a4rMafHGrzl5d38AOJ2VzeaagII7H fDjzGItpFlM2YQ5v0k2Z9XbWPhpTCQ7ggNCiQ= MIME-Version: 1.0 Received: by 10.231.33.137 with SMTP id h9mr3280919ibd.15.1249521373871; Wed, 05 Aug 2009 18:16:13 -0700 (PDT) In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> Date: Wed, 5 Aug 2009 21:16:13 -0400 Message-ID: From: "M. B. Anand" To: roll@ietf.org Content-Type: multipart/alternative; boundary=000325575e5ea0fdbd04706edd9f Subject: Re: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Aug 2009 01:16:15 -0000 --000325575e5ea0fdbd04706edd9f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dominique, > > Further, the whole text of 3.4.1 ("more optimum", "same optimality", > "less optimum") leads one to think that higher in the DAG is better. > Something sounds wrong to me if node N's preferred parent should > precisely be the "worse" of its parents. The alternates will themselves be at equal or less depth compared to the preferred, but they may not offer the _node N_ a chance to become less deep because that depends also on the node's optimization metric w.r.t the alternates. If one of the candidate neighbors does offer this, by all means the node can make that candidate the preferred. This is the `moving inwards along the DAG' - section 3.3.1.6, 5th paragraph. Of course, the node N will then need to update its set of parents. So the preferred parent will be the "best" according to the node's optimization. The idea is to forward traffic or move inwards - less deep - in DAGDepth - then there will never be loops. Forwarding sideways - same DAGDepth - is also allowed but that has some chance of loops. Going deeper will create the chance of loops. BTW, in the draft "higher" in the DAG means closer to the root, inwards in the DAG. See for example, Section 3.3.1.6, Section 5.3, point #6, Section 5.3.3.1 etc. I think you mean "lower" when you say " leads one to think that higher in the DAG is better". Regards, Anand. > > Can anybody offer a substantiated explanation? > Thanks > > Dominique > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000325575e5ea0fdbd04706edd9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dominique,

=


Further, the whole text of 3.4.1 ("more optimum", "same opti= mality",
"less optimum") leads one to think that higher in the DAG is bett= er.
Something sounds wrong to me if node N's preferred parent should
precisely be the "worse" of its parents.
<= br>The alternates will themselves be at equal or less depth compared to the= preferred, but they may not offer the _node N_ a chance to become less dee= p because that depends also on the node's optimization metric w.r.t the= alternates. If one of the candidate neighbors does offer this, by all mean= s the node can make that candidate the preferred. This is the `moving inwar= ds along the DAG' - section 3.3.1.6, 5th paragraph. Of course, the node= N will then need to update its set of parents. So the preferred parent wil= l be the "best" according to the node's optimization.

The idea is to forward traffic or move inwards - less deep - in DAGDept= h - then there will never be loops. Forwarding sideways - same DAGDepth - i= s also allowed but that has some chance of loops. Going deeper will create = the chance of loops.

BTW, in the draft "higher" in the DAG means closer to the roo= t, inwards in the DAG. See for example, Section 3.3.1.6, Section 5.3, point= #6, Section 5.3.3.1 etc. I think you mean "lower" when you say &= quot; leads one to think that higher in the DAG is better".

Regards,
Anand.



Can anybody offer a substantiated explanation?
Thanks

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


--000325575e5ea0fdbd04706edd9f-- From dominique.barthel@orange-ftgroup.com Thu Aug 6 02:43: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 77CB83A6D34 for ; Thu, 6 Aug 2009 02:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.552, 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 NnpNEhG4p6Oi for ; Thu, 6 Aug 2009 02:43:07 -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 2173B3A71E9 for ; Thu, 6 Aug 2009 02:43: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); Thu, 6 Aug 2009 11:43:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 11:40:30 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL preferred vs. alternate parents Thread-Index: AcoWM3rhFV2cGJo8QaSDZVBcGMT6DgAQY4nw References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 06 Aug 2009 09:43:06.0756 (UTC) FILETIME=[4D064C40:01CA167A] Subject: Re: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Aug 2009 09:43:08 -0000 Hello Anand, all, =20 Thanks for your answer. I do indeed share the notion that "higher" means = "closer to the root". Let me try to reformulate my question with an example. Node N springs into existence and discovers a few neighbors A, B, C and = D - node A advertises depth 1.25 - node B depth 3.75 - node C depth 4.50 - node D depth 8.25 Given the advertised depth, the link costs and other characteristics, = Node N determines through its objective function that its preferred = parent is node B and that it should take 5.25 (=3D B's depth 3.75 + link = cost 1.50) as its own depth. Node N then fleshes up its DAG by adding alternate parents: - node D is out of the question because it is lower in the DAG (event = horizon). - node A can be considered for inclusion as an alternate parent >From the excerpts of the RPL draft quoted below, as well as from = Pascal's email, I understand that C is not eligible to become an = alternate parent to N. My question is: "Why?" The only tentative explanation I've read so far is in the RPL draft, = Section 3.4.1 "This mechanism serves to avoid loops in the case where an = alternate parent is used- if no alternate parent is deeper than the = preferred parent then loops are avoided." which I don't view as an = explanation. If each node only forwards packet to nodes with lesser = depth (barring forwarding to siblings for this discussion) then loops = will be avoided even is C is included as an alternate parent of N.=20 Am I mistaken somewhere? [Of course, if we enforce depth to be integers and node N's depth to be = exactly its preferred parent's depth + 1, then this whole discussion = goes away. But it is my understanding that we are now dealing with = increments that are not exactly 1, and/or fractional depths, aren't we?] Regards,=20 Dominique Quotes : - 3.3.1.5 "It is recommended that a node maintain its DAG Parent set = such that its most preferred parent from the OCP goals also has the = greatest depth value in the DAG parent set." - 3.4.1 "For a node N, and its most preferred parent M, .... all parents = in the DAG parent set must be of a depth less than or equal to = DAGDepth(M)." - 5.2.1 "All nodes in the DAG Parent set should be of a depth less than = or equal to the most preferred DAG parent." - Pascal's email July 3rd 14:06 +0200 "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." = http://www.ietf.org/mail-archive/web/roll/current/msg01463.html ________________________________ De : M. B. Anand [mailto:privateanand@gmail.com]=20 Envoy=E9 : jeudi 6 ao=FBt 2009 03:15 =C0 : BARTHEL Dominique RD-TECH-GRE Objet : Re: [Roll] RPL preferred vs. alternate parents Hi Dominique, Further, the whole text of 3.4.1 ("more optimum", "same optimality", "less optimum") leads one to think that higher in the DAG is better. Something sounds wrong to me if node N's preferred parent should precisely be the "worse" of its parents. The alternates will themselves be at equal or less depth compared to the = preferred, but they may not offer the _node N_ a chance to become less = deep because that depends also on the node's optimization metric w.r.t = the alternates. If one of the candidate neighbors does offer this, by = all means the node can make that candidate the preferred. This is the = `moving inwards along the DAG' - section 3.3.1.6, 5th paragraph. Of = course, the node N will then need to update its set of parents. So the = preferred parent will be the "best" according to the node's = optimization.=20 The idea is to forward traffic or move inwards - less deep - in DAGDepth = - then there will never be loops. Forwarding sideways - same DAGDepth - = is also allowed but that has some chance of loops. Going deeper will = create the chance of loops. BTW, in the draft "higher" in the DAG means closer to the root, inwards = in the DAG. See for example, Section 3.3.1.6, Section 5.3, point #6, = Section 5.3.3.1 etc. I think you mean "lower" when you say " leads one = to think that higher in the DAG is better".=20 Regards, Anand. Can anybody offer a substantiated explanation? Thanks =09 Dominique _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 From jabeille@cisco.com Thu Aug 6 03:05: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 0288C3A6D28 for ; Thu, 6 Aug 2009 03:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.357 X-Spam-Level: X-Spam-Status: No, score=-9.357 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 n5vAbV49V4Xy for ; Thu, 6 Aug 2009 03:05:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ED5733A71CD for ; Thu, 6 Aug 2009 03:04:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAACNIekqQ/uCKe2dsb2JhbACCVZdwAQEWJAagSogqkE0FhBg X-IronPort-AV: E=Sophos;i="4.43,332,1246838400"; d="scan'208,217";a="46568149" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2009 10:04: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 n76A4YuN014514; Thu, 6 Aug 2009 12:04:34 +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 n76A4Y5f029286; Thu, 6 Aug 2009 10:04:34 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); Thu, 6 Aug 2009 12:04:34 +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_01CA167D.4C50EA7F" Date: Thu, 6 Aug 2009 12:04:27 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8603745286@xmb-ams-33d.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07E20C1B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fw: Next items ... (amended list) Thread-Index: AcoVJIk23/y16mhcRXalNkxPILEzowAfEDNAADbLbeA= References: <7892795E1A87F04CADFCCF41FADD00FC07E20C1B@xmb-ams-337.emea.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 06 Aug 2009 10:04:34.0629 (UTC) FILETIME=[4CA81F50:01CA167D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=37853; t=1249553074; x=1250417074; 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]=20Fw=3A=20=20Next=20items=20...= 20(amended=20list) |Sender:=20; bh=46tBKYqvtg1f3f+3T80D40U0G8jsuZH4URoAABo7Ns4=; b=D465jXBAJ+c2PHim6yyahN91x/2TUA2YgXDqxVia1yJxEEQ6zErp7Rv+Py guVByeBBFRRZgMrDnxzyUQKakmHyE4P2vkJK+F7jUMPRCGGfGyx4f2iHFOw/ jsakPp/yHG; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Fw: Next items ... (amended list) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Aug 2009 10:05:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA167D.4C50EA7F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 a few more items: [Packet format] Clarify the rationale to use RAs/NAs. More precisely:=20 - are RAs sent for router discovery/prefix discovery the same as those = used by ROLL (same timer).=20 -- If yes, does it impact the way router discovery/prefix discovery work = (preformance, do they really have the same timing constraints?) -- if yes, what is the approach with regards to update of RFC4861 = (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while = ROLL is not)? -- if not, why not using a specific packet? - NA:=20 -- Are NAs sent for ROLL used for anything else? If not why not use a = specific packet to carry DAOs? -- NAs are already pretty overloaded (DAD, NUD, Address resolution), = using a different packet may bring NA processing complexity down.=20 =20 Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: mercredi 5 ao=FBt 2009 09:59 To: Jerald.P.Martocci@jci.com; JP Vasseur (jvasseur) Cc: ROLL WG Subject: Re: [Roll] Fw: Next items ... (amended list) =09 =09 Hi Jerry: =20 This is a very good point. Long debated at 6LoWPAN, I suggest you dig = into the ML'logs on the web to find out what people said. =20 My own conclusion: - This is an adaptation layer problem, not a L3 problem o Some MACs are time synchronized or scheduled so it's not an issue = there o Some MACs use long preamble to wait for sleeping nodes and the = methed appears to do well too. =20 - Yet L3 has to be designed intelligently to cope with that, = in particular by reducing the need of multicast o This is what 6LoWPAN ND does with the whiteboard mechanism o This is what RPL does with the DAGs and DAOs as Jonathan explained = so well in the "why a DAG" discussion =20 The way I see it, some adaptation layers might want to make multicast a = bit more reliable and such an adaptation layer could actually transform = multicast in a series of unicast that is adapted to the sleep sequence = of the devices. In fact, it makes a lot more sense to cache RAs in a = router than it does in a WIFI access point. =20 DAOs can (and should) be used to advertise mcast listeners. I'm pretty = sure this will end up properly spelled out in the spec. The same process = could also be used to ask a router to store and forward FF02::1 between = its attached nodes. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com Sent: mardi 4 ao=FBt 2009 18:56 To: JP Vasseur (jvasseur) Cc: ROLL WG Subject: [Roll] Fw: Next items ... (amended list) =20 =09 =09 JP,=20 =09 RPL currently makes no mention of sleepy devices. These will be very = commonplace in WSNs. I would like to amend my list below and add sleepy = device management. RPL needs to state what happens to packets routed to = sleepy devices while they are asleep. Are they dropped? Will a proxy = manage the packet until the device awakens? Will the last router return = an error to the source?=20 =09 =09 ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on = 08/04/2009 11:43 AM -----=20 Jerald.P.Martocci@jci.com=20 Sent by: roll-bounces@ietf.org=20 08/03/2009 01:09 PM=20 To JP Vasseur =20 cc ROLL WG =20 Subject Re: [Roll] Next items ... =20 =09 =09 =09 =09 =09 I would like the following questions answered on subsequent revisions = of the draft:=20 =09 =09 a) What is the roll of 'siblings'? They are in the current RPL = document, yet seem to be demoted from parental links. As I read the = draft, one cannot use a sibling link unless the parental links are = exhausted. The nodes don't seem to explicitly define sibling links. =20 =09 b) What is the plan on communication to devices within direct radio = range? As I read the draft unless a node is made a 'parent', or = possibly a 'sibling' it cannot be communicated with. However, Anand = mentions in his memo that at the Stockholm meeting there was discussion = on directly connected devices. Unfortunately, I couldn't attend the = meeting.=20 =09 c) What are the approximate timer values for RPL? The document gives = no indication as to these timers, hence I can't calculate how long a = floating DAG may be dislodged from its network. In a real-time facility = management control system, all nodes are monitored for falling off-line. = If the convergence time is too long (more than 1 minute), the devices = will be flagged off-line and reported to the customer.=20 =09 d) What is the plan for security? RPL doesn't currently weigh in on = the topic. Are security policies optional or mandatory? Must the = policy be consistent with the rest of the enterprise's IT security on = other parts of the network? Will security require nodes to keep state = info as Rene suggests?=20 =09 e) What requirements from the 4 requirement drafts are being = considered? When the DT first was engaged, it said it would publish the = list of requirements as an appendix and note if the current draft = supported which requirement. This hasn't occurred and may be adding to = the email angst. As a requirement's author, I would rather know up = front that some of my MUST requirements are not being considered.=20 =09 f) What is the expected frame overhead size based on all the above = criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, = UDP/TCP. We need to add in the encryption and authentication overhead; = and now maybe source routing. I realize ROLL is trying to be agnostic = to L2, however in practice 802.15.4 is the only game in town. It only = carries a 128 by packet size. The DT/WG should at least give an = accounting of the expected frame overhead so we can determine what L2s = are feasible for the protocol.=20 =09 g) What routing data must persist a warmstart/coldstart? The overhead = to establish a DAG is significant. We should consider what data might = be able to transcend a network reboot to minimize communication startup = bottlenecks.=20 =09 h) How will packets routed to asleep devices be handled? will they be = dropped? buffered by a proxy? will a router return an 'asleep' error to = the source? =20 =09 As Pascal has noted in previous emails, some of these issues may be = considered out-of bounds for the protocol and should be an = implementation decision. That may indeed be true, but RPL should state = its case explicitly. In the Building Market, it is multi-disciplined = (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority = prescribes operation, the chances of LLN node-to-node interoperability = are moot.=20 =09 Thanks,=20 =09 Jerry=20 =09 =09 =09 JP Vasseur =20 Sent by: roll-bounces@ietf.org=20 08/03/2009 02:27 AM=20 =20 To ROLL WG =20 cc =09 Subject [Roll] Next items ... =20 =09 =09 =09 =09 =09 Dear all, =09 As a reminder, RPL being a WG ID, it now "belongs" to the WG. =09 Several working items have been listed but before starting to address =20 all open items in some unstructured way, I would like to propose the =20 following. =09 It clearly appeared that there were some misunderstandings on how RPL =20 works. The DT did an outstanding job but I also understand that =20 several areas must be clarified. So before changing RPL, adding new =20 mechanisms (e.g. to optimize P2P, support source routing, loop =20 detection, ... ), I would first want you to list your questions on the = mailing list on each area for which you would like to get =20 clarification. This will help make sure that everybody is indeed on =20 the same page. =09 From there, we will continue to quickly move forward, I will track =20 the list of open items via the issue tracker. =09 Many Thanks. =09 JP. _______________________________________________ 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_01CA167D.4C50EA7F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
a few more items:
[Packet format] Clarify the rationale to use = RAs/NAs. More=20 precisely: 
- are RAs sent for router discovery/prefix = discovery the=20 same as those used by ROLL (same timer).
-- If yes, does it impact the way router = discovery/prefix=20 discovery work (preformance, do they really have the same timing=20 constraints?)
-- if yes, what is the approach with regards to = update of=20 RFC4861 (6lowpan-nd is not in scope in my opinion as it is L2 dependant, = while=20 ROLL is not)?
-- if not, why not using a specific=20 packet?
- NA:
-- Are NAs sent for ROLL used for anything = else? If not why=20 not use a specific packet to carry DAOs?
-- NAs are already pretty overloaded (DAD, NUD, = Address=20 resolution), using a different packet may bring NA processing complexity = down.=20
 
Best,
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert=20 (pthubert)
Sent: mercredi 5 ao=FBt 2009 09:59
To:=20 Jerald.P.Martocci@jci.com; JP Vasseur (jvasseur)
Cc: ROLL=20 WG
Subject: Re: [Roll] Fw: Next items ... (amended=20 list)

Hi=20 Jerry:

 

This=20 is a very good point. Long debated at 6LoWPAN, I suggest you dig into = the=20 ML=92logs on the web to find out what people = said.

 

My=20 own conclusion:

-         =20 This=20 is an adaptation layer problem, not a L3 problem

o   = Some=20 MACs are time synchronized or scheduled so it=92s not an issue=20 there

o   = Some=20 MACs use long preamble to wait for sleeping nodes and the methed = appears to do=20 well too.

 

-         =20 Yet=20 L3 has to be designed intelligently to cope with that, in particular = by=20 reducing the need of multicast

o   = This=20 is what 6LoWPAN ND does with the whiteboard = mechanism

o   = This=20 is what RPL does with the DAGs and DAOs as Jonathan explained so well = in the=20 =93why a DAG=94 discussion

 

The=20 way I see it, some adaptation layers might want to make multicast a = bit more=20 reliable and such an adaptation layer could actually transform = multicast in a=20 series of unicast that is adapted to the sleep sequence of the = devices. In=20 fact, it makes a lot more sense to cache RAs in a router than it does = in a=20 WIFI access point.

 

DAOs=20 can (and should) be used to advertise mcast listeners. I=92m pretty = sure this=20 will end up properly spelled out in the spec. The same process could = also be=20 used to ask a router to store and forward FF02::1 between its attached = nodes.

 

Pascal

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com
Sent: mardi 4 ao=FBt 2009=20 18:56
To: JP Vasseur (jvasseur)
Cc: ROLL=20 WG
Subject: [Roll] Fw: Next items ... (amended=20 list)

 



JP,=20

RPL=20 currently makes no mention of sleepy devices.  These will be very = commonplace in WSNs.  I would like to amend my list below and add = sleepy=20 device management.  RPL needs to state what happens to packets = routed to=20 sleepy devices while they are asleep.  Are they dropped? =  Will a=20 proxy manage the packet until the device awakens? Will the last router = return=20 an error to the source?


-----=20 Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 = 11:43 AM=20 -----

Jerald.P.Martocci@jci.com=20
Sent by:=20 roll-bounces@ietf.org

08/03/2009=20 01:09 PM

To

JP=20 Vasseur <jvasseur@cisco.com> =

cc

ROLL=20 WG <roll@ietf.org>

Subject

Re:=20 [Roll] Next items = ...

 





I = would like=20 the following questions answered on subsequent revisions of the = draft:=20


a) = What is the=20 roll of 'siblings'?  They are in the current RPL document, yet = seem to be=20 demoted from parental links.  As I read the draft, one cannot use = a=20 sibling link unless the parental links are exhausted.  The nodes = don't=20 seem to explicitly define sibling links.  

b) = What is the=20 plan on communication to devices within direct radio range?  As I = read=20 the draft unless a node is made a 'parent', or possibly a 'sibling' it = cannot=20 be communicated with.  However, Anand mentions in his memo that = at the=20 Stockholm meeting there was discussion on directly connected devices.=20  Unfortunately, I couldn't attend the meeting.

c) = What are the=20 approximate timer values for RPL?  The document gives no = indication as to=20 these timers, hence I can't calculate how long a floating DAG may be = dislodged=20 from its network.  In a real-time facility management control = system, all=20 nodes are monitored for falling off-line.  If the convergence = time is too=20 long (more than 1 minute), the devices will be flagged off-line and = reported=20 to the customer.

d) = What is the=20 plan for security?  RPL doesn't currently weigh in on the topic.=20  Are security policies optional or mandatory?  Must the = policy be=20 consistent with the rest of the enterprise's IT security on other = parts of the=20 network?  Will security require nodes to keep state info as Rene=20 suggests?

e) = What=20 requirements from the 4 requirement drafts are being considered? =  When=20 the DT first was engaged, it said it would publish the list of = requirements as=20 an appendix and note if the current draft supported which requirement. =  This hasn't occurred and may be adding to the email angst. =  As a=20 requirement's author, I would rather know up front that some of my = MUST=20 requirements are not being considered.

f) = What is the=20 expected frame overhead size based on all the above criteria? =  6LoWPAN=20 requires subheader overhead for mesh, fragmentation, UDP/TCP.  We = need to=20 add in the encryption and authentication overhead; and now maybe = source=20 routing.  I realize ROLL is trying to be agnostic to L2, however = in=20 practice 802.15.4 is the only game in town.  It only carries a = 128 by=20 packet size.  The DT/WG should at least give an accounting of the = expected frame overhead so we can determine what L2s are feasible for = the=20 protocol.

g) = What routing=20 data must persist a warmstart/coldstart?  The overhead to = establish a DAG=20 is significant.  We should consider what data might be able to = transcend=20 a network reboot to minimize communication startup bottlenecks. =

h)=20 How will packets routed to asleep devices be handled? =  will they be=20 dropped? buffered by a proxy? will a router return an 'asleep' error = to the=20 source?  

As = Pascal has=20 noted in previous emails, some of these issues may be considered = out-of bounds=20 for the protocol and should be an implementation decision.  That = may=20 indeed be true, but RPL should state its case explicitly.  In the = Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and=20 multi-vendor.  Unless some higher authority prescribes operation, = the=20 chances of LLN node-to-node interoperability are moot. =

Thanks,=20

Jerry=20


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

08/03/2009=20 02:27 AM

 

To

ROLL=20 WG <roll@ietf.org>

cc

Subject

[Roll]=20 Next items = ...

 





Dear=20 all,

As a reminder, RPL being a WG ID, it now = "belongs" to the=20 WG.

Several working items have been listed but before = starting=20 to address  
all open items in some unstructured way, = I would=20 like to propose the  
following.

It = clearly=20 appeared that there were some misunderstandings on how RPL=20  
works. The DT did an outstanding job but I also = understand=20 that  
several areas must be clarified. So before = changing=20 RPL, adding new  
mechanisms (e.g. to optimize P2P, = support=20 source routing, loop  
detection, ... ), I would = first want=20 you to list your questions on the  
mailing list on = each area=20 for which you would like to get  
clarification. This = will=20 help make sure that everybody is indeed on  
the same = page.

From there, we will continue to quickly move = forward, I=20 will track  
the list of open items via the issue=20 tracker.

Many=20 = Thanks.

JP.
_________________________________= ______________
Roll=20 mailing=20 = list
Roll@ietf.org
https://www.ietf.org/mailman/l= istinfo/roll
_______________________________________________
Roll = mailing=20 = list
Roll@ietf.org
https://www.ietf.org/mailman/l= istinfo/roll

------_=_NextPart_001_01CA167D.4C50EA7F-- From privateanand@gmail.com Thu Aug 6 10:43: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 945E028C10F for ; Thu, 6 Aug 2009 10:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Z7uwA7bfgnKV for ; Thu, 6 Aug 2009 10:43:18 -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 4A9653A6A24 for ; Thu, 6 Aug 2009 10:43:18 -0700 (PDT) Received: by yxe3 with SMTP id 3so1403652yxe.29 for ; Thu, 06 Aug 2009 10:43:19 -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; bh=0iL7X6iaRE30olN8PnAsppFtsUAmtfzkGGMu9/EHPvM=; b=KF0VT22Lh0B6jHJzTP3IaWaPOoa983oVDJP0+sergU3JJXSMjBKmiLInElReNbg2GB V3kdhQepk8lMx2FXBVcMThcp9qtKPN/GwOI8ukolFkffnXDWoZqCPTiip/Qwbnxuc8Jv JEkKBL2YDEyyt2sIuYouGahsFOHGOG49BtIpY= 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; b=QlpEjW0cLK3Bftug2D1AgTwRNkRhJzPuHzqDY1p/+DzrWyoob/OtL0/DzyMwX7H1qe 6TLonkxCQkVcRoLcZ5WGCwM8GXZWuwfSz058UbOU7icg1ODitApa61zhQ1Z5W5vdsfWN K4r+qu4pCtJbzXZkEJp8J0ORmqgMVXg8EH2Mw= MIME-Version: 1.0 Received: by 10.231.19.7 with SMTP id y7mr305121iba.9.1249580599233; Thu, 06 Aug 2009 10:43:19 -0700 (PDT) In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> Date: Thu, 6 Aug 2009 13:43:19 -0400 Message-ID: From: "M. B. Anand" To: dominique.barthel@orange-ftgroup.com Content-Type: multipart/alternative; boundary=00221532cf74bc4c7104707ca7b5 Cc: roll@ietf.org Subject: Re: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Aug 2009 17:43:19 -0000 --00221532cf74bc4c7104707ca7b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dominique, On Thu, Aug 6, 2009 at 5:40 AM, wrote: > Hello Anand, all, > > Thanks for your answer. I do indeed share the notion that "higher" means > "closer to the root". > Let me try to reformulate my question with an example. > > Node N springs into existence and discovers a few neighbors A, B, C and D > - node A advertises depth 1.25 > - node B depth 3.75 > - node C depth 4.50 > - node D depth 8.25 > Given the advertised depth, the link costs and other characteristics, Node > N determines through its objective function that its preferred parent is > node B and that it should take 5.25 (= B's depth 3.75 + link cost 1.50) as > its own depth. > Node N then fleshes up its DAG by adding alternate parents: > - node D is out of the question because it is lower in the DAG (event > horizon). > - node A can be considered for inclusion as an alternate parent > From the excerpts of the RPL draft quoted below, as well as from Pascal's > email, I understand that C is not eligible to become an alternate parent to > N. > My question is: "Why?" > > The only tentative explanation I've read so far is in the RPL draft, > Section 3.4.1 "This mechanism serves to avoid loops in the case where an > alternate parent is used- if no alternate parent is deeper than the > preferred parent then loops are avoided." which I don't view as an > explanation. If each node only forwards packet to nodes with lesser depth > (barring forwarding to siblings for this discussion) then loops will be > avoided even is C is included as an alternate parent of N. > Am I mistaken somewhere? > > [Of course, if we enforce depth to be integers and node N's depth to be > exactly its preferred parent's depth + 1, then this whole discussion goes > away. But it is my understanding that we are now dealing with increments > that are not exactly 1, and/or fractional depths, aren't we?] Ah, I see what you meant. BTW, DAGDepth is an 8-bit unsigned integer, but the discussion doesn't go away since increments larger than 1 are possible, as you pointed out. You can have depth(B) = 4, depth(C) = 5, depth (N thru B) = 6, with the same point. In that case, you are saying why can't the node pick as its alternate the set of neighbors that are all less deep than _itself_ . In that example, node N could _forward_ to C but could not move to C without co-ordinating everyone else behind it since that would increase its depth (assuming that is so - if not, N could, if allowed by its optimization function, switch to C as the preferred). The idea I think is to construct a graph to allow each node to have a set of parents that could offer the node a better depth than its "preferred" because then it could switch to one of them without delay if needed without affecting anything else. A particular neighbor may be preferred for other reasons than depth depending on what is being optimized. All others may be less preferred but a node can go to any of them without increasing its depth. The parent set has also to do with the DAG structure and its maintenance and not just the temporary forwarding - it would be the subset of neighbors you could forward to that you can also move to. Best regards, Anand. --00221532cf74bc4c7104707ca7b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dominique,

On Thu, Aug 6, 2009 at 5:40 AM= , <dominique.barthel@orange-ftgroup.com> wrote:
Hello Anand, all,

Thanks for your answer. I do indeed share the notion that "higher"= ; means "closer to the root".
Let me try to reformulate my question with an example.

Node N springs into existence and discovers a few neighbors A, B, C and D - node A advertises depth 1.25
- node B depth 3.75
- node C depth 4.50
- node D depth 8.25
Given the advertised depth, the link costs and other characteristics, Node = N determines through its objective function that its preferred parent is no= de B and that it should take 5.25 (=3D B's depth 3.75 + link cost 1.50)= as its own depth.
Node N then fleshes up its DAG by adding alternate parents:
- node D is out of the question because it is lower in the DAG (event horiz= on).
- node A can be considered for inclusion as an alternate parent
>From the excerpts of the RPL draft quoted below, as well as from Pascal'= ;s email, I understand that C is not eligible to become an alternate parent= to N.
My question is: "Why?"

The only tentative explanation I've read so far is in the RPL draft, Se= ction 3.4.1 "This mechanism serves to avoid loops in the case where an= alternate parent is used- if no alternate parent is deeper than the prefer= red parent then loops are avoided." which I don't view as an expla= nation. If each node only forwards packet to nodes with lesser depth (barri= ng forwarding to siblings for this discussion) then loops will be avoided e= ven is C is included as an alternate parent of N.
Am I mistaken somewhere?

[Of course, if we enforce depth to be integers and node N's depth to be= exactly its preferred parent's depth + 1, then this whole discussion g= oes away. But it is my understanding that we are now dealing with increment= s that are not exactly 1, and/or fractional depths, aren't we?]


Ah, I see what you meant. BTW, DAGDepth is an 8-bit unsigned i= nteger, but the discussion doesn't go away since increments larger than= 1 are possible, as you pointed out. You can have depth(B) =3D 4, depth(C) = =3D 5, depth (N thru B) =3D 6, with the same point.

In that case, you are saying why can't the node pick as its alterna= te the set of neighbors that are all less deep than _itself_ .

In th= at example, node N could _forward_ to C but could not move to C without co-ordinating everyone else behind it since that would increase its depth (assuming that is so - if not, N could, if allowed by its optimiz= ation function, switch to C as the preferred).

The idea I think is t= o construct a graph to allow each node to have a set of parents that could offer the node a better depth than its "preferred" because = then it could switch to one of them without delay if needed without affecting anything else. A particular neighbor may be preferred for other reasons than depth depending on what is being optimized. All others may be less preferred but a node can go to any of them without increasing its depth. The parent set has also to do with the DAG structure and its maintenance and not just the temporary forwarding - it would be the= subset of neighbors you could forward to that you can also move to.

Best regards,
Anand.

--00221532cf74bc4c7104707ca7b5-- From zach@sensinode.com Thu Aug 6 23:17: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 07DD53A6B2A for ; Thu, 6 Aug 2009 23:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 VY+Vj67BCqM0 for ; Thu, 6 Aug 2009 23:17:46 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 07F803A6D27 for ; Thu, 6 Aug 2009 23:17:45 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n776Hffc011398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Aug 2009 09:17:41 +0300 Message-ID: <4A7BC707.70108@sensinode.com> Date: Fri, 07 Aug 2009 09:17:43 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <7892795E1A87F04CADFCCF41FADD00FC07E20C1B@xmb-ams-337.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8603745286@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8603745286@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Fw: Next items ... (amended list) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Aug 2009 06:17:48 -0000 Julien, Julien Abeille (jabeille) wrote: > Hi all, > > a few more items: > [Packet format] Clarify the rationale to use RAs/NAs. More precisely: > - are RAs sent for router discovery/prefix discovery the same as those > used by ROLL (same timer). > -- If yes, does it impact the way router discovery/prefix discovery work > (preformance, do they really have the same timing constraints?) > -- if yes, what is the approach with regards to update of RFC4861 > (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while > ROLL is not)? As many 6LoWPAN vendors will be making use of RPL for routing, we should definitely define the binding of RPL to 6LoWPAN-ND in addition to RFC4861. But I think this was already the plan? Although 6LoWPAN-ND isn't tied to just IEEE 802.15.4, it does target a class of link-layer technologies. The timings might already be more appropriate for RPL, but that should be checked as well. We are in the process of defining periods and timeouts next week for nd-05 so if ROLL has any requirements now is the time. As Jonathan and Pascal are authors of both, you guys can already take it into account. When using RPL with 6LoWPAN-ND we would of course piggyback DAOs on Node Registration message flows which are sent periodically to the ER anyways. Zach > -- if not, why not using a specific packet? > - NA: > -- Are NAs sent for ROLL used for anything else? If not why not use a > specific packet to carry DAOs? > -- NAs are already pretty overloaded (DAD, NUD, Address resolution), > using a different packet may bring NA processing complexity down. > Best, > Julien > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Pascal Thubert (pthubert) > *Sent:* mercredi 5 août 2009 09:59 > *To:* Jerald.P.Martocci@jci.com; JP Vasseur (jvasseur) > *Cc:* ROLL WG > *Subject:* Re: [Roll] Fw: Next items ... (amended list) > > Hi Jerry: > > > > This is a very good point. Long debated at 6LoWPAN, I suggest you > dig into the ML’logs on the web to find out what people said. > > > > My own conclusion: > > - This is an adaptation layer problem, not a L3 problem > > o Some MACs are time synchronized or scheduled so it’s not an > issue there > > o Some MACs use long preamble to wait for sleeping nodes and the > methed appears to do well too. > > > > - Yet L3 has to be designed intelligently to cope with > that, in particular by reducing the need of multicast > > o This is what 6LoWPAN ND does with the whiteboard mechanism > > o This is what RPL does with the DAGs and DAOs as Jonathan > explained so well in the “why a DAG” discussion > > > > The way I see it, some adaptation layers might want to make > multicast a bit more reliable and such an adaptation layer could > actually transform multicast in a series of unicast that is adapted > to the sleep sequence of the devices. In fact, it makes a lot more > sense to cache RAs in a router than it does in a WIFI access point. > > > > DAOs can (and should) be used to advertise mcast listeners. I’m > pretty sure this will end up properly spelled out in the spec. The > same process could also be used to ask a router to store and forward > FF02::1 between its attached nodes. > > > > Pascal > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Jerald.P.Martocci@jci.com > *Sent:* mardi 4 août 2009 18:56 > *To:* JP Vasseur (jvasseur) > *Cc:* ROLL WG > *Subject:* [Roll] Fw: Next items ... (amended list) > > > > > > JP, > > RPL currently makes no mention of sleepy devices. These will be > very commonplace in WSNs. I would like to amend my list below and > add sleepy device management. RPL needs to state what happens to > packets routed to sleepy devices while they are asleep. Are they > dropped? Will a proxy manage the packet until the device awakens? > Will the last router return an error to the source? > > > ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on > 08/04/2009 11:43 AM ----- > > *Jerald.P.Martocci@jci.com* > Sent by: roll-bounces@ietf.org > > 08/03/2009 01:09 PM > > > > To > > > > JP Vasseur > > cc > > > > ROLL WG > > Subject > > > > Re: [Roll] Next items ... > > > > > > > > > > I would like the following questions answered on subsequent > revisions of the draft: > > > a) What is the roll of 'siblings'? They are in the current RPL > document, yet seem to be demoted from parental links. As I read the > draft, one cannot use a sibling link unless the parental links are > exhausted. The nodes don't seem to explicitly define sibling links. > > b) What is the plan on communication to devices within direct radio > range? As I read the draft unless a node is made a 'parent', or > possibly a 'sibling' it cannot be communicated with. However, Anand > mentions in his memo that at the Stockholm meeting there was > discussion on directly connected devices. Unfortunately, I couldn't > attend the meeting. > > c) What are the approximate timer values for RPL? The document > gives no indication as to these timers, hence I can't calculate how > long a floating DAG may be dislodged from its network. In a > real-time facility management control system, all nodes are > monitored for falling off-line. If the convergence time is too long > (more than 1 minute), the devices will be flagged off-line and > reported to the customer. > > d) What is the plan for security? RPL doesn't currently weigh in on > the topic. Are security policies optional or mandatory? Must the > policy be consistent with the rest of the enterprise's IT security > on other parts of the network? Will security require nodes to keep > state info as Rene suggests? > > e) What requirements from the 4 requirement drafts are being > considered? When the DT first was engaged, it said it would publish > the list of requirements as an appendix and note if the current > draft supported which requirement. This hasn't occurred and may be > adding to the email angst. As a requirement's author, I would > rather know up front that some of my MUST requirements are not being > considered. > > f) What is the expected frame overhead size based on all the above > criteria? 6LoWPAN requires subheader overhead for mesh, > fragmentation, UDP/TCP. We need to add in the encryption and > authentication overhead; and now maybe source routing. I realize > ROLL is trying to be agnostic to L2, however in practice 802.15.4 is > the only game in town. It only carries a 128 by packet size. The > DT/WG should at least give an accounting of the expected frame > overhead so we can determine what L2s are feasible for the protocol. > > g) What routing data must persist a warmstart/coldstart? The > overhead to establish a DAG is significant. We should consider what > data might be able to transcend a network reboot to minimize > communication startup bottlenecks. > > *h) How will packets routed to asleep devices be handled?* * will > they be dropped? buffered by a proxy? will a router return an > 'asleep' error to the source? * > > As Pascal has noted in previous emails, some of these issues may be > considered out-of bounds for the protocol and should be an > implementation decision. That may indeed be true, but RPL should > state its case explicitly. In the Building Market, it is > multi-disciplined (HVAC, Fire, Lighting) and multi-vendor. Unless > some higher authority prescribes operation, the chances of LLN > node-to-node interoperability are moot. > > Thanks, > > Jerry > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 08/03/2009 02:27 AM > > > > > > To > > > > ROLL WG > > cc > > > > Subject > > > > [Roll] Next items ... > > > > > > > > > > Dear all, > > As a reminder, RPL being a WG ID, it now "belongs" to the WG. > > Several working items have been listed but before starting to address > all open items in some unstructured way, I would like to propose the > following. > > It clearly appeared that there were some misunderstandings on how RPL > works. The DT did an outstanding job but I also understand that > several areas must be clarified. So before changing RPL, adding new > mechanisms (e.g. to optimize P2P, support source routing, loop > detection, ... ), I would first want you to list your questions on the > mailing list on each area for which you would like to get > clarification. This will help make sure that everybody is indeed on > the same page. > > From there, we will continue to quickly move forward, I will track > the list of open items via the issue tracker. > > Many Thanks. > > JP. > _______________________________________________ > 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 -- 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 jvasseur@cisco.com Fri Aug 7 01:25: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 6D3383A6A70 for ; Fri, 7 Aug 2009 01:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.536 X-Spam-Level: X-Spam-Status: No, score=-9.536 tagged_above=-999 required=5 tests=[AWL=1.063, 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 ZF7O8IC8xFPU for ; Fri, 7 Aug 2009 01:25:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1E4273A680D for ; Fri, 7 Aug 2009 01:25:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAADKCe0qQ/uCLe2dsb2JhbACaQAEBFiQGnCSIKpAYBYQWigs X-IronPort-AV: E=Sophos;i="4.43,340,1246838400"; d="scan'208";a="46637946" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2009 08:25:46 +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 n778PjtO003910; Fri, 7 Aug 2009 10:25:45 +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 n778Pj5O001565; Fri, 7 Aug 2009 08:25:45 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:25:46 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:25:45 +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: Fri, 7 Aug 2009 10:25:44 +0200 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 08:25:45.0520 (UTC) FILETIME=[A90BA300:01CA1738] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16810.004 X-TM-AS-Result: No--22.046800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1006; t=1249633546; x=1250497546; 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]=20Loop=20detection=20between=20s ibling |Sender:=20; bh=sWwqoW7J3DcnMXsT/Ul6wP18IhuoqhcEnXuW6/3SpXk=; b=sPKzjOf0n6A/XLOO6C4C0p/m2JtCPbCU/aIbudlDJhbHsqmdjOi8Ll+R3/ Q0YA0TYTOZLlZq8iXakHHyOmjhqHnblgrxXDVZWpWg/HpU3r/Om8zs1vpGgd Xvb+VdQ77z; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 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: Fri, 07 Aug 2009 08:25:45 -0000 Hi, On Jul 27, 2009, at 1:01 PM, Mukul Goyal wrote: > JP, > > Please give more explanation. I did not understand at all. > You basically flag the packet when you forward to a sibling since you know that there might be a risk of loops. If the flagged packet comes back you detect the loop, simple, no overhead. Cheers. JP. > 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 rogge@fgan.de Fri Aug 7 01:34: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 63ACE3A6CE9 for ; Fri, 7 Aug 2009 01:34:40 -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 itUotOGV-IB1 for ; Fri, 7 Aug 2009 01:34:39 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 5F4843A6E7F for ; Fri, 7 Aug 2009 01:34:39 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MZKuN-0003sw-4w; Fri, 07 Aug 2009 10:34:39 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MZKuM-0005VT-O2; Fri, 07 Aug 2009 10:34:38 +0200 From: Henning Rogge To: roll@ietf.org Date: Fri, 7 Aug 2009 10:35:04 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2774532.gBrZqb5aVB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908071035.09589.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9661/Thu Aug 6 20:40:01 2009) by mailguard.fgan.de X-Scan-Signature: 0f287e88b12fb29766ba98e7b870a51f 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: Fri, 07 Aug 2009 08:34:40 -0000 --nextPart2774532.gBrZqb5aVB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri August 7 2009 10:25:44 schrieb JP Vasseur: > Hi, > > On Jul 27, 2009, at 1:01 PM, Mukul Goyal wrote: > > JP, > > > > Please give more explanation. I did not understand at all. > > You basically flag the packet when you forward to a sibling since you > know that > there might be a risk of loops. If the flagged packet comes back you > detect the > loop, simple, no overhead. If every node has to do this you need a variable number of flags in each=20 packet, which can be an MTU problem. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart2774532.gBrZqb5aVB 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) iEYEABECAAYFAkp75zgACgkQRIfGfFXsz+DmjACfZtuIhO4XqexX7HnR15hXMMn5 VH8AnizRIugnyJwhWd7ZvLHELpWCt8yc =ZCrG -----END PGP SIGNATURE----- --nextPart2774532.gBrZqb5aVB-- From jvasseur@cisco.com Fri Aug 7 02:09: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 946293A6CAF for ; Fri, 7 Aug 2009 02:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.614 X-Spam-Level: X-Spam-Status: No, score=-7.614 tagged_above=-999 required=5 tests=[AWL=-1.015, 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 fqv26aNHSY5F for ; Fri, 7 Aug 2009 02:09:37 -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 284D53A6EB2 for ; Fri, 7 Aug 2009 02:09:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAqMe0qrR7PE/2dsb2JhbAC3PIgqkBsFhBY X-IronPort-AV: E=Sophos;i="4.43,340,1246838400"; d="scan'208";a="182067227" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2009 09:09:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7799ULb011575; Fri, 7 Aug 2009 02:09:30 -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 n7799KfU017776; Fri, 7 Aug 2009 09:09:30 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 11:09:28 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 11:09:27 +0200 Message-Id: From: JP Vasseur To: Henning Rogge In-Reply-To: <200908071035.09589.rogge@fgan.de> 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, 7 Aug 2009 11:09:26 +0200 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908071035.09589.rogge@fgan.de> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 09:09:27.0918 (UTC) FILETIME=[C41DD0E0:01CA173E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1345; t=1249636170; x=1250500170; 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]=20Loop=20detection=20between=20s ibling |Sender:=20; bh=KjMZnV4MLQJ0ULo69I82EfGSk0qF6YN0rif/gPDAUE8=; b=bT6ysyHekMefi/O1fBUKGUzHUMKvGfN/nkNuRZoov0s/IZa3/F3IucNK4m ocCLdznNvTuuXnjcdLMU2BChe/btOD7w/lY4D7lb0O+IbOIpq2Lv4K2S06yv W7Jpr9UeLe; 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] 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: Fri, 07 Aug 2009 09:09:38 -0000 On Aug 7, 2009, at 10:35 AM, Henning Rogge wrote: > Am Fri August 7 2009 10:25:44 schrieb JP Vasseur: >> Hi, >> >> On Jul 27, 2009, at 1:01 PM, Mukul Goyal wrote: >>> JP, >>> >>> Please give more explanation. I did not understand at all. >> >> You basically flag the packet when you forward to a sibling since you >> know that >> there might be a risk of loops. If the flagged packet comes back you >> detect the >> loop, simple, no overhead. > If every node has to do this you need a variable number of flags in =20= > each > packet, which can be an MTU problem. not is you use an existing field or even a new short one with a =20 reasonably good pseudo-random generator (there are many) (collisions probability will =20= be extremely low). JP. > > Henning Rogge > > ************************************************* > Diplom Informatiker Henning Rogge > Forschungsgesellschaft f=FCr > Angewandte Naturwissenschaften e. V. (FGAN) > Neuenahrer Str. 20, 53343 Wachtberg, Germany > Tel.: 0049 (0)228 9435-961 > Fax: 0049 (0)228 9435-685 > E-Mail: rogge@fgan.de > Web: www.fgan.de > ************************************************ > Sitz der Gesellschaft: Bonn > Registergericht: Amtsgericht Bonn VR 2530 > Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender > (Stellv.) > From rogge@fgan.de Fri Aug 7 03:41: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 A05EA3A6804 for ; Fri, 7 Aug 2009 03:41:43 -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 tuFEjLjW3HAg for ; Fri, 7 Aug 2009 03:41:40 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9DCA63A6896 for ; Fri, 7 Aug 2009 03:41:40 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MZMtJ-0007QR-7J; Fri, 07 Aug 2009 12:41:41 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MZMtI-00062s-O9; Fri, 07 Aug 2009 12:41:40 +0200 From: Henning Rogge To: JP Vasseur Date: Fri, 7 Aug 2009 12:42:04 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908071035.09589.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart27773541.cfMjUOV7J6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908071242.09718.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9662/Fri Aug 7 09:43:35 2009) by mailguard.fgan.de X-Scan-Signature: 0f287e88b12fb29766ba98e7b870a51f Cc: roll@ietf.org 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: Fri, 07 Aug 2009 10:41:44 -0000 --nextPart27773541.cfMjUOV7J6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri August 7 2009 11:09:26 schrieb JP Vasseur: > not is you use an existing field or even a new short one with a > reasonably good > pseudo-random generator (there are many) (collisions probability will > be extremely > low). I'm not sure I understand your idea... let's assume we have a chain of 10 nodes which forward traffic towards a=20 target. Each of the nodes have to mark the package in a unique way without= =20 erasing other marks to be able to detect a routing loop. How do you plan to use a random number generator to compress the "mark"=20 information down to a static field ? Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart27773541.cfMjUOV7J6 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) iEYEABECAAYFAkp8BPwACgkQRIfGfFXsz+AoxACfd3tLBDH+co0Xq/bnmQA1YsHU 184AoJRRFb2O4ecYZUJXheXj9AzDzIJw =x/Lo -----END PGP SIGNATURE----- --nextPart27773541.cfMjUOV7J6-- From jvasseur@cisco.com Fri Aug 7 04:40: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 4E12A28C1C3 for ; Fri, 7 Aug 2009 04:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.578 X-Spam-Level: X-Spam-Status: No, score=-9.578 tagged_above=-999 required=5 tests=[AWL=1.021, 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 F27MeYaXyQA0 for ; Fri, 7 Aug 2009 04:40: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 ACE7D28C1D4 for ; Fri, 7 Aug 2009 04:39:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAOeve0qQ/uCKe2dsb2JhbACaQgEBFiQGm3uIK5AOBYQW X-IronPort-AV: E=Sophos;i="4.43,341,1246838400"; d="scan'208";a="46655621" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2009 11:39: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 n77BdcTK012536; Fri, 7 Aug 2009 13:39: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 n77BdcLQ023988; Fri, 7 Aug 2009 11:39:38 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:39:38 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:39:37 +0200 Message-Id: <7587187F-B296-4864-9A09-CB1FDCF996C9@cisco.com> From: JP Vasseur To: Henning Rogge In-Reply-To: <200908071242.09718.rogge@fgan.de> 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, 7 Aug 2009 13:39:36 +0200 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908071035.09589.rogge@fgan.de> <200908071242.09718.rogge@fgan.de> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 11:39:37.0962 (UTC) FILETIME=[BE856CA0:01CA1753] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16810.005 X-TM-AS-Result: No--11.164300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1500; t=1249645178; x=1250509178; 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]=20Loop=20detection=20between=20s ibling |Sender:=20; bh=WPuyh3g+mfyIWpd+/89kSGNrGdibYjzzNrcMn/AtBjs=; b=Z/epa9IL5vDa+MhIPBLuLTwVYgUEpFGZEI1mxLbplAao/N5pHheSKi5pUS s31F9xemNKVfFDJ0ZgPxjCj7eGtR0WRhoM5D62BIQPGdDGn+ED18ij+WOdoa KtXnVtb/tT; 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] 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: Fri, 07 Aug 2009 11:40:16 -0000 On Aug 7, 2009, at 12:42 PM, Henning Rogge wrote: > Am Fri August 7 2009 11:09:26 schrieb JP Vasseur: >> not is you use an existing field or even a new short one with a >> reasonably good >> pseudo-random generator (there are many) (collisions probability will >> be extremely >> low). > I'm not sure I understand your idea... > > let's assume we have a chain of 10 nodes which forward traffic =20 > towards a > target. Each of the nodes have to mark the package in a unique way =20 > without > erasing other marks to be able to detect a routing loop. Just the first node sending the packet to the sibling does. > > How do you plan to use a random number generator to compress the =20 > "mark" > information down to a static field ? There is a plethora of algorithm to do this > > Henning > > ************************************************* > Diplom Informatiker Henning Rogge > Forschungsgesellschaft f=FCr > Angewandte Naturwissenschaften e. V. (FGAN) > Neuenahrer Str. 20, 53343 Wachtberg, Germany > Tel.: 0049 (0)228 9435-961 > Fax: 0049 (0)228 9435-685 > E-Mail: rogge@fgan.de > Web: www.fgan.de > ************************************************ > Sitz der Gesellschaft: Bonn > Registergericht: Amtsgericht Bonn VR 2530 > Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender > (Stellv.) > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Fri Aug 7 12:11: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 3DA553A67E5 for ; Fri, 7 Aug 2009 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAD0k5PPcanE for ; Fri, 7 Aug 2009 12:11:17 -0700 (PDT) Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by core3.amsl.com (Postfix) with ESMTP id 16B473A6910 for ; Fri, 7 Aug 2009 12:11:17 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKSnx8V4ZJvjnD8U9xBu/MsZu/7sZRQOvR@postini.com; Fri, 07 Aug 2009 12:11: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 2009080714120883-1657603 ; Fri, 7 Aug 2009 14:12:08 -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: Fri, 7 Aug 2009 14:11:04 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/07/2009 02:11:10 PM, Serialize complete at 08/07/2009 02:11:10 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/07/2009 02:12:08 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/07/2009 02:12:17 PM, Serialize complete at 08/07/2009 02:12:17 PM Content-Type: multipart/alternative; boundary="=_alternative 0069627C8625760B_=" Subject: [Roll] Fw: I-D Submitter Authentication for draft-ietf-roll-building-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Aug 2009 19:11:18 -0000 This is a multipart message in MIME format. --=_alternative 0069627C8625760B_= Content-Type: text/plain; charset="US-ASCII" All, I have edited minor changes into draft-ietf-roll-building-routing-reqs-05.txt and submitted the -06 version to the IETF repository. The list of changes are noted below: Many nits cleaned up Mobility Requirements rewritten for better clarity Security Requirements rewritten for better clarity Appendix B - "Commercial Building Use Cases" deleted These changes were promulgated by comments received by IETF reviewers. This document has already been approved through 'last call' by the ROLL WG. ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/07/2009 02:01 PM ----- IETF I-D Submission Tool 08/07/2009 01:54 PM To jerald.p.martocci@jci.com cc Subject I-D Submitter Authentication for draft-ietf-roll-building-routing-reqs Please follow the link below to complete your I-D submission. https://datatracker.ietf.org/idst/auto_post.cgi?auth_key=QyJhFKnJoQtPEdXY1htkMwvyeruP8ZMi&submission_id=17291 Please note that if you do not follow the link above by 2009-08-10, then this submission will be canceled and your Internet-Draft will be permanently removed from the staging area. THIS PROCESS MUST BE COMPLETED BEFORE ANY CUTOFF DATES. IF A CUTOFF PERIOD BEGINS BEFORE YOU COMPLETE THE SUBMISSION PROCESS, YOUR SUBMISSION CANNOT BE ACCEPTED. The IETF Secretariat. --=_alternative 0069627C8625760B_= Content-Type: text/html; charset="US-ASCII"
All,

I have edited minor changes into draft-ietf-roll-building-routing-reqs-05.txt and submitted the -06 version to the IETF repository.  The list of changes are noted below:
  • Many nits cleaned up
  • Mobility Requirements rewritten for better clarity
  • Security Requirements rewritten for better clarity
  • Appendix B - "Commercial Building Use Cases" deleted

These changes were promulgated by comments received by IETF reviewers. This document has already been approved through 'last call' by the ROLL WG.



----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/07/2009 02:01 PM -----
IETF I-D Submission Tool <idsubmission@ietf.org>

08/07/2009 01:54 PM

To
jerald.p.martocci@jci.com
cc
Subject
I-D Submitter Authentication for          draft-ietf-roll-building-routing-reqs





Please follow the link below to complete your I-D submission.

https://datatracker.ietf.org/idst/auto_post.cgi?auth_key=QyJhFKnJoQtPEdXY1htkMwvyeruP8ZMi&submission_id=17291

Please note that if you do not follow the link above by 2009-08-10, then this submission will be canceled and your Internet-Draft will be permanently removed from the staging area.

THIS PROCESS MUST BE COMPLETED BEFORE ANY CUTOFF DATES.  IF A CUTOFF PERIOD BEGINS BEFORE YOU COMPLETE THE SUBMISSION PROCESS, YOUR SUBMISSION CANNOT BE ACCEPTED.

The IETF Secretariat.
 --=_alternative 0069627C8625760B_=-- From root@core3.amsl.com Fri Aug 7 12:15:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 78F113A6F9E; Fri, 7 Aug 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090807191501.78F113A6F9E@core3.amsl.com> Date: Fri, 7 Aug 2009 12:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-06.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, 07 Aug 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-06.txt Pages : 23 Date : 2009-08-07 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-06.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-07120017.I-D@ietf.org> --NextPart-- From wintert@acm.org Tue Aug 11 15:59: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 90B7A3A6BAC for ; Tue, 11 Aug 2009 15:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 XaXm8dS5ks34 for ; Tue, 11 Aug 2009 15:59:55 -0700 (PDT) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id 6B8F73A6BD7 for ; Tue, 11 Aug 2009 15:59:45 -0700 (PDT) Received: (qmail 80777 invoked from network); 11 Aug 2009 22:58:38 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 11 Aug 2009 15:58:37 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 5spMwg8VM1kbAuyo..1PZRkoTr5uVfPK.ssak1KVVMeXluPByOirA3Ql36bHJzAleI0ZOKebiGoZ4Wkr1ti_c.tE9mtOL3Rd94.SK1C1oMQLJgU.A7I0.2m8KCaaAdBdfwlpFcYn5RFvsgUy05T.BFYz3QE7tp36cK63G2ujx_0s8CM5gtjpTjwzZF8mA0vocu6ESa5STLE8iS2aSyruiNxda4wlphUBdkm2mdrdoaSldNBhYWEoavkjZg__d_faYEuaMKBAv3O1Rcen4ndRtFhWbO.a87rcDXNWmprHHm7LNSGeBDhIg3k8L3JZwCUQeNvPOHO_Jt0mmmJSatWjwvEPgeblWnl3Qm8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A81F79A.10104@acm.org> Date: Tue, 11 Aug 2009 18:58:34 -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] RPL Next Steps X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Aug 2009 22:59:57 -0000 WG, Please find below some additional feedback from the design team on the questions that have been raised so far for RPL. Not everything has been covered- but the questions have served to point out some areas of the draft where we need to continue and focus efforts. We (DT) propose, in the -01 version of the draft, to clarify as much as possible the outstanding questions and concerns in the current specification of RPL, with emphasis on the existing (-00) mechanisms. The intent is to provide a solid, unambiguous, implementable, foundation of the existing core mechanisms in -01. On this foundation we can then continue to build and expand other necessary mechanisms in later revisions, such as are being discussed for P2P routing. There is no doubt that the P2P issues need to be further discussed and addressed, but the thought is that by clearing up the existing mechanisms we may be able to make better progress in moving forward beyond the existing mechansisms in later revisions. WG, how does this sound as a strategy to make progress on RPL? Miscellaneous: - Based on WG feedback, instead of `depth' we will refer to `rank' - Instead of `siblings' we will refer to `nodes of the same rank' - We will update the text to reflect that 1) Grounded nodes do not always provide a default route 2) Destination prefix suboption of DIO includes lifetime --------------------------------------------------------------------------- From: Alexandru Petrescu I would like to get clarification on the IPv6 addressing architecture and subnet structure considered in RPL. -is it the AUTOCONF addressing model? DT: It is important that RPL work with whatever addressing model we utilize in the future and that it operate in contexts where the addressing model is already constrained. Thus, RPL treats the address as opaque. If you like, you can view it as flat, but really it is uninterpreted at this stage. With this in mind, it is clear that RPL will benefit from the ability to do route summarization along the DAG, particularly in order to improve scalability. Future work on the draft may evolve this mechanism, and there is work to do on the ROLL architectural framework that may offer additional clarifications. -is it the 6LoWPAN route over or mesh-under? DT: RPL intends to operate purely at L3, and it is the intention of RPL to be L2 agnostic, so it "routes over". If it were over, e.g. switched ethernet or 802.11 mesh or 802.15.4 mesh underneath, it should work. It should also work on, e.g., ethernet, 802.11, and 802.15.4 where no "meshing" is done at layer 2. -how many physical interfaces does a node have? DT: This is out of scope for RPL. -if a node has several interfaces then does it have only one physical interface? DT: This may be a typical case, but again out of scope for RPL. A subnetwork / adaptation layer should handle this. -what is the default route behaviour? Does each node have default route? DT: A default route MAY be offered by a grounded DAG, in which case it will be installed. In some cases (application specific) the default route may not be offered by a grounded DAG, in which case there is no default route and a node will not be able to use a default route to forward packets. In such cases it is presumed that an application, choosing not to provision a default route in a DAG root, will take care to use only prefixes that can be routed within the DAG. -are there IPv6 prefix subnets /64? DT: There could be, but it is not required. In cases where RPL allows prefix specification, the prefix length may be specified from 0-128. Here is a DAG excerpt from 01 draft: (A) |\ | `-----. | \ (B) \ \ | `-----. | \| (C) Does that mean the IPv6 addressing arechitecture is this: (A) |\ 2001:db8:1::/64 | `-----. | \ 2001:db8:2::/64 (B) \ \ | `-----. | 2001:db8:3::/64 \| (C) --------------------------------------------------------------------------- From: "Don Sturek" Here are some points that I would like to see the design team clarify with respect to the current RPL draft: 1) P2P support a. I believe the P2P feature uses Destination Address advertisements from the device wishing to receive P2P traffic: i. What are the requirements for the receiving device advertising via Destination Address Advertisements assuming it is not the DAG-root (eg, What is the rate of Destination Address advertisements, How does the device (or does it/can it) notify devices of lower rank/depth that it has detached from the DAG). If there is no mechanism for the receiving device to notify devices of lower rank/depth it if detaches, how is maintenance of the Destination Address advertisement caching within the DAG performed. DT: Destination advertisements as specified in -00 may be triggered by any node in the DAG who observes a change in the DAG. The request is made by setting the `D' bit and propagating a new DIO. This change may have been observed directly, e.g. a node changes its DAG Parents and preemptively triggers the DA mechanism to update the inward nodes, or equivalently by observing a change to the PathDigest. A DAO of lifetime 0 (no-DAO) is used to indicate that the reachability is lost (5.4.1.1). If the Node has a chance to leave gracefully, it could send that about itself. The most common case is timing out a child though. ii. What are the requirements for devices with lower rank/depth in the same DAG when receiving a Destination Address advertisement (eg, does it store the Destination Address advertisements of its children, Does it further re-propagate the Destination Address advertisements to devices of lower rank/depth, How long should devices of lower rank/depth store these destination address advertisements) DT: When a node is capable of storing DAs (i.e. it has sufficient storage for the DA state), then it will do so, along with the depth, and after some time will re-emit the best DA from the options it has seen, perhaps performing route aggregation/summarization if it is able. When a node is not capable of storing DAs (i.e. it has no storage for the DA state), then it will update the reverse routing statck in the DA and immediately pass it on. There is a related concern, brought up in IETF-75, about the effect of `fan-out' when coupled with the DA mechanism in a DAG, i.e. as DAs are propagated among (potentially) multiple sets of DAG parents, what steps need to be taken to keep the multiplicative effect under control. For nodes who are storing DAs, the DA's will be stored until a no-DAO is received or the DA lifetime expires. No-DAO (lifetime 0) would be propagated immediately and unreliably. This another instance where a loop is easily created and thus requires detection. This is a case where an approach to loop detection would be enough. In general, it is clear that there is work to do in the RPL draft to more clearly state the operation of the DA mechanism, and to remove some ambiguity in the description of the core mechanism. b. Routing of P2P traffic i. I assume that the DAG-root holds the address of all Destination Address Advertisements it has received from devices in its DAG. Is this true? DT: As mentioned on the list, there could be cases where only the MP2P flows are of interest (no P2MP traffic), in which case the DA mechanism may not even be invoked and there is not need to MUST the DAG-root to hold the addresses. If P2MP traffic is supported, and the DA mechanism is used, then the DAG-root MUST store the state learned from the DAs it receives. This should be further clarified in the draft. Note that if route summarization is in play, e.g. some sort of hierarchical addressing structure is supported, then the DAG root may not receive a DA for every device in its DAG; the addressing structure may allow DAs to be absorbed and aggregated as the move up the DAG. This mechanism needs further exploration, as described in the answer to a related question above. ii. I assume that other devices in the DAG of higher rank/depth from the DAG-root but still lower in rank than the final destination routes packets down the DAG. It seems possible for the destination to receive multiple copies (is this correct) and more importantly it also seems possible for an Unreachable notification to be generated by some device in the DAG when in fact the packet reached its destination through another path (did I read the proposal wrong?) DT: Yes duplicates may be received but this is beyond the scope of RPL, and any traffic running over an IP service should be prepared to handle (or ignore, or not care) possible duplicates. Likewise, in some implementations, it may be possible for ICMP unreachable to be issued when in fact the packet has slipped through. c. Sibling routing seems to be not supported (though I saw discussion of this on the reflector). It seems problematic to have Siblings processing Destination Address advertisements within the same DAG. We should leave this out of the clarification if my reading is correct and only add it back as part of support for optimized P2P if that is where the optimization leads. DT: To clarify, `sibling routing' in this question is the same as `next-door neighbor' or `1-hop' neighbor that has been discussed on the list, and in fact entails all neighbors (not just siblings as in nodes-of-the-same-rank). It is the intention that this type of routing is supported by RPL. The proposal on the table is that nodes will make use of mulicast DAOs in order to inform their neighbors of their owned prefixes. Text will be added to the -01 draft to specify this mechanism. I also have some questions on the freezing of DAGs and ungrounded DAGs but I think that is a separate issue and I will put out a note later in the week on this. DT: Please feel free to ask at any time- it will help to produce a better -01 draft. --------------------------------------------------------------------------- From: Jerald.P.Martocci@jci.com I would like the following questions answered on subsequent revisions of the draft: a) What is the roll of 'siblings'? They are in the current RPL document, yet seem to be demoted from parental links. As I read the draft, one cannot use a sibling link unless the parental links are exhausted. The nodes don't seem to explicitly define sibling links. DT: We will clarify this in the draft -01. Siblings are neighboring nodes of the same rank in the DAG. The idea is that forwarding via siblings may allow a packet to make progress when the parents not available, i.e. the sibling may have better luck making forward progress. It is certainly better than forwarding to a node of greater (outward) rank, and better than dropping the packet. So siblings are useful when making the list of successors; first try the parents, second try siblings, last give up. b) What is the plan on communication to devices within direct radio range? As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with. However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices. Unfortunately, I couldn't attend the meeting. DT: The intent is to support this and we intend to elaborate the mechanism in the next revistion. Please see the answer to `c' from Don above. c) What are the approximate timer values for RPL? The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network. In a real-time facility management control system, all nodes are monitored for falling off-line. If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer. DT: The intent is that RPL may be parameterized first in a set of applicability statements in each application domain and finally by the implementors/administrators of the installed LLNs. With this in mind, it is clear that the document needs to better extract and clarify the role of each timer, constraints on its values, and interactions with RPL mechanisms in order that informed decisions can be made. In some cases it may be appropriate to derive relationships between the timers (e.g. timeout X should be 3 times timeout Y), and in some cases it may be desirable to have timers be adaptive. We propose to clarify the timers in the -01 draft so that there is a better basis to have these discussions. A related task is, e.g. the proper operation of the supression mechanism as has been discussed on the list. d) What is the plan for security? RPL doesn't currently weigh in on the topic. Are security policies optional or mandatory? Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network? Will security require nodes to keep state info as Rene suggests? DT: There is no doubt that security is important and challenging for LLNs, and it is important that security be designed in and not bolted on. We await WG progress in the security framework, and the guidance of ROLL's advisor Rene Struik and will incorporate the necessary mechanisms into RPL. Of particular interest here is to identify any potential places where the unique issues of low power and lossy networks impact routing security. For example, have any of the measures that have been taken to operate with a small routing footprint or at low protocol overhead increased vulnerabilities? (It is conceivable that by recording very little information, being very parsimonious about what it communicated, and coping with transient inconsistencies and uncertainty, these networks are actually less vulnerable.) This may be distinct from the family of security issues for the end-hosts that may have interfaces to such networks. Of course, we need also to attend to the relatively common case where a node is both host and router. e) What requirements from the 4 requirement drafts are being considered? When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement. This hasn't occurred and may be adding to the email angst. As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered. DT: All requirements are to be considered, as summarized in http://www.ietf.org/mail-archive/web/roll/current/msg01291.html (but superceded as the application drafts are updated to become RFCs). The intent is not to re-iterate the requirements in the appendix, but rather to justify any requirements that are not met in the final specification. WG members must help to ensure that the requirements are suitably met by the proposed specification. f) What is the expected frame overhead size based on all the above criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP. We need to add in the encryption and authentication overhead; and now maybe source routing. I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town. It only carries a 128 by packet size. The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol. DT: As small as possible ;) ROLL is agnostic to L2, and there are most certainly folks in the WG involved with L2 other than 802.15.4. We do recognize that typical LLN solutions will be using very constrained link technologies. Let us continue to clarify the RPL specification, with the goal in mind to provide the simplest, smallest footprint core mechanism, and then see that any overhead is efficiently allocated. Then we should have justification of what an L2 may need to provide to support RPL, whether or not it is appropriate, and/or what sort of adaptation/subnetwork, is required for RPL operation. As a related point, there is still work to do with regards to header compression/address compression, ... g) What routing data must persist a warmstart/coldstart? The overhead to establish a DAG is significant. We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks. DT: It is not *required* that routing data persist a warmstart/coldstart, e.g. RPL should not be fundamentally broken by a failure to do so, but as you note it may certainly help to make things more efficient. We propose to clarify what data an implementation may consider to perist in the next version of the draft. As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision. That may indeed be true, but RPL should state its case explicitly. In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot. ------------------------------------------------------- RPL currently makes no mention of sleepy devices. These will be very commonplace in WSNs. I would like to amend my list below and add sleepy device management. RPL needs to state what happens to packets routed to sleepy devices while they are asleep. Are they dropped? Will a proxy manage the packet until the device awakens? Will the last router return an error to the source? DT: This should be handled with an adaptation layer, and the underlying L2, although L3 may need to be aware of such devices, e.g. to provision proper DA timeouts for `long sleepers', etc. We propose to follow the lead of 6LowPAN here and related L2 efforts such as 802.15.4e for the case of LoWPANs. PLC L2 layers and emerging WLAN, e.g., low power 802.11 have related but distinct behaviors. --------------------------------------------------------------------------- "Mathilde Durvy (mdurvy)" I would personally want to see more discussion on 3 topics where I'm still not fully convinced: [SIBLINGS] The role of siblings: this adds quite some extra complexity to the routing but what does it really bring in practice? Should siblings be part of the foundation layer? My opinion is no. DT: For the moment we think yes, see above answer to Jerry's question `a' above. But what does the rest of the WG think? [METRICS] 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? DT: We will clarify this further in the draft. The intent is that the depth (i.e. `rank') is to serve equivalently to this single metric you described: its value is determined by the mechanism defined in the OCP, it is to be derived in a way that is related to position in the DAG with certain properties useful for loop avoidance, and its loop avoidance properties are to be universal such that neighboring nodes may understand even in the case where they don't understand the OCP (e.g. `esperanto'). [TIMERS] 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 during the IETF meeting can we guarantee the right sequencing of RA / DAG Hop timer firing? DT: To be clarified, as per Jerry's question `c' above. In addition, note that we may not always be able to guarantee the sequencing of the RA / DAG Hop timers as in the example- in the best case scenario the timer values should allow for the coordinated freezing of the sub-DAG and subsequent DAG Merge. But in some cases, e.g. due to comm loss, the freezing might not be coordinated and the DAG Merge might be choppy/fragmented. But RPL should still be able to operate, by detecting resuling inconsistencies and repairing. --------------------------------------------------------------------------- From: "Julien Abeille (jabeille)" a few more items: [Packet format] Clarify the rationale to use RAs/NAs. More precisely: - are RAs sent for router discovery/prefix discovery the same as those used by ROLL (same timer). -- If yes, does it impact the way router discovery/prefix discovery work (preformance, do they really have the same timing constraints?) DT: The DIO is specified as an RA option, and just like any other option, it doesn't have to be sent in every RA. Sending the DIO does not have to be on the same timer. However, it may be advantageous to include a prefix information option along with a DIO so that a node can also autoconfigure its address in addition to configuring a default route with a single message transmission (reduced energy, channel utilization, etc). As a result, it may mean that some options specified in RFC4861 may be sent more frequently that if RPL was not using RA messages as a transport. We don't think there is any issue with sending options more frequently than expected - if you think there are, please raise them. -- if yes, what is the approach with regards to update of RFC4861 (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while ROLL is not)? -- if not, why not using a specific packet? - NA: -- Are NAs sent for ROLL used for anything else? If not why not use a specific packet to carry DAOs? -- NAs are already pretty overloaded (DAD, NUD, Address resolution), using a different packet may bring NA processing complexity down. DT: There was some discussion at IETF-75 regarding trying to generalize the ND binding. For now we may concentrate on the form and function of DIOs/DAOs and how they interact in the RPL protocol, leaving the RA and NA in place for the moment. Once the core mechanisms are refined we may then revisit/refine what is used to carry the advertisements. A clear preference would be to not cause modification to established IPv6 ND behaviour. - END - From Jerald.P.Martocci@jci.com Wed Aug 12 11: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 A77B93A6B97 for ; Wed, 12 Aug 2009 11:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 WHLYFl5HNQYG for ; Wed, 12 Aug 2009 11:04:48 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with ESMTP id 9FEA33A6C23 for ; Wed, 12 Aug 2009 11:04:10 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKSoMD8LTDXHYjNytMFJIF++dD9frZTpgw@postini.com; Wed, 12 Aug 2009 11:04:15 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009081212572818-1991521 ; Wed, 12 Aug 2009 12:57:28 -0500 In-Reply-To: <4A81F79A.10104@acm.org> MIME-Version: 1.0 To: Tim Winter X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 12 Aug 2009 12:56:07 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/12/2009 12:56:12 PM, Serialize complete at 08/12/2009 12:56:12 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/12/2009 12:57:28 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/12/2009 01:05:29 PM, Serialize complete at 08/12/2009 01:05:29 PM Content-Type: multipart/alternative; boundary="=_alternative 0062861086257610_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] RPL Next Steps X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Aug 2009 18:04:48 -0000 This is a multipart message in MIME format. --=_alternative 0062861086257610_= Content-Type: text/plain; charset="US-ASCII" This sounds like a plan. However, aren't you talking about the -02 version? I thought we already have a -01 version that introduced 'OCP'? Tim Winter Sent by: roll-bounces@ietf.org 08/11/2009 06:00 PM To ROLL WG cc Subject [Roll] RPL Next Steps WG, Please find below some additional feedback from the design team on the questions that have been raised so far for RPL. Not everything has been covered- but the questions have served to point out some areas of the draft where we need to continue and focus efforts. We (DT) propose, in the -01 version of the draft, to clarify as much as possible the outstanding questions and concerns in the current specification of RPL, with emphasis on the existing (-00) mechanisms. The intent is to provide a solid, unambiguous, implementable, foundation of the existing core mechanisms in -01. On this foundation we can then continue to build and expand other necessary mechanisms in later revisions, such as are being discussed for P2P routing. There is no doubt that the P2P issues need to be further discussed and addressed, but the thought is that by clearing up the existing mechanisms we may be able to make better progress in moving forward beyond the existing mechansisms in later revisions. WG, how does this sound as a strategy to make progress on RPL? Miscellaneous: - Based on WG feedback, instead of `depth' we will refer to `rank' - Instead of `siblings' we will refer to `nodes of the same rank' - We will update the text to reflect that 1) Grounded nodes do not always provide a default route 2) Destination prefix suboption of DIO includes lifetime --------------------------------------------------------------------------- From: Alexandru Petrescu I would like to get clarification on the IPv6 addressing architecture and subnet structure considered in RPL. -is it the AUTOCONF addressing model? DT: It is important that RPL work with whatever addressing model we utilize in the future and that it operate in contexts where the addressing model is already constrained. Thus, RPL treats the address as opaque. If you like, you can view it as flat, but really it is uninterpreted at this stage. With this in mind, it is clear that RPL will benefit from the ability to do route summarization along the DAG, particularly in order to improve scalability. Future work on the draft may evolve this mechanism, and there is work to do on the ROLL architectural framework that may offer additional clarifications. -is it the 6LoWPAN route over or mesh-under? DT: RPL intends to operate purely at L3, and it is the intention of RPL to be L2 agnostic, so it "routes over". If it were over, e.g. switched ethernet or 802.11 mesh or 802.15.4 mesh underneath, it should work. It should also work on, e.g., ethernet, 802.11, and 802.15.4 where no "meshing" is done at layer 2. -how many physical interfaces does a node have? DT: This is out of scope for RPL. -if a node has several interfaces then does it have only one physical interface? DT: This may be a typical case, but again out of scope for RPL. A subnetwork / adaptation layer should handle this. -what is the default route behaviour? Does each node have default route? DT: A default route MAY be offered by a grounded DAG, in which case it will be installed. In some cases (application specific) the default route may not be offered by a grounded DAG, in which case there is no default route and a node will not be able to use a default route to forward packets. In such cases it is presumed that an application, choosing not to provision a default route in a DAG root, will take care to use only prefixes that can be routed within the DAG. -are there IPv6 prefix subnets /64? DT: There could be, but it is not required. In cases where RPL allows prefix specification, the prefix length may be specified from 0-128. Here is a DAG excerpt from 01 draft: (A) |\ | `-----. | \ (B) \ \ | `-----. | \| (C) Does that mean the IPv6 addressing arechitecture is this: (A) |\ 2001:db8:1::/64 | `-----. | \ 2001:db8:2::/64 (B) \ \ | `-----. | 2001:db8:3::/64 \| (C) --------------------------------------------------------------------------- From: "Don Sturek" Here are some points that I would like to see the design team clarify with respect to the current RPL draft: 1) P2P support a. I believe the P2P feature uses Destination Address advertisements from the device wishing to receive P2P traffic: i. What are the requirements for the receiving device advertising via Destination Address Advertisements assuming it is not the DAG-root (eg, What is the rate of Destination Address advertisements, How does the device (or does it/can it) notify devices of lower rank/depth that it has detached from the DAG). If there is no mechanism for the receiving device to notify devices of lower rank/depth it if detaches, how is maintenance of the Destination Address advertisement caching within the DAG performed. DT: Destination advertisements as specified in -00 may be triggered by any node in the DAG who observes a change in the DAG. The request is made by setting the `D' bit and propagating a new DIO. This change may have been observed directly, e.g. a node changes its DAG Parents and preemptively triggers the DA mechanism to update the inward nodes, or equivalently by observing a change to the PathDigest. A DAO of lifetime 0 (no-DAO) is used to indicate that the reachability is lost (5.4.1.1). If the Node has a chance to leave gracefully, it could send that about itself. The most common case is timing out a child though. ii. What are the requirements for devices with lower rank/depth in the same DAG when receiving a Destination Address advertisement (eg, does it store the Destination Address advertisements of its children, Does it further re-propagate the Destination Address advertisements to devices of lower rank/depth, How long should devices of lower rank/depth store these destination address advertisements) DT: When a node is capable of storing DAs (i.e. it has sufficient storage for the DA state), then it will do so, along with the depth, and after some time will re-emit the best DA from the options it has seen, perhaps performing route aggregation/summarization if it is able. When a node is not capable of storing DAs (i.e. it has no storage for the DA state), then it will update the reverse routing statck in the DA and immediately pass it on. There is a related concern, brought up in IETF-75, about the effect of `fan-out' when coupled with the DA mechanism in a DAG, i.e. as DAs are propagated among (potentially) multiple sets of DAG parents, what steps need to be taken to keep the multiplicative effect under control. For nodes who are storing DAs, the DA's will be stored until a no-DAO is received or the DA lifetime expires. No-DAO (lifetime 0) would be propagated immediately and unreliably. This another instance where a loop is easily created and thus requires detection. This is a case where an approach to loop detection would be enough. In general, it is clear that there is work to do in the RPL draft to more clearly state the operation of the DA mechanism, and to remove some ambiguity in the description of the core mechanism. b. Routing of P2P traffic i. I assume that the DAG-root holds the address of all Destination Address Advertisements it has received from devices in its DAG. Is this true? DT: As mentioned on the list, there could be cases where only the MP2P flows are of interest (no P2MP traffic), in which case the DA mechanism may not even be invoked and there is not need to MUST the DAG-root to hold the addresses. If P2MP traffic is supported, and the DA mechanism is used, then the DAG-root MUST store the state learned from the DAs it receives. This should be further clarified in the draft. Note that if route summarization is in play, e.g. some sort of hierarchical addressing structure is supported, then the DAG root may not receive a DA for every device in its DAG; the addressing structure may allow DAs to be absorbed and aggregated as the move up the DAG. This mechanism needs further exploration, as described in the answer to a related question above. ii. I assume that other devices in the DAG of higher rank/depth from the DAG-root but still lower in rank than the final destination routes packets down the DAG. It seems possible for the destination to receive multiple copies (is this correct) and more importantly it also seems possible for an Unreachable notification to be generated by some device in the DAG when in fact the packet reached its destination through another path (did I read the proposal wrong?) DT: Yes duplicates may be received but this is beyond the scope of RPL, and any traffic running over an IP service should be prepared to handle (or ignore, or not care) possible duplicates. Likewise, in some implementations, it may be possible for ICMP unreachable to be issued when in fact the packet has slipped through. c. Sibling routing seems to be not supported (though I saw discussion of this on the reflector). It seems problematic to have Siblings processing Destination Address advertisements within the same DAG. We should leave this out of the clarification if my reading is correct and only add it back as part of support for optimized P2P if that is where the optimization leads. DT: To clarify, `sibling routing' in this question is the same as `next-door neighbor' or `1-hop' neighbor that has been discussed on the list, and in fact entails all neighbors (not just siblings as in nodes-of-the-same-rank). It is the intention that this type of routing is supported by RPL. The proposal on the table is that nodes will make use of mulicast DAOs in order to inform their neighbors of their owned prefixes. Text will be added to the -01 draft to specify this mechanism. I also have some questions on the freezing of DAGs and ungrounded DAGs but I think that is a separate issue and I will put out a note later in the week on this. DT: Please feel free to ask at any time- it will help to produce a better -01 draft. --------------------------------------------------------------------------- From: Jerald.P.Martocci@jci.com I would like the following questions answered on subsequent revisions of the draft: a) What is the roll of 'siblings'? They are in the current RPL document, yet seem to be demoted from parental links. As I read the draft, one cannot use a sibling link unless the parental links are exhausted. The nodes don't seem to explicitly define sibling links. DT: We will clarify this in the draft -01. Siblings are neighboring nodes of the same rank in the DAG. The idea is that forwarding via siblings may allow a packet to make progress when the parents not available, i.e. the sibling may have better luck making forward progress. It is certainly better than forwarding to a node of greater (outward) rank, and better than dropping the packet. So siblings are useful when making the list of successors; first try the parents, second try siblings, last give up. b) What is the plan on communication to devices within direct radio range? As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with. However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices. Unfortunately, I couldn't attend the meeting. DT: The intent is to support this and we intend to elaborate the mechanism in the next revistion. Please see the answer to `c' from Don above. c) What are the approximate timer values for RPL? The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network. In a real-time facility management control system, all nodes are monitored for falling off-line. If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer. DT: The intent is that RPL may be parameterized first in a set of applicability statements in each application domain and finally by the implementors/administrators of the installed LLNs. With this in mind, it is clear that the document needs to better extract and clarify the role of each timer, constraints on its values, and interactions with RPL mechanisms in order that informed decisions can be made. In some cases it may be appropriate to derive relationships between the timers (e.g. timeout X should be 3 times timeout Y), and in some cases it may be desirable to have timers be adaptive. We propose to clarify the timers in the -01 draft so that there is a better basis to have these discussions. A related task is, e.g. the proper operation of the supression mechanism as has been discussed on the list. d) What is the plan for security? RPL doesn't currently weigh in on the topic. Are security policies optional or mandatory? Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network? Will security require nodes to keep state info as Rene suggests? DT: There is no doubt that security is important and challenging for LLNs, and it is important that security be designed in and not bolted on. We await WG progress in the security framework, and the guidance of ROLL's advisor Rene Struik and will incorporate the necessary mechanisms into RPL. Of particular interest here is to identify any potential places where the unique issues of low power and lossy networks impact routing security. For example, have any of the measures that have been taken to operate with a small routing footprint or at low protocol overhead increased vulnerabilities? (It is conceivable that by recording very little information, being very parsimonious about what it communicated, and coping with transient inconsistencies and uncertainty, these networks are actually less vulnerable.) This may be distinct from the family of security issues for the end-hosts that may have interfaces to such networks. Of course, we need also to attend to the relatively common case where a node is both host and router. e) What requirements from the 4 requirement drafts are being considered? When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement. This hasn't occurred and may be adding to the email angst. As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered. DT: All requirements are to be considered, as summarized in http://www.ietf.org/mail-archive/web/roll/current/msg01291.html (but superceded as the application drafts are updated to become RFCs). The intent is not to re-iterate the requirements in the appendix, but rather to justify any requirements that are not met in the final specification. WG members must help to ensure that the requirements are suitably met by the proposed specification. f) What is the expected frame overhead size based on all the above criteria? 6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP. We need to add in the encryption and authentication overhead; and now maybe source routing. I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town. It only carries a 128 by packet size. The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol. DT: As small as possible ;) ROLL is agnostic to L2, and there are most certainly folks in the WG involved with L2 other than 802.15.4. We do recognize that typical LLN solutions will be using very constrained link technologies. Let us continue to clarify the RPL specification, with the goal in mind to provide the simplest, smallest footprint core mechanism, and then see that any overhead is efficiently allocated. Then we should have justification of what an L2 may need to provide to support RPL, whether or not it is appropriate, and/or what sort of adaptation/subnetwork, is required for RPL operation. As a related point, there is still work to do with regards to header compression/address compression, ... g) What routing data must persist a warmstart/coldstart? The overhead to establish a DAG is significant. We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks. DT: It is not *required* that routing data persist a warmstart/coldstart, e.g. RPL should not be fundamentally broken by a failure to do so, but as you note it may certainly help to make things more efficient. We propose to clarify what data an implementation may consider to perist in the next version of the draft. As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision. That may indeed be true, but RPL should state its case explicitly. In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor. Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot. ------------------------------------------------------- RPL currently makes no mention of sleepy devices. These will be very commonplace in WSNs. I would like to amend my list below and add sleepy device management. RPL needs to state what happens to packets routed to sleepy devices while they are asleep. Are they dropped? Will a proxy manage the packet until the device awakens? Will the last router return an error to the source? DT: This should be handled with an adaptation layer, and the underlying L2, although L3 may need to be aware of such devices, e.g. to provision proper DA timeouts for `long sleepers', etc. We propose to follow the lead of 6LowPAN here and related L2 efforts such as 802.15.4e for the case of LoWPANs. PLC L2 layers and emerging WLAN, e.g., low power 802.11 have related but distinct behaviors. --------------------------------------------------------------------------- "Mathilde Durvy (mdurvy)" I would personally want to see more discussion on 3 topics where I'm still not fully convinced: [SIBLINGS] The role of siblings: this adds quite some extra complexity to the routing but what does it really bring in practice? Should siblings be part of the foundation layer? My opinion is no. DT: For the moment we think yes, see above answer to Jerry's question `a' above. But what does the rest of the WG think? [METRICS] 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? DT: We will clarify this further in the draft. The intent is that the depth (i.e. `rank') is to serve equivalently to this single metric you described: its value is determined by the mechanism defined in the OCP, it is to be derived in a way that is related to position in the DAG with certain properties useful for loop avoidance, and its loop avoidance properties are to be universal such that neighboring nodes may understand even in the case where they don't understand the OCP (e.g. `esperanto'). [TIMERS] 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 during the IETF meeting can we guarantee the right sequencing of RA / DAG Hop timer firing? DT: To be clarified, as per Jerry's question `c' above. In addition, note that we may not always be able to guarantee the sequencing of the RA / DAG Hop timers as in the example- in the best case scenario the timer values should allow for the coordinated freezing of the sub-DAG and subsequent DAG Merge. But in some cases, e.g. due to comm loss, the freezing might not be coordinated and the DAG Merge might be choppy/fragmented. But RPL should still be able to operate, by detecting resuling inconsistencies and repairing. --------------------------------------------------------------------------- From: "Julien Abeille (jabeille)" a few more items: [Packet format] Clarify the rationale to use RAs/NAs. More precisely: - are RAs sent for router discovery/prefix discovery the same as those used by ROLL (same timer). -- If yes, does it impact the way router discovery/prefix discovery work (preformance, do they really have the same timing constraints?) DT: The DIO is specified as an RA option, and just like any other option, it doesn't have to be sent in every RA. Sending the DIO does not have to be on the same timer. However, it may be advantageous to include a prefix information option along with a DIO so that a node can also autoconfigure its address in addition to configuring a default route with a single message transmission (reduced energy, channel utilization, etc). As a result, it may mean that some options specified in RFC4861 may be sent more frequently that if RPL was not using RA messages as a transport. We don't think there is any issue with sending options more frequently than expected - if you think there are, please raise them. -- if yes, what is the approach with regards to update of RFC4861 (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while ROLL is not)? -- if not, why not using a specific packet? - NA: -- Are NAs sent for ROLL used for anything else? If not why not use a specific packet to carry DAOs? -- NAs are already pretty overloaded (DAD, NUD, Address resolution), using a different packet may bring NA processing complexity down. DT: There was some discussion at IETF-75 regarding trying to generalize the ND binding. For now we may concentrate on the form and function of DIOs/DAOs and how they interact in the RPL protocol, leaving the RA and NA in place for the moment. Once the core mechanisms are refined we may then revisit/refine what is used to carry the advertisements. A clear preference would be to not cause modification to established IPv6 ND behaviour. - END - _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0062861086257610_= Content-Type: text/html; charset="US-ASCII"

This sounds like a plan.   However, aren't you talking about the -02 version?  I thought we already have a -01 version that introduced 'OCP'?




Tim Winter <wintert@acm.org>
Sent by: roll-bounces@ietf.org

08/11/2009 06:00 PM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] RPL Next Steps





WG,

Please find below some additional feedback from the design team on the
questions that have been raised so far for RPL.  Not everything has been
covered- but the questions have served to point out some areas of the draft
where we need to continue and focus efforts.

We (DT) propose, in the -01 version of the draft, to clarify as much
as possible the outstanding questions and concerns in the current
specification of RPL, with emphasis on the existing (-00) mechanisms.  The
intent is to provide a solid, unambiguous, implementable, foundation of the
existing core mechanisms in -01.  On this foundation we can then continue
to build and expand other necessary mechanisms in later revisions, such as
are being discussed for P2P routing.  There is no doubt that the P2P issues
need to be further discussed and addressed, but the thought is that by
clearing up the existing mechanisms we may be able to make better progress
in moving forward beyond the existing mechansisms in later revisions.

WG, how does this sound as a strategy to make progress on RPL?





Miscellaneous:
- Based on WG feedback, instead of `depth' we will refer to `rank'
- Instead of `siblings' we will refer to `nodes of the same rank'
- We will update the text to reflect that
       1) Grounded nodes do not always provide a default route
       2) Destination prefix suboption of DIO includes lifetime


---------------------------------------------------------------------------
       From: Alexandru Petrescu <alexandru.petrescu@gmail.com>

       I would like to get clarification on the IPv6 addressing architecture
       and subnet structure considered in RPL.

       -is it the AUTOCONF addressing model?

DT: It is important that RPL work with whatever addressing model we utilize
in the future and that it operate in contexts where the addressing model is
already constrained.  Thus, RPL treats the address as opaque.  If you like,
you can view it as flat, but really it is uninterpreted at this stage.

With this in mind, it is clear that RPL will benefit from the ability to do
route summarization along the DAG, particularly in order to improve
scalability.  Future work on the draft may evolve this mechanism, and there
is work to do on the ROLL architectural framework that may offer additional
clarifications.


       -is it the 6LoWPAN route over or mesh-under?
DT: RPL intends to operate purely at L3, and it is the intention of RPL to
be L2 agnostic, so it "routes over".  If it were over, e.g. switched
ethernet or 802.11 mesh or 802.15.4 mesh underneath, it should work.  It
should also work on, e.g., ethernet, 802.11, and 802.15.4 where no
"meshing" is done at layer 2.

       -how many physical interfaces does a node have?
DT: This is out of scope for RPL.

       -if a node has several interfaces then does it have only one physical
         interface?
DT: This may be a typical case, but again out of scope for RPL.  A
subnetwork / adaptation layer should handle this.

       -what is the default route behaviour?  Does each node have default
         route?
DT: A default route MAY be offered by a grounded DAG, in which case it will
be installed.  In some cases (application specific) the default route may
not be offered by a grounded DAG, in which case there is no default route
and a node will not be able to use a default route to forward packets.  In
such cases it is presumed that an application, choosing not to provision a
default route in a DAG root, will take care to use only prefixes that can
be routed within the DAG.



       -are there IPv6 prefix subnets /64?
DT: There could be, but it is not required.  In cases where RPL allows
prefix specification, the prefix length may be specified from 0-128.

       Here is a DAG excerpt from 01 draft:

                          (A)
                           |\
                           | `-----.
                           |        \
                          (B)        \
                            \        |
                             `-----. |
                                    \|
                                    (C)

       Does that mean the IPv6 addressing arechitecture is this:


                          (A)
                           |\
           2001:db8:1::/64 | `-----.
                           |        \  2001:db8:2::/64
                          (B)        \
                            \        |
                             `-----. |
                2001:db8:3::/64     \|
                                    (C)



---------------------------------------------------------------------------
       From: "Don Sturek" <d.sturek@att.net>

       Here are some points that I would like to see the design team
       clarify with respect to the current RPL draft:
       1)  P2P support
               a.    I believe the P2P feature uses Destination Address
                       advertisements from the device wishing to receive
                       P2P traffic:
                       i.  What are the requirements for the receiving
                               device advertising via Destination Address
                               Advertisements assuming it is not the
                               DAG-root (eg, What is the rate of
                               Destination Address advertisements, How
                               does the device (or does it/can it) notify
                               devices of lower rank/depth that it has
                               detached from the DAG).   If there is no
                               mechanism for the receiving device to
                               notify devices of lower rank/depth it if
                               detaches, how is maintenance of the
                               Destination Address advertisement caching
                               within the DAG performed.
DT: Destination advertisements as specified in -00 may be triggered by any
node in the DAG who observes a change in the DAG.  The request is made by
setting the `D' bit and propagating a new DIO.  This change may have been
observed directly, e.g. a node changes its DAG Parents and preemptively
triggers the DA mechanism to update the inward nodes, or equivalently by
observing a change to the PathDigest.

A DAO of lifetime 0 (no-DAO) is used to indicate that the reachability is
lost (5.4.1.1).  If the Node has a chance to leave gracefully, it could
send that about itself.  The most common case is timing out a child though.

                       ii.   What are the requirements for devices with
                               lower rank/depth in the same DAG when
                               receiving a Destination Address
                               advertisement (eg, does it store the
                               Destination Address advertisements of its
                               children, Does it further re-propagate the
                               Destination Address advertisements to
                               devices of lower rank/depth, How long
                               should devices of lower rank/depth store
                               these destination address advertisements)

DT:
When a node is capable of storing DAs (i.e. it has sufficient storage for
the DA state), then it will do so, along with the depth, and after some
time will re-emit the best DA from the options it has seen, perhaps
performing route aggregation/summarization if it is able.

When a node is not capable of storing DAs (i.e. it has no storage for the
DA state), then it will update the reverse routing statck in the DA and
immediately pass it on.

There is a related concern, brought up in IETF-75, about the effect of
`fan-out' when coupled with the DA mechanism in a DAG, i.e. as DAs are
propagated among (potentially) multiple sets of DAG parents, what steps
need to be taken to keep the multiplicative effect under control.

For nodes who are storing DAs, the DA's will be stored until a no-DAO is
received or the DA lifetime expires.

No-DAO (lifetime 0) would be propagated immediately and unreliably.  This
another instance where a loop is easily created and thus requires
detection.  This is a case where an approach to loop detection would be
enough.

In general, it is clear that there is work to do in the RPL draft to more
clearly state the operation of the DA mechanism, and to remove some
ambiguity in the description of the core mechanism.

               b.    Routing of P2P traffic
                       i.     I assume that the DAG-root holds the address
                               of all Destination Address Advertisements
                               it has received from devices in its DAG.
                               Is this true?
DT: As mentioned on the list, there could be cases where only the MP2P flows
are of interest (no P2MP traffic), in which case the DA mechanism may not
even be invoked and there is not need to MUST the DAG-root to hold the
addresses.

If P2MP traffic is supported, and the DA mechanism is used, then the
DAG-root MUST store the state learned from the DAs it receives.  This
should be further clarified in the draft.

Note that if route summarization is in play, e.g. some sort of hierarchical
addressing structure is supported, then the DAG root may not receive a DA
for every device in its DAG; the addressing structure may allow DAs to be
absorbed and aggregated as the move up the DAG.  This mechanism needs
further exploration, as described in the answer to a related question
above.

                       ii.    I assume that other devices in the DAG of higher
                               rank/depth from the DAG-root but still
                               lower in rank than the final destination
                               routes packets down the DAG.  It seems
                               possible for the destination to receive
                               multiple copies (is this correct) and more
                               importantly it also seems possible for an
                               Unreachable notification to be generated by
                               some device in the DAG when in fact the
                               packet reached its destination through
                               another path (did I read the proposal
                               wrong?)
DT: Yes duplicates may be received but this is beyond the scope of RPL, and
any traffic running over an IP service should be prepared to handle
(or ignore, or not care) possible duplicates.  Likewise, in some
implementations, it may be possible for ICMP unreachable to be issued when
in fact the packet has slipped through.

               c.    Sibling routing seems to be not supported (though I
                               saw discussion of this on the reflector).
                               It seems problematic to have Siblings
                               processing Destination Address
                               advertisements within the same DAG.  We
                               should leave this out of the clarification
                               if my reading is correct and only add it
                               back as part of support for optimized P2P
                               if that is where the optimization leads.
DT: To clarify, `sibling routing' in this question is the same as
`next-door neighbor' or `1-hop' neighbor that has been discussed on the
list, and in fact entails all neighbors (not just siblings as in
nodes-of-the-same-rank).  It is the intention that this type of routing is
supported by RPL.  The proposal on the table is that nodes will make use of
mulicast DAOs in order to inform their neighbors of their owned prefixes.
Text will be added to the -01 draft to specify this mechanism.


       I also have some questions on the freezing of DAGs and ungrounded
       DAGs but I think that is a separate issue and I will put out a note
       later in the week on this.
DT: Please feel free to ask at any time- it will help to produce a better
-01 draft.

---------------------------------------------------------------------------
       From: Jerald.P.Martocci@jci.com

       I would like the following questions answered on subsequent
       revisions of the draft:

       a) What is the roll of 'siblings'?  They are in the current RPL
       document, yet seem to be demoted from parental links.  As I read
       the draft, one cannot use a sibling link unless the parental links
       are exhausted.  The nodes don't seem to explicitly define sibling
       links.
DT: We will clarify this in the draft -01.  Siblings are neighboring nodes
of the same rank in the DAG.  The idea is that forwarding via siblings may
allow a packet to make progress when the parents not available, i.e. the
sibling may have better luck making forward progress.  It is certainly
better than forwarding to a node of greater (outward) rank, and better than
dropping the packet.  So siblings are useful when making the list of
successors; first try the parents, second try siblings, last give up.

       b) What is the plan on communication to devices within direct radio
       range?  As I read the draft unless a node is made a 'parent', or
       possibly a 'sibling' it cannot be communicated with.  However,
       Anand mentions in his memo that at the Stockholm meeting there was
       discussion on directly connected devices.  Unfortunately, I
       couldn't attend the meeting.
DT: The intent is to support this and we intend to elaborate the mechanism
in the next revistion.  Please see the answer to `c' from Don
above.

       c) What are the approximate timer values for RPL?  The document
       gives no indication as to these timers, hence I can't calculate how
       long a floating DAG may be dislodged from its network.  In a
       real-time facility management control system, all nodes are
       monitored for falling off-line.  If the convergence time is too
       long (more than 1 minute), the devices will be flagged off-line and
       reported to the customer.
DT: The intent is that RPL may be parameterized first in a set of
applicability statements in each application domain and finally by the
implementors/administrators of the installed LLNs.  With this in mind, it
is clear that the document needs to better extract and clarify the role of
each timer, constraints on its values, and interactions with RPL mechanisms
in order that informed decisions can be made.  In some cases it may be
appropriate to derive relationships between the timers (e.g. timeout X
should be 3 times timeout Y), and in some cases it may be desirable to
have timers be adaptive.  We propose to clarify the timers in the -01 draft
so that there is a better basis to have these discussions.  A related task
is, e.g. the proper operation of the supression mechanism as has been
discussed on the list.

       d) What is the plan for security?  RPL doesn't currently weigh in
       on the topic.  Are security policies optional or mandatory?  Must
       the policy be consistent with the rest of the enterprise's IT
       security on other parts of the network?  Will security require
       nodes to keep state info as Rene suggests?
DT: There is no doubt that security is important and challenging for LLNs,
and it is important that security be designed in and not bolted on.  We
await WG progress in the security framework, and the guidance of ROLL's
advisor Rene Struik and will incorporate the necessary mechanisms into RPL.

Of particular interest here is to identify any potential places where the
unique issues of low power and lossy networks impact routing security.  For
example, have any of the measures that have been taken to operate with a
small routing footprint or at low protocol overhead increased
vulnerabilities?  (It is conceivable that by recording very little
information, being very parsimonious about what it communicated, and coping
with transient inconsistencies and uncertainty, these networks are actually
less vulnerable.) This may be distinct from the family of security issues for
the end-hosts that may have interfaces to such networks.  Of course, we
need also to attend to the relatively common case where a node is both host
and router.

       e) What requirements from the 4 requirement drafts are being
       considered?  When the DT first was engaged, it said it would
       publish the list of requirements as an appendix and note if the
       current draft supported which requirement.  This hasn't occurred
       and may be adding to the email angst.  As a requirement's author, I
       would rather know up front that some of my MUST requirements are
       not being considered.
DT: All requirements are to be considered, as summarized in
http://www.ietf.org/mail-archive/web/roll/current/msg01291.html (but
superceded as the application drafts are updated to become RFCs).  The
intent is not to re-iterate the requirements in the appendix, but rather to
justify any requirements that are not met in the final specification.  WG
members must help to ensure that the requirements are suitably met by the
proposed specification.

       f) What is the expected frame overhead size based on all the above
       criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation,
       UDP/TCP.  We need to add in the encryption and authentication overhead;
       and now maybe source routing.  I realize ROLL is trying to be
       agnostic to L2, however in practice 802.15.4 is the only game in
       town.  It only carries a 128 by packet size.  The DT/WG should at
       least give an accounting of the expected frame overhead so we can
       determine what L2s are feasible for the protocol.
DT: As small as possible ;)  ROLL is agnostic to L2, and there are most
certainly folks in the WG involved with L2 other than 802.15.4.  We do
recognize that typical LLN solutions will be using very constrained link
technologies.  Let us continue to clarify the RPL specification, with the
goal in mind to provide the simplest, smallest footprint core mechanism,
and then see that any overhead is efficiently allocated.  Then we should
have justification of what an L2 may need to provide to support RPL,
whether or not it is appropriate, and/or what sort of
adaptation/subnetwork, is required for RPL operation.

As a related point, there is still work to do with regards to header
compression/address compression, ...

       g) What routing data must persist a warmstart/coldstart?  The
       overhead to establish a DAG is significant.  We should consider
       what data might be able to transcend a network reboot to minimize
       communication startup bottlenecks.
DT: It is not *required* that routing data persist a warmstart/coldstart,
e.g. RPL should not be fundamentally broken by a failure to do so, but as
you note it may certainly help to make things more efficient.  We propose
to clarify what data an implementation may consider to perist in the next
version of the draft.

       As Pascal has noted in previous emails, some of these issues may be
       considered out-of bounds for the protocol and should be an
       implementation decision.  That may indeed be true, but RPL should
       state its case explicitly.  In the Building Market, it is
       multi-disciplined (HVAC, Fire, Lighting) and multi-vendor.  Unless
       some higher authority prescribes operation, the chances of LLN
       node-to-node interoperability are moot.

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

       RPL currently makes no mention of sleepy devices.  These will be
       very commonplace in WSNs.  I would like to amend my list below and
       add sleepy device management.  RPL needs to state what happens to
       packets routed to sleepy devices while they are asleep.  Are they
       dropped?  Will a proxy manage the packet until the device awakens?
       Will the last router return an error to the source?
DT: This should be handled with an adaptation layer, and the underlying L2,
although L3 may need to be aware of such devices, e.g. to provision proper
DA timeouts for `long sleepers', etc.  We propose to follow the lead of
6LowPAN here and related L2 efforts such as 802.15.4e for the case of
LoWPANs.  PLC L2 layers and emerging WLAN, e.g., low power 802.11 have
related but distinct behaviors.


---------------------------------------------------------------------------
             "Mathilde Durvy (mdurvy)" <mdurvy@cisco.com>

       I would personally want to see more discussion on 3 topics where
       I'm still not fully convinced:

       [SIBLINGS] The role of siblings: this adds quite some extra
       complexity to the routing but what does it really bring in
       practice?  Should siblings be part of the foundation layer? My
       opinion is no.
DT: For the moment we think yes, see above answer to Jerry's question `a'
above.  But what does the rest of the WG think?

       [METRICS] 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?
DT: We will clarify this further in the draft.  The intent is that the
depth (i.e. `rank') is to serve equivalently to this single metric you
described: its value is determined by the mechanism defined in the OCP, it
is to be derived in a way that is related to position in the DAG with
certain properties useful for loop avoidance, and its loop avoidance
properties are to be universal such that neighboring nodes may understand
even in the case where they don't understand the OCP (e.g. `esperanto').

       [TIMERS] 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 during the IETF meeting
       can we guarantee the right sequencing of RA / DAG Hop timer firing?
DT: To be clarified, as per Jerry's question `c' above.  In addition, note
that we may not always be able to guarantee the sequencing of the RA / DAG
Hop timers as in the example- in the best case scenario the timer values
should allow for the coordinated freezing of the sub-DAG and subsequent DAG
Merge.  But in some cases, e.g. due to comm loss, the freezing might not be
coordinated and the DAG Merge might be choppy/fragmented.  But RPL should
still be able to operate, by detecting resuling inconsistencies and
repairing.

---------------------------------------------------------------------------
       From: "Julien Abeille (jabeille)" <jabeille@cisco.com>

       a few more items:
       [Packet format] Clarify the rationale to use RAs/NAs. More precisely:
       - are RAs sent for router discovery/prefix discovery the same as
               those used by ROLL (same timer).
               -- If yes, does it impact the way router discovery/prefix
                       discovery work (preformance, do they really have
                       the same timing constraints?)

DT: The DIO is specified as an RA option, and just like any other option,
it doesn't have to be sent in every RA. Sending the DIO does not have to be
on the same timer. However, it may be advantageous to include a prefix
information option along with a DIO so that a node can also autoconfigure
its address in addition to configuring a default route with a single
message transmission (reduced energy, channel utilization, etc). As a
result, it may mean that some options specified in RFC4861 may be sent more
frequently that if RPL was not using RA messages as a transport. We don't
think there is any issue with sending options more frequently than expected
- if you think there are, please raise them.

               -- if yes, what is the approach with regards to update of
                       RFC4861 (6lowpan-nd is not in scope in my opinion
                       as it is L2 dependant, while ROLL is not)?
               -- if not, why not using a specific packet?

       - NA:
               -- Are NAs sent for ROLL used for anything else? If not why
                       not use a specific packet to carry DAOs?

               -- NAs are already pretty overloaded (DAD, NUD, Address
                       resolution), using a different packet may bring NA
                       processing complexity down.
DT:  There was some discussion at IETF-75 regarding trying to generalize
the ND binding.  For now we may concentrate on the form and function of
DIOs/DAOs and how they interact in the RPL protocol, leaving the RA and
NA in place for the moment.  Once the core mechanisms are refined we may
then revisit/refine what is used to carry the advertisements.  A clear
preference would be to not cause modification to established IPv6 ND
behaviour.




- END -
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0062861086257610_=-- From wintert@acm.org Wed Aug 12 12:55: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 1F1EA3A6807 for ; Wed, 12 Aug 2009 12:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.217, 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 gawTPVvfuWq6 for ; Wed, 12 Aug 2009 12:55:06 -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 31E193A67B7 for ; Wed, 12 Aug 2009 12:55:06 -0700 (PDT) Received: (qmail 12038 invoked from network); 12 Aug 2009 19:53:43 -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; 12 Aug 2009 12:53:43 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: ICKBBGQVM1krtzOSSJo2EZqPg_B5tzUEKnhAbxpghPZFKhzNbuuZy8wpBMFPXPHio1V1OIAn21WK9oIwQUMk3rbDeUxIo4JtRuaX.EnBOPjkzf6UXC_mQ7x5uum0mLTILM6moUxPjaQgHM1ZV7bixHP5HL3883Ii5ukuUaQ._D6fNiMViiTXSmHSnOoiDh_OvF.REaF_Yowg5sJu0L6tFE2kiFINZWqtosyx3fau6EsCmoh58b9bc6byIOFibRkywN5mq6sGiwHzWUNNegwZBA5PywK8NjEHIFb4oAduCnMwh9svI.HM410My34fMZifscQSLrkJbmgpxPv4A.AiFrhjKj6LHKlEtK2X X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A831DC8.6000806@acm.org> Date: Wed, 12 Aug 2009 15:53:44 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Next Steps X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Aug 2009 19:55:07 -0000 Hi Jerry, Sorry for the confusion- The individual submission, draft-dt-roll-rpl, had made it to revision -01 with the OCP additions. The WG draft, draft-ietf-roll-rpl, is still at -00. (The contents are equivalent). So the next revision of the WG document will be be draft-ietf-roll-rpl-01 Thanks, -Tim Jerald.P.Martocci@jci.com wrote: > > > */This sounds like a plan. However, aren't you talking about the -02 > version? I thought we already have a -01 version that introduced 'OCP'?/* > > > > > *Tim Winter * > Sent by: roll-bounces@ietf.org > > 08/11/2009 06:00 PM > > > To > ROLL WG > cc > > Subject > [Roll] RPL Next Steps > > > > > > > > > WG, > > Please find below some additional feedback from the design team on the > questions that have been raised so far for RPL. Not everything has been > covered- but the questions have served to point out some areas of the draft > where we need to continue and focus efforts. > > We (DT) propose, in the -01 version of the draft, to clarify as much > as possible the outstanding questions and concerns in the current > specification of RPL, with emphasis on the existing (-00) mechanisms. The > intent is to provide a solid, unambiguous, implementable, foundation of the > existing core mechanisms in -01. On this foundation we can then continue > to build and expand other necessary mechanisms in later revisions, such as > are being discussed for P2P routing. There is no doubt that the P2P issues > need to be further discussed and addressed, but the thought is that by > clearing up the existing mechanisms we may be able to make better progress > in moving forward beyond the existing mechansisms in later revisions. > > WG, how does this sound as a strategy to make progress on RPL? > > From nicolas.riou@fr.schneider-electric.com Wed Aug 12 13:49: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 7776F28C0F7 for ; Wed, 12 Aug 2009 13:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 j4OcbmE-tl4f for ; Wed, 12 Aug 2009 13:49:30 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id C7BC53A6AF3 for ; Wed, 12 Aug 2009 13:49:07 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2009081222483969-43734 ; Wed, 12 Aug 2009 22:48:39 +0200 To: roll@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Wed, 12 Aug 2009 22:42:57 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 12/08/2009 22:48:39, Serialize complete at 12/08/2009 22:48:39, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 08/12/2009 10:48:39 PM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 08/12/2009 10:49:12 PM, Serialize complete at 08/12/2009 10:49:12 PM Content-Type: multipart/alternative; boundary="=_alternative 00724D87C1257610_=" Cc: nicolas.riou@fr.schneider-electric.com Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Aug 2009 20:49:34 -0000 Message en plusieurs parties au format MIME --=_alternative 00724D87C1257610_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hi DT and rollers, I?m arriving a bit late on the mailing list but I would like to say that I = fully support Jerry and Mukul regarding P2P support. Efficient P2P support = is essential for building application systems, especially for=20 time-sensitive applications (lighting control, fire?).=20 Beyond P2P, I would also like to get better understanding on multicast=20 support with RPL. Even though multicast should be avoided when possible in = a LLNs, it is still required for multiple building automation applications = (to control banks of lights simultaneously, to control complex and=20 time-sensitive automation scenes, to quickly trigger emergency procedures=20 and disseminate information to multiple devices?) and to allow for future=20 publish/subscribe architectures. In building scenarios, multicast traffic=20 will not necessarily be initiated from the DAG root toward leaves but from = any arbitrary node in the lowpan to a group of arbitrary nodes. Except in=20 section 3.3.3.1 ?DAO can convey multicast listeners?, the draft provides=20 little information on how multicast traffic will be spread. Is it possible = to get some more details on multicast support in RPL? Is it conceivable to = operate MLD into lowpans (I assume no), else is there any plan to define a = tailored lightweight MLD protocol to avoid flooding the whole network and=20 irrigate only zones where multicast flow subscribers exist? Thanks and Best regards, Nicolas --=_alternative 00724D87C1257610_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi DT and rollers,

I’m arriving a bit late on the mail= ing list but I would like to say that I fully support Jerry and Mukul regarding P2P support. Efficient P2P support is essential for building application systems, especially for time-sensitive applications (lighting control, fire…).
Beyond P2P, I would also like to get bett= er understanding on multicast support with RPL. Even though multicast should be avoided when possible in a LLNs, it is still required for multiple build= ing automation applications (to control banks of lights simultaneously, to control complex and time-sensitive automation scenes, to quickly trigger emergency procedures and disseminate information to multiple devices…) and to allow for future publish/subscribe architectures. In building scenar= ios, multicast traffic will not necessarily be initiated from the DAG root toward leaves but from any arbitrary node in the lowpan to a group of arbitrary nodes. Except in section 3.3.3.1 “DAO can convey multicast listeners&= #8221;, the draft provides little information on how multicast traffic will be spread. Is it possible to get some more details on multicast support in RPL? Is it conceivable to operate MLD into lowpans (I assume no), else is there any plan to define a tailored lightweight MLD protocol to avoid flooding the whole network and irrigate only zones where multicast flow subscribers exist?

Thanks and Best regards,
Nicolas
 --=_alternative 00724D87C1257610_=-- From alexandru.petrescu@gmail.com Tue Aug 18 07:30: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 5E0E128C1F0 for ; Tue, 18 Aug 2009 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, 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 fH6PmF0q4iha for ; Tue, 18 Aug 2009 07:30:15 -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 3737628C1A8 for ; Tue, 18 Aug 2009 07:30:15 -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 n7IETttN001768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Aug 2009 16:29: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 n7IETsqt007035; Tue, 18 Aug 2009 16:29: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 n7IETrnJ023911; Tue, 18 Aug 2009 16:29:54 +0200 Message-ID: <4A8ABAE1.4060401@gmail.com> Date: Tue, 18 Aug 2009 16:29:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tim Winter References: <4A81F79A.10104@acm.org> In-Reply-To: <4A81F79A.10104@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] RPL Next Steps X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Aug 2009 14:30:16 -0000 Tim and DT, thank you for addressing my comments on the draft. A. Petrescu wrote and then T. Winter on behalf of DT wrote: >> I would like to get clarification on the IPv6 addressing >> architecture and subnet structure considered in RPL. >> >> -is it the AUTOCONF addressing model? > > DT: It is important that RPL work with whatever addressing model we > utilize in the future and that it operate in contexts where the > addressing model is already constrained. Thus, RPL treats the > address as opaque. If you like, you can view it as flat, but really > it is uninterpreted at this stage. Sorry, I don't follow. I feel like you provide an answer that doesn't answer anything, but which is valid in itself. The AUTOCONF addressing model seems to be a special model where host-based routes are used mostly and where rarely the /64 prefixes are allocated on subnets. It's under development. http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 And where link-local addresses are rarely if ever used. It is important to know, for example, whether RPL uses link-local addresses or not. YOu say they're opaque, but what kind of opaqueness? If it is "route-over" - will the link-local addressed packets be forwarded between subnets? Probably not. If so, it should be said so. If the ROLL network is like an ad-hoc network where link-local addresses are rarely if ever used - then this too should be said. > With this in mind, it is clear that RPL will benefit from the ability > to do route summarization along the DAG, particularly in order to > improve scalability. Future work on the draft may evolve this > mechanism, and there is work to do on the ROLL architectural > framework that may offer additional clarifications. I am highly interested to know the addressing model and the subnets that are used by an example RPL deployment. I can offer remarks towards designing such an addressing model. Maybe starting with an example. >> -is it the 6LoWPAN route over or mesh-under? > > DT: RPL intends to operate purely at L3, and it is the intention of > RPL to be L2 agnostic, so it "routes over". If it were over, e.g. > switched ethernet or 802.11 mesh or 802.15.4 mesh underneath, it > should work. It should also work on, e.g., ethernet, 802.11, and > 802.15.4 where no "meshing" is done at layer 2. Ok, then if it "routes over" then we should know what an example addressing architecture and subnet structure should be. >> -how many physical interfaces does a node have? > > DT: This is out of scope for RPL. I find this strange. >> -if a node has several interfaces then does it have only one >> physical interface? > > DT: This may be a typical case, but again out of scope for RPL. A > subnetwork / adaptation layer should handle this. This sounds like you _require_ an adaptation layer. Whereas it seems less and less clear to me that an adaptation layer is needed. >> -what is the default route behaviour? Does each node have default >> route? > > DT: A default route MAY be offered by a grounded DAG, in which case > it will be installed. In some cases (application specific) the > default route may not be offered by a grounded DAG, in which case > there is no default route and a node will not be able to use a > default route to forward packets. In such cases it is presumed that > an application, choosing not to provision a default route in a DAG > root, will take care to use only prefixes that can be routed within > the DAG. Thanks for clarification. I assume that if there is no default routes in the ROLL network then that network is not connected to the Internet. Just a note. >> -are there IPv6 prefix subnets /64? > > DT: There could be, but it is not required. In cases where RPL > allows prefix specification, the prefix length may be specified from > 0-128. Should be 0,3-64 otherwise itcouldn't work (the first 3 bits can't be touched, and beyond 64 the stateless autoconf wouldn't work anymore). >> Here is a DAG excerpt from 01 draft: >> >> (A) >> |\ >> | `-----. >> | \ >> (B) \ >> \ | >> `-----. | >> \| >> (C) >> >> Does that mean the IPv6 addressing arechitecture is this: >> >> >> (A) >> |\ >> 2001:db8:1::/64 | `-----. >> | \ 2001:db8:2::/64 >> (B) \ >> \ | >> `-----. | >> 2001:db8:3::/64 \| >> (C) Let me restate this question: is this prefix distribution in the graph above valid for ROLL network and RPL protocol? Or is it totaly wrong? Thanks, Alex From alexandru.petrescu@gmail.com Tue Aug 18 07:35: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 6A57D3A69CA for ; Tue, 18 Aug 2009 07:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwwajjqqD686 for ; Tue, 18 Aug 2009 07:35:38 -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 5414B3A6AD2 for ; Tue, 18 Aug 2009 07:35:38 -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 n7IEZRAj024404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Aug 2009 16:35:27 +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 n7IEZQZA008225; Tue, 18 Aug 2009 16:35:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n7IEZQPZ004974; Tue, 18 Aug 2009 16:35:26 +0200 Message-ID: <4A8ABC2E.9070603@gmail.com> Date: Tue, 18 Aug 2009 16:35:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tim Winter References: <4A831DC8.6000806@acm.org> In-Reply-To: <4A831DC8.6000806@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] RPL Next Steps X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Aug 2009 14:35:39 -0000 Did one know that OCP (RPL Objective Code Point) also stands for "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core" RFC4037 on the Standards Track? Alex Tim Winter a écrit : > Hi Jerry, > > Sorry for the confusion- The individual submission, > draft-dt-roll-rpl, had made it to revision -01 with the OCP > additions. The WG draft, draft-ietf-roll-rpl, is still at -00. (The > contents are equivalent). > > So the next revision of the WG document will be be > draft-ietf-roll-rpl-01 > > Thanks, > > -Tim > > > Jerald.P.Martocci@jci.com wrote: >> >> */This sounds like a plan. However, aren't you talking about the >> -02 version? I thought we already have a -01 version that >> introduced 'OCP'?/* >> >> >> >> >> *Tim Winter * Sent by: roll-bounces@ietf.org >> >> 08/11/2009 06:00 PM >> >> To ROLL WG cc Subject [Roll] RPL Next Steps >> >> >> >> >> >> >> >> >> WG, >> >> Please find below some additional feedback from the design team on >> the questions that have been raised so far for RPL. Not everything >> has been covered- but the questions have served to point out some >> areas of the draft where we need to continue and focus efforts. >> >> We (DT) propose, in the -01 version of the draft, to clarify as >> much as possible the outstanding questions and concerns in the >> current specification of RPL, with emphasis on the existing (-00) >> mechanisms. The intent is to provide a solid, unambiguous, >> implementable, foundation of the existing core mechanisms in -01. >> On this foundation we can then continue to build and expand other >> necessary mechanisms in later revisions, such as are being >> discussed for P2P routing. There is no doubt that the P2P issues >> need to be further discussed and addressed, but the thought is that >> by clearing up the existing mechanisms we may be able to make >> better progress in moving forward beyond the existing mechansisms >> in later revisions. >> >> WG, how does this sound as a strategy to make progress on RPL? >> >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From wwwrun@core3.amsl.com Wed Aug 19 06:38:48 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6EEE03A6DBC; Wed, 19 Aug 2009 06:38:48 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090819133848.6EEE03A6DBC@core3.amsl.com> Date: Wed, 19 Aug 2009 06:38:48 -0700 (PDT) Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Document Action: 'Industrial Routing Requirements in Low Power and Lossy Networks' to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Aug 2009 13:38:48 -0000 The IESG has approved the following document: - 'Industrial Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-06.txt Technical Summary Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers by extending the information set available from wired systems. In an industrial environment, low power, high reliability, and easy installation and maintenance are mandatory qualities for wireless devices. The aim of this document is to analyze the requirements for the routing protocol used for Low power and Lossy Networks (LLN) in industrial environments. IPv6 is perceived as a key technology to provide the scalability and interoperability that are required in that space and is being more and more present in standards and products under development and early deployments. Cable is perceived as a more proven, safer techhnology, and existing, operational deployments are very stable in time. For these reasons, it is not expected that wireless will replace wire in any foreseeable future; the consensus in the industrial space is rather that wireless will tremendously augment the scope and benefits of automation by enabling the control of devices that were not connected in the past for reasons of cost and/or deployment complexities. But for LLN to be adopted in the industrial environment, the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The routing protocol used for low power and lossy networks (LLN) is important to fulfilling these goals. Industrial automation is segmented into two distinct application spaces, known as "process" or "process control" and "discrete manufacturing" or "factory automation". In industrial process control, the product is typically a fluid (oil, gas, chemicals ...). In factory automation or discrete manufacturing, the products are individual elements (screws, cars, dolls). While there is some overlap of products and systems between these two segments, they are surprisingly separate communities. The specifications targeting industrial process control tend to have more tolerance for network latency than what is needed for factory automation. Irrespective of this different 'process' and 'discrete' plant nature both plant types will have similar needs for automating the collection of data that used to be collected manually, or was not collected before. Examples are wireless sensors that report the state of a fuse, report the state of a luminary, HVAC status, report vibration levels on pumps, report man-down, and so on. Other novel application arenas that equally apply to both 'process' and 'discrete' involve mobile sensors that roam in and out of plants, such as active sensor tags on containers or vehicles. Some if not all of these applications will need to be served by the same low power and lossy wireless network technology. This may mean several disconnected, autonomous LLN networks connecting to multiple hosts, but sharing the same ether. Interconnecting such networks, if only to supervise channel and priority allocations, or to fully synchronize, or to share path capacity within a set of physical network components may be desired, or may not be desired for practical reasons, such as e.g. cyber security concerns in relation to plant safety and integrity. All application spaces desire battery operated networks of hundreds of sensors and actuators communicating with LLN access points. In an oil refinery, the total number of devices might exceed one million, but the devices will be clustered into smaller networks that in most cases interconnect and report to an existing plant network infrastructure. Working Group Summary No controversy. Document Quality The I-D is informational and specifies IPv6 routing requirements. Personnel Who is the Document Shepherd for this document? JP Vasseur (jvasseur@cisco.com) Who is the Responsible Area Director? Adrian Farrel (adrian.farrel@huawei.com) From pthubert@cisco.com Wed Aug 19 09:01: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 E16153A6B1E for ; Wed, 19 Aug 2009 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.78 X-Spam-Level: X-Spam-Status: No, score=-9.78 tagged_above=-999 required=5 tests=[AWL=0.819, 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 vUXPw8ny9yKq for ; Wed, 19 Aug 2009 09:01:54 -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 462353A67F8 for ; Wed, 19 Aug 2009 09:01:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AABS/i0qQ/uCLe2dsb2JhbACPXYswAQEWJAahbogvkVMFhBo X-IronPort-AV: E=Sophos;i="4.43,409,1246838400"; d="scan'208";a="47442722" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2009 16:01:57 +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 n7JG1vmc012924; Wed, 19 Aug 2009 18:01:57 +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 n7JG1vb9006389; Wed, 19 Aug 2009 16:01:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 18:01:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 18:01:51 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0D0B95@XMB-AMS-107.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL preferred vs. alternate parents Thread-Index: AcoWM3rhFV2cGJo8QaSDZVBcGMT6DgAQY4nwApvnk3A= References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> From: "Pascal Thubert (pthubert)" To: , "Tim Winter" X-OriginalArrivalTime: 19 Aug 2009 16:01:57.0414 (UTC) FILETIME=[60EC3460:01CA20E6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5670; t=1250697717; x=1251561717; 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=20preferred=20vs.=20altern ate=20parents |Sender:=20; bh=Juk340l4Nnlqk02t2MS7v0s2H6yvZxXi+F69TesO87I=; b=cCYdkDAhgkQ64jQjBNea4g6Wyf6jiJRfxuNZNTfnF2zpVipMktFhkloKtR Ozy/hhEiZqzMy0+2jsZgZs5eKgLruiXoHXLZ3rsC2W9G6kJjWyIX+23UlAm3 XBXxLIXW1H; 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 preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Aug 2009 16:01:56 -0000 Hi Dominique ad Anand: >Let me try to reformulate my question with an example. > >Node N springs into existence and discovers a few neighbors A, B, C and = D >- node A advertises depth 1.25 >- node B depth 3.75 >- node C depth 4.50 >- node D depth 8.25 >Given the advertised depth, the link costs and other characteristics, = Node N determines through its objective >function that its preferred parent is node B and that it should take = 5.25 (=3D B's depth 3.75 + link cost 1.50) >as its own depth. >Node N then fleshes up its DAG by adding alternate parents: >- node D is out of the question because it is lower in the DAG (event = horizon). >- node A can be considered for inclusion as an alternate parent >From the excerpts of the RPL draft quoted below, as well as from = Pascal's email, I understand that C is not >eligible to become an alternate parent to N. >My question is: "Why?" The text has been reshuffled and that might explain why the rationale is = unclear. Placing a limit that the depth of the best parent is the worst = depth for any acceptable parent is not for loop avoidance, you could = pick any parent set and be deeper than the worst of them and that'd be = cool.=20 The reason is to "honestly" place an event horizon on what can make you = move, in order to avoid the so called greedy behavior. In your example, = the event horizon includes only A and B so whatever happens to C is = ignored. This avoids a greedy behavior of leaving the tree to reattach = behind C, which C could emulate later to attach behind self, and we're = in a greedy loop. > >The only tentative explanation I've read so far is in the RPL draft, = Section 3.4.1 "This mechanism serves to >avoid loops in the case where an alternate parent is used- if no = alternate parent is deeper than the preferred >parent then loops are avoided." which I don't view as an explanation. = If each node only forwards packet to >nodes with lesser depth (barring forwarding to siblings for this = discussion) then loops will be avoided even >is C is included as an alternate parent of N. >Am I mistaken somewhere? > >[Of course, if we enforce depth to be integers and node N's depth to be = exactly its preferred parent's depth + >1, then this whole discussion goes away. But it is my understanding = that we are now dealing with increments >that are not exactly 1, and/or fractional depths, aren't we?] You're perfectly right. If we migrate to finer sub-increments, we can = accept C as a parent as opposed to sibling.=20 The rule should now say that we derive our own depth from the preferred = parent + link cost, and then an acceptable parent is anyone that's = inwards from us, in your case A, B and C. Great point :) Pascal =20 > >Regards, >Dominique > >Quotes : >- 3.3.1.5 "It is recommended that a node maintain its DAG Parent set = such that its most preferred parent from >the OCP goals also has the greatest depth value in the DAG parent set." >- 3.4.1 "For a node N, and its most preferred parent M, .... all = parents in the DAG parent set must be of a >depth less than or equal to DAGDepth(M)." >- 5.2.1 "All nodes in the DAG Parent set should be of a depth less than = or equal to the most preferred DAG >parent." >- Pascal's email July 3rd 14:06 +0200 "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." = http://www.ietf.org/mail-archive/web/roll/current/msg01463.html >________________________________ > >De : M. B. Anand [mailto:privateanand@gmail.com] >Envoy=E9 : jeudi 6 ao=FBt 2009 03:15 >=C0 : BARTHEL Dominique RD-TECH-GRE >Objet : Re: [Roll] RPL preferred vs. alternate parents > > >Hi Dominique, > > > > > > Further, the whole text of 3.4.1 ("more optimum", "same optimality", > "less optimum") leads one to think that higher in the DAG is better. > Something sounds wrong to me if node N's preferred parent should > precisely be the "worse" of its parents. > > >The alternates will themselves be at equal or less depth compared to = the preferred, but they may not offer the >_node N_ a chance to become less deep because that depends also on the = node's optimization metric w.r.t the >alternates. If one of the candidate neighbors does offer this, by all = means the node can make that candidate >the preferred. This is the `moving inwards along the DAG' - section = 3.3.1.6, 5th paragraph. Of course, the >node N will then need to update its set of parents. So the preferred = parent will be the "best" according to >the node's optimization. > >The idea is to forward traffic or move inwards - less deep - in = DAGDepth - then there will never be loops. >Forwarding sideways - same DAGDepth - is also allowed but that has some = chance of loops. Going deeper will >create the chance of loops. > >BTW, in the draft "higher" in the DAG means closer to the root, inwards = in the DAG. See for example, Section >3.3.1.6, Section 5.3, point #6, Section 5.3.3.1 etc. I think you mean = "lower" when you say " leads one to >think that higher in the DAG is better". > >Regards, >Anand. > > > > > > > Can anybody offer a substantiated explanation? > Thanks > > Dominique > _______________________________________________ > 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 roger.alexander@ekasystems.com Wed Aug 19 15:22: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 DBA0028C0D6 for ; Wed, 19 Aug 2009 15:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-1.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 bir1RsPo+SUB for ; Wed, 19 Aug 2009 15:22:17 -0700 (PDT) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id 6D24D3A6A82 for ; Wed, 19 Aug 2009 15:22:17 -0700 (PDT) Received: (qmail 12754 invoked from network); 19 Aug 2009 22:22:21 -0000 Received: from unknown (HELO NAVAJO) (roger.alexander@209.48.242.70 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 19 Aug 2009 22:22:20 -0000 X-Yahoo-SMTP: f4aLZiaswBDsxvV5XgIN2aI9HC.7M2EhZSsdK7e_g3WQxp2yUttBXT91Jw-- X-YMail-OSG: sCAZPlwVM1m8yo6ZQZavRtjPXMtDupOWYtHRprKvhsNqcgt3vvKb9nwGob1pO3hQ3_IerIDJEZC8DrIEiKiCevyZ8jofOysLpGmJlqNa4.yBIBFhb5trlpsxnEpRF1_NfzXXw1KU5vpeUIiJr6cxJHlZLCwTyCOTvXLLUAqMcVVwqELU125DUPQeKxJX763cK2_sOjdYtuOIKvPNXIh7I4XFkyX2k387HfOaM_xxnCEfzj.e6c4qYCmF8LUrS1yPm_R5KEvm7A8oZIRvuJWw_BF8oTYh0ZOfMe4B3FRtKNJeUq8- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Pascal Thubert \(pthubert\)'" , , "'Tim Winter'" References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> <6A2A459175DABE4BB11DE2026AA50A5D0D0B95@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0D0B95@XMB-AMS-107.cisco.com> Date: Wed, 19 Aug 2009 18:24:10 -0400 Message-ID: <017801ca211b$c6085970$52190c50$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoWM3rhFV2cGJo8QaSDZVBcGMT6DgAQY4nwApvnk3AAAyvFwA== Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Aug 2009 22:22:18 -0000 Hi Pascal, WG, I am not clear on the example given in Section 3.4.2.1 and referenced to some degree in your response below regarding greedy parent selection. = The cycle set up by nodes alternating with each other regarding who is the parent should be avoided if nodes in a DAG are always clear about the = OCP metrics establishing the parent-child relationship. Two nodes exchanging (receiving) routing information will determine their respective = depths/ranks relative to the root of the DAG. The node with a higher depth/rank = (closer to the root) should always be the parent. Even as links change, once relative depth/rank determines the parent-child relationship, nodes can = be greedy in parent selection provided that between any two nodes the parent-child relationship is understood (which follows directly from the routing information and confirmed via subsequent Destination Advertisements). In the example in Figure 2 with the root at node A, until link costs = change the depth of nodes B or C relative to the node A, one or the other (B or = C) will be the parent node. Depth/rank relative to the root establishes = which node is the parent. A node cannot maintain another node in its parent = set where that node, through Destination Advertisements, confirms itself as = a child of the node. This would be consistent with the statement in = Section 3.3.1.5 "A general property of the depth value presented by the node is = that it should be greater than that 'presented' by any of its DAG parents." = With this explicit specification 'greed' would be permitted without leading = to the cycle described in Section 3.4.2. That also gets to a second issue that I would like to raise regarding a = node re-joining a DAG at a depth/rank lower (further from the root) than a current preferred parent. As stated at the end of section 3.4.1, "In the case where a node looses connectivity to the DAG, it must first leave = the DAG before it may then rejoin at a deeper point." It should not always = be necessary for the node to leave the DAG and invoke the process of = freezing the sub-DAG, etc. when the parent set becomes depleted. If the node can establish a parent at a lower depth and that parent candidate is not on = its sub-DAG, the node should be free to make that attachment when the parent = set is depleted.=20 For loop avoidance the node re-joining at lower depth should be = restricted to parents that are NOT on the node's sub-DAG (as determined by = exchanged and maintained DAs). With such a specification, if the parent set = becomes deleted the node can immediately re-join the DAG through a parent = candidate that is at a lower depth outside its sub-DAG. While this leads to a temporary period in which the connectivity of the sub-DAG is suboptimal (relative to prior advertised node depth), because it allows = connectivity to be maintained it may still be potentially preferable to the overhead of freezing the sub-DAG and the subsequently triggered re-associations. The temporary sub-optimality will be incrementally removed through the subsequent routing update exchanges without creating the additional = network overhead. Thanks for your feedback. Roger K Alexander=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Pascal Thubert (pthubert) > Sent: Wednesday, August 19, 2009 12:02 PM > To: dominique.barthel@orange-ftgroup.com; Tim Winter > Cc: roll@ietf.org > Subject: Re: [Roll] RPL preferred vs. alternate parents >=20 > Hi Dominique ad Anand: >=20 > >Let me try to reformulate my question with an example. > > > >Node N springs into existence and discovers a few neighbors A, B, C > and D > >- node A advertises depth 1.25 > >- node B depth 3.75 > >- node C depth 4.50 > >- node D depth 8.25 > >Given the advertised depth, the link costs and other characteristics, > Node N determines through its objective > >function that its preferred parent is node B and that it should take > 5.25 (=3D B's depth 3.75 + link cost 1.50) > >as its own depth. > >Node N then fleshes up its DAG by adding alternate parents: > >- node D is out of the question because it is lower in the DAG (event > horizon). > >- node A can be considered for inclusion as an alternate parent > >From the excerpts of the RPL draft quoted below, as well as from > Pascal's email, I understand that C is not > >eligible to become an alternate parent to N. > >My question is: "Why?" >=20 > The text has been reshuffled and that might explain why the rationale > is unclear. Placing a limit that the depth of the best parent is the > worst depth for any acceptable parent is not for loop avoidance, you > could pick any parent set and be deeper than the worst of them and > that'd be cool. >=20 > The reason is to "honestly" place an event horizon on what can make = you > move, in order to avoid the so called greedy behavior. In your = example, > the event horizon includes only A and B so whatever happens to C is > ignored. This avoids a greedy behavior of leaving the tree to reattach > behind C, which C could emulate later to attach behind self, and we're > in a greedy loop. >=20 > > > >The only tentative explanation I've read so far is in the RPL draft, > Section 3.4.1 "This mechanism serves to > >avoid loops in the case where an alternate parent is used- if no > alternate parent is deeper than the preferred > >parent then loops are avoided." which I don't view as an explanation. > If each node only forwards packet to > >nodes with lesser depth (barring forwarding to siblings for this > discussion) then loops will be avoided even > >is C is included as an alternate parent of N. > >Am I mistaken somewhere? > > > >[Of course, if we enforce depth to be integers and node N's depth to > be exactly its preferred parent's depth + > >1, then this whole discussion goes away. But it is my understanding > that we are now dealing with increments > >that are not exactly 1, and/or fractional depths, aren't we?] >=20 > You're perfectly right. If we migrate to finer sub-increments, we can > accept C as a parent as opposed to sibling. > The rule should now say that we derive our own depth from the = preferred > parent + link cost, and then an acceptable parent is anyone that's > inwards from us, in your case A, B and C. >=20 > Great point :) >=20 > Pascal >=20 > > > >Regards, > >Dominique > > > >Quotes : > >- 3.3.1.5 "It is recommended that a node maintain its DAG Parent set > such that its most preferred parent from > >the OCP goals also has the greatest depth value in the DAG parent > set." > >- 3.4.1 "For a node N, and its most preferred parent M, .... all > parents in the DAG parent set must be of a > >depth less than or equal to DAGDepth(M)." > >- 5.2.1 "All nodes in the DAG Parent set should be of a depth less > than or equal to the most preferred DAG > >parent." > >- Pascal's email July 3rd 14:06 +0200 "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." http://www.ietf.org/mail- > archive/web/roll/current/msg01463.html > >________________________________ > > > >De : M. B. Anand [mailto:privateanand@gmail.com] > >Envoy=E9 : jeudi 6 ao=FBt 2009 03:15 > >=C0 : BARTHEL Dominique RD-TECH-GRE > >Objet : Re: [Roll] RPL preferred vs. alternate parents > > > > > >Hi Dominique, > > > > > > > > > > > > Further, the whole text of 3.4.1 ("more optimum", "same > optimality", > > "less optimum") leads one to think that higher in the DAG is > better. > > Something sounds wrong to me if node N's preferred parent should > > precisely be the "worse" of its parents. > > > > > >The alternates will themselves be at equal or less depth compared to > the preferred, but they may not offer the > >_node N_ a chance to become less deep because that depends also on = the > node's optimization metric w.r.t the > >alternates. If one of the candidate neighbors does offer this, by all > means the node can make that candidate > >the preferred. This is the `moving inwards along the DAG' - section > 3.3.1.6, 5th paragraph. Of course, the > >node N will then need to update its set of parents. So the preferred > parent will be the "best" according to > >the node's optimization. > > > >The idea is to forward traffic or move inwards - less deep - in > DAGDepth - then there will never be loops. > >Forwarding sideways - same DAGDepth - is also allowed but that has > some chance of loops. Going deeper will > >create the chance of loops. > > > >BTW, in the draft "higher" in the DAG means closer to the root, > inwards in the DAG. See for example, Section > >3.3.1.6, Section 5.3, point #6, Section 5.3.3.1 etc. I think you mean > "lower" when you say " leads one to > >think that higher in the DAG is better". > > > >Regards, > >Anand. > > > > > > > > > > > > > > Can anybody offer a substantiated explanation? > > Thanks > > > > Dominique > > _______________________________________________ > > 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 Mon Aug 24 01: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 B996A28C16E for ; Mon, 24 Aug 2009 01:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.613 X-Spam-Level: X-Spam-Status: No, score=-7.613 tagged_above=-999 required=5 tests=[AWL=-1.015, 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 x1xDwLbcWo4V for ; Mon, 24 Aug 2009 01:53:13 -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 D8D3B28C155 for ; Mon, 24 Aug 2009 01:53:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAEPykUqrR7PD/2dsb2JhbACCJy+6Fog3jhkFhBo X-IronPort-AV: E=Sophos;i="4.44,264,1249257600"; d="scan'208,217";a="373741166" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2009 08:53:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7O8rKZe028963 for ; Mon, 24 Aug 2009 01:53:20 -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 n7O8qFsI025372 for ; Mon, 24 Aug 2009 08:53:19 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 10:53:16 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 10:53:15 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-10-66371307 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 10:53:14 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Aug 2009 08:53:15.0303 (UTC) FILETIME=[516A4B70:01CA2498] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16844.004 X-TM-AS-Result: No--9.311800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3788; t=1251104000; x=1251968000; 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:=20ROLL=20WG=20Interim=20Meeting |Sender:=20; bh=1Yalef+kBfIAaw8QQmYbyfWANjONT3F6Q7+crdmnKFw=; b=vPGOYzZfF+1VcvbOlFGl48CRUJfmRJxQ7Q6ozNsmWxtpF9+3Ybj+9mMSa7 i4txpyerzUvIJOOJPNhm2Lx4uNiUL+mhh4k6i25hzrqCsD4agoyKOxcFlQSd FQ3JhdFrUx; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] ROLL WG Interim Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2009 08:53:14 -0000 --Apple-Mail-10-66371307 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, In order to keep moving at the same pace, which is of utmost importance for this industry, we are planning to have an interim ROLL Working Group meeting before IETF-76. Since the previous Interim ROLL WG meeting took place in the US, we choose Europe for the location. Date and Venue September 30 hosted by Cisco Systems in ROLLE, Switzerland (30mn drive from Geneva Airport). Logistics details will of course be announced and discussed on the ML in due time. Here is a very first draft of the agenda, comments are of course very much welcome. As you can see we have enough to fill 3 hours of discussions. 1) Agenda/admin (Chairs - 5mn) [5] 2) WG Status (Chairs - 10 mn) [15] 3) RPL: Routing Protocol for Low power and Lossy networks draft-dt-roll-rpl-01 (TBD - 90mn) [115] 5) Metric ID - draft-ietf-roll-metric (TBD - 30mn) [145] 6) A Security Framework for Routing over Low Power and Lossy Networks (Tzeta - 35mn) [180] draft-tsao-roll-security-framework Let us know if you have any feed-back, thanks to send an email in reply to let us know if you are planning to attend (for logistic). Note also that the meeting has not yet been approved by Adrian. Thanks. JP. --Apple-Mail-10-66371307 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

In order to keep moving at the same pace, = which is of utmost importance for this industry, 
we are = planning to have an interim ROLL Working Group meeting before = IETF-76.

Since the previous Interim ROLL WG = meeting took place in the US, we choose Europe for = the 
location.

Date and = Venue
September 30 hosted by Cisco Systems in = ROLLE, Switzerland (30mn drive from Geneva = Airport).

Logistics details = will of course be announced and discussed on the ML in due = time.

Here is a very first draft of the agenda, = comments are of course very much welcome. As you can see
we = have enough to fill 3 hours of = discussions.

1) Agenda/admin (Chairs - = 5mn) [5]
       =   
2) WG Status (Chairs - 10 mn) = [15]
       =   
3) RPL: Routing Protocol for Low power = and Lossy networks
draft-dt-roll-rpl-01 (TBD - 90mn) = [115]

5) Metric ID - = draft-ietf-roll-metric (TBD - 30mn) [145]
   =  
6) A Security Framework for Routing over Low = Power and Lossy Networks
(Tzeta - 35mn) = [180]
draft-tsao-roll-security-framework

Let us know if you have any feed-back, thanks to = send an email in reply to let us know if you are planning
to = attend (for logistic).

Note also that the = meeting has not yet been approved by = Adrian.

Thanks.

JP= .


<= /html>= --Apple-Mail-10-66371307-- From jvasseur@cisco.com Mon Aug 24 02:31: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 092893A6D68 for ; Mon, 24 Aug 2009 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.579 X-Spam-Level: X-Spam-Status: No, score=-9.579 tagged_above=-999 required=5 tests=[AWL=1.019, 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 lflHSCSXvhXT for ; Mon, 24 Aug 2009 02:31: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 635853A6DF3 for ; Mon, 24 Aug 2009 02:31:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEAAGb7kUqQ/uCKe2dsb2JhbACCJy+YMQEBFiQGoRGIN44aBYQa X-IronPort-AV: E=Sophos;i="4.44,264,1249257600"; d="scan'208,217";a="47736118" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2009 09:31: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 n7O9Vpow014831 for ; Mon, 24 Aug 2009 11:31:51 +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 n7O9VpQ7016353 for ; Mon, 24 Aug 2009 09:31:51 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:31:50 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:31:50 +0200 Message-Id: <2EF81894-6F6A-42D7-95A3-C8D41C26DF2E@cisco.com> From: JP Vasseur To: ROLL WG In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-24-68686225 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 11:31:49 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Aug 2009 09:31:50.0875 (UTC) FILETIME=[B59A8AB0:01CA249D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5167; t=1251106311; x=1251970311; 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:=20ROLL=20WG=20Interim=20Meeting=20-=20September=2 030=20-=20Geneva |Sender:=20; bh=DzTpLkALSCh2cD1I1xC/EsjRxKNfWIdYhpYa5A1q4kk=; b=ec5jF0jBnuSi6yeXMDL1aKsl263DTMMh8Is2cFCfbc3k8WV5q/nsHWMSD9 UwhhwAgZnQjzsc+a8X1KEQvjM6i0EKx0dZm62/pvdA/9lSsH/lqvdEPY2t39 q5GN3nQjOO; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] ROLL WG Interim Meeting - September 30 - Geneva X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2009 09:31:48 -0000 --Apple-Mail-24-68686225 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Two quick but important updates. 1) Duration: we will of course have more than 3 hours - Proposal is to start at 11:00am (for people traveling that day to arrive on time) and finish by 4-5pm. 2) The Interim WG Meeting has been approved by our AD Adrian. Thanks. JP. On Aug 24, 2009, at 10:53 AM, JP Vasseur wrote: > Dear all, > > In order to keep moving at the same pace, which is of utmost > importance for this industry, > we are planning to have an interim ROLL Working Group meeting before > IETF-76. > > Since the previous Interim ROLL WG meeting took place in the US, we > choose Europe for the > location. > > Date and Venue > September 30 hosted by Cisco Systems in ROLLE, Switzerland (30mn > drive from Geneva Airport). > > Logistics details will of course be announced and discussed on the > ML in due time. > > Here is a very first draft of the agenda, comments are of course > very much welcome. As you can see > we have enough to fill 3 hours of discussions. > > 1) Agenda/admin (Chairs - 5mn) [5] > > 2) WG Status (Chairs - 10 mn) [15] > > 3) RPL: Routing Protocol for Low power and Lossy networks > draft-dt-roll-rpl-01 (TBD - 90mn) [115] > > 5) Metric ID - draft-ietf-roll-metric (TBD - 30mn) [145] > > 6) A Security Framework for Routing over Low Power and Lossy Networks > (Tzeta - 35mn) [180] > draft-tsao-roll-security-framework > > Let us know if you have any feed-back, thanks to send an email in > reply to let us know if you are planning > to attend (for logistic). > > Note also that the meeting has not yet been approved by Adrian. > > Thanks. > > JP. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-24-68686225 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Two quick but important = updates.

1) Duration: we will of course have more = than 3 hours - Proposal is to start at 11:00am (for people traveling = that day to arrive on time) and finish by 4-5pm.
2) The = Interim WG Meeting has been approved by our AD = Adrian.

Thanks.

JP.

On Aug 24, 2009, at 10:53 AM, JP Vasseur = wrote:

Dear = all,

In order to keep moving at the same pace, = which is of utmost importance for this industry, 
we are = planning to have an interim ROLL Working Group meeting before = IETF-76.

Since the previous Interim ROLL WG = meeting took place in the US, we choose Europe for = the 
location.

Date and = Venue
September 30 hosted by Cisco Systems in = ROLLE, Switzerland (30mn drive from Geneva = Airport).

Logistics details = will of course be announced and discussed on the ML in due = time.

Here is a very first draft of the agenda, = comments are of course very much welcome. As you can see
we = have enough to fill 3 hours of = discussions.

1) Agenda/admin (Chairs - = 5mn) [5]
       =   
2) WG Status (Chairs - 10 mn) = [15]
       =   
3) RPL: Routing Protocol for Low power = and Lossy networks
draft-dt-roll-rpl-01 (TBD - 90mn) = [115]

5) Metric ID - = draft-ietf-roll-metric (TBD - 30mn) [145]
   =  
6) A Security Framework for Routing over Low = Power and Lossy Networks
(Tzeta - 35mn) = [180]
draft-tsao-roll-security-framework

Let us know if you have any feed-back, thanks to = send an email in reply to let us know if you are planning
to = attend (for logistic).

Note also that the = meeting has not yet been approved by = Adrian.

Thanks.

JP= .


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

= --Apple-Mail-24-68686225-- From jvasseur@cisco.com Tue Aug 25 02:35: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 C0C713A6AF0 for ; Tue, 25 Aug 2009 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.612 X-Spam-Level: X-Spam-Status: No, score=-9.612 tagged_above=-999 required=5 tests=[AWL=0.987, 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 t0p45-k8eFaD for ; Tue, 25 Aug 2009 02:35:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 65CB63A6ADF for ; Tue, 25 Aug 2009 02:35:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAAOxMk0qQ/uCLe2dsb2JhbACbBwEBFiQGohuIN49QBYQa X-IronPort-AV: E=Sophos;i="4.44,271,1249257600"; d="scan'208";a="47820422" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2009 09:35:45 +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 n7P9Zjj1005775 for ; Tue, 25 Aug 2009 11:35:45 +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 n7P9ZjLS020678 for ; Tue, 25 Aug 2009 09:35:45 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:35:45 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:35:45 +0200 Message-Id: <61CCDE2D-96A7-46D1-862E-0AE1CF0ED838@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 v936) Date: Tue, 25 Aug 2009 11:35:44 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Aug 2009 09:35:45.0118 (UTC) FILETIME=[6BA2EFE0:01CA2567] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16846.005 X-TM-AS-Result: No--6.405400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=288; t=1251192945; x=1252056945; 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:=20Minutes=20ROLL=20Meeting=20IETF=2075=20posted |Sender:=20; bh=OIPsOhSNRWkOGCaD5Xj4tfCvj63340DpAgLCPo5IUNo=; b=tszEvDBaHhd4W6WYv8D5RioMh3wwju9ym749pzgKydoJAcCWqrfgs/bnzc giIh3dyab/hg+ySOt5MfZwsSYia7Ef0PDYMJxF4oC3YfkvGp3SeczRO1BYS+ qf5QsFHIRO; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Minutes ROLL Meeting IETF 75 posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2009 09:35:41 -0000 Dear WG, The draft minutes of the ROLL WG Meeting IETF 75 have been posted: http://www.ietf.org/proceedings/75/minutes/roll.txt Let me know if you have any comment by September 1. Many Thanks to Thomas Clausen for the notes and Adrian for Jabber scribbing. Thanks. JP. From pal@cs.stanford.edu Tue Aug 25 10:25: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 BDCFD28C4F6 for ; Tue, 25 Aug 2009 10:25:03 -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 G4ag3yKJNuS4 for ; Tue, 25 Aug 2009 10:25:02 -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 516DC3A6F93 for ; Tue, 25 Aug 2009 10:24:30 -0700 (PDT) Received: from dnab4220f2.stanford.edu ([171.66.32.242]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Mfzke-0000bL-0d; Tue, 25 Aug 2009 10:24:08 -0700 Message-Id: <72CC957F-1773-4766-A0DC-D671EB46108D@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <7587187F-B296-4864-9A09-CB1FDCF996C9@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 10:02:15 -0700 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908071035.09589.rogge@fgan.de> <200908071242.09718.rogge@fgan.de> <7587187F-B296-4864-9A09-CB1FDCF996C9@cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: roll@ietf.org 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: Tue, 25 Aug 2009 17:25:04 -0000 On Aug 7, 2009, at 4:39 AM, JP Vasseur wrote: > > On Aug 7, 2009, at 12:42 PM, Henning Rogge wrote: > >> Am Fri August 7 2009 11:09:26 schrieb JP Vasseur: >>> not is you use an existing field or even a new short one with a >>> reasonably good >>> pseudo-random generator (there are many) (collisions probability >>> will >>> be extremely >>> low). >> I'm not sure I understand your idea... >> >> let's assume we have a chain of 10 nodes which forward traffic >> towards a >> target. Each of the nodes have to mark the package in a unique way >> without >> erasing other marks to be able to detect a routing loop. > > Just the first node sending the packet to the sibling does. > >> >> How do you plan to use a random number generator to compress the >> "mark" >> information down to a static field ? > > There is a plethora of algorithm to do this Even you have a perfect randomization function, this requires O(n) bits, where n is the length of the route. In contrast, if you use a gradient, it requires O(log(n)) bits, with no dependence on random number generators for compression. Furthermore, adding a tag requires keeping track of outstanding tags. If they are deterministic than you can have deterministic (repeated) failures; if they are randomized then you need to store state. The chance of collision in tag field is inversely proportional to its size. This seems like design that looks good on paper but is impractical. Or am I missing something? Phil From hrogge@googlemail.com Tue Aug 25 10:51: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 87E533A6BF2 for ; Tue, 25 Aug 2009 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kpzJknpA4-no for ; Tue, 25 Aug 2009 10:51:08 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 6D4D83A6F35 for ; Tue, 25 Aug 2009 10:51:08 -0700 (PDT) Received: by ewy3 with SMTP id 3so3953752ewy.42 for ; Tue, 25 Aug 2009 10:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=vXY3Mcls7+3R5f4z9sXxELUW9I36O2Hcw1iRq79msQU=; b=SJNIgkeObqG5PDhxXheH6RN4WrMjSAJ1W9CYVoLWUTHoLraLloV403EijnGtrtekrw QSzEZIcB1mxJaND43Mrsr/yqCD6bf0UKObvyrpcBKt+I/kafj5wT2pK8QjGnB5UPrsvw mU0s4VudWFBcPT4Hft8m9kYtGDzP5mxkGV7Zo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=apzzMjfEKWOzcSzohcaadcK5UwGWOUvf8nnoD1ZRTz/U0NfvputZc8d1U9qnwYENnM PQ5amBkSe61F/9gSSqFk4jZCZPVwjb/wZAkzmvO5SxurgUohG3Ou8OyndUe8tfaVRieJ 86fcegsvnrjb1uQsj6bD0r0NE1PPX5NVRpfF8= Received: by 10.210.68.8 with SMTP id q8mr6889147eba.39.1251222671490; Tue, 25 Aug 2009 10:51:11 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm1700517eyg.40.2009.08.25.10.51.10 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Aug 2009 10:51:10 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Tue, 25 Aug 2009 19:51:04 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-gentoo-r5; KDE/4.3.0; x86_64; ; ) References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <7587187F-B296-4864-9A09-CB1FDCF996C9@cisco.com> <72CC957F-1773-4766-A0DC-D671EB46108D@cs.stanford.edu> In-Reply-To: <72CC957F-1773-4766-A0DC-D671EB46108D@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2460941.J9gZ7USpdb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908251951.09480.hrogge@googlemail.com> 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: Tue, 25 Aug 2009 17:51:09 -0000 --nextPart2460941.J9gZ7USpdb Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 25 August 2009 19:02:15 schrieb Philip Levis: > Even you have a perfect randomization function, this requires O(n) > bits, where n is the length of the route. In contrast, if you use a > gradient, it requires O(log(n)) bits, with no dependence on random > number generators for compression. > > Furthermore, adding a tag requires keeping track of outstanding tags. > If they are deterministic than you can have deterministic (repeated) > failures; if they are randomized then you need to store state. The > chance of collision in tag field is inversely proportional to its size. > > This seems like design that looks good on paper but is impractical. Or > am I missing something? Just adding a cyclic sequence number at the sender (or the gateway into the= =20 ROLL network) will do the job of well. Source IP and sequence number will b= e a=20 unique pair unless the sequence number is not too short. Of course each node still have to track lot's of IP/seqno pairs. =2D-------- What would do you think about just using doing duplicate detection link bas= ed=20 instead of end2end based (at least for the RPL protocol). If each nodes add= =20 it's "depth" to the package on a link base, you can easily detect when a=20 package goes "upwards" on the receiver side. Maybe it would be even better = to=20 add your own depth and the depth of the next hop (as you know it), would ma= ke=20 it easier to detect errors in the acyclic graph. Henning Rogge --nextPart2460941.J9gZ7USpdb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqUJI0ACgkQcenvcwAcHWdFtwCgh2r745PSRWVPX+JFbUPIdbyx bs8An2nr5HZUnyhalzPHdBbibXad0hfL =Ihma -----END PGP SIGNATURE----- --nextPart2460941.J9gZ7USpdb-- From pal@cs.stanford.edu Tue Aug 25 11:01: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 55A9428C4D4 for ; Tue, 25 Aug 2009 11:01:58 -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 IM7OsuxKK08L for ; Tue, 25 Aug 2009 11:01:57 -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 8FD4328C46D for ; Tue, 25 Aug 2009 11:01:57 -0700 (PDT) Received: from dnab4220f2.stanford.edu ([171.66.32.242]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Mg0LL-0002Qu-26; Tue, 25 Aug 2009 11:02:03 -0700 Message-Id: <5F2C9FCA-AE60-4C76-9FFB-C09AC7AD650A@cs.stanford.edu> From: Philip Levis To: Henning Rogge In-Reply-To: <200908251951.09480.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 11:02:06 -0700 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <7587187F-B296-4864-9A09-CB1FDCF996C9@cisco.com> <72CC957F-1773-4766-A0DC-D671EB46108D@cs.stanford.edu> <200908251951.09480.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: roll@ietf.org 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: Tue, 25 Aug 2009 18:01:58 -0000 On Aug 25, 2009, at 10:51 AM, Henning Rogge wrote: > Am Dienstag 25 August 2009 19:02:15 schrieb Philip Levis: >> Even you have a perfect randomization function, this requires O(n) >> bits, where n is the length of the route. In contrast, if you use a >> gradient, it requires O(log(n)) bits, with no dependence on random >> number generators for compression. >> >> Furthermore, adding a tag requires keeping track of outstanding tags. >> If they are deterministic than you can have deterministic (repeated) >> failures; if they are randomized then you need to store state. The >> chance of collision in tag field is inversely proportional to its >> size. >> >> This seems like design that looks good on paper but is impractical. >> Or >> am I missing something? > Just adding a cyclic sequence number at the sender (or the gateway > into the > ROLL network) will do the job of well. Source IP and sequence number > will be a > unique pair unless the sequence number is not too short. > > Of course each node still have to track lot's of IP/seqno pairs. Right -- and this goes against the need for very limited state. If you assume very low utilization (queues are empty), then a node doesn't need to track lots of pairs. But if you have a burst of traffic it needs to maintain ~H*Q pairs, where H is number of hops in the loop and Q is the queue depth. > --------- > What would do you think about just using doing duplicate detection > link based > instead of end2end based (at least for the RPL protocol). If each > nodes add > it's "depth" to the package on a link base, you can easily detect > when a > package goes "upwards" on the receiver side. Maybe it would be even > better to > add your own depth and the depth of the next hop (as you know it), > would make > it easier to detect errors in the acyclic graph. I'm not sure I understand: are you describing something like CTP's datapath validation or a different mechanism? Phil From hrogge@googlemail.com Tue Aug 25 11: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 EAE173A6FCF for ; Tue, 25 Aug 2009 11:13: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 IenAGqlXW7mW for ; Tue, 25 Aug 2009 11:13:06 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 9AABA3A6FC4 for ; Tue, 25 Aug 2009 11:12:44 -0700 (PDT) Received: by ewy3 with SMTP id 3so3972760ewy.42 for ; Tue, 25 Aug 2009 11:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=xmXbA0asRQjIklhCKdCo4NUZ6D+6N2zw6z4PsXg39S0=; b=CLCoOf36u9oA+j3uX3WHsFl33opSfiV1ndXqI3BEe8iFNGpPjvkSdhGDyX8TO3LIXt 8RkzIDTtl535ZG1C3lrO+JtBHfnrwOc3s/07+b59TMxZ/So0bvAFuof4Nc4e4/K9As5v luWn9Ul44wwo9hMLvnHIt6RWjeA8qFZ9e79k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=kGLkn/SsQ01OCCA3jIG5rfimwT6ZBXDwwANs9/i7A7muwf+AKvHrxDBTzDg5djtKSy Avd9NE0QoEswNfNO6QcKDA7vUdmA0LlKxm+dQOr51nsfOD7iBo0JN1Z3nYi/ALSOgZf0 9JzxeyhjVOxzJK5BfF7jzLzwuVKZ8BrQzkaGs= Received: by 10.210.43.17 with SMTP id q17mr5214839ebq.0.1251223966488; Tue, 25 Aug 2009 11:12:46 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm1681901eye.46.2009.08.25.11.12.45 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Aug 2009 11:12:45 -0700 (PDT) From: Henning Rogge To: Philip Levis Date: Tue, 25 Aug 2009 20:12:40 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-gentoo-r5; KDE/4.3.0; x86_64; ; ) References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908251951.09480.hrogge@googlemail.com> <5F2C9FCA-AE60-4C76-9FFB-C09AC7AD650A@cs.stanford.edu> In-Reply-To: <5F2C9FCA-AE60-4C76-9FFB-C09AC7AD650A@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2074306.PoefPU5tq4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908252012.44822.hrogge@googlemail.com> Cc: roll@ietf.org 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: Tue, 25 Aug 2009 18:13:07 -0000 --nextPart2074306.PoefPU5tq4 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 25 August 2009 20:02:06 schrieb Philip Levis: > Right -- and this goes against the need for very limited state. If you > assume very low utilization (queues are empty), then a node doesn't > need to track lots of pairs. But if you have a burst of traffic it > needs to maintain ~H*Q pairs, where H is number of hops in the loop > and Q is the queue depth. And the queue depth must be corresponding to the maximum livetime of a=20 packet... not good for small routers. > I'm not sure I understand: are you describing something like CTP's > datapath validation or a different mechanism? Don't know (can you give me a link to CTPs datapath validation?). The idea is to have some integrated checking of the "increasing depth" whil= e=20 packets travel along the acyclic tree. Henning --nextPart2074306.PoefPU5tq4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqUKZwACgkQcenvcwAcHWfY9QCdHdgwChgTnYJF+mvoQ90A54PR 6NcAnjaiZgSDVh1jOddJFdtV8ZdaR3Tp =psPQ -----END PGP SIGNATURE----- --nextPart2074306.PoefPU5tq4-- From pal@cs.stanford.edu Tue Aug 25 11:18: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 3FE533A6FD3 for ; Tue, 25 Aug 2009 11:18:39 -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 me4nmz8CFlLV for ; Tue, 25 Aug 2009 11:18:38 -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 02E153A6F42 for ; Tue, 25 Aug 2009 11:18:18 -0700 (PDT) Received: from dnab4220f2.stanford.edu ([171.66.32.242]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Mg0bA-0006XP-39; Tue, 25 Aug 2009 11:18:24 -0700 Message-Id: <68500AC8-DC1D-4AD6-B34C-16C220C77021@cs.stanford.edu> From: Philip Levis To: Henning Rogge In-Reply-To: <200908252012.44822.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 11:18:23 -0700 References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908251951.09480.hrogge@googlemail.com> <5F2C9FCA-AE60-4C76-9FFB-C09AC7AD650A@cs.stanford.edu> <200908252012.44822.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: roll@ietf.org 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: Tue, 25 Aug 2009 18:18:39 -0000 On Aug 25, 2009, at 11:12 AM, Henning Rogge wrote: > Am Dienstag 25 August 2009 20:02:06 schrieb Philip Levis: >> Right -- and this goes against the need for very limited state. If >> you >> assume very low utilization (queues are empty), then a node doesn't >> need to track lots of pairs. But if you have a burst of traffic it >> needs to maintain ~H*Q pairs, where H is number of hops in the loop >> and Q is the queue depth. > And the queue depth must be corresponding to the maximum livetime of a > packet... not good for small routers. > >> I'm not sure I understand: are you describing something like CTP's >> datapath validation or a different mechanism? > Don't know (can you give me a link to CTPs datapath validation?). > > The idea is to have some integrated checking of the "increasing > depth" while > packets travel along the acyclic tree Section 3.1 of this paper: http://sing.stanford.edu/pubs/sing-09-01.pdf Section 3.2 describes how CTP responds when it detects a potential loop. Phil From hrogge@googlemail.com Tue Aug 25 11:25: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 AD0183A6A10 for ; Tue, 25 Aug 2009 11:25:44 -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 AkqKKtvFHlid for ; Tue, 25 Aug 2009 11:25:43 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 8DB013A68B3 for ; Tue, 25 Aug 2009 11:25:43 -0700 (PDT) Received: by ewy3 with SMTP id 3so3984156ewy.42 for ; Tue, 25 Aug 2009 11:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=8GTR6EgefBzBl9X+fn5TKrXGg5UBMZb06eTHeOVhFNg=; b=mRyWBSbL8a6bNeyuZqgqofhxF8L2SmhU2xsBfta0MBar6bENQsMkOPjlRZgxemrnww /X0BNV+op2RbemQu7UPiy6aU0VTkp+y5yqd59dxJhFqbhpX83d5+J5IfNamh+wfoj7jg 4R0A3RhnY3YwDO2EwkJQwtc0coHprAvCYoHFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=s4IL3xsz+YkkmK9ZaNA/Rm6BcNFlmD+r9LLUl0JnLezzrHAGGfVdZ9cPFCkY63eXrL Xr5Gd5eIiWJ1r8XRNFSbvSiwaTQsS6drjR2ppGK4bRffSJhvDjo4ilFUD4oDnfwwLQWs U9WMljOsikFuwhqeAQT3iRdn3YcI878O+vGp0= Received: by 10.210.16.11 with SMTP id 11mr7037808ebp.50.1251224744396; Tue, 25 Aug 2009 11:25:44 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm916508eyf.15.2009.08.25.11.25.43 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Aug 2009 11:25:43 -0700 (PDT) From: Henning Rogge To: Philip Levis Date: Tue, 25 Aug 2009 20:25:33 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-gentoo-r5; KDE/4.3.0; x86_64; ; ) References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu> <200908252012.44822.hrogge@googlemail.com> <68500AC8-DC1D-4AD6-B34C-16C220C77021@cs.stanford.edu> In-Reply-To: <68500AC8-DC1D-4AD6-B34C-16C220C77021@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2081190.DBAkYiCJSQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908252025.42546.hrogge@googlemail.com> Cc: roll@ietf.org 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: Tue, 25 Aug 2009 18:25:44 -0000 --nextPart2081190.DBAkYiCJSQ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Am Dienstag 25 August 2009 20:18:23 schrieb Philip Levis: > Section 3.1 of this paper: http://sing.stanford.edu/pubs/sing-09-01.pdf > > Section 3.2 describes how CTP responds when it detects a potential loop. Okay, that sounds like the same idea. Henning --nextPart2081190.DBAkYiCJSQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqULKYACgkQcenvcwAcHWeZSQCfb+G1JbJ+uo/SpwWxLFLQAFDC dIsAn36qdUudJhFqxmS+KwxYZ8gxynhe =1deS -----END PGP SIGNATURE----- --nextPart2081190.DBAkYiCJSQ-- From root@core3.amsl.com Tue Aug 25 15:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5FDB03A6AC5; Tue, 25 Aug 2009 15:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090825223001.5FDB03A6AC5@core3.amsl.com> Date: Tue, 25 Aug 2009 15:30:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] ROLL WG Interim Meeting, September 30, 2009, Geneva, Switzerland X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2009 22:30:01 -0000 The ROLL WG will have an interim meeting on September 30, 2009 in Geneva, Switzerland. Date and Venue September 30 hosted by Cisco Systems in ROLLE, Switzerland (30min drive from Geneva Airport). The proposed start time is 11:00 AM. Draft Agenda 1) Agenda/admin (Chairs - 5min) [5] 2) WG Status (Chairs - 10 min) [15] 3) RPL: Routing Protocol for Low power and Lossy networks draft-dt-roll-rpl-01 (TBD - 120min) [140] 5) Metric ID - draft-ietf-roll-metric (TBD - 60min) [240] 6) A Security Framework for Routing over Low Power and Lossy Networks (Tzeta - 60min) [300] draft-tsao-roll-security-framework Further logistical details will be announced on the ROLL mailing list. From pthubert@cisco.com Wed Aug 26 02:04: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 937F83A685D for ; Wed, 26 Aug 2009 02:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.871 X-Spam-Level: X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.728, 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 xPm3oHi9J2Mq for ; Wed, 26 Aug 2009 02:04:09 -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 3B9CA3A6DB3 for ; Wed, 26 Aug 2009 02:04:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAAGqXlEqQ/uCKe2dsb2JhbACbEAEBFiQGo1mIOZBMBYQailE X-IronPort-AV: E=Sophos;i="4.44,278,1249257600"; d="scan'208";a="47913763" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2009 09:04:14 +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 n7Q94E1Q023247; Wed, 26 Aug 2009 11:04:14 +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 n7Q94ESv018356; Wed, 26 Aug 2009 09:04:14 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 11:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 11:04:01 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D167686@XMB-AMS-107.cisco.com> In-Reply-To: <200908252012.44822.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Loop detection between sibling Thread-Index: Acolr72DknWhLMe8S3KViOCdKxTPngAdho7A References: <344931971.5385111248692512011.JavaMail.root@mail02.pantherlink.uwm.edu><200908251951.09480.hrogge@googlemail.com><5F2C9FCA-AE60-4C76-9FFB-C09AC7AD650A@cs.stanford.edu> <200908252012.44822.hrogge@googlemail.com> From: "Pascal Thubert (pthubert)" To: "Henning Rogge" , "Philip Levis" X-OriginalArrivalTime: 26 Aug 2009 09:04:14.0535 (UTC) FILETIME=[2F2C9D70:01CA262C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4064; t=1251277454; x=1252141454; 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]=20Loop=20detection=20between=20s ibling |Sender:=20; bh=dbt+lP5PYCNqVuPvm0hjTEwUcdVSHjyscq2aM+rtxSk=; b=afqEM9CNMojB0uBjA8XXRmIMnI53jaDS4hxJJiafDbqoFAJy1pneKTFCQX n9/iXIg2q8BBtxkKR+MouUu17qSgv/6mhkYDYWlvLwclGFeoJOiMoBG79UqZ YtvpufmJmS; 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] 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: Wed, 26 Aug 2009 09:04:10 -0000 Hi Phil and Henning, We have 3 sorts of loops in RPL (that I know of ;) ) - DAG loops. A parent detaches and reattaches to a child that has missed = the whole sequence and kept advertising the original DAG all this time. = This happens when RA-DIOs are missed. The current draft avoids those = loops using the sequence number. Without the seq number, the protection = is limited (repeat DIOs during DAG hop timer), and temporary loops might = occur. CTP/iRPF will not work (unless I miss something) if the loop = involves at least 3 nodes. RPL eliminates the loop as soon as a DIO is = received from a parent that appears to be going down, as the child has = to detach from it immediately. The alternate of staying attached and = following the parent in its fall would have counted to infinity and = rapidly caused to detach too. - DAO loops, that's when the parent has a route installed by a DAO to a = child, but the child has cleaned up the state. This loop happens when a = no-DAO was missed till a heartbeat cleans up all states. The current = draft does not do a thing yet. RPF, CTP or split horizon apply well. = IOW, drop a packet from a parent that you could have routed back to. The = technique used for a packet from a sibling could apply too depending on = how we do it. - Sibling loops, and I thought this thread was specifically about those = ones. Clearly iRPF cannot apply there since the hops do not make any fwd = progress. Current draft limits those loops by split horizon -do not send = back to the same sibling) and parent preference (always prefer parents = vs. siblings). There are ideas floating around about: * aggressively dropping the TTL to limit the impact of the loops * randomizing the next hop to exit the loop if there's one * maintaining per packet states. * tunneling (a la CAPWAP) or source routing (path vector) Maintaining states might work in very specific cases with very low = traffic. It might be used as a hint if only some packets are sampled. = But being L3 also means being generic and that technique hardly works on = the general case so it can at best be an option. Another aspect is that the hosts themselves should not be aware of the = routing games. So I cannot see RPL asking hosts to sequence their = packets. Note that if there's a loop then a packet will exhaust TTL. There's = little point doing anything until then. When that happen, the node that = exhaust the TTL is within a loop for packets to that destination. = Poisoning self as a next hop for that destination to the router that = passed the packet should break the loop. This creates states per = destinations as opposed to per packet. We could also do more complex stuff like explore the path to that = destination with a record route message that might trigger updates = (trickle, DIOs, the whole 9 yards), and/or learn the path along the loop = (source route). But is that necessary? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Henning Rogge >Sent: mardi 25 ao=FBt 2009 20:13 >To: Philip Levis >Cc: roll@ietf.org >Subject: Re: [Roll] Loop detection between sibling > >Am Dienstag 25 August 2009 20:02:06 schrieb Philip Levis: >> Right -- and this goes against the need for very limited state. If = you >> assume very low utilization (queues are empty), then a node doesn't >> need to track lots of pairs. But if you have a burst of traffic it >> needs to maintain ~H*Q pairs, where H is number of hops in the loop >> and Q is the queue depth. >And the queue depth must be corresponding to the maximum livetime of a = packet... not good for small routers. > >> I'm not sure I understand: are you describing something like CTP's >> datapath validation or a different mechanism? >Don't know (can you give me a link to CTPs datapath validation?). > >The idea is to have some integrated checking of the "increasing depth" = while packets travel along the acyclic >tree. > >Henning From pthubert@cisco.com Wed Aug 26 02:57: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 38EA03A688F for ; Wed, 26 Aug 2009 02:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.690, 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 NY0GfThAjt0a for ; Wed, 26 Aug 2009 02:57: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 8BBA53A6844 for ; Wed, 26 Aug 2009 02:57:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAACSjlEqQ/uCLe2dsb2JhbACbEAEBFiQGo2CIOZBFBYQa X-IronPort-AV: E=Sophos;i="4.44,278,1249257600"; d="scan'208";a="47919264" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2009 09:53:32 +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 n7Q9rWm1014473; Wed, 26 Aug 2009 11:53:32 +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 n7Q9rW7J003959; Wed, 26 Aug 2009 09:53:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 11:53:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 11:53:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D1676D4@XMB-AMS-107.cisco.com> In-Reply-To: <017801ca211b$c6085970$52190c50$@alexander@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL preferred vs. alternate parents Thread-Index: AcoWM3rhFV2cGJo8QaSDZVBcGMT6DgAQY4nwApvnk3AAAyvFwAFOvvIQ References: <8E09C72DBC577D489F13A71228C0B7BF4E4B9B@ftrdmel0.rd.francetelecom.fr> <8E09C72DBC577D489F13A71228C0B7BF4E4D0E@ftrdmel0.rd.francetelecom.fr> <6A2A459175DABE4BB11DE2026AA50A5D0D0B95@XMB-AMS-107.cisco.com> <017801ca211b$c6085970$52190c50$@alexander@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Roger K. Alexander" X-OriginalArrivalTime: 26 Aug 2009 09:53:32.0269 (UTC) FILETIME=[121F01D0:01CA2633] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12888; t=1251280412; x=1252144412; 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=20preferred=20vs.=20altern ate=20parents |Sender:=20; bh=LPXiIrT58XiINeMjayQw4fVxGwqc3HruOvJMS0JoMaI=; b=JFIyn+Fy045eyH4LKtgFyzYfGm4pX+i8Z0U65bwt9OucfLNObhya0eltWF qBjHAaK77PZv2wlN0qpBpUXwvAu4f/h2W/T4U4dSmyXc/YJGC9qdaHxpTuvr UJrlk2rPGW; 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 preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2009 09:57:19 -0000 >I am not clear on the example given in Section 3.4.2.1 and referenced = to >some degree in your response below regarding greedy parent selection. = The >cycle set up by nodes alternating with each other regarding who is the >parent should be avoided if nodes in a DAG are always clear about the = OCP >metrics establishing the parent-child relationship. Two nodes = exchanging >(receiving) routing information will determine their respective = depths/ranks >relative to the root of the DAG. The node with a higher depth/rank = (closer >to the root) should always be the parent. Even as links change, once >relative depth/rank determines the parent-child relationship, nodes can = be >greedy in parent selection provided that between any two nodes the >parent-child relationship is understood (which follows directly from = the >routing information and confirmed via subsequent Destination >Advertisements). The insertion of a new router curves the routing space and new values of = metrics get propagated. Other routers that are influenced by that change = have to reposition themselves in that new context. Doing so, they also = modify the curve of the routing space. If that curve can influence the = first router then we can be in a feedback loop and count to infinity.=20 An example of that is an OF that cares for bandwidth. 2 nodes A and B = that belong to different subDAGs might wish to attach to one another to = augment their available bandwidth by using the other one's DAG. Say A = has a smaller rank than B. B can attach to A immediately. Say now that B = wished (greedily) to use A. It could detach and reattach deeper than A. = And the loop starts. The easy way to break that loop is to create an event horizon, like = routers look towards the sink and whatever has a causality behind their = back, they do not see so there cannot be in a feedback loop. By ignoring = RAs from deeper, we limit the risk of a feedback loop in the OF. This is tricky, because if for instance traffic or bandwidth utilization = was used as a metric for an Objective Function, then the routing is = actually influenced by stuff happening behind the horizon, and we know = since early Arpanet that this is a feedback loop that leads to = instabilities. So I think we are saying the same thing. You can attach the many parents = as long as you respect some rules like parenting.=20 What I called greedy is not trying to have many parents, but being = unfair or dishonest about it. Same rank routing (sibling) aims at = fairness. It is expected that an OF honestly selects the parent that = provides the best attachment for its objective and does not attach = deeper than that in order to greedily get more while depriving the rest. > >In the example in Figure 2 with the root at node A, until link costs = change >the depth of nodes B or C relative to the node A, one or the other (B = or C) >will be the parent node. Depth/rank relative to the root establishes = which >node is the parent. A node cannot maintain another node in its parent = set >where that node, through Destination Advertisements, confirms itself as = a >child of the node. This would be consistent with the statement in = Section >3.3.1.5 "A general property of the depth value presented by the node is = that >it should be greater than that 'presented' by any of its DAG parents." = With >this explicit specification 'greed' would be permitted without leading = to >the cycle described in Section 3.4.2. The event horizon rule could be finer grained like ignore anything from = one's subDAG as opposed to deeper in rank.=20 It's just harder to figure out. Obviously, if all routers in the subDAG = sent DAO and we had info in there to correlate with the RA-DIOs they = also send, then we could ignore selectively those RA_DIOs. But we do not = necessarily have NA_DAOs for all and space for states. >That also gets to a second issue that I would like to raise regarding a = node >re-joining a DAG at a depth/rank lower (further from the root) than a >current preferred parent. As stated at the end of section 3.4.1, "In = the >case where a node looses connectivity to the DAG, it must first leave = the >DAG before it may then rejoin at a deeper point." It should not always = be >necessary for the node to leave the DAG and invoke the process of = freezing >the sub-DAG, etc. when the parent set becomes depleted. If the node can >establish a parent at a lower depth and that parent candidate is not on = its >sub-DAG, the node should be free to make that attachment when the = parent set >is depleted. Sure. But how do you know that. The whole process of detaching is about = marking those nodes that we cannot attach back to. As you say, they are = all in the subDAG, yet it's not the whole subDAG. >For loop avoidance the node re-joining at lower depth should be = restricted >to parents that are NOT on the node's sub-DAG (as determined by = exchanged >and maintained DAs). With such a specification, if the parent set = becomes Sadly that's not always there not always complete nor in sync. I'm not = sure that the group is ready to enforce DAOs at all times for that sole = purpose. >deleted the node can immediately re-join the DAG through a parent = candidate >that is at a lower depth outside its sub-DAG. While this leads to a >temporary period in which the connectivity of the sub-DAG is suboptimal Note that on top, the draft says to detach from a parent that is going = down to avoid count to infinity if the parent of there was wrong and the = attachment router was in fact in its subDAG. >(relative to prior advertised node depth), because it allows = connectivity to >be maintained it may still be potentially preferable to the overhead of >freezing the sub-DAG and the subsequently triggered re-associations. = The >temporary sub-optimality will be incrementally removed through the >subsequent routing update exchanges without creating the additional = network >overhead. Well, the idea is on the table.=20 Like I said, I do not think we force all the nodes to keep states for = all nodes in their subDAGs. >Thanks for your feedback. Pleasure; Pascal > >Roger K Alexander > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >> Pascal Thubert (pthubert) >> Sent: Wednesday, August 19, 2009 12:02 PM >> To: dominique.barthel@orange-ftgroup.com; Tim Winter >> Cc: roll@ietf.org >> Subject: Re: [Roll] RPL preferred vs. alternate parents >> >> Hi Dominique ad Anand: >> >> >Let me try to reformulate my question with an example. >> > >> >Node N springs into existence and discovers a few neighbors A, B, C >> and D >> >- node A advertises depth 1.25 >> >- node B depth 3.75 >> >- node C depth 4.50 >> >- node D depth 8.25 >> >Given the advertised depth, the link costs and other = characteristics, >> Node N determines through its objective >> >function that its preferred parent is node B and that it should take >> 5.25 (=3D B's depth 3.75 + link cost 1.50) >> >as its own depth. >> >Node N then fleshes up its DAG by adding alternate parents: >> >- node D is out of the question because it is lower in the DAG = (event >> horizon). >> >- node A can be considered for inclusion as an alternate parent >> >From the excerpts of the RPL draft quoted below, as well as from >> Pascal's email, I understand that C is not >> >eligible to become an alternate parent to N. >> >My question is: "Why?" >> >> The text has been reshuffled and that might explain why the rationale >> is unclear. Placing a limit that the depth of the best parent is the >> worst depth for any acceptable parent is not for loop avoidance, you >> could pick any parent set and be deeper than the worst of them and >> that'd be cool. >> >> The reason is to "honestly" place an event horizon on what can make = you >> move, in order to avoid the so called greedy behavior. In your = example, >> the event horizon includes only A and B so whatever happens to C is >> ignored. This avoids a greedy behavior of leaving the tree to = reattach >> behind C, which C could emulate later to attach behind self, and = we're >> in a greedy loop. >> >> > >> >The only tentative explanation I've read so far is in the RPL draft, >> Section 3.4.1 "This mechanism serves to >> >avoid loops in the case where an alternate parent is used- if no >> alternate parent is deeper than the preferred >> >parent then loops are avoided." which I don't view as an = explanation. >> If each node only forwards packet to >> >nodes with lesser depth (barring forwarding to siblings for this >> discussion) then loops will be avoided even >> >is C is included as an alternate parent of N. >> >Am I mistaken somewhere? >> > >> >[Of course, if we enforce depth to be integers and node N's depth to >> be exactly its preferred parent's depth + >> >1, then this whole discussion goes away. But it is my understanding >> that we are now dealing with increments >> >that are not exactly 1, and/or fractional depths, aren't we?] >> >> You're perfectly right. If we migrate to finer sub-increments, we can >> accept C as a parent as opposed to sibling. >> The rule should now say that we derive our own depth from the = preferred >> parent + link cost, and then an acceptable parent is anyone that's >> inwards from us, in your case A, B and C. >> >> Great point :) >> >> Pascal >> >> > >> >Regards, >> >Dominique >> > >> >Quotes : >> >- 3.3.1.5 "It is recommended that a node maintain its DAG Parent set >> such that its most preferred parent from >> >the OCP goals also has the greatest depth value in the DAG parent >> set." >> >- 3.4.1 "For a node N, and its most preferred parent M, .... all >> parents in the DAG parent set must be of a >> >depth less than or equal to DAGDepth(M)." >> >- 5.2.1 "All nodes in the DAG Parent set should be of a depth less >> than or equal to the most preferred DAG >> >parent." >> >- Pascal's email July 3rd 14:06 +0200 "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." http://www.ietf.org/mail- >> archive/web/roll/current/msg01463.html >> >________________________________ >> > >> >De : M. B. Anand [mailto:privateanand@gmail.com] >> >Envoy=E9 : jeudi 6 ao=FBt 2009 03:15 >> >=C0 : BARTHEL Dominique RD-TECH-GRE >> >Objet : Re: [Roll] RPL preferred vs. alternate parents >> > >> > >> >Hi Dominique, >> > >> > >> > >> > >> > >> > Further, the whole text of 3.4.1 ("more optimum", "same >> optimality", >> > "less optimum") leads one to think that higher in the DAG is >> better. >> > Something sounds wrong to me if node N's preferred parent should >> > precisely be the "worse" of its parents. >> > >> > >> >The alternates will themselves be at equal or less depth compared to >> the preferred, but they may not offer the >> >_node N_ a chance to become less deep because that depends also on = the >> node's optimization metric w.r.t the >> >alternates. If one of the candidate neighbors does offer this, by = all >> means the node can make that candidate >> >the preferred. This is the `moving inwards along the DAG' - section >> 3.3.1.6, 5th paragraph. Of course, the >> >node N will then need to update its set of parents. So the preferred >> parent will be the "best" according to >> >the node's optimization. >> > >> >The idea is to forward traffic or move inwards - less deep - in >> DAGDepth - then there will never be loops. >> >Forwarding sideways - same DAGDepth - is also allowed but that has >> some chance of loops. Going deeper will >> >create the chance of loops. >> > >> >BTW, in the draft "higher" in the DAG means closer to the root, >> inwards in the DAG. See for example, Section >> >3.3.1.6, Section 5.3, point #6, Section 5.3.3.1 etc. I think you = mean >> "lower" when you say " leads one to >> >think that higher in the DAG is better". >> > >> >Regards, >> >Anand. >> > >> > >> > >> > >> > >> > >> > Can anybody offer a substantiated explanation? >> > Thanks >> > >> > Dominique >> > _______________________________________________ >> > 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 Wed Aug 26 09:04: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 1344C3A6C40 for ; Wed, 26 Aug 2009 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.943 X-Spam-Level: X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=0.655, 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 hVL5OrLW5OTc for ; Wed, 26 Aug 2009 09: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 566053A709D for ; Wed, 26 Aug 2009 09:04:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAANT5lEqQ/uCKe2dsb2JhbACCKS2YOwEWJAakW4g5kDwFhBqBWA X-IronPort-AV: E=Sophos;i="4.44,280,1249257600"; d="scan'208,217";a="47955283" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2009 16:04:08 +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 n7QG48n8004953; Wed, 26 Aug 2009 18:04:08 +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 n7QG48v9019008; Wed, 26 Aug 2009 16:04:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:04:08 +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_01CA2666.D7D43E17" Date: Wed, 26 Aug 2009 18:03:57 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D1678C3@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Next items ... Thread-Index: AcobjnvHOof3+bwvQBqZUGu9XWiroAKv4bRw References: From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 26 Aug 2009 16:04:08.0686 (UTC) FILETIME=[D80EF8E0:01CA2666] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12105; t=1251302648; x=1252166648; 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]=20Next=20items=20... |Sender:=20; bh=vnVnEk820oFfyLQVoSzpFOzioFFjvz58PFysJUSLIOM=; b=QOpm8/GqKlWnO4G2/1lmHF17QGAL+B+9kqAOLMwu3be5IojcwxIOeSSkyl dWAbOUMI9S7P8+/hbTDuNIENdRCZXNlOQl+4dXXo03yNyKToEIb4wBAjmS4b URo7AWAYJn; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2009 16:04:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2666.D7D43E17 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut Nicolas, =20 Yes we need to beef up the description of multicast. =20 Basically you can see DAO as a transport for MLD registrations. I would = assume that a listener would use MLD over its link to its router. If the = router is using ROLL, it would carry that registration as a DAO to its = parent(s). Note that strictly speaking that should be only one parent = (the preferred one) so we have real mcast tree. Note that passing the = registration to multiple parents improves the reliability but is more = costly and a pruning process is required.=20 =20 At the same time, the router populates its MRIB/MFIB so that it keeps an = entry to forward a mcast packet to all its children router that passed a = DAO, as well as all the attached node that registered. =20 For unicast, It is expected that the sink of the RPL DAG terminates RPL = and inject RPL routes in the infrastructure using whatever protocol is = used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes = attached to the RPL routers ( that's needed iff the source can be in the = infrastructure). For such a source, the packet will be replicated has it = flows down the preferred tree along the states installed from the DAO.=20 =20 For a source inside the DAG, the packet is passed up the tree and to all = the registered children but the one that passed the packet. Then again, = if there is a listener in the infrastructure then the sink has to = propagate the packet in the infrastructure. =20 Makes sense? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = nicolas.riou@fr.schneider-electric.com Sent: mercredi 12 ao=FBt 2009 22:43 To: roll@ietf.org Cc: nicolas.riou@fr.schneider-electric.com Subject: Re: [Roll] Next items ... =20 Hi DT and rollers,=20 I'm arriving a bit late on the mailing list but I would like to say that = I fully support Jerry and Mukul regarding P2P support. Efficient P2P = support is essential for building application systems, especially for = time-sensitive applications (lighting control, fire...).=20 Beyond P2P, I would also like to get better understanding on multicast = support with RPL. Even though multicast should be avoided when possible = in a LLNs, it is still required for multiple building automation = applications (to control banks of lights simultaneously, to control = complex and time-sensitive automation scenes, to quickly trigger = emergency procedures and disseminate information to multiple devices...) = and to allow for future publish/subscribe architectures. In building = scenarios, multicast traffic will not necessarily be initiated from the = DAG root toward leaves but from any arbitrary node in the lowpan to a = group of arbitrary nodes. Except in section 3.3.3.1 "DAO can convey = multicast listeners", the draft provides little information on how = multicast traffic will be spread. Is it possible to get some more = details on multicast support in RPL? Is it conceivable to operate MLD = into lowpans (I assume no), else is there any plan to define a tailored = lightweight MLD protocol to avoid flooding the whole network and = irrigate only zones where multicast flow subscribers exist?=20 Thanks and Best regards,=20 Nicolas ------_=_NextPart_001_01CA2666.D7D43E17 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut Nicolas,

 

Yes we need to beef up the description of = multicast.

 

Basically you can see DAO as a transport for MLD = registrations. I would assume that a listener would use MLD over its link to its = router. If the router is using ROLL, it would carry that registration as a DAO to = its parent(s). Note that strictly speaking that should be only one parent = (the preferred one) so we have real mcast tree. Note that passing the = registration to multiple parents improves the reliability but is more costly and a = pruning process is required.

 

At the same time, the router populates its MRIB/MFIB so = that it keeps an entry to forward a mcast packet to all its children router that = passed a DAO, as well as all the attached node that = registered.

 

For unicast, It is expected that the sink of the RPL DAG terminates RPL and inject RPL routes in the infrastructure using = whatever protocol is used there. For mcast/IPv6 the sink can proxy MLDV2/3 for = all the nodes attached to the RPL routers ( that’s needed iff the source can be = in the infrastructure). For such a source, the packet will be replicated has it = flows down the preferred tree along the states installed from the DAO. =

 

For a source inside the DAG, the packet is passed up the = tree and to all the registered children but the one that passed the packet. = Then again, if there is a listener in the infrastructure then the sink has to propagate the packet in the infrastructure.

 

Makes sense?

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = nicolas.riou@fr.schneider-electric.com
Sent: mercredi 12 ao=FBt 2009 22:43
To: roll@ietf.org
Cc: nicolas.riou@fr.schneider-electric.com
Subject: Re: [Roll] Next items ...

 


Hi DT = and rollers,

I’m arriving a bit late on the mailing list but I would like to say that I = fully support Jerry and Mukul regarding P2P support. Efficient P2P support is = essential for building application systems, especially for time-sensitive = applications (lighting control, fire…).
Beyond = P2P, I would also like to get better understanding on multicast support with = RPL. Even though multicast should be avoided when possible in a LLNs, it is still required for multiple building automation applications (to control banks = of lights simultaneously, to control complex and time-sensitive automation = scenes, to quickly trigger emergency procedures and disseminate information to = multiple devices…) and to allow for future publish/subscribe architectures. = In building scenarios, multicast traffic will not necessarily be initiated = from the DAG root toward leaves but from any arbitrary node in the lowpan to = a group of arbitrary nodes. Except in section 3.3.3.1 “DAO can convey = multicast listeners”, the draft provides little information on how multicast traffic will be spread. Is it possible to get some more details on = multicast support in RPL? Is it conceivable to operate MLD into lowpans (I assume = no), else is there any plan to define a tailored lightweight MLD protocol to = avoid flooding the whole network and irrigate only zones where multicast flow subscribers exist?

Thanks = and Best regards,
Nicolas

------_=_NextPart_001_01CA2666.D7D43E17-- From weianni@huawei.com Thu Aug 27 02:13: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 5E8353A6D69 for ; Thu, 27 Aug 2009 02:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.817 X-Spam-Level: **** X-Spam-Status: No, score=4.817 tagged_above=-999 required=5 tests=[AWL=2.319, BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 pyU23xWOU+nI for ; Thu, 27 Aug 2009 02:13:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AE9173A6A22 for ; Thu, 27 Aug 2009 02:12:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP100FPB2X4WA@szxga04-in.huawei.com> for roll@ietf.org; Thu, 27 Aug 2009 17:12:41 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP100MUP2X3MK@szxga04-in.huawei.com> for roll@ietf.org; Thu, 27 Aug 2009 17:12:39 +0800 (CST) Received: from w00151475 ([10.111.16.57]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP1008SS2X3QJ@szxml06-in.huawei.com> for roll@ietf.org; Thu, 27 Aug 2009 17:12:39 +0800 (CST) Date: Thu, 27 Aug 2009 17:12:39 +0800 From: Anni Wei To: roll@ietf.org Message-id: <001c01ca26f6$86c777b0$39106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_Z8wKxBUH+Lg5tRxBaXcWCQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Roll] new draft:A routing method based on detection frames over LLNs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2009 09:13:34 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Z8wKxBUH+Lg5tRxBaXcWCQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear ROLL WG members, I have submitted a new draft about A routing method based on detection frames over LLNs. A URL for this Internet-Draft is:http://tools.ietf.org/html/draft-wei-roll-rmdf-00Comments and feedback are appreciated. With Best Regards Anni Wei Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China --Boundary_(ID_Z8wKxBUH+Lg5tRxBaXcWCQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM1NjIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNjN2VkY2M+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxG T05UIHNpemU9Mj48Rk9OVCBzaXplPTQ+RGVhciZuYnNwO1JPTEwgV0cgbWVtYmVycyw8L0ZPTlQ+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUz48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCmZh Y2U9y87M5SBzaXplPTQ+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCA8U1BBTiBj bGFzcz1oMT5BIHJvdXRpbmcgDQptZXRob2QgYmFzZWQgb24gZGV0ZWN0aW9uIGZyYW1lcyBvdmVy IExMTnM8L1NQQU4+LjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPjxQUkU+PFNQQU4gbGFuZz1F Ti1VUz48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZ OiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2Vybmlu ZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFu c2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1z by1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpI LUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIGZhY2U9y87M5T48Rk9OVCBzaXpl PTQ+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9TUEFOPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGxhbmc9RU4tVVM+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1m b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRh bmE7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBw dDsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5n dWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj48Rk9OVCBmYWNlPcvOzOU+PEZPTlQgc2l6ZT00PjxBIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaS1yb2xsLXJtZGYtMDAiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdlaS1yb2xsLXJtZGYtMDA8L0E+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9TUEFOPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGxhbmc9RU4tVVM+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlk aS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0Ei PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZl cmRhbmE7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAx LjBwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFu Z3VhZ2U6IEFSLVNBIj48L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsg bXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6 IEFSLVNBIj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFN SUxZOiBWZXJkYW5hOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2Vy bmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1i aWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgZmFjZT3LzszlIHNpemU9ND5Db21tZW50cyBhbmQg ZmVlZGJhY2sgYXJlIGFwcHJlY2lhdGVkLjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvU1BBTj48L1BS RT48UFJFPjxTUEFOIGxhbmc9RU4tVVM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMXB0OyBGT05ULUZBTUlMWTogVmVyZGFuYTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvO zOU7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCBz aXplPTQ+PC9GT05UPjwvU1BBTj48L1NQQU4+PC9TUEFOPjxGT05UIGZhY2U9y87M5T48L0ZPTlQ+ Jm5ic3A7PC9QUkU+PFBSRT48U1BBTiBsYW5nPUVOLVVTPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVO LVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T QSI+PEZPTlQgZmFjZT3LzszlIHNpemU9ND5XaXRoIEJlc3QgUmVnYXJkcyA8L0ZPTlQ+PC9QUkU+ PFBSRT48Rk9OVCBmYWNlPcvOzOUgc2l6ZT00PkFubmkgV2VpPEJSPiZuYnNwOyZuYnNwOyBIdWF3 ZWkgVGVjaG5vbG9naWVzPEJSPiZuYnNwOyZuYnNwOyBIdWF3ZWkgQnVpbGRpbmcsIFhpbnhpIFJv YWQgTm8uMzxCUj4mbmJzcDsmbmJzcDsgSGFpZGlhbiBEaXN0cmljdCwgQmVpamluZyZuYnNwOyAx MDAwODU8QlI+Jm5ic3A7Jm5ic3A7IFAuIFIuIENoaW5hPC9GT05UPjwvUFJFPjwvU1BBTj48L1NQ QU4+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_Z8wKxBUH+Lg5tRxBaXcWCQ)-- From roger.alexander@ekasystems.com Thu Aug 27 15:25: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 026DD28C5F7 for ; Thu, 27 Aug 2009 15:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_40=-0.185, 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 7jWItNZWBTwp for ; Thu, 27 Aug 2009 15:25:10 -0700 (PDT) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id 25EF928C59B for ; Thu, 27 Aug 2009 15:25:10 -0700 (PDT) Received: (qmail 24321 invoked from network); 27 Aug 2009 22:25:15 -0000 Received: from unknown (HELO NAVAJO) (roger.alexander@209.48.242.70 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 27 Aug 2009 22:25:14 -0000 X-Yahoo-SMTP: f4aLZiaswBDsxvV5XgIN2aI9HC.7M2EhZSsdK7e_g3WQxp2yUttBXT91Jw-- X-YMail-OSG: GHoaIuoVM1lEKAkyGEaoQudHKD0rVw6kz6KB0.Hztprd2XYSWznB45mGQ6N7WhvzDykmPOiWjBEZePY7wUwKg8IEd0LlbcZSUgmKkeaD62.2XUp6JNV6gmnLCYIr1mBfNUaA9aOf2xqDi3NOV5wCwEegBUvNQ0sDMtOoTgV_2ckqtyolBLLssjgO2iTWTQscTQwQXKWzxY0baevG0T8YWqT61gg7BYlWulKQekQYYQQvrz9WQJvJzK45Duas16CWJPWH22K6XLlRpvv9LXlyggKjvJPcL9TH1gM61veMr8Ccsp8- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: Date: Thu, 27 Aug 2009 18:27:06 -0400 Message-ID: <044b01ca2765$82559f30$8700dd90$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoWM3rhFV2cGJo8QaSDZVBcGMT6DgAQY4nwApvnk3AAAyvFwAFOvvIQADyBoDAAEcWT8A== Content-Language: en-us Subject: Re: [Roll] RPL preferred vs. alternate parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2009 22:25:12 -0000 Hi Pascal, Thanks again for the feedback.=20 Roger > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, August 26, 2009 5:53 AM > To: Roger K. Alexander > Cc: roll@ietf.org; dominique.barthel@orange-ftgroup.com; Tim Winter > Subject: RE: [Roll] RPL preferred vs. alternate parents >=20 > >I am not clear on the example given in Section 3.4.2.1 and referenced > to > >some degree in your response below regarding greedy parent selection. > The > >cycle set up by nodes alternating with each other regarding who is = the > >parent should be avoided if nodes in a DAG are always clear about the > OCP > >metrics establishing the parent-child relationship. Two nodes > exchanging > >(receiving) routing information will determine their respective > depths/ranks > >relative to the root of the DAG. The node with a higher depth/rank > (closer > >to the root) should always be the parent. Even as links change, once > >relative depth/rank determines the parent-child relationship, nodes > can be > >greedy in parent selection provided that between any two nodes the > >parent-child relationship is understood (which follows directly from > the > >routing information and confirmed via subsequent Destination > >Advertisements). >=20 >=20 > The insertion of a new router curves the routing space and new values > of metrics get propagated. Other routers that are influenced by that > change have to reposition themselves in that new context. Doing so, > they also modify the curve of the routing space. If that curve can > influence the first router then we can be in a feedback loop and count > to infinity. >=20 > An example of that is an OF that cares for bandwidth. 2 nodes A and B > that belong to different subDAGs might wish to attach to one another = to > augment their available bandwidth by using the other one's DAG. Say A > has a smaller rank than B. B can attach to A immediately. Say now that > B wished (greedily) to use A. It could detach and reattach deeper than > A. And the loop starts. >=20 > The easy way to break that loop is to create an event horizon, like > routers look towards the sink and whatever has a causality behind = their > back, they do not see so there cannot be in a feedback loop. By > ignoring RAs from deeper, we limit the risk of a feedback loop in the > OF. >=20 > This is tricky, because if for instance traffic or bandwidth > utilization was used as a metric for an Objective Function, then the > routing is actually influenced by stuff happening behind the horizon, > and we know since early Arpanet that this is a feedback loop that = leads > to instabilities. >=20 > So I think we are saying the same thing. You can attach the many > parents as long as you respect some rules like parenting. >=20 > What I called greedy is not trying to have many parents, but being > unfair or dishonest about it. Same rank routing (sibling) aims at > fairness. It is expected that an OF honestly selects the parent that > provides the best attachment for its objective and does not attach > deeper than that in order to greedily get more while depriving the > rest. >=20 If nodes are 'greedy' but observe rank in their associations then greed, = in terms of permitting multiple alternatives, is not a bad thing. >=20 > > > >In the example in Figure 2 with the root at node A, until link costs > change > >the depth of nodes B or C relative to the node A, one or the other (B > or C) > >will be the parent node. Depth/rank relative to the root establishes > which > >node is the parent. A node cannot maintain another node in its parent > set > >where that node, through Destination Advertisements, confirms itself > as a > >child of the node. This would be consistent with the statement in > Section > >3.3.1.5 "A general property of the depth value presented by the node > is that > >it should be greater than that 'presented' by any of its DAG = parents." > With > >this explicit specification 'greed' would be permitted without = leading > to > >the cycle described in Section 3.4.2. >=20 > The event horizon rule could be finer grained like ignore anything = from > one's subDAG as opposed to deeper in rank. > It's just harder to figure out. Obviously, if all routers in the = subDAG > sent DAO and we had info in there to correlate with the RA-DIOs they > also send, then we could ignore selectively those RA_DIOs. But we do > not necessarily have NA_DAOs for all and space for states. >=20 The establishment of routing state outward along the DAG is the basis on which nodes discover/maintain the routing members of its sub-DAG. >=20 > >That also gets to a second issue that I would like to raise regarding > a node > >re-joining a DAG at a depth/rank lower (further from the root) than a > >current preferred parent. As stated at the end of section 3.4.1, "In > the > >case where a node looses connectivity to the DAG, it must first leave > the > >DAG before it may then rejoin at a deeper point." It should not = always > be > >necessary for the node to leave the DAG and invoke the process of > freezing > >the sub-DAG, etc. when the parent set becomes depleted. If the node > can > >establish a parent at a lower depth and that parent candidate is not > on its > >sub-DAG, the node should be free to make that attachment when the > parent set > >is depleted. >=20 > Sure. But how do you know that. The whole process of detaching is = about > marking those nodes that we cannot attach back to. As you say, they = are > all in the subDAG, yet it's not the whole subDAG. >=20 >=20 I may not have been very clear. My references to a node's sub-DAG is to = the set of nodes of lower rank that have a path to the DAG root through the given node. Nodes that maintain state have as part of their routing = table (for outward routes) all nodes that are in their sub-DAG. Together with parents (that provide the default routes towards the DAG root), these = are the only route entries required to be maintained by a node for the particular DAG. Therefore for re-attaching to DAG these nodes should be = part of the restricted set. > >For loop avoidance the node re-joining at lower depth should be > restricted > >to parents that are NOT on the node's sub-DAG (as determined by > exchanged > >and maintained DAs). With such a specification, if the parent set > becomes >=20 > Sadly that's not always there not always complete nor in sync. I'm not > sure that the group is ready to enforce DAOs at all times for that = sole > purpose. >=20 > >deleted the node can immediately re-join the DAG through a parent > candidate > >that is at a lower depth outside its sub-DAG. While this leads to a > >temporary period in which the connectivity of the sub-DAG is > suboptimal >=20 > Note that on top, the draft says to detach from a parent that is going > down to avoid count to infinity if the parent of there was wrong and > the attachment router was in fact in its subDAG. >=20 > >(relative to prior advertised node depth), because it allows > connectivity to > >be maintained it may still be potentially preferable to the overhead > of > >freezing the sub-DAG and the subsequently triggered re-associations. > The > >temporary sub-optimality will be incrementally removed through the > >subsequent routing update exchanges without creating the additional > network > >overhead. >=20 > Well, the idea is on the table. > Like I said, I do not think we force all the nodes to keep states for > all nodes in their subDAGs. For nodes that keep state it will be necessary that sub-DAG information = be maintained for outward routing. Some further discussion may be in order. >=20 > >Thanks for your feedback. >=20 > Pleasure; >=20 > Pascal >=20 > > > >Roger K Alexander > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf > Of > >> Pascal Thubert (pthubert) > >> Sent: Wednesday, August 19, 2009 12:02 PM > >> To: dominique.barthel@orange-ftgroup.com; Tim Winter > >> Cc: roll@ietf.org > >> Subject: Re: [Roll] RPL preferred vs. alternate parents > >> > >> Hi Dominique ad Anand: > >> > >> >Let me try to reformulate my question with an example. > >> > > >> >Node N springs into existence and discovers a few neighbors A, B, = C > >> and D > >> >- node A advertises depth 1.25 > >> >- node B depth 3.75 > >> >- node C depth 4.50 > >> >- node D depth 8.25 > >> >Given the advertised depth, the link costs and other > characteristics, > >> Node N determines through its objective > >> >function that its preferred parent is node B and that it should > take > >> 5.25 (=3D B's depth 3.75 + link cost 1.50) > >> >as its own depth. > >> >Node N then fleshes up its DAG by adding alternate parents: > >> >- node D is out of the question because it is lower in the DAG > (event > >> horizon). > >> >- node A can be considered for inclusion as an alternate parent > >> >From the excerpts of the RPL draft quoted below, as well as from > >> Pascal's email, I understand that C is not > >> >eligible to become an alternate parent to N. > >> >My question is: "Why?" > >> > >> The text has been reshuffled and that might explain why the > rationale > >> is unclear. Placing a limit that the depth of the best parent is = the > >> worst depth for any acceptable parent is not for loop avoidance, = you > >> could pick any parent set and be deeper than the worst of them and > >> that'd be cool. > >> > >> The reason is to "honestly" place an event horizon on what can make > you > >> move, in order to avoid the so called greedy behavior. In your > example, > >> the event horizon includes only A and B so whatever happens to C is > >> ignored. This avoids a greedy behavior of leaving the tree to > reattach > >> behind C, which C could emulate later to attach behind self, and > we're > >> in a greedy loop. > >> > >> > > >> >The only tentative explanation I've read so far is in the RPL > draft, > >> Section 3.4.1 "This mechanism serves to > >> >avoid loops in the case where an alternate parent is used- if no > >> alternate parent is deeper than the preferred > >> >parent then loops are avoided." which I don't view as an > explanation. > >> If each node only forwards packet to > >> >nodes with lesser depth (barring forwarding to siblings for this > >> discussion) then loops will be avoided even > >> >is C is included as an alternate parent of N. > >> >Am I mistaken somewhere? > >> > > >> >[Of course, if we enforce depth to be integers and node N's depth > to > >> be exactly its preferred parent's depth + > >> >1, then this whole discussion goes away. But it is my = understanding > >> that we are now dealing with increments > >> >that are not exactly 1, and/or fractional depths, aren't we?] > >> > >> You're perfectly right. If we migrate to finer sub-increments, we > can > >> accept C as a parent as opposed to sibling. > >> The rule should now say that we derive our own depth from the > preferred > >> parent + link cost, and then an acceptable parent is anyone that's > >> inwards from us, in your case A, B and C. > >> > >> Great point :) > >> > >> Pascal > >> > >> > > >> >Regards, > >> >Dominique > >> > > >> >Quotes : > >> >- 3.3.1.5 "It is recommended that a node maintain its DAG Parent > set > >> such that its most preferred parent from > >> >the OCP goals also has the greatest depth value in the DAG parent > >> set." > >> >- 3.4.1 "For a node N, and its most preferred parent M, .... all > >> parents in the DAG parent set must be of a > >> >depth less than or equal to DAGDepth(M)." > >> >- 5.2.1 "All nodes in the DAG Parent set should be of a depth less > >> than or equal to the most preferred DAG > >> >parent." > >> >- Pascal's email July 3rd 14:06 +0200 "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." http://www.ietf.org/mail- > >> archive/web/roll/current/msg01463.html > >> >________________________________ > >> > > >> >De : M. B. Anand [mailto:privateanand@gmail.com] > >> >Envoy=E9 : jeudi 6 ao=FBt 2009 03:15 > >> >=C0 : BARTHEL Dominique RD-TECH-GRE > >> >Objet : Re: [Roll] RPL preferred vs. alternate parents > >> > > >> > > >> >Hi Dominique, > >> > > >> > > >> > > >> > > >> > > >> > Further, the whole text of 3.4.1 ("more optimum", "same > >> optimality", > >> > "less optimum") leads one to think that higher in the DAG is > >> better. > >> > Something sounds wrong to me if node N's preferred parent should > >> > precisely be the "worse" of its parents. > >> > > >> > > >> >The alternates will themselves be at equal or less depth compared > to > >> the preferred, but they may not offer the > >> >_node N_ a chance to become less deep because that depends also on > the > >> node's optimization metric w.r.t the > >> >alternates. If one of the candidate neighbors does offer this, by > all > >> means the node can make that candidate > >> >the preferred. This is the `moving inwards along the DAG' - = section > >> 3.3.1.6, 5th paragraph. Of course, the > >> >node N will then need to update its set of parents. So the > preferred > >> parent will be the "best" according to > >> >the node's optimization. > >> > > >> >The idea is to forward traffic or move inwards - less deep - in > >> DAGDepth - then there will never be loops. > >> >Forwarding sideways - same DAGDepth - is also allowed but that has > >> some chance of loops. Going deeper will > >> >create the chance of loops. > >> > > >> >BTW, in the draft "higher" in the DAG means closer to the root, > >> inwards in the DAG. See for example, Section > >> >3.3.1.6, Section 5.3, point #6, Section 5.3.3.1 etc. I think you > mean > >> "lower" when you say " leads one to > >> >think that higher in the DAG is better". > >> > > >> >Regards, > >> >Anand. > >> > > >> > > >> > > >> > > >> > > >> > > >> > Can anybody offer a substantiated explanation? > >> > Thanks > >> > > >> > Dominique > >> > _______________________________________________ > >> > 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 nicolas.riou@fr.schneider-electric.com Fri Aug 28 03:28: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 627FD3A69A7 for ; Fri, 28 Aug 2009 03:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=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 hEaCaepQ6xLR for ; Fri, 28 Aug 2009 03:28:20 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 79DB83A6921 for ; Fri, 28 Aug 2009 03:28:12 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2009082812281373-60990 ; Fri, 28 Aug 2009 12:28:13 +0200 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D1678C3@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Fri, 28 Aug 2009 12:22:36 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/08/2009 12:28:17, Serialize complete at 28/08/2009 12:28:17, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 08/28/2009 12:28:13 PM, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 08/28/2009 12:28:15 PM, Serialize complete at 08/28/2009 12:28:15 PM Content-Type: multipart/alternative; boundary="=_alternative 00398556C1257620_=" Cc: roll@ietf.org Subject: Re: [Roll] Next items ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Aug 2009 10:28:27 -0000 Message en plusieurs parties au format MIME --=_alternative 00398556C1257620_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hi Pascal, Thanks for your answer. It makes sense indeed. Best regards, Nicolas. "Pascal Thubert (pthubert)" =20 26/08/2009 18:03 A Nicolas Riou/FR/Schneider@Europe, cc Objet RE: [Roll] Next items ... Salut Nicolas, =20 Yes we need to beef up the description of multicast. =20 Basically you can see DAO as a transport for MLD registrations. I would=20 assume that a listener would use MLD over its link to its router. If the=20 router is using ROLL, it would carry that registration as a DAO to its=20 parent(s). Note that strictly speaking that should be only one parent (the = preferred one) so we have real mcast tree. Note that passing the=20 registration to multiple parents improves the reliability but is more=20 costly and a pruning process is required.=20 =20 At the same time, the router populates its MRIB/MFIB so that it keeps an=20 entry to forward a mcast packet to all its children router that passed a=20 DAO, as well as all the attached node that registered. =20 For unicast, It is expected that the sink of the RPL DAG terminates RPL=20 and inject RPL routes in the infrastructure using whatever protocol is=20 used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes=20 attached to the RPL routers ( that?s needed iff the source can be in the=20 infrastructure). For such a source, the packet will be replicated has it=20 flows down the preferred tree along the states installed from the DAO.=20 =20 For a source inside the DAG, the packet is passed up the tree and to all=20 the registered children but the one that passed the packet. Then again, if = there is a listener in the infrastructure then the sink has to propagate=20 the packet in the infrastructure. =20 Makes sense? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 nicolas.riou@fr.schneider-electric.com Sent: mercredi 12 ao=FBt 2009 22:43 To: roll@ietf.org Cc: nicolas.riou@fr.schneider-electric.com Subject: Re: [Roll] Next items ... =20 Hi DT and rollers,=20 I?m arriving a bit late on the mailing list but I would like to say that I = fully support Jerry and Mukul regarding P2P support. Efficient P2P support = is essential for building application systems, especially for=20 time-sensitive applications (lighting control, fire?).=20 Beyond P2P, I would also like to get better understanding on multicast=20 support with RPL. Even though multicast should be avoided when possible in = a LLNs, it is still required for multiple building automation applications = (to control banks of lights simultaneously, to control complex and=20 time-sensitive automation scenes, to quickly trigger emergency procedures=20 and disseminate information to multiple devices?) and to allow for future=20 publish/subscribe architectures. In building scenarios, multicast traffic=20 will not necessarily be initiated from the DAG root toward leaves but from = any arbitrary node in the lowpan to a group of arbitrary nodes. Except in=20 section 3.3.3.1 ?DAO can convey multicast listeners?, the draft provides=20 little information on how multicast traffic will be spread. Is it possible = to get some more details on multicast support in RPL? Is it conceivable to = operate MLD into lowpans (I assume no), else is there any plan to define a = tailored lightweight MLD protocol to avoid flooding the whole network and=20 irrigate only zones where multicast flow subscribers exist?=20 Thanks and Best regards,=20 Nicolas =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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F --=_alternative 00398556C1257620_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi Pascal,

Thanks for your answer. It makes sen= se indeed.

Best regards,
Nicolas.




"Pascal Thubert = (pthubert)" <pthubert@cisco.com>

26/08/2009 18:03

A
Nicolas Riou/FR/Schneider@Europe, &l= t;roll@ietf.org>
cc
Objet
RE: [Roll] Next items ...




Salut Nicolas,
 
Yes we need to beef up = the description of multicast.
 
Basically you can see D= AO as a transport for MLD registrations. I would assume that a listener would use MLD over its link to its router. If the router is using ROLL, it would carry that registration as a DAO to its parent(s). Note that strictly speak= ing that should be only one parent (the preferred one) so we have real mcast tree. Note that passing the registration to multiple parents improves the reliability but is more costly and a pruning process is required.
 
At the same time, the r= outer populates its MRIB/MFIB so that it keeps an entry to forward a mcast packet to all its children router that passed a DAO, as well as all the attached node that registered.
 
For unicast, It is expe= cted that the sink of the RPL DAG terminates RPL and inject RPL routes in the infrastructure using whatever protocol is used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes attached to the RPL routers ( that’s needed iff the source can be in the infrastructure). For such a source, the packet will be replicated has it flows down the preferred tree along the states installed from the DAO.
 
For a source inside the= DAG, the packet is passed up the tree and to all the registered children but the one that passed the packet. Then again, if there is a listener in the infrastructure then the sink has to propagate the packet in the infrastruct= ure.
 
Makes sense?
 
Pascal
From: roll-bounces@ietf.org [mail= to:roll-bounces@ietf.org] On Behalf Of nicolas.riou@fr.schneider-electric.com
Sent: mercredi 12 ao=FBt 2009 22:43
To: roll@ietf.org
Cc: nicolas.riou@fr.schneider-electric.com
Subject: Re: [Roll] Next items ...
 

Hi DT and rollers,

I’m arriving a bit late on the mailing list but I would like to say t= hat I fully support Jerry and Mukul regarding P2P support. Efficient P2P support is essential for building application systems, especially for time-sensitive applications (lighting control, fire…).
Beyond P2P, I would also like to get better understanding on multicast support with RPL. Even though multicast should be avoided when possible in a LLNs, it is still required for multiple building automation applicatio= ns (to control banks of lights simultaneously, to control complex and time-sen= sitive automation scenes, to quickly trigger emergency procedures and disseminate information to multiple devices…) and to allow for future publish/sub= scribe architectures. In building scenarios, multicast traffic will not necessarily be initiated from the DAG root toward leaves but from any arbitrary node in the lowpan to a group of arbitrary nodes. Except in section 3.3.3.1 “DAO can convey multicast listeners”, the draft provides little= information on how multicast traffic will be spread. Is it possible to get some more details on multicast support in RPL? Is it conceivable to operate MLD into lowpans (I assume no), else is there any plan to define a tailored lightwei= ght MLD protocol to avoid flooding the whole network and irrigate only zones where multicast flow subscribers exist?

Thanks and Best regards,
Nicolas


=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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
This email has been scanned by the MessageLabs Email Security System.
=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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

--=_alternative 00398556C1257620_=--