From jpv@cisco.com Mon May 2 10:43:39 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DE5E0722 for ; Mon, 2 May 2011 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyRhDA4-Luns for ; Mon, 2 May 2011 10:43:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF80CE06A3 for ; Mon, 2 May 2011 10:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4246; q=dns/txt; s=iport; t=1304358218; x=1305567818; h=from:subject:date:references:to:message-id:mime-version; bh=nAEi/suMbLqjSdvbsh/Lr3LLWWXeeyo7SjsuEvVV1Ys=; b=XU+kBVK9EgZZC5cOH+osQ2uGUfIPsXgi+AMVext7wBLgTzlF94Ptujaa EAd1xLVwORJQQIIeNSoq5E+Co3EXnjLD1eC2b4kwIsi53GlI3CS6QjFOp yci3f0Y/TbUC0ydnMrcFl4PPuwOJerMj9+uVt7aOFmmoIOJrIDkhXx44b o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIfsvk2rRDoG/2dsb2JhbACmHneIcZw9nBWGAASOeYQZCYoC X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208,217";a="306669076" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 02 May 2011 17:43:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p42HhcTT027793 for ; Mon, 2 May 2011 17:43:38 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 10:43:38 -0700 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 May 2011 10:43:37 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-25--366497618 Date: Mon, 2 May 2011 19:43:36 +0200 References: <20110425063018.GA3039@amsl.com> To: ROLL WG Message-Id: <64744D08-E905-4712-8177-B429A3C84EB7@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 02 May 2011 17:43:37.0611 (UTC) FILETIME=[777325B0:01CC08F0] Subject: [Roll] Fwd: Reminder - Contacting the IETF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 May 2011 17:43:39 -0000 --Apple-Mail-25--366497618 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "Glen Barney" > Date: April 25, 2011 8:30:18 AM GMT+02:00 > To: , > Subject: Reminder - Contacting the IETF >=20 > Dear IETF Community - >=20 > As a follow-up to the outage reminder sent earlier, please be advised = and > reminded that you can report technical and/or website problems to the = IETF > by sending email to the IETF Secretariat staff at: = ietf-action@ietf.org >=20 > Further information about ways to contact the secretariat and report = problems > can be seen at: http://www.ietf.org/secretariat/ >=20 > All community members should be aware of this contact information, in = the > event it is ever required. As always, if there are any questions, = please > let us know. >=20 > Glen > Glen Barney > IT Director > AMS (IETF Secretariat) >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --Apple-Mail-25--366497618 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: "Glen Barney" = <glen@amsl.com>
Date: April 25, 2011 = 8:30:18 AM GMT+02:00
Subject: Reminder - = Contacting the IETF

Dear IETF = Community -

As a follow-up to the outage reminder sent earlier, please be advised = and
reminded that you can report technical and/or website problems to the = IETF
by sending email to the IETF Secretariat staff at:  ietf-action@ietf.org

Further information about ways to contact the secretariat and report = problems
can be seen at:  http://www.ietf.org/secretariat/=

All community members should be aware of this contact information, in = the
event it is ever required.  As always, if there are any questions, = please
let us know.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/ietf-announce


= --Apple-Mail-25--366497618-- From vincent.brillault@imag.fr Tue May 3 04:45:24 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED6E06A6 for ; Tue, 3 May 2011 04:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz10i1EADxMs for ; Tue, 3 May 2011 04:45:23 -0700 (PDT) Received: from mx.lerya.net (lerya.net [213.251.186.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE57E06A4 for ; Tue, 3 May 2011 04:45:20 -0700 (PDT) Received: from fea.lerya.net (fea.lerya.net [10.9.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.lerya.net (Postfix) with ESMTPS id D54B160AB8 for ; Tue, 3 May 2011 13:45:14 +0200 (CEST) Received: by fea.lerya.net (Postfix, from userid 1042) id EA15E20038; Tue, 3 May 2011 13:45:15 +0200 (CEST) Date: Tue, 3 May 2011 13:45:15 +0200 From: Vincent Brillault To: roll@ietf.org Message-ID: <20110503114515.GJ32677@Fea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AjmyJqqohANyBN/e" Content-Disposition: inline X-Mailer: Mutt 1.5.x User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 11:45:24 -0000 --AjmyJqqohANyBN/e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear ROLL WG, I'm hoping that I did not miss an earlier discussion on the topic. Feel fre= e to point me to earlier posts if I did. The problem that this mail tackles is that of selectively repairing downwar= d routes Consider the following situation, in storing mode configuration : DODAGroot | | Node 1 | ____|____ | | Node 2 | | Node 3 | (/) | (/) Node 4 Suppose that the OF function create the following situation : - N4 uses N2 as its preferred parent - N4 knows about N3 but does not consider it as a "DAO parent" Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from N2... That looks perfectly fine, given the behavior of the trickle algorithm : Ma= ybe N2 doesn't emit anything because the situation is consistent... The cur= rent specification says that a "node is responsible to emit DAO messages in= order to provision the downward route". But in this situation, N4 doesn't = know that the downward route is broken. Suppose now that the DODAGroot wants to send a message to N4. As N2 is dead= , N1 sends a DAOnopath back to the root. At first sight, there are two solutions to obtain a new path to N4: - The root can increase its DTSN, hoping that its descendants do the same. = This is seems overkill as this may trigger all descendants to resend DAOs. = Moreover, if Node 4 effectively gets the DIO with a DTSN increase, this lat= ter does not come from its own DAO parent (it's dead), so N4 will ignore it. - Otherwise, the root can increase its DODAGVersion, which rebuilds the who= le DODAG. Node 4 hears the global repair from Node 3 and choose this parent= =2E This seems very much overkill.=20 So for now a broken downward route can only be repaired by global rebuild.= =20 In fact, there seems to be a lightweight solution to this problem: in the R= PL p2p specification, there is a "Route Discovery Option", which allows a n= ode to search for another Node. Unfortunately, usage of this option is restricted : "RPLInstanceID MUST be = a local value". Without this limitation, a DODAGroot could add such a "Rout= e Discovery Option" in the DIO it sends. The resulting DIO is inconsistent = with the previous one and will be broadcast within all the LLN. The benefits of using this option for this purpose are: - Use of the structure of the existing DODAG, without any calculations (not= a global repair); - Only the targeted DAO will get generated;=20 - Allow on-demand routing for particular LLN with small memory footprint Drawbacks may be: - response with a DAO to a Route Discovery Option (instead of a DRO); - the Metric Container of the Route DIscovery Option doesn't seem really us= efull in that case. Perhaps, the limitation of a single RDO per DIO should be lifted in this ca= se. Thank you in advance, Vincent Brillault --AjmyJqqohANyBN/e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk2/6ssACgkQZq4yYBXMAIBLOQEAjIWt3ODdbbQ4viG3OOX0llVN UzTJh/mW0U2XoEF1JBcBAIT7Gkhk223kGTsnTAQca4ny4ccVFfhbEfCjXf88tCNm =/ck5 -----END PGP SIGNATURE----- --AjmyJqqohANyBN/e-- From prvs=09766c809=mukul@uwm.edu Tue May 3 05:10:33 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9EE06A4 for ; Tue, 3 May 2011 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OMrFI8-wIqO for ; Tue, 3 May 2011 05:10:29 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D0E07F4 for ; Tue, 3 May 2011 05:10:29 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip2mta.uwm.edu with ESMTP; 03 May 2011 07:10:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1204E12E3B0; Tue, 3 May 2011 07:10:29 -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 M67BqQmi8UCk; Tue, 3 May 2011 07:10:28 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 989B912E3AE; Tue, 3 May 2011 07:10:28 -0500 (CDT) Date: Tue, 3 May 2011 07:10:28 -0500 (CDT) From: Mukul Goyal To: Vincent Brillault Message-ID: <833973891.168144.1304424628514.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <20110503114515.GJ32677@Fea> 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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 12:10:33 -0000 Vincent I think using the RDO in the manner you described would lead to as much overhead as incrementing the Version Number for the DAG. Incrementing the Version Number seems like the right solution for this case. The P2P mechanism is not designed to repair existing DAGs. Thanks Mukul ----- Original Message ----- From: "Vincent Brillault" To: roll@ietf.org Sent: Tuesday, May 3, 2011 6:45:15 AM Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes Dear ROLL WG, I'm hoping that I did not miss an earlier discussion on the topic. Feel free to point me to earlier posts if I did. The problem that this mail tackles is that of selectively repairing downward routes Consider the following situation, in storing mode configuration : DODAGroot | | Node 1 | ____|____ | | Node 2 | | Node 3 | (/) | (/) Node 4 Suppose that the OF function create the following situation : - N4 uses N2 as its preferred parent - N4 knows about N3 but does not consider it as a "DAO parent" Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from N2... That looks perfectly fine, given the behavior of the trickle algorithm : Maybe N2 doesn't emit anything because the situation is consistent... The current specification says that a "node is responsible to emit DAO messages in order to provision the downward route". But in this situation, N4 doesn't know that the downward route is broken. Suppose now that the DODAGroot wants to send a message to N4. As N2 is dead, N1 sends a DAOnopath back to the root. At first sight, there are two solutions to obtain a new path to N4: - The root can increase its DTSN, hoping that its descendants do the same. This is seems overkill as this may trigger all descendants to resend DAOs. Moreover, if Node 4 effectively gets the DIO with a DTSN increase, this latter does not come from its own DAO parent (it's dead), so N4 will ignore it. - Otherwise, the root can increase its DODAGVersion, which rebuilds the whole DODAG. Node 4 hears the global repair from Node 3 and choose this parent. This seems very much overkill. So for now a broken downward route can only be repaired by global rebuild. In fact, there seems to be a lightweight solution to this problem: in the RPL p2p specification, there is a "Route Discovery Option", which allows a node to search for another Node. Unfortunately, usage of this option is restricted : "RPLInstanceID MUST be a local value". Without this limitation, a DODAGroot could add such a "Route Discovery Option" in the DIO it sends. The resulting DIO is inconsistent with the previous one and will be broadcast within all the LLN. The benefits of using this option for this purpose are: - Use of the structure of the existing DODAG, without any calculations (not a global repair); - Only the targeted DAO will get generated; - Allow on-demand routing for particular LLN with small memory footprint Drawbacks may be: - response with a DAO to a Route Discovery Option (instead of a DRO); - the Metric Container of the Route DIscovery Option doesn't seem really usefull in that case. Perhaps, the limitation of a single RDO per DIO should be lifted in this case. Thank you in advance, Vincent Brillault _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue May 3 05:52:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8D9E0808 for ; Tue, 3 May 2011 05:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.982 X-Spam-Level: X-Spam-Status: No, score=-9.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbvxn9vBEcks for ; Tue, 3 May 2011 05:52:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB0FE0769 for ; Tue, 3 May 2011 05:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4942; q=dns/txt; s=iport; t=1304427149; x=1305636749; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QSe3ngQK3KlnSz9DO3XbQkhVUnCExKE2ovWRS4nIY90=; b=LibudLgnWRBQcCcVT5G9bBQ5Z7kB1TPellF1xEWIEdu9N1L04AlG0UHA xnRmjhJmcoW4TPdcnIFqOlQ2hhXYYAw6DEjQKtZ0dnjkQoa8INb2pBPI9 FtU0A68B40mZqU6TXvZTKbGwscoSirRMwJFviz0n57eqj0VC0nZb9hjeq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwAAFj5v02Q/khMgWdsb2JhbACYBo4FFAEBFiYlqQmcaYYCBJM7iVw1 X-IronPort-AV: E=Sophos;i="4.64,309,1301875200"; d="scan'208";a="86542997" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 May 2011 12:52:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p43CqSkd029164; Tue, 3 May 2011 12:52:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 14:52:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 14:52:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D047D25E9@XMB-AMS-107.cisco.com> In-Reply-To: <833973891.168144.1304424628514.JavaMail.root@mail05.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes Thread-Index: AcwJiyFynzZjXclxT+aXVinjziUEWAABUYTQ References: <20110503114515.GJ32677@Fea> <833973891.168144.1304424628514.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Vincent Brillault" X-OriginalArrivalTime: 03 May 2011 12:52:28.0394 (UTC) FILETIME=[F565ECA0:01CC0990] Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 12:52:31 -0000 Mukul: I had in mind that the DIO with a target option would be useful for such a repair. And I thought that this mechanism would come with P2P additions. Basically the idea is that when the root is missing a route to a destination then it issues a DIO with a target that points to that destination within the current version.=20 In this case, node 4 would see the DIO from node 3, and would trying DAO / ack to node 2. Failing, it would fall back to node 3. Do I miss something? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, May 03, 2011 2:10 PM > To: Vincent Brillault > Cc: roll@ietf.org > Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively > repairing downward routes >=20 > Vincent >=20 > I think using the RDO in the manner you described would lead to as much > overhead as incrementing the Version Number for the DAG. > Incrementing the Version Number seems like the right solution for this case. > The P2P mechanism is not designed to repair existing DAGs. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Vincent Brillault" > To: roll@ietf.org > Sent: Tuesday, May 3, 2011 6:45:15 AM > Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing > downward routes >=20 > Dear ROLL WG, >=20 > I'm hoping that I did not miss an earlier discussion on the topic. Feel free to > point me to earlier posts if I did. >=20 > The problem that this mail tackles is that of selectively repairing downward > routes >=20 > Consider the following situation, in storing mode configuration : >=20 > DODAGroot > | > | > Node 1 > | > ____|____ > | | > Node 2 | > | Node 3 > | (/) > | (/) > Node 4 >=20 > Suppose that the OF function create the following situation : > - N4 uses N2 as its preferred parent > - N4 knows about N3 but does not consider it as a "DAO parent" >=20 > Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. >=20 > Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from > N2... >=20 > That looks perfectly fine, given the behavior of the trickle algorithm : Maybe > N2 doesn't emit anything because the situation is consistent... The current > specification says that a "node is responsible to emit DAO messages in order > to provision the downward route". But in this situation, N4 doesn't know that > the downward route is broken. >=20 > Suppose now that the DODAGroot wants to send a message to N4. As N2 is > dead, N1 sends a DAOnopath back to the root. > At first sight, there are two solutions to obtain a new path to N4: >=20 > - The root can increase its DTSN, hoping that its descendants do the same. > This is seems overkill as this may trigger all descendants to resend DAOs. > Moreover, if Node 4 effectively gets the DIO with a DTSN increase, this latter > does not come from its own DAO parent (it's dead), so N4 will ignore it. >=20 > - Otherwise, the root can increase its DODAGVersion, which rebuilds the > whole DODAG. Node 4 hears the global repair from Node 3 and choose this > parent. This seems very much overkill. >=20 > So for now a broken downward route can only be repaired by global rebuild. >=20 > In fact, there seems to be a lightweight solution to this problem: in the RPL > p2p specification, there is a "Route Discovery Option", which allows a node to > search for another Node. >=20 > Unfortunately, usage of this option is restricted : "RPLInstanceID MUST be a > local value". Without this limitation, a DODAGroot could add such a "Route > Discovery Option" in the DIO it sends. The resulting DIO is inconsistent with > the previous one and will be broadcast within all the LLN. >=20 > The benefits of using this option for this purpose are: > - Use of the structure of the existing DODAG, without any calculations (not a > global repair); > - Only the targeted DAO will get generated; > - Allow on-demand routing for particular LLN with small memory footprint >=20 > Drawbacks may be: > - response with a DAO to a Route Discovery Option (instead of a DRO); > - the Metric Container of the Route DIscovery Option doesn't seem really > usefull in that case. >=20 > Perhaps, the limitation of a single RDO per DIO should be lifted in this case. >=20 > Thank you in advance, >=20 > Vincent Brillault >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=09766c809=mukul@uwm.edu Tue May 3 06:56:21 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8ADE081A for ; Tue, 3 May 2011 06:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HX3t3eChv8Y for ; Tue, 3 May 2011 06:56:20 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9EE0816 for ; Tue, 3 May 2011 06:56:20 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip1mta.uwm.edu with ESMTP; 03 May 2011 08:56:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 294691FD042; Tue, 3 May 2011 08:56:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQsjsk4fnpcq; Tue, 3 May 2011 08:56:19 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A3F261FD036; Tue, 3 May 2011 08:56:19 -0500 (CDT) Date: Tue, 3 May 2011 08:56:19 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <444252320.169324.1304430979567.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D047D25E9@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 13:56:22 -0000 Pascal Route Discovery option is not meant for the purpose you described. It is meant for discovery of new source/HbH routes. We will need a new option if you want to repair an existing DAG in the manner you specified. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Vincent Brillault" Cc: roll@ietf.org Sent: Tuesday, May 3, 2011 7:52:25 AM Subject: RE: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes Mukul: I had in mind that the DIO with a target option would be useful for such a repair. And I thought that this mechanism would come with P2P additions. Basically the idea is that when the root is missing a route to a destination then it issues a DIO with a target that points to that destination within the current version. In this case, node 4 would see the DIO from node 3, and would trying DAO / ack to node 2. Failing, it would fall back to node 3. Do I miss something? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, May 03, 2011 2:10 PM > To: Vincent Brillault > Cc: roll@ietf.org > Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively > repairing downward routes > > Vincent > > I think using the RDO in the manner you described would lead to as much > overhead as incrementing the Version Number for the DAG. > Incrementing the Version Number seems like the right solution for this case. > The P2P mechanism is not designed to repair existing DAGs. > > Thanks > Mukul > > ----- Original Message ----- > From: "Vincent Brillault" > To: roll@ietf.org > Sent: Tuesday, May 3, 2011 6:45:15 AM > Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing > downward routes > > Dear ROLL WG, > > I'm hoping that I did not miss an earlier discussion on the topic. Feel free to > point me to earlier posts if I did. > > The problem that this mail tackles is that of selectively repairing downward > routes > > Consider the following situation, in storing mode configuration : > > DODAGroot > | > | > Node 1 > | > ____|____ > | | > Node 2 | > | Node 3 > | (/) > | (/) > Node 4 > > Suppose that the OF function create the following situation : > - N4 uses N2 as its preferred parent > - N4 knows about N3 but does not consider it as a "DAO parent" > > Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. > > Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from > N2... > > That looks perfectly fine, given the behavior of the trickle algorithm : Maybe > N2 doesn't emit anything because the situation is consistent... The current > specification says that a "node is responsible to emit DAO messages in order > to provision the downward route". But in this situation, N4 doesn't know that > the downward route is broken. > > Suppose now that the DODAGroot wants to send a message to N4. As N2 is > dead, N1 sends a DAOnopath back to the root. > At first sight, there are two solutions to obtain a new path to N4: > > - The root can increase its DTSN, hoping that its descendants do the same. > This is seems overkill as this may trigger all descendants to resend DAOs. > Moreover, if Node 4 effectively gets the DIO with a DTSN increase, this latter > does not come from its own DAO parent (it's dead), so N4 will ignore it. > > - Otherwise, the root can increase its DODAGVersion, which rebuilds the > whole DODAG. Node 4 hears the global repair from Node 3 and choose this > parent. This seems very much overkill. > > So for now a broken downward route can only be repaired by global rebuild. > > In fact, there seems to be a lightweight solution to this problem: in the RPL > p2p specification, there is a "Route Discovery Option", which allows a node to > search for another Node. > > Unfortunately, usage of this option is restricted : "RPLInstanceID MUST be a > local value". Without this limitation, a DODAGroot could add such a "Route > Discovery Option" in the DIO it sends. The resulting DIO is inconsistent with > the previous one and will be broadcast within all the LLN. > > The benefits of using this option for this purpose are: > - Use of the structure of the existing DODAG, without any calculations (not a > global repair); > - Only the targeted DAO will get generated; > - Allow on-demand routing for particular LLN with small memory footprint > > Drawbacks may be: > - response with a DAO to a Route Discovery Option (instead of a DRO); > - the Metric Container of the Route DIscovery Option doesn't seem really > usefull in that case. > > Perhaps, the limitation of a single RDO per DIO should be lifted in this case. > > Thank you in advance, > > Vincent Brillault > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Tue May 3 07:07:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F086E080E for ; Tue, 3 May 2011 07:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEtNwrojaDYJ for ; Tue, 3 May 2011 07:07:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCC23E06A8 for ; Tue, 3 May 2011 07:07:25 -0700 (PDT) Received: by fxm15 with SMTP id 15so130228fxm.31 for ; Tue, 03 May 2011 07:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=AWaq0ExsF7ig+uQoOdyeHiQkzZ0S7JHZgTyFsIBVO14=; b=rbysOkZYIr2UQiOHmSiNHm4xbGoV2ArEWUnL4toIYM7WkZOQdGC8s2CzVYhvS99q2J hGvmqba9+YL3D+uLz4UOrbRKxuk946tQuIvzwVskhmAyU0PV/mWaSKkYQ4OrfSl88Yh3 2vvyvfeGs67iQidw+1c9TNlTIdXpbrU8hScF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=VugbsMephmyCtPa7nZA1B+umQ0ETbz5j9nSK6F/BMG88g9hHVZbiY8VXhziEvjB9Gh T/6NNHAMbBdy9LtQVCpGIM/GpHKFnFUIZxGmuXHT35mlJ3GbnddIRf2xVEjtzn3qPVI0 AB07a9U50tSrDZtcf3gt/t5KlhpVRM6LhEIzc= Received: by 10.223.145.78 with SMTP id c14mr654738fav.75.1304431639834; Tue, 03 May 2011 07:07:19 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.223.45.78 with HTTP; Tue, 3 May 2011 07:06:25 -0700 (PDT) In-Reply-To: <444252320.169324.1304430979567.JavaMail.root@mail05.pantherlink.uwm.edu> References: <6A2A459175DABE4BB11DE2026AA50A5D047D25E9@XMB-AMS-107.cisco.com> <444252320.169324.1304430979567.JavaMail.root@mail05.pantherlink.uwm.edu> From: Emmanuel Baccelli Date: Tue, 3 May 2011 16:06:25 +0200 X-Google-Sender-Auth: j0wu6_qD4yeFfi0fdoZeZv3iD5A Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=0023540103b686b23904a25fa8d9 Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 14:07:28 -0000 --0023540103b686b23904a25fa8d9 Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal, I agree with Mukul. We do not want to overload the P2P spec with too many options. On the other hand, maybe a side spec could provide what you propose? regards Emmanuel On Tue, May 3, 2011 at 3:56 PM, Mukul Goyal wrote: > Pascal > > Route Discovery option is not meant for the purpose you described. It is > meant for discovery of new source/HbH routes. We will need a new option if > you want to repair an existing DAG in the manner you specified. > > Thanks > Mukul > > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "Mukul Goyal" , "Vincent Brillault" < > vincent.brillault@imag.fr> > Cc: roll@ietf.org > Sent: Tuesday, May 3, 2011 7:52:25 AM > Subject: RE: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : > Selectively repairing downward routes > > Mukul: > > I had in mind that the DIO with a target option would be useful for such > a repair. And I thought that this mechanism would come with P2P > additions. > > Basically the idea is that when the root is missing a route to a > destination then it issues a DIO with a target that points to that > destination within the current version. > In this case, node 4 would see the DIO from node 3, and would trying > DAO / ack to node 2. Failing, it would fall back to node 3. > > Do I miss something? > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Mukul Goyal > > Sent: Tuesday, May 03, 2011 2:10 PM > > To: Vincent Brillault > > Cc: roll@ietf.org > > Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : > Selectively > > repairing downward routes > > > > Vincent > > > > I think using the RDO in the manner you described would lead to as > much > > overhead as incrementing the Version Number for the DAG. > > Incrementing the Version Number seems like the right solution for this > case. > > The P2P mechanism is not designed to repair existing DAGs. > > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "Vincent Brillault" > > To: roll@ietf.org > > Sent: Tuesday, May 3, 2011 6:45:15 AM > > Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : > Selectively repairing > > downward routes > > > > Dear ROLL WG, > > > > I'm hoping that I did not miss an earlier discussion on the topic. > Feel free to > > point me to earlier posts if I did. > > > > The problem that this mail tackles is that of selectively repairing > downward > > routes > > > > Consider the following situation, in storing mode configuration : > > > > DODAGroot > > | > > | > > Node 1 > > | > > ____|____ > > | | > > Node 2 | > > | Node 3 > > | (/) > > | (/) > > Node 4 > > > > Suppose that the OF function create the following situation : > > - N4 uses N2 as its preferred parent > > - N4 knows about N3 but does not consider it as a "DAO parent" > > > > Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. > > > > Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from > > N2... > > > > That looks perfectly fine, given the behavior of the trickle algorithm > : Maybe > > N2 doesn't emit anything because the situation is consistent... The > current > > specification says that a "node is responsible to emit DAO messages in > order > > to provision the downward route". But in this situation, N4 doesn't > know that > > the downward route is broken. > > > > Suppose now that the DODAGroot wants to send a message to N4. As N2 is > > dead, N1 sends a DAOnopath back to the root. > > At first sight, there are two solutions to obtain a new path to N4: > > > > - The root can increase its DTSN, hoping that its descendants do the > same. > > This is seems overkill as this may trigger all descendants to resend > DAOs. > > Moreover, if Node 4 effectively gets the DIO with a DTSN increase, > this latter > > does not come from its own DAO parent (it's dead), so N4 will ignore > it. > > > > - Otherwise, the root can increase its DODAGVersion, which rebuilds > the > > whole DODAG. Node 4 hears the global repair from Node 3 and choose > this > > parent. This seems very much overkill. > > > > So for now a broken downward route can only be repaired by global > rebuild. > > > > In fact, there seems to be a lightweight solution to this problem: in > the RPL > > p2p specification, there is a "Route Discovery Option", which allows a > node to > > search for another Node. > > > > Unfortunately, usage of this option is restricted : "RPLInstanceID > MUST be a > > local value". Without this limitation, a DODAGroot could add such a > "Route > > Discovery Option" in the DIO it sends. The resulting DIO is > inconsistent with > > the previous one and will be broadcast within all the LLN. > > > > The benefits of using this option for this purpose are: > > - Use of the structure of the existing DODAG, without any calculations > (not a > > global repair); > > - Only the targeted DAO will get generated; > > - Allow on-demand routing for particular LLN with small memory > footprint > > > > Drawbacks may be: > > - response with a DAO to a Route Discovery Option (instead of a DRO); > > - the Metric Container of the Route DIscovery Option doesn't seem > really > > usefull in that case. > > > > Perhaps, the limitation of a single RDO per DIO should be lifted in > this case. > > > > Thank you in advance, > > > > Vincent Brillault > > > > _______________________________________________ > > 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 > --0023540103b686b23904a25fa8d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal,
I agree with Mukul. We do not want to overload the P2P spec = with too many options. On the other hand, maybe a side spec could provide w= hat you propose?
regards
Emmanuel

On Tue, May 3, 2011 at 3:56 PM, Mukul Goyal <mukul@uwm.edu> wrote:
Pascal

Route Discovery option is not meant for the purpose you described. It is me= ant for discovery of new source/HbH routes. We will need a new option if yo= u want to repair an existing DAG in the manner you specified.

Thanks
Mukul


----- Original Message -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Mukul Goyal" <mukul@uwm.= edu>, "Vincent Brillault" <vincent.brillault@imag.fr>
Cc: roll@ietf.org
Sent: Tuesday, May 3, 2011 7:52:25 AM
Subject: RE: [Roll] draft-ietf-roll= -rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes

Mukul:

I had in mind that the DIO with a target option would be useful for such a repair. And I thought that this mechanism would come with P2P
additions.

Basically the idea is that when the root is missing a route to a
destination then it issues a DIO with a target that points to that
destination within the current version.
In this case, node 4 would =A0see the DIO from node 3, and would trying
DAO / ack to node 2. Failing, it would fall back to node 3.

Do I miss something?

Pascal
http= ://www.xtranormal.com/watch/7011357/


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Mukul Goyal
> Sent: Tuesday, May 03, 2011 2:10 PM
> To: Vincent Brillault
> Cc: roll@ietf.org
> Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl :
Selectively
> repairing downward routes
>
> Vincent
>
> I think using the RDO in the manner you described would lead to as
much
> overhead as incrementing the Version Number for the DAG.
> Incrementing the Version Number seems like the right solution for this=
case.
> The P2P mechanism is not designed to repair existing DAGs.
>
> Thanks
> Mukul
>
> ----- Original Message -----
> From: "Vincent Brillault" <vincent.brillault@imag.fr>
> To: roll@ietf.org
> Sent: Tuesday, May 3, 2011 6:45:15 AM
> Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl :
Selectively repairing
> downward routes
>
> Dear ROLL WG,
>
> I'm hoping that I did not miss an earlier discussion on the topic.=
Feel free to
> point me to earlier posts if I did.
>
> The problem that this mail tackles is that of selectively repairing downward
> routes
>
> Consider the following situation, in storing mode configuration :
>
> =A0 =A0 =A0 DODAGroot
> =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 Node 1
> =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 ____|____
> =A0 =A0 =A0 | =A0 =A0 =A0 |
> =A0 =A0 Node 2 =A0 =A0|
> =A0 =A0 =A0 | =A0 =A0 Node 3
> =A0 =A0 =A0 | =A0 =A0 =A0(/)
> =A0 =A0 =A0 | =A0 =A0 (/)
> =A0 =A0 =A0 =A0Node 4
>
> Suppose that the OF function create the following situation :
> - N4 uses N2 as its preferred parent
> - N4 knows about N3 but does not consider it as a "DAO parent&quo= t;
>
> Whenever Node 2 increases its DTSN, N4 sends an unicast DAO.
>
> Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from<= br> > N2...
>
> That looks perfectly fine, given the behavior of the trickle algorithm=
: Maybe
> N2 doesn't emit anything because the situation is consistent... Th= e
current
> specification says that a "node is responsible to emit DAO messag= es in
order
> to provision the downward route". But in this situation, N4 doesn= 't
know that
> the downward route is broken.
>
> Suppose now that the DODAGroot wants to send a message to N4. As N2 is=
> dead, N1 sends a DAOnopath back to the root.
> At first sight, there are two solutions to obtain a new path to N4: >
> - The root can increase its DTSN, hoping that its descendants do the same.
> This is seems overkill as this may trigger all descendants to resend DAOs.
> Moreover, if Node 4 effectively gets the DIO with a DTSN increase,
this latter
> does not come from its own DAO parent (it's dead), so N4 will igno= re
it.
>
> - Otherwise, the root can increase its DODAGVersion, which rebuilds the
> whole DODAG. Node 4 hears the global repair from Node 3 and choose
this
> parent. This seems very much overkill.
>
> So for now a broken downward route can only be repaired by global
rebuild.
>
> In fact, there seems to be a lightweight solution to this problem: in<= br> the RPL
> p2p specification, there is a "Route Discovery Option", whic= h allows a
node to
> search for another Node.
>
> Unfortunately, usage of this option is restricted : "RPLInstanceI= D
MUST be a
> local value". Without this limitation, a DODAGroot could add such= a
"Route
> Discovery Option" in the DIO it sends. The resulting DIO is
inconsistent with
> the previous one and will be broadcast within all the LLN.
>
> The benefits of using this option for this purpose are:
> - Use of the structure of the existing DODAG, without any calculations=
(not a
> global repair);
> - Only the targeted DAO will get generated;
> - Allow on-demand routing for particular LLN with small memory
footprint
>
> Drawbacks may be:
> - response with a DAO to a Route Discovery Option (instead of a DRO);<= br> > - the Metric Container of the Route DIscovery Option doesn't seem<= br> really
> usefull in that case.
>
> Perhaps, the limitation of a single RDO per DIO should be lifted in this case.
>
> Thank you in advance,
>
> Vincent Brillault
>
> _______________________________________________
> 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
ht= tps://www.ietf.org/mailman/listinfo/roll

--0023540103b686b23904a25fa8d9-- From Daniel.Popa@itron.com Tue May 3 09:00:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D059EE0849 for ; Tue, 3 May 2011 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iTkwIjg4Wyl for ; Tue, 3 May 2011 09:00:29 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 2E597E0711 for ; Tue, 3 May 2011 09:00:19 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.110]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 3 May 2011 09:00:19 -0700 From: "Popa, Daniel" To: Vincent Brillault , "roll@ietf.org" Date: Tue, 3 May 2011 09:00:17 -0700 Thread-Topic: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes Thread-Index: AcwJh5uDcNGhUNzuQKuFd1w8eYR1AQAIeYtg Message-ID: <83027ECE5ECDC04E9BA5350B756A88E1598FAD3BBA@ITR-EXMBXVS-1.itron.com> References: <20110503114515.GJ32677@Fea> In-Reply-To: <20110503114515.GJ32677@Fea> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 16:00:29 -0000 Hi Vincent,=20 You bring up an interesting example. I think that we can have a third optio= n:=20 In LLNs, you should rely on the MAC layer also to provide a way to detect (= one-hop) neighborhood connectivity. By doing so, the Node 4 can detect that= the link to Node 2 is "dead" and decide to switch to the next available up= link, the link to Node 3; (by analogy, think at this as some handover mecha= nism, because you should take this action when link quality goes down). The= refore, Node 4 can decide to use Node 3 as parent - instead of Node 2 - and= send a DAO to the root, indicating the new downward path to reach it.=20 What do you think? All the best,=20 Daniel =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Vincent Brillault > Sent: Tuesday, May 03, 2011 1:45 PM > To: roll@ietf.org > Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : > Selectively repairing downward routes >=20 > Dear ROLL WG, >=20 > I'm hoping that I did not miss an earlier discussion on the topic. Feel > free to point me to earlier posts if I did. >=20 > The problem that this mail tackles is that of selectively repairing > downward routes >=20 > Consider the following situation, in storing mode configuration : >=20 > DODAGroot > | > | > Node 1 > | > ____|____ > | | > Node 2 | > | Node 3 > | (/) > | (/) > Node 4 >=20 > Suppose that the OF function create the following situation : > - N4 uses N2 as its preferred parent > - N4 knows about N3 but does not consider it as a "DAO parent" >=20 > Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. >=20 > Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from > N2... >=20 > That looks perfectly fine, given the behavior of the trickle algorithm > : Maybe N2 doesn't emit anything because the situation is consistent... > The current specification says that a "node is responsible to emit DAO > messages in order to provision the downward route". But in this > situation, N4 doesn't know that the downward route is broken. >=20 > Suppose now that the DODAGroot wants to send a message to N4. As N2 is > dead, N1 sends a DAOnopath back to the root. > At first sight, there are two solutions to obtain a new path to N4: >=20 > - The root can increase its DTSN, hoping that its descendants do the > same. This is seems overkill as this may trigger all descendants to > resend DAOs. Moreover, if Node 4 effectively gets the DIO with a DTSN > increase, this latter does not come from its own DAO parent (it's > dead), so N4 will ignore it. >=20 > - Otherwise, the root can increase its DODAGVersion, which rebuilds the > whole DODAG. Node 4 hears the global repair from Node 3 and choose this > parent. This seems very much overkill. >=20 > So for now a broken downward route can only be repaired by global > rebuild. >=20 > In fact, there seems to be a lightweight solution to this problem: in > the RPL p2p specification, there is a "Route Discovery Option", which > allows a node to search for another Node. >=20 > Unfortunately, usage of this option is restricted : "RPLInstanceID MUST > be a local value". Without this limitation, a DODAGroot could add such > a "Route Discovery Option" in the DIO it sends. The resulting DIO is > inconsistent with the previous one and will be broadcast within all the > LLN. >=20 > The benefits of using this option for this purpose are: > - Use of the structure of the existing DODAG, without any calculations > (not a global repair); > - Only the targeted DAO will get generated; > - Allow on-demand routing for particular LLN with small memory > footprint >=20 > Drawbacks may be: > - response with a DAO to a Route Discovery Option (instead of a DRO); > - the Metric Container of the Route DIscovery Option doesn't seem > really usefull in that case. >=20 > Perhaps, the limitation of a single RDO per DIO should be lifted in > this case. >=20 > Thank you in advance, >=20 > Vincent Brillault From gnawali@cs.stanford.edu Tue May 3 15:59:16 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E51E06B2 for ; Tue, 3 May 2011 15:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T70EmKyf+utt for ; Tue, 3 May 2011 15:59:15 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id B1167E06A5 for ; Tue, 3 May 2011 15:59:15 -0700 (PDT) Received: from mail-pw0-f44.google.com ([209.85.160.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QHOYl-0001gE-Df for roll@ietf.org; Tue, 03 May 2011 15:59:15 -0700 Received: by pwi5 with SMTP id 5so331393pwi.31 for ; Tue, 03 May 2011 15:59:15 -0700 (PDT) Received: by 10.68.66.40 with SMTP id c8mr521582pbt.493.1304463555036; Tue, 03 May 2011 15:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Tue, 3 May 2011 15:58:55 -0700 (PDT) In-Reply-To: <20110503225521.68E72E06B2@ietfa.amsl.com> References: <20110503225521.68E72E06B2@ietfa.amsl.com> From: Omprakash Gnawali Date: Tue, 3 May 2011 15:58:55 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 22:59:16 -0000 Here is the latest update. This version does not set MinHopRankIncrease. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, May 3, 2011 at 3:55 PM Subject: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-03 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-03.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-roll-minrank-hysteresis-of Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2011-05-03 WG ID: =A0 =A0 =A0 =A0 =A0 roll Number_of_pages: 10 Abstract: The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. The IETF Secretariat. From Internet-Drafts@ietf.org Tue May 3 16:00:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA9AE06B2; Tue, 3 May 2011 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdOWwpzKl3V8; Tue, 3 May 2011 16:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7915CE06A5; Tue, 3 May 2011 16:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 16:00:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-minrank-hysteresis-of-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 23:00:02 -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 : The Minimum Rank Objective Function with Hysteresis Author(s) : O. Gnawali, P. Levis Filename : draft-ietf-roll-minrank-hysteresis-of-03.txt Pages : 10 Date : 2011-05-03 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-03.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-minrank-hysteresis-of-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03155521.I-D@ietf.org> --NextPart-- From rmarchap@cisco.com Tue May 3 20:38:22 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0AE06AB for ; Tue, 3 May 2011 20:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl77-5UXWAy5 for ; Tue, 3 May 2011 20:38:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id CA766E0681 for ; Tue, 3 May 2011 20:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmarchap@cisco.com; l=6281; q=dns/txt; s=iport; t=1304480301; x=1305689901; h=mime-version:subject:date:message-id:from:to; bh=Si9VFL0MGtjkLZJk9bh9s5rtjaVyY1B6is1i0O+7n2A=; b=TrbMzGNNp+3xwyejX/U0AQq6kMh5qQ608ZnEniQ/gbIlxdIJaNgU56t7 FiMsu5GdxYWnHjBoZ2H1Uoibnu5XqBGUVbtbkuJx/rNJkYH2UpV7pfNum /MAELN+lKC+UrPph2HLp2JX0S0AUJEyJVQVbC4WLuVTiK5ZynQZL/VNXH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0HAHvJwE2rRDoI/2dsb2JhbACCYZVnjVZ3pRmBHZ4RhgIEhiWNFoov X-IronPort-AV: E=Sophos;i="4.64,312,1301875200"; d="scan'208,217";a="307850891" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 04 May 2011 03:38:21 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p443cLcU002701 for ; Wed, 4 May 2011 03:38:21 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 20:38:21 -0700 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_01CC0A0C.B6C1A939" Date: Tue, 3 May 2011 20:38:18 -0700 Message-ID: <7B822F730F822147977ED5B684ACE4900D4E6356@xmb-sjc-21b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAO Inconsistency Detection and Recovery section in RPL Draft 19 Thread-Index: AcwKDLUl68B/Ly/yTiicvDd36f066g== From: "Rajesh Marchappanavar (rmarchap)" To: X-OriginalArrivalTime: 04 May 2011 03:38:21.0569 (UTC) FILETIME=[B728C710:01CC0A0C] Subject: [Roll] DAO Inconsistency Detection and Recovery section in RPL Draft 19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 May 2011 03:38:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0A0C.B6C1A939 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 In section "11.2.2.3. DAO Inconsistency Detection and Recovery" the following paragraph is very ambiguous. I can't figure out, who is neighbor, node, router. Looks like terms have been used interchangeably. Could this be rewritten please. =20 Upon receiving a packet with a Forwarding-Error bit set, the node MUST remove the routing states that caused forwarding to that neighbor, clear the Forwarding-Error bit and attempt to send the packet again. The packet may be sent to an alternate neighbor, after the expiration of a user-configurable implementation specific timer. If that alternate neighbor still has an inconsistent DAO state via this node, the process will recurse, this node will set the Forwarding-Error 'F' bit and the routing state in the alternate neighbor will be cleaned up as well. =20 Cheers, Rajesh =20 ------_=_NextPart_001_01CC0A0C.B6C1A939 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

In section “11.2.2.3.  DAO Inconsistency Detection and = Recovery” the following paragraph is

very ambiguous. I can’t figure out, who is neighbor, node, router. = Looks like terms have

been used interchangeably. Could this be rewritten = please.

 

   Upon receiving a packet with a Forwarding-Error bit set, the = node

   MUST remove the routing states that caused forwarding to = that

   neighbor, clear the Forwarding-Error bit and attempt to send = the

   packet again.  The packet may be sent to an alternate neighbor, = after

   the expiration of a user-configurable implementation specific = timer.

   If that alternate neighbor still has an inconsistent DAO state = via

   this node, the process will recurse, this node will set = the

   Forwarding-Error 'F' bit and the routing state in the = alternate

   neighbor will be cleaned up as well.

 

Cheers,

Rajesh

 

------_=_NextPart_001_01CC0A0C.B6C1A939-- From rmarchap@cisco.com Tue May 3 20:49:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1129E06F7 for ; Tue, 3 May 2011 20:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVxDVCUPQbi0 for ; Tue, 3 May 2011 20:49:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id EAA98E06C8 for ; Tue, 3 May 2011 20:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmarchap@cisco.com; l=5926; q=dns/txt; s=iport; t=1304480967; x=1305690567; h=mime-version:subject:date:message-id:from:to; bh=+0TZx4oLidEY8P71lPY0yFvcFKT0O+1RA5ctp69owRw=; b=ip+0Iuks2wv6Vgs2WS2mu5seiEx2xWYV0kVNzEoWg187vTHq+1T7U0VZ F5yYSJRkBWrECHHJYjpGUnFKBJhvoQw9x/HJCbzJG3b9tQogYKnfdjlKM Yavddgss2XWQILpye0xtrJPB9/fkR0y/QWFJ5oUoxWAkhhK0A+Zypo0Z3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0HAELMwE2rRDoJ/2dsb2JhbACCYZVnjVZ3pSGBHZ4ShgIEhiWNFoov X-IronPort-AV: E=Sophos;i="4.64,312,1301875200"; d="scan'208,217";a="691505471" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 03:49:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p443nRNm020928 for ; Wed, 4 May 2011 03:49:27 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 20:49:27 -0700 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_01CC0A0E.43D5CE71" Date: Tue, 3 May 2011 20:49:25 -0700 Message-ID: <7B822F730F822147977ED5B684ACE4900D4E6359@xmb-sjc-21b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Section 11.2 Loop Avoidance and Detection of RPL draft 19 Thread-Index: AcwKDkMWWGatjvbiSoOiQ1dHV6EMOQ== From: "Rajesh Marchappanavar (rmarchap)" To: X-OriginalArrivalTime: 04 May 2011 03:49:27.0522 (UTC) FILETIME=[44192420:01CC0A0E] Subject: [Roll] Section 11.2 Loop Avoidance and Detection of RPL draft 19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 May 2011 03:49:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0A0E.43D5CE71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Below is an extract from draft 19 of RPL - =20 11.2.1. Source Node Operation =20 If the source is aware of the RPLInstanceID that is preferred for the packet, then it MUST set the RPLInstanceID field associated with the packet accordingly, otherwise it MUST set it to the RPL_DEFAULT_INSTANCE. =20 Where in the packet should the source set the RPLIndtanceID field? In RPL options in IPv6 hop-by-hop Header? If so, then a source outside the RPL domain should form a IPv6 hop-by-hop header with RPL option. =20 Draft-ietf-6man-rpl-option-03 says this in section 5 - =20 For datagrams entering the RPL domain, RPL Border Routers MUST drop received datagrams that contain a RPL Option in the IPv6 Extension headers. =20 A source outside RPL domain would set RPLInstanceID in RPL option in IPv6 extension header (hop-by-hop header) And the RPL border router would drop the packet. =20 What am I missing? =20 Cheers, Rajesh =20 ------_=_NextPart_001_01CC0A0E.43D5CE71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below is an extract from draft 19 of RPL = –

 

11.2.1.  Source Node Operation

 

   If the source is aware of the RPLInstanceID that is preferred for = the

   packet, then it MUST set the RPLInstanceID field associated with = the

   packet accordingly, otherwise it MUST set it to = the

   RPL_DEFAULT_INSTANCE.

 

Where in the packet should the source set the = RPLIndtanceID field? In RPL options in IPv6 hop-by-hop

Header? If so, then a source outside the RPL domain = should form a IPv6 hop-by-hop header with RPL option.

 

Draft-ietf-6man-rpl-option-03 says this in section = 5 –

 

   For datagrams entering the RPL domain, RPL Border =
Routers MUST drop
   received datagrams =
that contain a RPL Option in the IPv6 =
Extension
   headers.

 

A source outside RPL domain would set RPLInstanceID = in RPL option in IPv6 extension header (hop-by-hop header)

And the RPL border router would drop the = packet.

 

What am I missing?

 

Cheers,

Rajesh

 

------_=_NextPart_001_01CC0A0E.43D5CE71-- From c.chauvenet@watteco.com Wed May 4 00:46:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47DE0765 for ; Wed, 4 May 2011 00:46:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKgijnBeGt3b for ; Wed, 4 May 2011 00:46:13 -0700 (PDT) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 76C97E06D4 for ; Wed, 4 May 2011 00:46:12 -0700 (PDT) Received: from mail14-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Wed, 4 May 2011 07:46:12 +0000 Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2-R.bigfish.com (Postfix) with ESMTP id 4D6772F8A63; Wed, 4 May 2011 07:46:12 +0000 (UTC) X-SpamScore: -110 X-BigFish: VPS-110(zz9371O1454K542M1dbaL1418M1432Nc540K15caKJ14ffOzz1202hzz1033IL8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2 (MessageSwitch) id 1304495169590631_5672; Wed, 4 May 2011 07:46:09 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.244]) by mail14-tx2.bigfish.com (Postfix) with ESMTP id 821DD78804E; Wed, 4 May 2011 07:46:09 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 4 May 2011 07:46:08 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Wed, 4 May 2011 00:46:05 -0700 From: C Chauvenet To: "Popa, Daniel" , Vincent Brillault , "roll@ietf.org" Date: Wed, 4 May 2011 00:47:28 -0700 Thread-Topic: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes Thread-Index: AcwJh5uDcNGhUNzuQKuFd1w8eYR1AQAIeYtgACEX6LA= Message-ID: References: <20110503114515.GJ32677@Fea> <83027ECE5ECDC04E9BA5350B756A88E1598FAD3BBA@ITR-EXMBXVS-1.itron.com> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E1598FAD3BBA@ITR-EXMBXVS-1.itron.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 May 2011 07:46:14 -0000 Hi all,=20 I agree that vincent brings an interesting point. As Daniel pointed out, this is related to Neighbor Unreachability Detection= (NUD). Even if RPL doesn't specify a strict mechanism to maintain the connectivity= with (at least) a parent, a node should attach itself to an alternative p= arent if it detects that its best parent is no more reachable. So in your case, N4 should detect that N2 died and select N3 as its new bes= t parent and send a DAO to N3. N4 can detect N2 loss by periodic metric updating (for example, due to many= fails to reach N2, the ETX on the link from N4 to N2 will increase to a v= alue that will overstep a threshold to trigger a parent switching). Best, C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de P= opa, Daniel Envoy=E9=A0: mardi 3 mai 2011 18:00 =C0=A0: Vincent Brillault; roll@ietf.org Objet=A0: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selecti= vely repairing downward routes Hi Vincent,=20 You bring up an interesting example. I think that we can have a third optio= n:=20 In LLNs, you should rely on the MAC layer also to provide a way to detect (= one-hop) neighborhood connectivity. By doing so, the Node 4 can detect that= the link to Node 2 is "dead" and decide to switch to the next available up= link, the link to Node 3; (by analogy, think at this as some handover mecha= nism, because you should take this action when link quality goes down). The= refore, Node 4 can decide to use Node 3 as parent - instead of Node 2 - and= send a DAO to the root, indicating the new downward path to reach it.=20 What do you think? All the best, Daniel =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Vincent Brillault > Sent: Tuesday, May 03, 2011 1:45 PM > To: roll@ietf.org > Subject: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : > Selectively repairing downward routes >=20 > Dear ROLL WG, >=20 > I'm hoping that I did not miss an earlier discussion on the topic.=20 > Feel free to point me to earlier posts if I did. >=20 > The problem that this mail tackles is that of selectively repairing=20 > downward routes >=20 > Consider the following situation, in storing mode configuration : >=20 > DODAGroot > | > | > Node 1 > | > ____|____ > | | > Node 2 | > | Node 3 > | (/) > | (/) > Node 4 >=20 > Suppose that the OF function create the following situation : > - N4 uses N2 as its preferred parent > - N4 knows about N3 but does not consider it as a "DAO parent" >=20 > Whenever Node 2 increases its DTSN, N4 sends an unicast DAO. >=20 > Now if Node 2 suddently dies. Node 4 would not hear anymore DIOs from=20 > N2... >=20 > That looks perfectly fine, given the behavior of the trickle algorithm > : Maybe N2 doesn't emit anything because the situation is consistent... > The current specification says that a "node is responsible to emit DAO=20 > messages in order to provision the downward route". But in this=20 > situation, N4 doesn't know that the downward route is broken. >=20 > Suppose now that the DODAGroot wants to send a message to N4. As N2 is=20 > dead, N1 sends a DAOnopath back to the root. > At first sight, there are two solutions to obtain a new path to N4: >=20 > - The root can increase its DTSN, hoping that its descendants do the=20 > same. This is seems overkill as this may trigger all descendants to=20 > resend DAOs. Moreover, if Node 4 effectively gets the DIO with a DTSN=20 > increase, this latter does not come from its own DAO parent (it's=20 > dead), so N4 will ignore it. >=20 > - Otherwise, the root can increase its DODAGVersion, which rebuilds=20 > the whole DODAG. Node 4 hears the global repair from Node 3 and choose=20 > this parent. This seems very much overkill. >=20 > So for now a broken downward route can only be repaired by global=20 > rebuild. >=20 > In fact, there seems to be a lightweight solution to this problem: in=20 > the RPL p2p specification, there is a "Route Discovery Option", which=20 > allows a node to search for another Node. >=20 > Unfortunately, usage of this option is restricted : "RPLInstanceID=20 > MUST be a local value". Without this limitation, a DODAGroot could add=20 > such a "Route Discovery Option" in the DIO it sends. The resulting DIO=20 > is inconsistent with the previous one and will be broadcast within all=20 > the LLN. >=20 > The benefits of using this option for this purpose are: > - Use of the structure of the existing DODAG, without any calculations=20 > (not a global repair); > - Only the targeted DAO will get generated; > - Allow on-demand routing for particular LLN with small memory=20 > footprint >=20 > Drawbacks may be: > - response with a DAO to a Route Discovery Option (instead of a DRO); > - the Metric Container of the Route DIscovery Option doesn't seem=20 > really usefull in that case. >=20 > Perhaps, the limitation of a single RDO per DIO should be lifted in=20 > this case. >=20 > Thank you in advance, >=20 > Vincent Brillault _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Wed May 4 03:42:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAABE070D for ; Wed, 4 May 2011 03:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVxFElRrcV9i for ; Wed, 4 May 2011 03:42:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE4E0719 for ; Wed, 4 May 2011 03:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=9309; q=dns/txt; s=iport; t=1304505750; x=1305715350; h=from:subject:date:message-id:cc:to:mime-version; bh=dx8QWj8EEpFH9fxoZHuQ524nixRiH1Ch7tr1yjupccA=; b=QNQ9qNJkYOcKqIAgoYPGw88fpOhoOb1iLgUQPxAcVoMYE41eoMvO57Fu vMKcZuLcJ1vsHPeSK9+kHM/Gpzsh7VrvlkCYbIuu6Vp7h4OAhKDanaqlP IgenyDRJGSDdHdHpr7ZknZLSph4qRaFauDLVbCqe6xOdvBAPmCT7fBxO8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB4twU2rRDoG/2dsb2JhbACmF3eleZ4phgcEhi+JBoQcCYo1 X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208,217";a="441427642" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 04 May 2011 10:42:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p44AgRN5014127; Wed, 4 May 2011 10:42:27 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 May 2011 03:42:27 -0700 Received: from [10.2.49.136] ([10.21.118.209]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 May 2011 03:42:26 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-127--218967912 Date: Wed, 4 May 2011 03:42:26 -0700 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 04 May 2011 10:42:26.0719 (UTC) FILETIME=[F5A68AF0:01CC0A47] Subject: [Roll] Time to move on the applicability statement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 May 2011 10:42:31 -0000 --Apple-Mail-127--218967912 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, As discussed during our last IETF meeting in Prague, now that RPL has = been approved and is in the RFC Editor queue, it is time to move on the "applicability = statements",=20 according to our charter. Many of you expressed some interest on various = applicability=20 IDs such as Industrial automation, urban networks, home automation, = smart metering, ...=20 What we'd like to propose is to adopt a common "structure" for all IDs. What are we trying to achieve ? The IETF has produced a number of = applicability statements.=20 That being said, the objective may slightly differ according to the = context. RPL has been=20 designed to be flexible while meeting a number of requirements such as = code size, memory=20 requirements, ... As a result RPL is a flexible protocol offering = various options depending on=20 the use case requirements. A good example is the routing metric = documents, that specifies a=20 number of link/node metrics/constraints. Some deployments may require to = implement a very=20 small subset of those (even none of them) or a combination of metrics = and/or constraints.=20 This is also true for various RPL options and features. The aim of the applicability statement is to describe how RPL could be = used to satisfy the requirement of a specific application. This is not a deployment guide = ... Feel free to indicate which mode of operation could be used, along with the metric, ... even = mention which timers setting could be used if you think that this is appropriate: the = objective is not to provide a=20 detailed deployment guide, but rather simply explain which = options/features could be used for a specific use case. Remember to focus on RPL not the entire solution = scope including potentially 6lowpan, CoAP, ... Address management could be part of it though if = using PIO in DIO. One recommendation: be concise, no need to write a book ;-) Ideally ID = should not exceed 20=20 pages. Note that one may support different mode of operation for example, = according to the device capability and network size: for example, I know that some = implementations for smart metering will support the non-storing while others will elect to use the storing = mode. It is perfectly acceptable to document both along with the assumption of the network and the = devices capabilities. Table of Content 1. Introduction 2. Overview of the Deployment Scenario Mainly a very short summary of the deployment scenario and=20 reference to the Reqs RFC) 3. Using RPL to Meet the Functional Requirements Extract requirements from the Reqs RFC Might be a simple list with pointers into the Reqs RFC For each, list the RPL features that are used or explicitly not used to meet the requirements=20 4. RPL Profile 4.1 RPL Features Mode of operation: storing versus non-storing Use of P2P of the base specification or the P2P solution Number of DAG Repair Mode Metrics 4.2 RPL Options (if any) (for each RPL option you need to say: - should it be implemented [required, optional, not required] - should it be deployed [required, recommended, optional, not recommended, must not] - which requirement in section 3 it meets [if applicable] ) 4.3 Recommended Configuration Defaults and Ranges (For each configurable thing in the RPL spec - default value - recommended ranges for implementations) 4.4 Additional Configuration Recommendations (Anything that is not configurable in the RPL spec that should be configurable in this deployment) 5. Other Related Protocols (OPTIONAL) (what else do you need implemented, what assumptions can/should be made) 6. Manageability (if applicable) 7. Security (if applicable) Thanks. JP. ps: special thanks to Adrian for his input.= --Apple-Mail-127--218967912 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

As discussed during our last IETF meeting in = Prague, now that RPL has been approved
and is in the RFC = Editor queue, it is time to move on the "applicability = statements", 
according to our charter. Many of = you expressed some interest on various applicability 
IDs = such as Industrial automation, urban networks, home = automation, smart metering, ... 
What we'd like to = propose is to adopt a common "structure" for all = IDs.

What are we trying to achieve = ? The IETF has produced a number of = applicability statements. 
That being said, the = objective may slightly differ according to the context. RPL has = been 
designed to be flexible while meeting a number = of requirements such as code size, memory 
requirements, = ... As a result RPL is a flexible protocol offering various = options depending on 
the use case requirements. A = good example is the routing metric documents, that specifies = a 
number of link/node metrics/constraints. = Some deployments may require to implement a = very 
small subset of those (even none of = them) or a combination of metrics and/or = constraints. 
This is also true for various = RPL options and features.

The aim of the = applicability statement is to describe how RPL could be used to satisfy = the
requirement of a specific application. This is not a = deployment guide ... Feel free to indicate
which mode of = operation could be used, along with the metric, ... even mention which = timers
setting could be used if you think that this is = appropriate: the objective is not to = provide a 
detailed deployment guide, but rather = simply explain which options/features could be used for
a = specific use case. Remember to focus on RPL not the entire solution = scope including potentially
6lowpan, CoAP, ... Address = management could be part of it though if using PIO in = DIO.

One recommendation: be concise, no need to = write a book ;-) Ideally ID should not exceed = 20 
pages.

Note that one may = support different mode of operation for example, according to the = device
capability and network size: for example, I know that = some implementations for smart metering
will support the = non-storing while others will elect to use the storing mode. It is = perfectly acceptable
to document both along with the = assumption of the network and the devices = capabilities.

Table of = Content

1. Introduction
2. Overview = of the Deployment Scenario
Mainly a very short summary of the = deployment scenario and 
reference to the Reqs = RFC)
3. Using RPL to Meet the Functional = Requirements
Extract requirements from the Reqs = RFC
Might be a simple list with pointers into the Reqs = RFC
For each, list the RPL features that are used or = explicitly not
used to meet the = requirements 
4. RPL Profile
4.1 RPL = Features
Mode of operation: storing versus = non-storing
Use of P2P of the base specification or the P2P = solution
Number of DAG
Repair = Mode
Metrics
4.2 RPL Options (if any)
(for = each RPL option you need to say:
    - should = it be implemented [required, optional, not = required]
    - should it be deployed = [required, recommended, optional, not
     =   recommended, must not]
    - which = requirement in section 3 it meets [if applicable] )
4.3 = Recommended Configuration Defaults and Ranges
   = (For each configurable thing in the RPL spec
   =   - default value
     - recommended = ranges for implementations)
4.4 Additional Configuration = Recommendations
   (Anything that is not = configurable in the RPL spec that should be
   =   configurable in this deployment)
5. Other Related = Protocols (OPTIONAL)
   (what else do you need = implemented, what assumptions can/should
    be = made)
6. Manageability (if applicable)
7. Security = (if = applicable)

Thanks.

JP.<= /div>

ps: special thanks to Adrian for his = input.
= --Apple-Mail-127--218967912-- From vincent.brillault@imag.fr Thu May 5 02:06:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2C1E073C for ; Thu, 5 May 2011 02:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KirgGCGlrhzU for ; Thu, 5 May 2011 02:06:28 -0700 (PDT) Received: from mx.lerya.net (lerya.net [213.251.186.118]) by ietfa.amsl.com (Postfix) with ESMTP id B484DE06E6 for ; Thu, 5 May 2011 02:06:28 -0700 (PDT) Received: from fea.lerya.net (fea.lerya.net [10.9.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.lerya.net (Postfix) with ESMTPS id 5A8E860AB8; Thu, 5 May 2011 11:06:23 +0200 (CEST) Received: by fea.lerya.net (Postfix, from userid 1042) id 4153E20038; Thu, 5 May 2011 11:06:24 +0200 (CEST) Date: Thu, 5 May 2011 11:06:24 +0200 From: Vincent Brillault To: "roll@ietf.org" Message-ID: <20110505090624.GD11166@Fea> References: <20110503114515.GJ32677@Fea> <83027ECE5ECDC04E9BA5350B756A88E1598FAD3BBA@ITR-EXMBXVS-1.itron.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: X-Mailer: Mutt 1.5.x User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Roll] draft-ietf-roll-rpl, draft-ietf-roll-p2p-rpl : Selectively repairing downward routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 May 2011 09:06:29 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Daniel, Hi C=E9dric, As both of you pointed out, this example is related to NUD, if there is suc= h information (from ACKs or beacons) from the MAC layer, then the problem i= s much simpler. Still, it seems that RPL should be able to repair the downward routes by it= self, in the case the NUD done by the MAC layer is not efficient. Otherwise, let's consider another example. Let's call the Nodes M[1-9]* so that we won't mix up anything. Consider a simple network, stabilized : root -- M1 -- M2 -- M3 -- M4 -- M5 Suppose that M3 suddently reboots and loses all states. When it comes back = to life, M3 hears a DIO from M2 and re-attaches the DODAG, emmiting it's ow= n DIO. If we suppose the network was really stabilized, I think that the only info= rmation we have are : - M2 & M4 : some NS (DAD), but that's not RPL-related. - M2 : new DAO from M3, perhaps inconsistent (DAOSequence lower than the pr= evious one -- but we don't know it, as we dont have to store it). - M4 : perhaps an inconsistent DIO (DTSN lower than the previous one). On the current draft, I don't see anything that deals with this issue. I ma= y have missed something on how to handle a inconsistent DTSN (incrementing = its own DTSN should do the trick), but the main idea is : If one node on the dodag forgets one downward route, what should we do ? On this example, if the root sends a packet for M5, M3 will send back a DAO= nopath. As Mukul pointed out, the root should increase the Version Number. = Every node will change its version, but as it won't change its preferred pa= rent, there are no reason for sending a DAO and the downward route won't be= repaired. It's possible that there is a way to handle such downward route destruction= , and in that case the selective repair is useless. But perhaps there are o= ther issues that RPL doesn't handle. As a border effect such a selective re= pair will handle them. What do you think ? Sincerely, Vincent PS : In section 7.1, which deals with "Sequence Counter", I see no referenc= es to the DTSN. Shouldn't it appear here ? --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk3CaJAACgkQZq4yYBXMAIC1iAD/bzran6zlSIFa3XdwZIRwSpnT nz2sPsxEWlFcMxPw630BAKp+Do5ppVLEFSPosOKA5Fv2By/oac9ebJ09uDbYE7qB =SaXW -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From pthubert@cisco.com Thu May 5 09:07:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEF7E0728 for ; Thu, 5 May 2011 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.751 X-Spam-Level: X-Spam-Status: No, score=-10.751 tagged_above=-999 required=5 tests=[AWL=1.248, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS9Arp8CR3Mi for ; Thu, 5 May 2011 09:07:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42BE0694 for ; Thu, 5 May 2011 09:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=10753; q=dns/txt; s=iport; t=1304611667; x=1305821267; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hDId1A3m7zXnM0VxFVKj+dqEPa8a+1kgPfxt2pacltc=; b=bqpg2KG0MnQky1wR93vWco9T351eIeAiKjs/uyNH8/tmAr70Nm/4FWge ODIyR9ykbmveAo4feF9oDJ3cp/nU2m1rD0jLh/iv5nmbLSSwbSzYXEhAj T1hspCzwmYvj+5XkzQwxh7kfXensQ04NfS7xmn7MQF+akK7h4fjI2tqNV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAADbLwk2Q/khLgWdsb2JhbAAul2iOJxQBARYmJacinjCDC4J8BJN2iiU X-IronPort-AV: E=Sophos;i="4.64,320,1301875200"; d="scan'208";a="28845664" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 16:07:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p45G7R1M014275; Thu, 5 May 2011 16:07:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 18:07: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: Thu, 5 May 2011 18:07:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> In-Reply-To: <4DB04573.7060302@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: AcwANDza6czBzWWEQlar/ODK5vYh9ALChU7Q References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 05 May 2011 16:07:27.0869 (UTC) FILETIME=[87A7A2D0:01CC0B3E] Cc: roll@ietf.org Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 May 2011 16:07:49 -0000 Hi Phoebus: I made editorial changes to follow your late but welcome advice, and published a OF0-11. Please let me know if I covered your points as expected. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Phoebus Chen [mailto:phoebus@ieee.org] > Sent: Thursday, April 21, 2011 4:56 PM > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: OF0 draft v9: preferred metric, Stretch-of-Rank, configuring > parameters, and editorial comments >=20 > Pascal, >=20 > Thanks for your responses. I've replied inline below, preceded by > PC>. >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 > On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote: > > Hello Phoebus : ) > > > > Where have you been? We've been missing your excellent comments. > > > >> Sorry these comments are coming so late, after last call. I > > hope you > >> can at least incorporate some of them. > > > > [Pascal] That's beyond me. I suppose that the shepherd has to decide. > > Let's see: > > > > > >> > >> My comments below are based on my current understanding that > >> Phil and you are no longer using hop-count as the rank increment. > > Instead, > >> each node will have an implementation specific way of converting a > > node or > >> link cost to a rank. I'm still unclear if there is a preference rule > > to try to stick > >> with using the same metrics as the metrics advertised in a received > > DIO, if > >> the current node has access to multiple types of metrics (energy, LQI, > > ETX, > >> etc.). That would allow the root node to specify a preferred type of > > metric to > >> use in the instance. > >> > >> > >> Major Points: > >> ************* > >> 1) I'm still hoping that the format for writing Objective Function > > specifications > >> can be more uniform, as I mentioned in an earlier comment (point > > number 7 > >> in http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). > >> Comparing MRHOF and OF0, I think that the discussion on Step-of-Rank / > >> Stretch-of-Rank etc. can be moved to it's own subsection. > >> > >> I suggest the following reorganization of sections: > >> > >> 3. Objective Function 0 > >> 3.1. Computing Rank-increase > >> 3.2. Parent / Backup Successor Selection > >> 3.2.1. Selection of the Preferred Parent > >> 3.2.2. Selection of the backup feasible successor > >> 3.3. Advertising Rank-increase > >> 4. Interface with RPL core > >> > > [Pascal] Looks good. That much is doc organization and I suppose I can > > accommodate it at this stage. > > It would certainly be beneficial if both OF drafts have a common > > structure. > > > >> If you are allowing the root to specified a preferred metric type, > > then Section > >> 3.3. should state how to propagate this preference. I would have > > assumed > >> it's by propagating an empty DAG/Metric Container, but in (Section > > 2.1, draft- > >> ietf-roll-routing-metrics-19) it says "The object body carries one or > > more sub- > >> objects defined later in this document" > >> which means you cannot have empty containers. > > > > [Pascal] OF0 does not have metric containers at all, so they do not need > > to be empty. That's because OF0 is generic, for the better or the worse. > > Because we want all implementations to interop with OF0, regardless of > > the medium etc... > > > > So the idea is to have no constraint on what the implementation uses to > > derive the Rank, no container, no configuration option, just the base > > RPL spec. > > > > Rather, we normalize the resulting values so they can compare between > > implementations. >=20 > PC> OK. I thought allowing the root to specify a preferred metric would > PC> be nice, but I see that it's not necessary for basic operations. >=20 > > > > Now, I understand that a configuration container could help make the OF > > more self-contained/autonomic. > > > >> Maybe the overview in Section 3 should also state explicitly that the > >> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that > > order. > > > > [Pascal] Yes, and this is what we mean by > > " As it scans all the candidate neighbors, OF0 keeps the parent that > > is > > the best for the following criteria (in order):" > > the language may not be perfect but I hardly think the reader can be > > getting the text wrong. > > I'm open to an editorial change if the sense is conserved. > > >=20 > PC> I think the text you quoted above is very clear, but given its > PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or > PC> Section 3.2.1 of the suggested new order), it applies to > PC> parent selection. I'm saying there should be a sentence in the new > PC> Section 3 (overview) saying that we first compute > PC> Rank-Increase (Sec. 3.1), then select the preferred parent > PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then > PC> advertise Rank-Increase (Sec. 3.3). > PC> > PC> Maybe this is obvious, but I think it helps to state it explicitly. > PC> Especially since the guidelines given in > PC> (Section 14.1, draft-ietf-roll-rpl-19) are suggestions, > PC> rather than MUSTs: > PC> "Most Objective Functions are expected to follow..." > PC> And these suggestions don't say the steps must be followed in > PC> order either. >=20 > >> > >> > >> 2) There have been two variables and one parameter defined in the > >> overview section, but they are not mentioned in Section 7, OF0 > > Constants > >> and Variables. > >> Variables: Step-of-Rank, Stretch-of-Rank > >> Parameters: Rank-factor > >> (I noticed that there is no MINIMUM_RANK_STRETCH and > >> DEFAULT_RANK_STRETCH and presume this is intentional.) > >> > > [Pascal] You're right. A stretch of 0 is acceptable so there is no > > MINIMUM. > > If there was a DEFAULT I expect it should be zero as well. By > > compliance with the main spec. > > I'm fine adding it. What do you think? > > >=20 > PC> That would be nice for clarity. I think most implementors will > PC> use default values in a spec without a second thought unless they > PC> have a strong reason to do otherwise. >=20 > >> Also, it would be nice to use underscore instead of hyphen for > >> variables, like in MRHOF (and use capital letters for parameters). > >> > > [Pascal] OK. I did not really mean those as variables, but why not. > > > >> Finally, how is Stretch-of-Rank computed? Implementation dependent? > > > > [Pascal] It is not computed. It is configured and can be left to 0. Does > > not have to be there at all in an implementation. > > I can clarify that. > > >=20 > PC> OK. >=20 > >> 3) How does one configure the parameter(s) (Rank-Factor) from the > > root? > >> (I just realized that this same comment applies to the parameters in > >> MRHOF as well). Or is that not configurable from the root, but must > > be > >> configured before deployment of the nodes? > > > > [Pascal] The Rank factor has to be a per node policy, like the > > Stretch-of-Rank. Right now, we do not have config containers to > > distribute it. > > > > > >> > >> 4) I think it would be nice to adopt the format of > >> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of for > > the > >> Terminology section. That is, write the word, then the definition > > (this > >> is not done for "feasible successor" in this section). Some other > > words > >> to define in this section are "Rank-increase," "RPL core," and "higher > >> order interface." Unless the last one is common IPv6 terminology that > > I > >> am unaware of... I was unable to tell if that meant the higher order > >> bits of the interface are higher, or if the interface is somehow > > preferred. > > > > I think that the RPL terminology is the place for having those in > > common. >=20 > PC> Do you mean you or JP will add those terms and definitions to > PC> (draft-ietf-roll-terminology-05) or > PC> (Section 2, draft-ietf-roll-rpl-19)? I think the definition of > PC> "Rank-increase" belongs in OF0. >=20 > > > >> > >> 5) Just a reminder that the discussion on Rank-increase in the > >> introduction section > >> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can be > >> stored in one octet." > >> needs to be aligned with text in Section 3, > >> "Ri =3D Rf*Sp + Sr" > >> so that they are consistent. I see you are discussing this with > > Omprakash. > > > > Sp and Sr are expressed as units of 0x100 and Rf is integer, so they are > > consistent. Do I miss something? > > >=20 > PC> I see. I didn't realize that step_of_rank had to be a multiple of > PC> 0x100. You only mention at the bottom of page 3 that "The exact > PC> method for computing the Step-of-Rank is implementation-dependent" > PC> and give bounds MINIMUM_STEP_OF_RANK and > MAXIMUM_STEP_OF_RANK > PC> that are multiples of MinHopRankIncrease. > PC> > PC> On a related note, there's a recent discussion of using the ETX > PC> directly (identity) as the rank, which doesn't match this > PC> requirement that step_of_rank be a multiple of 0x100 in OF0. In > PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a > PC> multiple of 128, not 256 (0x100). > PC> > PC> Is it actually necessary to mention "rank-increase" in the > PC> introduction, before the terminology section? Can we remove > "The Rank > of a node is obtained by adding a normalized scalar Rank-increase to > the Rank of a selected preferred parent. OF0 uses a unit of Rank- > increase of 0x100 so that Rank value can be stored in one octet. > This allows up to at least 28 hops even when default settings are > used and each hop has the worst Rank-increase of 9." > PC> Or move it some point later? It may be a bit confusing to bring up > PC> so much detail at this point in the text. >=20 > >> > >> 6) I like the "Abstract Interface with RPL core" section, but would it > >> be better to separate them into "Input" and "Output"? That would end > > up > >> splitting up "Providing DAG information" and "Providing a Parent List" > >> into two pieces though. > >> > >> > >> More minor editorial comments to follow below, preceded by PC>. > > > > Thanks for those. I'll include them in a rev. > > > >> > >> -- > >> Phoebus Chen > >> Postdoctoral Researcher > >> Automatic Control Lab, KTH (Royal Institute of Technology) > >> http://www.ee.kth.se/~phoebus > >> > >> From Internet-Drafts@ietf.org Thu May 5 09:15:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA4E0694; Thu, 5 May 2011 09:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoZ-0AyZ2-m4; Thu, 5 May 2011 09:15:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70756E086B; Thu, 5 May 2011 09:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505161501.5347.33331.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 09:15:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 May 2011 16:15:27 -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 Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-11.txt Pages : 11 Date : 2011-05-05 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol that is adapted to such networks. RPL requires a specific Objective Function to establish a desired routing topology. This document specifies a basic Objective Function that relies only on RPL's basic Protocol Data Units; it does not use extensions such as RPL metric containers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-11.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-of0-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05090518.I-D@ietf.org> --NextPart-- From d.sturek@att.net Thu May 5 11:47:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C668CE07E5 for ; Thu, 5 May 2011 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyCb9MWpw8y1 for ; Thu, 5 May 2011 11:47:35 -0700 (PDT) Received: from nm15.access.bullet.mail.sp2.yahoo.com (nm15.access.bullet.mail.sp2.yahoo.com [98.139.44.142]) by ietfa.amsl.com (Postfix) with SMTP id 33947E07B3 for ; Thu, 5 May 2011 11:47:35 -0700 (PDT) Received: from [98.139.44.107] by nm15.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:47:32 -0000 Received: from [98.139.44.65] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:47:32 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:47:32 -0000 X-Yahoo-Newman-Id: 270780.62029.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 10230 invoked from network); 5 May 2011 18:47:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1304621251; bh=IZKMBziwIu15t0yRgeBj9KoBYq1RIR9WCQJBvmRTcvE=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=5WtRbS7bBUFyGyrwE+lXusqWe7esd6XTvomqbff6zcQKXvzbBQuAkN0EOEbkDsAc0kryXW44wOaeyaiyGHN+I+rgmnCMEvk5LIaj7sidJXvXtgt7UHcJN4FJ6EZEl+dW3sF1QzRwjBECo+EIEJsmtk/9qRthA1ccMe4U4bDPDZo= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp109.sbc.mail.bf1.yahoo.com with SMTP; 05 May 2011 11:47:30 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: KtjUsQwVM1ktFyNvCcH.Vtiz4Au_YCzXW7ry9AoW1JggByk ZGNdacBbbhtdTyNqwRuJWwN0S2w13.7OvbhgObAYK_hQQh7FQ61fzzxZw4Zr 0q64VzMwuF327fzWuVxiKX3.0e_ynkn02rAbtsaklMavvWd0r7.tyRrSX06x NgQJawoHGa3lRsdLi2A0EDHQyCbyo_SpVPE.Exa72eX630qLKVcvavdQE2QM 8r_butS2fpyX4EspgKX4DC5szT_9o0u31NKI4sdVl1c0.4Jnp17GFhd0o1ym MxU8xS4mX5qfMqbD4s7evUe_3pAalRbaSWFayrOU6secl3g-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: Date: Thu, 5 May 2011 11:47:27 -0700 Message-ID: <015c01cc0b54$e29b78e0$a7d26aa0$@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: AcwLVMUrFaevSOB3QSme1ev+gudWqAAAAj1A Content-Language: en-us Subject: [Roll] FW: New ZigBee Alliance Comment Submitted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:47:35 -0000 FYI. CCB is in for the ZigBee Help issue you sent me.... Don -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, May 05, 2011 11:47 AM To: Don Sturek; Phil Jamieson Subject: New ZigBee Alliance Comment Submitted Comment CC-1406 was successfully submitted by Don Sturek. You will be receive an email when this comment has been reviewed. Subject: Possible typo - Could be corrected in r19 Type: Editorial Description: I'm reading Zigbee Specification document 053474r17, and I found an error on page 399, at line 29. The value of nwkMaxChildren=8 is wrong and must be nwkMaxChildren=6, to be agree with the others attributes values on the example and to get the result shown on table 3.50 Suggested Remedy: Came in from ZigBee Help. Seem to remember this being fixed after r17 but we should check From d.sturek@att.net Thu May 5 11:54:55 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CEFE07D0 for ; Thu, 5 May 2011 11:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRNqBH9HfSVj for ; Thu, 5 May 2011 11:54:55 -0700 (PDT) Received: from nm30.access.bullet.mail.sp2.yahoo.com (nm30.access.bullet.mail.sp2.yahoo.com [98.139.44.157]) by ietfa.amsl.com (Postfix) with SMTP id 102B3E07B3 for ; Thu, 5 May 2011 11:54:54 -0700 (PDT) Received: from [98.139.44.106] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:54:54 -0000 Received: from [98.139.44.64] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:54:54 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 05 May 2011 18:54:54 -0000 X-Yahoo-Newman-Id: 726874.17048.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 79693 invoked from network); 5 May 2011 18:54:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1304621694; bh=w3Tn8vhY13ZHcDJhzXSB436A1NCuOQUtvs4SM+DDQ5U=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=Qt452gmlqdQMT16Rqq0aPAYdhLkyWeLGJeJ/ceW2AxUzu4Yzu1yYVIKKzbeb7vLfSfgHiU9PiM07+gt5eP8ATDUjPhIXBSBxcGO8BDT4AO53vtSZLphZIyyWxHuk2S2XQFXANY3vfGbjJ0J269cjdvt12thZuNVTgUqmsv6PZvM= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 05 May 2011 11:54:54 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: GGHXV3QVM1nFhf4isA5lOVFW.q.rf20H_xArDLyHRxEoBxl .Co9pKzqgx5ot10L8SVgUBncVKLWTaihIt1913qsNj.4FEtn4tiwKw_flZX4 Kw1PpOHdI3UQKOx_hToe8orTRZI5gVzd.MCjgogI5fpxZlT317DBDUV1a4KS ENL1ETW9nqQVtpFwPr0JhXJm.Whh.k1jz1YJaQo4gitqWlI_4rbajJA7WSjY vWmyc6MdU0Anu5HoROFITZx.LPRHmOJm2vV7PXeqw4izFZWV5y5By_SklvRs HRMvEef0WDm.ds00ObG9H7cEEk_7lLcAj3YCWA_0VFXpurqksuyz7wrT2w1n qEuw7fExEqqSIQ1J8bVVqKNJ.7xIOxtUt9qUTkptu X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <015c01cc0b54$e29b78e0$a7d26aa0$@sturek@att.net> In-Reply-To: <015c01cc0b54$e29b78e0$a7d26aa0$@sturek@att.net> Date: Thu, 5 May 2011 11:54:52 -0700 Message-ID: <017001cc0b55$eac6e210$c054a630$@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: AcwLVMUrFaevSOB3QSme1ev+gudWqAAAAj1AAABB7zA= Content-Language: en-us Subject: Re: [Roll] FW: New ZigBee Alliance Comment Submitted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:54:55 -0000 Sorry ROLL folks, messed up! Owe you a beer or something at the next IETF! Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: Thursday, May 05, 2011 11:47 AM To: roll@ietf.org Subject: [Roll] FW: New ZigBee Alliance Comment Submitted FYI. CCB is in for the ZigBee Help issue you sent me.... Don -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, May 05, 2011 11:47 AM To: Don Sturek; Phil Jamieson Subject: New ZigBee Alliance Comment Submitted Comment CC-1406 was successfully submitted by Don Sturek. You will be receive an email when this comment has been reviewed. Subject: Possible typo - Could be corrected in r19 Type: Editorial Description: I'm reading Zigbee Specification document 053474r17, and I found an error on page 399, at line 29. The value of nwkMaxChildren=8 is wrong and must be nwkMaxChildren=6, to be agree with the others attributes values on the example and to get the result shown on table 3.50 Suggested Remedy: Came in from ZigBee Help. Seem to remember this being fixed after r17 but we should check _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu May 5 12:08:02 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922FAE0901 for ; Thu, 5 May 2011 12:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDQnejGI-PKt for ; Thu, 5 May 2011 12:08:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E0598E08C2 for ; Thu, 5 May 2011 12:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1595; q=dns/txt; s=iport; t=1304622481; x=1305832081; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2YS4UsNpCeP0A4He6gpQsBZZ6Yv8I2yMfUtO5B+sCZ0=; b=H7zT3bqXQ4lTJ04Q7VapJNBRBeTgnhsyqNpUhDQKouB9AEawN34GJZ1W Q2ANM78I8rpsRbCssXSK/5zW6zLiO1Es3v3m7IZXP1IBD1jrScOdTBl8J WHXuSwrfc+RD0pLMU9T7lpQcO2y62nj8jCN8eg7pqV2dfnGNpvy+9AuHX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICAPv0wk2rRDoJ/2dsb2JhbACYFkCNZ3eIcp4Pnj+GBwSGOIkShCyKQw X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="309315602" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 19:08:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p45J81hh011613; Thu, 5 May 2011 19:08:01 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 12:08:01 -0700 Received: from dhcp-171-70-221-248.cisco.com ([171.70.221.248]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 12:07:59 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <017001cc0b55$eac6e210$c054a630$@sturek@att.net> Date: Thu, 5 May 2011 12:07:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <015c01cc0b54$e29b78e0$a7d26aa0$@sturek@att.net> <017001cc0b55$eac6e210$c054a630$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 05 May 2011 19:07:59.0744 (UTC) FILETIME=[BFF49800:01CC0B57] Cc: roll@ietf.org Subject: Re: [Roll] FW: New ZigBee Alliance Comment Submitted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 May 2011 19:08:02 -0000 On May 5, 2011, at 11:54 AM, Don Sturek wrote: > Sorry ROLL folks, messed up! Owe you a beer or something at the next IETF! Thanks :-))) > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don > Sturek > Sent: Thursday, May 05, 2011 11:47 AM > To: roll@ietf.org > Subject: [Roll] FW: New ZigBee Alliance Comment Submitted > > FYI. CCB is in for the ZigBee Help issue you sent me.... > > Don > > > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: Thursday, May 05, 2011 11:47 AM > To: Don Sturek; Phil Jamieson > Subject: New ZigBee Alliance Comment Submitted > > Comment CC-1406 was successfully submitted by Don Sturek. > You will be receive an email when this comment has been reviewed. > > Subject: Possible typo - Could be corrected in r19 > Type: Editorial > Description: I'm reading Zigbee Specification document 053474r17, and I > found an error on page 399, at line 29. The value of nwkMaxChildren=8 is > wrong and must be nwkMaxChildren=6, to be agree with the others attributes > values on the example and to get the result shown on table 3.50 > Suggested Remedy: Came in from ZigBee Help. Seem to remember this being > fixed after r17 but we should check > > _______________________________________________ > 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 jpv@cisco.com Sat May 7 17:16:15 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB35E06A3 for ; Sat, 7 May 2011 17:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.003 X-Spam-Level: X-Spam-Status: No, score=-99.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_ASCII_ART_SPACINGc=0.833, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wsf2JPfRFYS for ; Sat, 7 May 2011 17:16:12 -0700 (PDT) Received: from vbn.0050420.lodgenet.net (unknown [12.229.246.2]) by ietfa.amsl.com (Postfix) with ESMTP id 61C3DE069B for ; Sat, 7 May 2011 17:16:12 -0700 (PDT) Received: from [10.2.70.132] (helo=[10.2.70.132]) by vbn.0050420.lodgenet.net with esmtp (Exim 3.34 #1) id 1QIrfP-0000hJ-00; Sat, 07 May 2011 17:16:11 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-55-88935560 Date: Sat, 7 May 2011 17:14:09 -0700 Message-Id: To: "Pascal Thubert (pthubert)" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: ROLL WG Subject: [Roll] Few comments on OF0 before publication request X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 00:16:15 -0000 --Apple-Mail-55-88935560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pascal, Here they are: ROLL P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track May 5, 2011 Expires: November 6, 2011 RPL Objective Function 0 draft-ietf-roll-of0-11 Abstract The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic=20 JP> Remove "generic" Distance Vector protocol that is adapted to such networks. JP> s/such networks/Low power and Lossy Networks (LLNs) RPL requires a specific Objective Function to establish a desired routing topology. This document specifies a basic Objective Function that relies only on RPL's basic Protocol Data Units JP> What do you mean by "protocol data units" ? ; it does not use extensions such as RPL metric containers. JP> it does not require the use of routing metrics Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 6, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Thubert Expires November 6, 2011 [Page 1] =0C Internet-Draft draft-ietf-roll-of0 May 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4 4. OF0 operations . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Feasible successors selection . . . . . . . . . . . . . . 6 4.2.1. Selection of the Preferred Parent . . . . . . . . . . 6 4.2.2. Selection of the backup feasible successor . . . . . . 7 5. Abstract Interface with RPL core . . . . . . . . . . . . . . . 8 6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Configurable parameters . . . . . . . . . . . . . . . . . 8 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Thubert Expires November 6, 2011 [Page 2] =0C Internet-Draft draft-ietf-roll-of0 May 2011 1. Introduction The Routing Protocol for Low Power and Lossy Networks [I-D.ietf-roll-rpl] was designed as a generic core=20 JP> s/generic core/modular distance vector routing protocol that is agnostic to metrics=20 JP>s/agnostic to metrics/that may not may not require the use of=20 routing metrics. and that is adapted to a given problem using Objective Functions (OF). This separation of Objective Functions from the core protocol specification allows RPL to adapt to meet the different optimization criteria required by the wide range of use cases. RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed in a new Version to enable a global reoptimization of the graph. An Objective Function selects the DODAG Version that a device joins within an instance, and a number of neighbor routers within that DODAG Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by the generic RPL core=20 JP> avoid using the term "core" ...=20 to enable a degree of loop avoidance and verify forward progression towards a destination, as specified in [I-D.ietf-roll-rpl]. The Objective Function 0 (OF0) corresponds to the Objective Code Point 0 (OCP0).=20 JP> Code point can be defined later. OF0 only requires the information in the RPL DIO base container, such as Rank and the DODAGPreference field that describes an administrative preference [I-D.ietf-roll-rpl]. The Rank of a node is obtained by adding a normalized scalar, rank_increase, to the Rank of a selected preferred parent. OF0 uses a unit MinHopRankIncrease of rank_increase of 0x100 so that Rank value can be stored in one octet. This allows up to at least 28 hops even when default settings are used and each hop has the worst rank_increase of 9. JP> Clear for RPL designer but ... please elaborate on the last two = sentences. Since there is no default OF or metric container in the RPL main specification, it might happen that, unless two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate. OF0 is designed to be common to all implementations that are not specifically designed to apply to a given case for which further guidance is provided. =20 JP> Confusing wording ... IMO you can remove the last sentence This is why it is very abstract=20 JP> Very abstract? as to how the link properties are transformed into a rank_increase and leaves that responsibility to implementation; rather, OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range, as opposed to formulating the details of its computation. This is also why OF0 ignores metric containers. Thubert Expires November 6, 2011 [Page 3] =0C Internet-Draft draft-ietf-roll-of0 May 2011 2. Terminology The terminology used in this document is consistent with and incorporates that described in `Terminology in Low power And Lossy Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. The term feasible successor is used to refer to a neighbor that can possibly be used as a next-hop for upwards traffic following the loop avoidance and forwarding rules that the nodes implements and that are defined outside of this specification, in particular in the RPL specification. JP> s/defined outside of this specification, in particular in the RPL specification./defined in [I-D.ietf-roll-rpl] 3. Objective Function 0 Overview The core RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors. All parents are feasible successors for upgoing traffic (towards the root). Additionally, RPL allows the use of parents in a subsequent Version of a same DODAG as feasible successors, in which case this node acts as a leaf in the subsequent DODAG Version. Further specifications might extend the set of feasible successors, for instance to nodes of a same Rank, aka siblings. JP> Remove previous sentence, out of the scope. The Goal=20 JP> s/Goal/objective of the OF0 is for a node to join a DODAG Version that offers connectivity to a specific set of nodes or to a larger routing infrastructure. =20 JP> Add "with no attempt to optimize the path according to a specific routing metric" For the purpose of OF0, Grounded thus means that the root provides such connectivity. How that connectivity is asserted and maintained is out of scope. Objective Function 0 is designed to find the nearest Grounded root. This can be achieved if the Rank of a node represents closely=20 JP> closely ? its distance to the root. This need is balanced with the other need of maintaining some path diversity. =20 JP> what do you mean by "balanced with the other need of maintaining some path diversity" ? In the absence of a Grounded root, LLN inner connectivity is still desirable and floating DAGs will form, rooted at the nodes with the highest administrative preference. OF0 selects a preferred parent and a backup feasible successor if one is available. All the upward traffic is normally routed via the preferred parent. When the link conditions do not let an upward packet through the preferred parent, the packet is passed to the backup feasible successor. JP> Add "there is no attempt to perform load balancing" OF0 assigns a step_of_rank to each link to another node that it monitors. The exact method for computing the step_of_rank=20 JP> Indicate where is "step_of_rank" defined is implementation-dependent. Thubert Expires November 6, 2011 [Page 4] =0C Internet-Draft draft-ietf-roll-of0 May 2011 4. OF0 operations 4.1. Computing Rank One trivial=20 JP> remove "trivial" OF0 implementation might compute the step_of_rank from as a classical administrative cost that is assigned to the link. Using a metric similar to hop count implies that the OF0 implementation only considers neighbors with good enough connectivity, for instance neighbors that are reachable over an Ethernet link, or a WIFI link in infrastructure mode. JP> Not necesarily ... furthermore, why are you referring to = Ethernet/Wifi links? In most wireless networks JP> s/in most wireless networks/in most LLNs , a Rank that is analogous to an unweighted hop count favors paths with long distance links=20 JP> Long distance links ? and poor connectivity properties. Other link properties such as the expected transmission count metric (ETX) [DeCouto03] should be used=20 JP> should be used for what ? instead to compute the step_of_rank. For instance, the Minimum Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how link cost can be computed and on how hysteresis can improve Rank stability. An implementation MAY allow to stretch the step_of_rank with a stretch_of_rank=20 JP> refer to the section where this is defined up to no more than MAXIMUM_RANK_STRETCH in order to enable the selection of a feasible successor and maintain path diversity. =20 JP> you do no explain the implication on path diversity? The use of a stretch_of_rank augments the apparent distance from the node to the root and distorts the DODAG; it should be used with care so as to avoid instabilities due to greedy behaviours. JP> paragraph above too cryptic ...=20 The step_of_rank is expressed in units of MINIMUM_STEP_OF_RANK. As a result, the least significant octet in the RPL Rank is not used. The default step_of_rank is DEFAULT_STEP_OF_RANK for each hop. An implementation MUST maintain the stretched step_of_rank between MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to reflect a large variation of link quality. The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. An implementation SHOULD allow a configurable factor called Rank- factor and to apply the factor on all links and peers. JP> Factor used where and how ? An implementation MAY recognizes sub-categories of peers and links, such as different MAC types, in which case it SHOULD be able to configure a more specific Rank-factor to those categories. The Rank- factor SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. Thubert Expires November 6, 2011 [Page 5] =0C Internet-Draft draft-ietf-roll-of0 May 2011 The step_of_rank Sp that is computed for that link is multiplied by the Rank-factor Rf and then possibly stretched by a stretch_of_rank Sr. The resulting rank_increase Ri is added to the Rank of preferred parent R(P) to obtain that of this node R(N): R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease JP> Add a short example in appendix for clarity Optionally, the administrative preference of a root MAY be configured to supersede the goal to join a Grounded DODAG. In that case, nodes will associate to the root with the highest preference available, regardless of whether that root is Grounded or not. Compared to a deployment with a multitude of Grounded roots that would result in a same multitude of DODAGs, such a configuration may result in possibly less but larger DODAGs, as many as roots configured with the highest priority in the reachable vicinity. 4.2. Feasible successors selection 4.2.1. Selection of the Preferred Parent As it scans all the candidate neighbors, OF0 performs in order the following checks and keeps the parent that is the best for the first criterion that makes a difference: 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to reparent and in particular the boundaries to augment its Rank within a DODAG Version. =20 JP> point to the section in RPL core specification A candidate that would not satisfy those rules MUST NOT be considered. 2. An implementation should=20 JP> should or SHOULD ? validate a router prior to selecting it as preferred. This validation process is implementation and link type dependent, and is out of scope. A router that has been validated is preferable. JP> You mean "ensure that the link is sufficiently stable" not "Validate the router" 3. When multiple interfaces are available, a policy might be locally configured to order them and that policy applies first; that is a router on a higher order interface in the policy is preferable. 4. If the administrative preference of the root is configured to supersede the goal to join a Grounded DODAG, a router that offers connectivity to a more preferable root SHOULD be preferred. 5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not. Thubert Expires November 6, 2011 [Page 6] =0C Internet-Draft draft-ietf-roll-of0 May 2011 6. A router that offers connectivity to a more preferable root SHOULD be preferred. 7. When comparing 2 routers=20 JP> s/2/two JP>s/routers/parents that belong to the same DODAG, a router that offers connectivity to the freshest DODAG=20 JP>freshed =3D> higher Version Version SHOULD be preferred. 8. The parent that causes the lesser resulting Rank for this node, as specified in Section 4.1, SHOULD be preferred. 9. A DODAG Version for which there is an alternate parent SHOULD be preferred. This check is optional. It is performed by computing the backup feasible successor while assuming that the router that is currently examined is finally selected as preferred parent. 10. The preferred parent that was in use already SHOULD be preferred. 11. A router that has announced a DIO message more recently SHOULD be preferred. 4.2.2. Selection of the backup feasible successor When selecting a backup feasible successor, the OF performs in order the following checks: 1. When multiple interfaces are available, a router on a higher order interface is preferable. 2. The backup feasible successor MUST NOT be the preferred parent. 3. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent DODAG Version. 4. Along with RPL rules, a Router in the same DODAG Version as this node and with a Rank that is higher than the Rank computed for this node MUST NOT be selected as a feasible successor. 5. A router with a lesser Rank SHOULD be preferred. 6. A router that has been validated as usable by an implementation dependant validation process SHOULD be preferred. 7. The backup feasible successor that was in use already SHOULD be preferred. Thubert Expires November 6, 2011 [Page 7] =0C Internet-Draft draft-ietf-roll-of0 May 2011 5. Abstract Interface with RPL core Objective Function 0 interacts with the core RPL in the following ways: Processing DIO: This core RPL=20 JP> core RPL triggers ?? triggers the OF when a new DIO was received. OF0 analyses the information in the DIO and may select the source as a parent or sibling. JP> Remove sibling Providing DAG information: The OF is called to provide information about a given instance. This includes material from the DIO base header, the role (router, leaf), and the Rank of this node. JP> what are you defining here ? Providing a Parent List: The OF0 support can be required=20 JP> required by who ? to provide the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry. Trigger: The OF0 support may trigger the RPL core to inform it that a change occurred. This can be used to indicate whether the change requires a new DIO to be fired or whether trickle timers need to be reset. JP> Part of this section belong to a manageability section 6. OF0 Operands 6.1. Variables OF0 uses the following variables: step_of_rank (unsigned integer): an intermediate computation based on the link properties with a certain neighbor. rank-increase (unsigned integer): delta between the Rank of the preferred parent and self 6.2. Configurable parameters OF0 can use the following optional parameters: stretch_of_rank (unsigned integer): an optional augmentation to the step-of-rank of the preferred parent to allow the selection of additional parents. rank_factor (unsigned integer): A configurable factor that is used to multiply the effect of the link properties in the rank_increase computation. Thubert Expires November 6, 2011 [Page 8] =0C Internet-Draft draft-ietf-roll-of0 May 2011 6.3. Constants OF0 fixes the following constants: MinHopRankIncrease: 256 DEFAULT_STEP_OF_RANK: 3 MINIMUM_STEP_OF_RANK: 1 MAXIMUM_STEP_OF_RANK: 9 DEFAULT_RANK_STRETCH: 0 MAXIMUM_RANK_STRETCH: 5 DEFAULT_RANK_FACTOR: 1 MINIMUM_RANK_FACTOR: 1 MAXIMUM_RANK_FACTOR: 4 7. IANA Considerations This specification requires the assignment of an OCP for OF0. The value of 0 is suggested. 8. Security Considerations Security Considerations for OCP/OF are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 9. Acknowledgements Most specific thanks to Philip Levis and Phoebus Chen for their help in finalizing this document. Many thanks also to Tim Winter, JP Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in-depth review and first hand implementer's feedback. 10. References Thubert Expires November 6, 2011 [Page 9] =0C Internet-Draft draft-ietf-roll-of0 May 2011 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [DeCouto03] De Couto, Aguayo, Bicket, and Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03 The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California,, 2003, . [I-D.ietf-roll-minrank-hysteresis-of] Gnawali, O. and P. Levis, "The Minimum Rank Objective Function with Hysteresis", draft-ietf-roll-minrank-hysteresis-of-03 (work in progress), May 2011. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-19 (work in progress), March 2011. JP> Note referenced anywhere in the document. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-05 (work in progress), March 2011. [I-D.tsao-roll-security-framework] Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-02 (work in progress), March 2010. JP> ID NITS: Thubert Expires November 6, 2011 [Page 10] =0C Internet-Draft draft-ietf-roll-of0 May 2011 Author's Address Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Thubert Expires November 6, 2011 [Page 11] =0C --Apple-Mail-55-88935560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Pascal,

Here they are:

ROLL               =
                                      P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                             May 5, 2011
Expires: November 6, 2011


                        RPL Objective Function 0
                         draft-ietf-roll-of0-11

Abstract

   The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
   generic 
JP> Remove "generic"
Distance Vector =
protocol that is adapted to such networks.
JP> s/such networks/Low power =
and Lossy Networks (LLNs)
   RPL requires a specific Objective Function to establish a desired
   routing topology.  This document specifies a basic Objective Function
   that relies only on RPL's basic Protocol Data Units
JP> What do you mean by =
"protocol data units" ?
; it does not use
   extensions such as RPL metric containers.
JP> it does not require the use =
of routing metrics

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ie=
tf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 6, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Thubert                 Expires November 6, 2011                [Page 1]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Objective Function 0 Overview  . . . . . . . . . . . . . . . .  4
   4.  OF0 operations . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Computing Rank . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Feasible successors selection  . . . . . . . . . . . . . .  6
       4.2.1.  Selection of the Preferred Parent  . . . . . . . . . .  6
       4.2.2.  Selection of the backup feasible successor . . . . . .  7
   5.  Abstract Interface with RPL core . . . . . . . . . . . . . . .  8
   6.  OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Variables  . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Configurable parameters  . . . . . . . . . . . . . . . . .  8
     6.3.  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10




















Thubert                 Expires November 6, 2011                [Page 2]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


1.  Introduction

   The Routing Protocol for Low Power and Lossy Networks
   [I-D.ietf-roll-rpl] was designed as a generic =
core 
JP> s/generic core/modular distance vector routing =
protocol
that is agnostic
   to metrics 
JP>s/agnostic to metrics/that may not may not require the =
use of 
routing metrics.
and that is adapted to =
a given problem using Objective
   Functions (OF).  This separation of Objective Functions from the core
   protocol specification allows RPL to adapt to meet the different
   optimization criteria required by the wide range of use cases.

   RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
   within instances of the protocol.  Each instance is associated with a
   specialized Objective Function.  A DODAG is periodically
   reconstructed in a new Version to enable a global reoptimization of
   the graph.

   An Objective Function selects the DODAG Version that a device joins
   within an instance, and a number of neighbor routers within that
   DODAG Version as parents or feasible successors.  The OF generates
   the Rank of the device, that represents an abstract distance to the
   root within the DODAG.  In turn, the Rank is used by the generic RPL
   core 
JP> avoid using the term "core" =
... 
to enable a degree of loop avoidance and =
verify forward
   progression towards a destination, as specified in
   [I-D.ietf-roll-rpl].

   The Objective Function 0 (OF0) corresponds to the Objective Code
   Point 0 (OCP0). 
JP> Code point can be defined later.
 =
OF0 only requires the information in the RPL DIO
   base container, such as Rank and the DODAGPreference field that
   describes an administrative preference [I-D.ietf-roll-rpl].  The Rank
   of a node is obtained by adding a normalized scalar, rank_increase,
   to the Rank of a selected preferred parent.  OF0 uses a unit
   MinHopRankIncrease of rank_increase of 0x100 so that Rank value can
   be stored in one octet.  This allows up to at least 28 hops even when
   default settings are used and each hop has the worst rank_increase of
   9.
JP> =
Clear for RPL designer but ... please elaborate on the last two =
sentences.
   Since there is no default OF or =
metric container in the RPL main
   specification, it might happen that, unless two given implementations
   follow the same guidance for a specific problem or environment, those
   implementations will not support a common OF with which they could
   interoperate.  OF0 is designed to be common to all implementations
   that are not specifically designed to apply to a given case for which
   further guidance is provided.  
JP> Confusing wording ... IMO =
you can remove the last sentence
This is why it is =
very abstract 
JP> Very abstract?
as to
   how the link properties are transformed into a rank_increase and
   leaves that responsibility to implementation; rather, OF0 enforces
   normalized values for the rank_increase of a normal link and its
   acceptable range, as opposed to formulating the details of its
   computation.  This is also why OF0 ignores metric containers.




Thubert                 Expires November 6, 2011                [Page 3]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


2.  Terminology

   The terminology used in this document is consistent with and
   incorporates that described in `Terminology in Low power And Lossy
   Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].

   The term feasible successor is used to refer to a neighbor that can
   possibly be used as a next-hop for upwards traffic following the loop
   avoidance and forwarding rules that the nodes implements and that =
are
   defined outside of this specification, in particular in =
the RPL
   specification.

JP> =
s/defined outside of this specification, in particular in the =
RPL
   specification./defined in [I-D.ietf-roll-rpl]
3.  =
Objective Function 0 Overview

   The core RPL specification describes constraints on how nodes select
   potential parents, called a parent set, from their neighbors.  All
   parents are feasible successors for upgoing traffic (towards the
   root).  Additionally, RPL allows the use of parents in a subsequent
   Version of a same DODAG as feasible successors, in which case this
   node acts as a leaf in the subsequent DODAG Version.  Further
   specifications might extend the set of feasible successors, for
   instance to nodes of a same Rank, aka siblings.
JP> =
Remove previous sentence, out of the scope.

   The Goal 
JP> =
s/Goal/objective
of the OF0 is for a =
node to join a DODAG Version that offers
   connectivity to a specific set of nodes or to a larger routing
   infrastructure.  
JP> Add "with no attempt to =
optimize the path according to a specific
routing =
metric"
For the purpose of OF0, =
Grounded thus means that the
   root provides such connectivity.  How that connectivity is asserted
   and maintained is out of scope.

   Objective Function 0 is designed to find the nearest Grounded root.
   This can be achieved if the Rank of a node represents =
closely 
JP> closely =
?
its
   distance to the root.  This need is balanced with the other need of
   maintaining some path diversity.  
JP> what =
do you mean by "balanced with the other need of =
maintaining
some path diversity" =
?
In the absence of a Grounded root,
   LLN inner connectivity is still desirable and floating DAGs will
   form, rooted at the nodes with the highest administrative preference.

   OF0 selects a preferred parent and a backup feasible successor if one
   is available.  All the upward traffic is normally routed via the
   preferred parent.  When the link conditions do not let an upward
   packet through the preferred parent, the packet is passed to the
   backup feasible successor.
JP> Add "there is no attempt to =
perform load balancing"


   OF0 assigns a step_of_rank to each link to another node that it
   monitors.  The exact method for computing the =
step_of_rank 
JP> Indicate where is =
"step_of_rank" defined
is
   implementation-dependent.





Thubert                 Expires November 6, 2011                [Page 4]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


4.  OF0 operations

4.1.  Computing Rank

   One trivial 
JP> remove =
"trivial"
OF0 implementation might =
compute the step_of_rank from as
   a classical administrative cost that is assigned to the link.  Using
   a metric similar to hop count implies that the OF0 implementation
   only considers neighbors with good enough connectivity, for instance
   neighbors that are reachable over an Ethernet link, or a WIFI link in
   infrastructure mode.
JP> Not necesarily ... =
furthermore, why are you referring to Ethernet/Wifi =
links?

   In most wireless networks
JP> s/in most wireless =
networks/in most LLNs
, a Rank that is =
analogous to an unweighted
   hop count favors paths with long distance links 
JP> Long =
distance links ?
and poor connectivity
   properties.  Other link properties such as the expected transmission
   count metric (ETX) [DeCouto03] should be used 
JP> =
should be used for what ?
instead to =
compute the
   step_of_rank.  For instance, the Minimum Rank Objective Function with
   Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on
   how link cost can be computed and on how hysteresis can improve Rank
   stability.

   An implementation MAY allow to stretch the step_of_rank with a
   stretch_of_rank 
JP> refer to the section where =
this is defined
up to no more than =
MAXIMUM_RANK_STRETCH in order to
   enable the selection of a feasible successor and maintain path
   diversity.  
JP> you do no explain the =
implication on path diversity?
The use =
of a stretch_of_rank augments the apparent
   distance from the node to the root and distorts the DODAG; it should
   be used with care so as to avoid instabilities due to greedy
   behaviours.
JP> paragraph above too cryptic =
... 

   The step_of_rank is expressed in units of MINIMUM_STEP_OF_RANK.  As a
   result, the least significant octet in the RPL Rank is not used.  The
   default step_of_rank is DEFAULT_STEP_OF_RANK for each hop.  An
   implementation MUST maintain the stretched step_of_rank between
   MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to
   reflect a large variation of link quality.

   The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not
   be sufficient in every case to strongly distinguish links of
   different types or categories in order to favor, say, powered over
   battery-operated or wired over wireless, within a same DAG.

   An implementation SHOULD allow a configurable factor called Rank-
   factor and to apply the factor on all links and =
peers.
JP> Factor used where and how ?
   =
An implementation MAY recognizes sub-categories of peers and links,
   such as different MAC types, in which case it SHOULD be able to
   configure a more specific Rank-factor to those categories.  The Rank-
   factor SHOULD be set between MINIMUM_RANK_FACTOR and
   MAXIMUM_RANK_FACTOR.



Thubert                 Expires November 6, 2011                [Page 5]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


   The step_of_rank Sp that is computed for that link is multiplied by
   the Rank-factor Rf and then possibly stretched by a stretch_of_rank
   Sr. The resulting rank_increase Ri is added to the Rank of preferred
   parent R(P) to obtain that of this node R(N):

   R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease

JP> Add a short example in appendix for =
clarity

   Optionally, the administrative preference of a root MAY be configured
   to supersede the goal to join a Grounded DODAG.  In that case, nodes
   will associate to the root with the highest preference available,
   regardless of whether that root is Grounded or not.  Compared to a
   deployment with a multitude of Grounded roots that would result in a
   same multitude of DODAGs, such a configuration may result in possibly
   less but larger DODAGs, as many as roots configured with the highest
   priority in the reachable vicinity.

4.2.  Feasible successors selection

4.2.1.  Selection of the Preferred Parent

   As it scans all the candidate neighbors, OF0 performs in order the
   following checks and keeps the parent that is the best for the first
   criterion that makes a difference:

   1.   [I-D.ietf-roll-rpl] spells out the generic rules for a node to
        reparent and in particular the boundaries to augment its Rank
        within a DODAG Version.  
JP> =
point to the section in RPL core =
specification
A candidate that would =
not satisfy
        those rules MUST NOT be considered.

   2.   An implementation should 
JP> =
should or SHOULD ?
validate a router =
prior to selecting it
        as preferred.  This validation process is implementation and
        link type dependent, and is out of scope.  A router that has
        been validated is preferable.
JP> You =
mean "ensure that the link is sufficiently stable" not =
"Validate
the router"


   3.   When multiple interfaces are available, a policy might be
        locally configured to order them and that policy applies first;
        that is a router on a higher order interface in the policy is
        preferable.

   4.   If the administrative preference of the root is configured to
        supersede the goal to join a Grounded DODAG, a router that
        offers connectivity to a more preferable root SHOULD be
        preferred.

   5.   A router that offers connectivity to a grounded DODAG Version
        SHOULD be preferred over one that does not.





Thubert                 Expires November 6, 2011                [Page 6]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


   6.   A router that offers connectivity to a more preferable root
        SHOULD be preferred.

   7.   When comparing 2 routers 
JP> =
s/2/two
JP>s/routers/parents
that =
belong to the same DODAG, a router
        that offers connectivity to the freshest =
DODAG 
JP>freshed =3D> higher =
Version
Version SHOULD be
        preferred.

   8.   The parent that causes the lesser resulting Rank for this node,
        as specified in Section 4.1, SHOULD be preferred.

   9.   A DODAG Version for which there is an alternate parent SHOULD be
        preferred.  This check is optional.  It is performed by
        computing the backup feasible successor while assuming that the
        router that is currently examined is finally selected as
        preferred parent.

   10.  The preferred parent that was in use already SHOULD be
        preferred.

   11.  A router that has announced a DIO message more recently SHOULD
        be preferred.

4.2.2.  Selection of the backup feasible successor

   When selecting a backup feasible successor, the OF performs in order
   the following checks:

   1.  When multiple interfaces are available, a router on a higher
       order interface is preferable.

   2.  The backup feasible successor MUST NOT be the preferred parent.

   3.  The backup feasible successor MUST be either in the same DODAG
       Version as this node or in an subsequent DODAG Version.

   4.  Along with RPL rules, a Router in the same DODAG Version as this
       node and with a Rank that is higher than the Rank computed for
       this node MUST NOT be selected as a feasible successor.

   5.  A router with a lesser Rank SHOULD be preferred.

   6.  A router that has been validated as usable by an implementation
       dependant validation process SHOULD be preferred.

   7.  The backup feasible successor that was in use already SHOULD be
       preferred.





Thubert                 Expires November 6, 2011                [Page 7]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


5.  Abstract Interface with RPL core

   Objective Function 0 interacts with the core RPL in the following
   ways:

   Processing DIO:  This core RPL 
JP> core =
RPL triggers ??
triggers the OF when a =
new DIO was
      received.  OF0 analyses the information in the DIO and may select
      the source as a parent or sibling.
JP> =
Remove sibling

   Providing DAG information:  The OF is called to provide information
      about a given instance.  This includes material from the DIO base
      header, the role (router, leaf), and the Rank of this node.

JP> what are you defining here ?

   Providing a Parent List:  The OF0 support can be =
required 
JP> required by who =
?
to provide
      the ordered list of the parents and feasible successors for a
      given instance to the RPL core.  This includes the material that
      is contained in the transit option for each entry.

   Trigger:  The OF0 support may trigger the RPL core to inform it that
      a change occurred.  This can be used to indicate whether the
      change requires a new DIO to be fired or whether trickle timers
      need to be reset.
JP> Part of this section belong =
to a manageability section

6.  OF0 Operands

6.1.  Variables

   OF0 uses the following variables:

   step_of_rank (unsigned integer):  an intermediate computation based
      on the link properties with a certain neighbor.

   rank-increase (unsigned integer):  delta between the Rank of the
      preferred parent and self

6.2.  Configurable parameters

   OF0 can use the following optional parameters:

   stretch_of_rank (unsigned integer):  an optional augmentation to the
      step-of-rank of the preferred parent to allow the selection of
      additional parents.

   rank_factor (unsigned integer):  A configurable factor that is used
      to multiply the effect of the link properties in the rank_increase
      computation.




Thubert                 Expires November 6, 2011                [Page 8]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


6.3.  Constants

   OF0 fixes the following constants:

   MinHopRankIncrease:  256

   DEFAULT_STEP_OF_RANK:  3

   MINIMUM_STEP_OF_RANK:  1

   MAXIMUM_STEP_OF_RANK:  9

   DEFAULT_RANK_STRETCH:  0

   MAXIMUM_RANK_STRETCH:  5

   DEFAULT_RANK_FACTOR:  1

   MINIMUM_RANK_FACTOR:  1

   MAXIMUM_RANK_FACTOR:  4


7.  IANA Considerations

   This specification requires the assignment of an OCP for OF0.  The
   value of 0 is suggested.


8.  Security Considerations

   Security Considerations for OCP/OF are to be developed in accordance
   with recommendations laid out in, for example,
   [I-D.tsao-roll-security-framework].


9.  Acknowledgements

   Most specific thanks to Philip Levis and Phoebus Chen for their help
   in finalizing this document.

   Many thanks also to Tim Winter, JP Vasseur, Julien Abeille, Mathilde
   Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in-depth
   review and first hand implementer's feedback.


10.  References




Thubert                 Expires November 6, 2011                [Page 9]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [DeCouto03]
              De Couto, Aguayo, Bicket, and Morris, "A High-Throughput
              Path Metric for Multi-Hop Wireless Routing", MobiCom
              '03 The 9th ACM International Conference on Mobile
              Computing and Networking, San Diego, California,, 2003, =
<h
              ttp://pd=
os.csail.mit.edu/papers/grid:mobicom03/paper.pdf>.

   [I-D.ietf-roll-minrank-hysteresis-of]
              Gnawali, O. and P. Levis, "The Minimum Rank Objective
              Function with Hysteresis",
              draft-ietf-roll-minrank-hysteresis-of-03 (work in
              progress), May 2011.

   [I-D.ietf-roll-routing-metrics]
              Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
              Barthel, "Routing Metrics used for Path Calculation in Low
              Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-19 (work in progress),
              March 2011.
JP> Note referenced anywhere in =
the document.


   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-05 (work in
              progress), March 2011.

   [I-D.tsao-roll-security-framework]
              Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
              Security Framework for Routing over Low Power and Lossy
              Networks", draft-tsao-roll-security-framework-02 (work in
              progress), March 2010.



JP> ID NITS:







Thubert                 Expires November 6, 2011               [Page 10]
=0C
Internet-Draft             draft-ietf-roll-of0                  May 2011


Author's Address

   Pascal Thubert (editor)
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com







































Thubert                 Expires November 6, 2011               [Page 11]
=0C

= --Apple-Mail-55-88935560-- From jpv@cisco.com Sun May 8 08:55:42 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670DE0789 for ; Sun, 8 May 2011 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qN7tvTqPpTt for ; Sun, 8 May 2011 08:55:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8DE0759 for ; Sun, 8 May 2011 08:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=9908; q=dns/txt; s=iport; t=1304870140; x=1306079740; h=from:subject:date:message-id:cc:to:mime-version; bh=+OrwGf5UH/sTrAN4B04EAGAWv7h5fvfEjixdCm+iKes=; b=FnNy04w97g/WTB1Qi0FmfAoUGeWyDneUT7RDfNRGdI8wH8v8rc1rwS5g a+XrykbPewkYfFNnzIGM2i5iYQtIG/IedzGrDvI+iiTtGgpqiOykdfItC oajXGLFTAOkFW/GxKD0wUs/O0j2Xg1dyvtHue7/XrYLpjZAyZTVD6+pg1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHy8xk2rRDoJ/2dsb2JhbACmGHeoJZx+hgwEhkCJJYQoCYl4VA X-IronPort-AV: E=Sophos;i="4.64,335,1301875200"; d="scan'208,217";a="693812099" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 08 May 2011 15:55:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p48Ftd04007274; Sun, 8 May 2011 15:55:39 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 08:55:39 -0700 Received: from [10.2.70.132] ([10.21.90.199]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 08:55:39 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-8-145424784 Date: Sun, 8 May 2011 08:55:39 -0700 Message-Id: To: Omprakash Gnawali , Philip Levis Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 15:55:39.0249 (UTC) FILETIME=[60860E10:01CC0D98] Cc: ROLL WG Subject: [Roll] Few comments before sending the publication request to IESG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 15:55:42 -0000 --Apple-Mail-8-145424784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Just minor comments before sending the publications request: 1) If the node does not have metrics to compute the Gnawali & Levis Expires November 4, 2011 [Page 4] Internet-Draft draft-ietf-roll-minrank-hysteresis-of May 2011 path cost through any of the candidate neighbors, it MUST join one of the candidate neighbors as a leaf node. JP> You many replace that "it must join one of the candidate neighbors = as a=20 leaf node" according to I-D.ietf-roll-rpl. 2) I would suggest to add a manageability section pointing out that the = following parameters should be configurable: - PARENT_SWITCH_THRESHOLD - If the configuration disallows a node to be a Floating root and no neighbors are discovered, the node does not have a preferred parent, and MUST set cur_min_path_cost to MAX_PATH_COST. =3D> The configuration SHOULD allow for configuring whether or not a = node could be a floating root. - PARENT_SET_SIZE 3) s/covert the the /convert the 4) In the absence of metric container, MRHOF uses ETX as its metric. It locally computes the ETX of links to its neighbors and adds this value to their advertised Rank to compute the associated Rank of routes. Once parent selection and rank computation is performed using the ETX metric, the node advertises a Rank equal to the ETX cost and SHOULD NOT include a metric container in its DIO messages. JP> You are suggesting here to not use the metric container if the link = metric in use is the ETX and embed it in the rank. Don't you think that this may lead to = interoperability=20 issues ? How do I need when receiving a DIO if the value of the rank = reflects the ETX or some other scalar ? By looking at the OCP, deduct that there is no = container ? Wouldn't it be "cleaner" to simply use of the metric container and use the ETX = metric defined in=20 draft-ietf-roll-metrics ? 5) In section 5, these values are RECOMMENDED (please indicate it), then = add a manageability section allowing to configure these values. 6) The following IDs should be normative: [I-D.ietf-roll-routing-metrics] Vasseur, J. and D. Networks, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-01 (work in progress), October 2009. [I-D.ietf-roll-rpl] Gnawali & Levis Expires November 4, 2011 [Page 9] Internet-Draft draft-ietf-roll-minrank-hysteresis-of May 2011 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-05 (work in progress), December 2009. 7) Outdated references: Checking references for intended status: Proposed Standard = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =3D=3D Outdated reference: A later version (-19) exists of draft-ietf-roll-routing-metrics-01 =3D=3D Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-05 =3D=3D Outdated reference: A later version (-05) exists of draft-ietf-roll-terminology-01 Thanks. JP.= --Apple-Mail-8-145424784 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Gnawali & Levis Expires November 4, = 2011 [Page 4] Internet-Draft = draft-ietf-roll-minrank-hysteresis-of May 2011 path cost through any of the candidate neighbors, it MUST join one of the candidate neighbors as a leaf node.
JP> You many = replace that "it must join one of the candidate neighbors as = a 
leaf node" according to = I-D.ietf-roll-rpl.

2) I would suggest to add a = manageability section pointing out that the = following
parameters should be = configurable:

- =
PARENT_SWITCH_THRESHOLD
- If the configuration disallows a =
node to be a Floating root and
       no neighbors are =
discovered, the node does not have a preferred
       parent, and MUST set cur_min_path_cost to =
MAX_PATH_COST.
=3D> The configuration SHOULD allow for = configuring whether or not a node could be
a floating = root.

- covert the the /convert the

In the absence of metric container, MRHOF = uses ETX as its metric. It
   locally computes the ETX =
of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes.  Once parent selection and rank computation is performed
   using the ETX metric, the node advertises a Rank equal to the ETX
   cost and SHOULD NOT include a metric container in its DIO messages.
JP> You are suggesting = here to not use the metric container if the link metric in use = is
the ETX and embed it in the rank. Don't = you think that this may lead to interoperability
issues ? How do I need when receiving a DIO if the value of the = rank reflects the ETX or
some other scalar = ? By looking at the OCP, deduct that there is no container ? Wouldn't = it
be "cleaner" to simply use of the metric = container and use the ETX metric defined in
draft-ietf-roll-metrics ?

5) In section 5, = these values are RECOMMENDED (please indicate it), then add a = manageability
section allowing to = configure these values.
6) The following = IDs should be normative:
Gnawali & Levis Expires November 4, = 2011 [Page 9] Internet-Draft = draft-ietf-roll-minrank-hysteresis-of May 2011 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-05 (work in progress), December = 2009.


7) Outdated = references:

Checking =
references for intended status: Proposed Standard
  =
--------------------------------------------------------------------------=
--

     (See RFCs 3967 and 4897 for information about using normative =
references
     to lower-maturity documents in RFCs)

  =3D=3D Outdated reference: A later version (-19) exists of
     draft-ietf-roll-routing-metrics-01

  =3D=3D Outdated reference: A later version (-19) exists of
     draft-ietf-roll-rpl-05

  =3D=3D Outdated reference: A later version (-05) exists of
     draft-ietf-roll-terminology-01
=
Thanks.

JP.
<= /div>= --Apple-Mail-8-145424784-- From gnawali@cs.stanford.edu Sun May 8 21:47:32 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F460E068E for ; Sun, 8 May 2011 21:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi4TLuNudbwp for ; Sun, 8 May 2011 21:47:32 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3009DE064E for ; Sun, 8 May 2011 21:47:32 -0700 (PDT) Received: from mail-pz0-f44.google.com ([209.85.210.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QJINX-00048G-Go for roll@ietf.org; Sun, 08 May 2011 21:47:31 -0700 Received: by pzk5 with SMTP id 5so2971336pzk.31 for ; Sun, 08 May 2011 21:47:31 -0700 (PDT) Received: by 10.68.69.14 with SMTP id a14mr5893042pbu.292.1304916451048; Sun, 08 May 2011 21:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Sun, 8 May 2011 21:47:11 -0700 (PDT) From: Omprakash Gnawali Date: Sun, 8 May 2011 21:47:11 -0700 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: ROLL WG Subject: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 04:47:32 -0000 On Sun, May 8, 2011 at 8:55 AM, JP Vasseur wrote: ... > 4)=A0In the absence of metric container, MRHOF uses ETX as its metric. It > > locally computes the ETX of links to its neighbors and adds this > value to their advertised Rank to compute the associated Rank of > routes. Once parent selection and rank computation is performed > using the ETX metric, the node advertises a Rank equal to the ETX > cost and SHOULD NOT include a metric container in its DIO messages. > > JP>=A0You are suggesting here to not use the metric container if the link > metric in use is > the ETX and embed it in the rank. Don't you think that this may lead to > interoperability > issues ? How do I need when receiving a DIO if the value of the rank > reflects the ETX or > some other scalar ? By looking at the OCP, deduct that there is no contai= ner > ? Wouldn't it > be "cleaner" to simply use of the metric container and use the ETX metric > defined in > draft-ietf-roll-metrics ? It is perfectly fine to use the metric containers if we want to use the ETX metric. But if there is no metric container, we assume that we are using the ETX metric. I think your interpretation is slightly different from what I had in mind so perhaps this warrants rewording and making it explicit that it is fine to use metric container with the ETX metric. - om_p From jpv@cisco.com Mon May 9 05:25:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA3E068D for ; Mon, 9 May 2011 05:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.513 X-Spam-Level: X-Spam-Status: No, score=-109.513 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7OkW0Z2KeRY for ; Mon, 9 May 2011 05:25:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (unknown [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id BAE79E0685 for ; Mon, 9 May 2011 05:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4335; q=dns/txt; s=iport; t=1304943905; x=1306153505; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=baLWY6E270XNRqP9iddlLgOgdcNnCZ1/HBe9IszXDCY=; b=DneVO3nhsP3i68KskKLp4fvQD7rPTYmVpF7WJW1R5p28NGTQNvcNvM3W vqzfBU372c7TJ+nDvHwqchui/yOUTsHimYvRbd6Kwf4OHehhBEDGr7y5x P2VFsVSBH9bZcHmukIjJ2c5Dlm3H/LetWYeGYr8rluVQvl96VWlKkKZSc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPcx02rRDoG/2dsb2JhbAClfHeIcZ9nnUKGDASGQIklhCgJiXhU X-IronPort-AV: E=Sophos;i="4.64,340,1301875200"; d="scan'208,217";a="694094839" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 09 May 2011 12:25:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49CP5TW010267; Mon, 9 May 2011 12:25:05 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 05:25:05 -0700 Received: from [10.2.70.132] ([10.21.90.111]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 05:25:04 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-48-219189941 From: JP Vasseur In-Reply-To: Date: Mon, 9 May 2011 05:25:04 -0700 Message-Id: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> References: To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 09 May 2011 12:25:04.0512 (UTC) FILETIME=[200BF000:01CC0E44] Cc: ROLL WG Subject: Re: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 12:25:07 -0000 --Apple-Mail-48-219189941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks om_p - see below On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote: > On Sun, May 8, 2011 at 8:55 AM, JP Vasseur wrote: > ... >=20 > > 4) In the absence of metric container, MRHOF uses ETX as its metric. = It > > > > locally computes the ETX of links to its neighbors and adds this > > value to their advertised Rank to compute the associated Rank of > > routes. Once parent selection and rank computation is performed > > using the ETX metric, the node advertises a Rank equal to the ETX > > cost and SHOULD NOT include a metric container in its DIO = messages. > > > > JP> You are suggesting here to not use the metric container if the = link > > metric in use is > > the ETX and embed it in the rank. Don't you think that this may lead = to > > interoperability > > issues ? How do I need when receiving a DIO if the value of the rank > > reflects the ETX or > > some other scalar ? By looking at the OCP, deduct that there is no = container > > ? Wouldn't it > > be "cleaner" to simply use of the metric container and use the ETX = metric > > defined in > > draft-ietf-roll-metrics ? >=20 >=20 > It is perfectly fine to use the metric containers if we want to use > the ETX metric. But if there is no metric container, we assume that we > are using the ETX metric. I think your interpretation is slightly > different from what I had in mind so perhaps this warrants rewording > and making it explicit that it is fine to use metric container with > the ETX metric. >=20 If at all possible, I would recommend one way to carry the ETX with the metric container. Cheers. JP. >=20 > - om_p >=20 --Apple-Mail-48-219189941 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks om_p - see below

On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote:

On Sun, May 8, 2011 at 8:55 AM, JP Vasseur <jpv@cisco.com> wrote:
...

> 4) In the absence of metric container, MRHOF uses ETX as its metric. It
>
>    locally computes the ETX of links to its neighbors and adds this
>    value to their advertised Rank to compute the associated Rank of
>    routes.  Once parent selection and rank computation is performed
>    using the ETX metric, the node advertises a Rank equal to the ETX
>    cost and SHOULD NOT include a metric container in its DIO messages.
>
> JP> You are suggesting here to not use the metric container if the link
> metric in use is
> the ETX and embed it in the rank. Don't you think that this may lead to
> interoperability
> issues ? How do I need when receiving a DIO if the value of the rank
> reflects the ETX or
> some other scalar ? By looking at the OCP, deduct that there is no container
> ? Wouldn't it
> be "cleaner" to simply use of the metric container and use the ETX metric
> defined in
> draft-ietf-roll-metrics ?


It is perfectly fine to use the metric containers if we want to use
the ETX metric. But if there is no metric container, we assume that we
are using the ETX metric. I think your interpretation is slightly
different from what I had in mind so perhaps this warrants rewording
and making it explicit that it is fine to use metric container with
the ETX metric.

If at all possible, I would recommend one way to carry the ETX with the
metric container.

Cheers.

JP.


- om_p


--Apple-Mail-48-219189941-- From Internet-Drafts@ietf.org Mon May 9 09:30:11 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA4E0874; Mon, 9 May 2011 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTERb0abauVa; Mon, 9 May 2011 09:30:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87195E0860; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.86628.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-security-framework-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 16:30:11 -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 : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al Filename : draft-ietf-roll-security-framework-05.txt Pages : 48 Date : 2011-04-24 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-05.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-security-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09092444.I-D@ietf.org> --NextPart-- From gnawali@cs.stanford.edu Mon May 9 09:36:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9371FE090F for ; Mon, 9 May 2011 09:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5hhktjt8AhU for ; Mon, 9 May 2011 09:36:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id E3B26E0882 for ; Mon, 9 May 2011 09:36:28 -0700 (PDT) Received: from mail-pw0-f44.google.com ([209.85.160.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QJTBd-0003GI-Ea for roll@ietf.org; Mon, 09 May 2011 09:19:57 -0700 Received: by pwi5 with SMTP id 5so3273836pwi.31 for ; Mon, 09 May 2011 09:19:57 -0700 (PDT) Received: by 10.68.65.68 with SMTP id v4mr10085582pbs.158.1304957997076; Mon, 09 May 2011 09:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Mon, 9 May 2011 09:19:37 -0700 (PDT) In-Reply-To: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> References: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> From: Omprakash Gnawali Date: Mon, 9 May 2011 09:19:37 -0700 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: ROLL WG Subject: Re: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 16:36:49 -0000 On Mon, May 9, 2011 at 5:25 AM, JP Vasseur wrote: > Thanks om_p - see below > On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote: > > On Sun, May 8, 2011 at 8:55 AM, JP Vasseur wrote: > ... > >> 4)=A0In the absence of metric container, MRHOF uses ETX as its metric. I= t >> >>=A0=A0=A0 locally computes the ETX of links to its neighbors and adds thi= s >>=A0=A0=A0 value to their advertised Rank to compute the associated Rank o= f >>=A0=A0=A0 routes.=A0 Once parent selection and rank computation is perfor= med >>=A0=A0=A0 using the ETX metric, the node advertises a Rank equal to the E= TX >>=A0=A0=A0 cost and SHOULD NOT include a metric container in its DIO messa= ges. >> >> JP>=A0You are suggesting here to not use the metric container if the lin= k >> metric in use is >> the ETX and embed it in the rank. Don't you think that this may lead to >> interoperability >> issues ? How do I need when receiving a DIO if the value of the rank >> reflects the ETX or >> some other scalar ? By looking at the OCP, deduct that there is no >> container >> ? Wouldn't it >> be "cleaner" to simply use of the metric container and use the ETX metri= c >> defined in >> draft-ietf-roll-metrics ? > > > It is perfectly fine to use the metric containers if we want to use > the ETX metric. But if there is no metric container, we assume that we > are using the ETX metric. I think your interpretation is slightly > different from what I had in mind so perhaps this warrants rewording > and making it explicit that it is fine to use metric container with > the ETX metric. > > If at all possible, I would recommend one way to carry the ETX with the > metric container. There was a strong case made for simplification when Rank is an identity function so that we don't have to incur the overhead of metric container for something basic like ETX. Richard Kelsey made this initial comment on this topic: "I would like to be able to use ETX as the rank directly, without the additional overhead of a metric container. It seems silly to send the same value twice, once as the rank and once wrapped in a metric container." There were a few emails discussing this topic after this initial comment. If you have a different opinion on this matter, we can definitely discuss t= hat. - om_p From jpv@cisco.com Mon May 9 14:44:02 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11782E0705 for ; Mon, 9 May 2011 14:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shalwpP8pT3L for ; Mon, 9 May 2011 14:44:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 243FAE08B0 for ; Mon, 9 May 2011 14:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6444; q=dns/txt; s=iport; t=1304977441; x=1306187041; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=2pE3v8IEjuaFMnkGxi/TH/FMgflY4v7VfWSMC13Y2H8=; b=Wgk/sQnpBQcPMC/lCgQuqyeRwi6mwCkNlrerEG5lugqRBuf7UoCaI15t bGwrfrnMEmGsVapWPS7NYIAsQJCFAfLjGyMvSydga2FT7xHX4DmCRr/3U a0G1qKlg7ruxGU+0JJvHINBQ7XIuunxOfZX0+5mSg6r6WzVnfQTEPmd2Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPVfyE2rRDoG/2dsb2JhbACmAXeIcZ8Hni2DDYJ/BIZAiSSEKAmJeVQ X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208,217";a="353508693" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 21:43:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49Lhuc3028147; Mon, 9 May 2011 21:43:56 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 14:43:56 -0700 Received: from [192.168.1.19] ([10.21.82.98]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 14:43:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-56-252551043 From: JP Vasseur In-Reply-To: Date: Mon, 9 May 2011 14:41:05 -0700 Message-Id: References: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 09 May 2011 21:43:55.0701 (UTC) FILETIME=[32315650:01CC0E92] Cc: ROLL WG Subject: Re: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 21:44:02 -0000 --Apple-Mail-56-252551043 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2011, at 9:19 AM, Omprakash Gnawali wrote: > On Mon, May 9, 2011 at 5:25 AM, JP Vasseur wrote: > > Thanks om_p - see below > > On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote: > > > > On Sun, May 8, 2011 at 8:55 AM, JP Vasseur wrote: > > ... > > > >> 4) In the absence of metric container, MRHOF uses ETX as its = metric. It > >> > >> locally computes the ETX of links to its neighbors and adds this > >> value to their advertised Rank to compute the associated Rank of > >> routes. Once parent selection and rank computation is performed > >> using the ETX metric, the node advertises a Rank equal to the = ETX > >> cost and SHOULD NOT include a metric container in its DIO = messages. > >> > >> JP> You are suggesting here to not use the metric container if the = link > >> metric in use is > >> the ETX and embed it in the rank. Don't you think that this may = lead to > >> interoperability > >> issues ? How do I need when receiving a DIO if the value of the = rank > >> reflects the ETX or > >> some other scalar ? By looking at the OCP, deduct that there is no > >> container > >> ? Wouldn't it > >> be "cleaner" to simply use of the metric container and use the ETX = metric > >> defined in > >> draft-ietf-roll-metrics ? > > > > > > It is perfectly fine to use the metric containers if we want to use > > the ETX metric. But if there is no metric container, we assume that = we > > are using the ETX metric. I think your interpretation is slightly > > different from what I had in mind so perhaps this warrants rewording > > and making it explicit that it is fine to use metric container with > > the ETX metric. > > > > If at all possible, I would recommend one way to carry the ETX with = the > > metric container. >=20 > There was a strong case made for simplification when Rank is an > identity function so that we don't have to incur the overhead of > metric container for something basic like ETX. Richard Kelsey made > this initial comment on this topic: >=20 > "I would like to be able to use ETX as the rank directly, > without the additional overhead of a metric container. It > seems silly to send the same value twice, once as the rank > and once wrapped in a metric container." >=20 > There were a few emails discussing this topic after this initial = comment. >=20 > If you have a different opinion on this matter, we can definitely = discuss that. >=20 The question is how to guarantee interop is another routing metrics = wants to adopt the same approach ? Thanks. JP. >=20 > - om_p >=20 --Apple-Mail-56-252551043 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 9, 2011, at 9:19 AM, Omprakash Gnawali wrote:

On Mon, May 9, 2011 at 5:25 AM, JP Vasseur <jpv@cisco.com> wrote:
> Thanks om_p - see below
> On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote:
>
> On Sun, May 8, 2011 at 8:55 AM, JP Vasseur <jpv@cisco.com> wrote:
> ...
>
>> 4) In the absence of metric container, MRHOF uses ETX as its metric. It
>>
>>    locally computes the ETX of links to its neighbors and adds this
>>    value to their advertised Rank to compute the associated Rank of
>>    routes.  Once parent selection and rank computation is performed
>>    using the ETX metric, the node advertises a Rank equal to the ETX
>>    cost and SHOULD NOT include a metric container in its DIO messages.
>>
>> JP> You are suggesting here to not use the metric container if the link
>> metric in use is
>> the ETX and embed it in the rank. Don't you think that this may lead to
>> interoperability
>> issues ? How do I need when receiving a DIO if the value of the rank
>> reflects the ETX or
>> some other scalar ? By looking at the OCP, deduct that there is no
>> container
>> ? Wouldn't it
>> be "cleaner" to simply use of the metric container and use the ETX metric
>> defined in
>> draft-ietf-roll-metrics ?
>
>
> It is perfectly fine to use the metric containers if we want to use
> the ETX metric. But if there is no metric container, we assume that we
> are using the ETX metric. I think your interpretation is slightly
> different from what I had in mind so perhaps this warrants rewording
> and making it explicit that it is fine to use metric container with
> the ETX metric.
>
> If at all possible, I would recommend one way to carry the ETX with the
> metric container.

There was a strong case made for simplification when Rank is an
identity function so that we don't have to incur the overhead of
metric container for something basic like ETX. Richard Kelsey made
this initial comment on this topic:

"I would like to be able to use ETX as the rank directly,
without the additional overhead of a metric container.  It
seems silly to send the same value twice, once as the rank
and once wrapped in a metric container."

There were a few emails discussing this topic after this initial comment.

If you have a different opinion on this matter, we can definitely discuss that.

The question is how to guarantee interop is another routing metrics wants to adopt
the same approach ?

Thanks.

JP.


- om_p


--Apple-Mail-56-252551043-- From gnawali@cs.stanford.edu Mon May 9 16:23:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C3E06E1 for ; Mon, 9 May 2011 16:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozSxwaqAkvf3 for ; Mon, 9 May 2011 16:23:36 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id EBA73E069E for ; Mon, 9 May 2011 16:23:36 -0700 (PDT) Received: from mail-px0-f179.google.com ([209.85.212.179]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QJZnb-0005GZ-Ux for roll@ietf.org; Mon, 09 May 2011 16:23:36 -0700 Received: by pxi2 with SMTP id 2so3522860pxi.38 for ; Mon, 09 May 2011 16:23:35 -0700 (PDT) Received: by 10.68.35.135 with SMTP id h7mr9632176pbj.493.1304983415377; Mon, 09 May 2011 16:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Mon, 9 May 2011 16:23:14 -0700 (PDT) In-Reply-To: References: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> From: Omprakash Gnawali Date: Mon, 9 May 2011 16:23:14 -0700 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: a2fe995cb7ed4309b2d212c2bd713a7d Cc: ROLL WG Subject: Re: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 May 2011 23:23:38 -0000 On Mon, May 9, 2011 at 2:41 PM, JP Vasseur wrote: > > On May 9, 2011, at 9:19 AM, Omprakash Gnawali wrote: > > On Mon, May 9, 2011 at 5:25 AM, JP Vasseur wrote: >> Thanks om_p - see below >> On May 8, 2011, at 9:47 PM, Omprakash Gnawali wrote: >> >> On Sun, May 8, 2011 at 8:55 AM, JP Vasseur wrote: >> ... >> >>> 4)=A0In the absence of metric container, MRHOF uses ETX as its metric. = It >>> >>>=A0=A0=A0 locally computes the ETX of links to its neighbors and adds th= is >>>=A0=A0=A0 value to their advertised Rank to compute the associated Rank = of >>>=A0=A0=A0 routes.=A0 Once parent selection and rank computation is perfo= rmed >>>=A0=A0=A0 using the ETX metric, the node advertises a Rank equal to the = ETX >>>=A0=A0=A0 cost and SHOULD NOT include a metric container in its DIO mess= ages. >>> >>> JP>=A0You are suggesting here to not use the metric container if the li= nk >>> metric in use is >>> the ETX and embed it in the rank. Don't you think that this may lead to >>> interoperability >>> issues ? How do I need when receiving a DIO if the value of the rank >>> reflects the ETX or >>> some other scalar ? By looking at the OCP, deduct that there is no >>> container >>> ? Wouldn't it >>> be "cleaner" to simply use of the metric container and use the ETX metr= ic >>> defined in >>> draft-ietf-roll-metrics ? >> >> >> It is perfectly fine to use the metric containers if we want to use >> the ETX metric. But if there is no metric container, we assume that we >> are using the ETX metric. I think your interpretation is slightly >> different from what I had in mind so perhaps this warrants rewording >> and making it explicit that it is fine to use metric container with >> the ETX metric. >> >> If at all possible, I would recommend one way to carry the ETX with the >> metric container. > > There was a strong case made for simplification when Rank is an > identity function so that we don't have to incur the overhead of > metric container for something basic like ETX. Richard Kelsey made > this initial comment on this topic: > > "I would like to be able to use ETX as the rank directly, > without the additional overhead of a metric container.=A0 It > seems silly to send the same value twice, once as the rank > and once wrapped in a metric container." > > There were a few emails discussing this topic after this initial comment. > > If you have a different opinion on this matter, we can definitely discuss > that. > > The question is how to guarantee interop is another routing metrics wants= to > adopt > the same approach ? I think there are three cases here: 1. etx-no-container and etx-no-container That is not a problem because both the networks are using etx metric without the metric container. 2. etx-container and etx-container That is not a problem because both the networks are using the etx metric with the metric container. 3. etx-container and etx-no-container This is a problem because one network uses the etx metric with the container and another uses the etx metric without the container. I believe you are concerned about the third case. One way to make these networks inter-operate is by saying if you want to use the etx metric, you never use it inside a container. You use it as rank directly. Other ideas are welcome. - om_p From phoebus@ieee.org Tue May 10 09:45:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0CE076D for ; Tue, 10 May 2011 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.649 X-Spam-Level: X-Spam-Status: No, score=-107.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIeCERDROVXW for ; Tue, 10 May 2011 09:45:34 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7F05CE0856 for ; Tue, 10 May 2011 09:45:33 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 49F25155860; Tue, 10 May 2011 15:12:32 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id gS9dc9MabFsu; Tue, 10 May 2011 15:12:29 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-10.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id C1CE8156B26; Tue, 10 May 2011 15:12:27 +0200 (CEST) Message-ID: <4DC939BB.50406@ieee.org> Date: Tue, 10 May 2011 15:12:27 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 16:45:36 -0000 Pascal, You covered most of the points. I. Regarding the point I made below (reformatted for easy reading): ... PC> Maybe the overview in Section 3 should also state explicitly that PC> the processing rules of a DIO must do 3.1, then 3.2, then 3.3, in PC> that order. PT> Yes, and this is what we mean by PT> " As it scans all the candidate neighbors, OF0 keeps the parent PT> that is the best for the following criteria (in order):" PT> the language may not be perfect but I hardly think the reader can be PT> getting the text wrong. PT> I'm open to an editorial change if the sense is conserved. > PC> I think the text you quoted above is very clear, but given its > PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or > PC> Section 3.2.1 of the suggested new order), it applies to > PC> parent selection. I'm saying there should be a sentence in the new > PC> Section 3 (overview) saying that we first compute > PC> Rank-Increase (Sec. 3.1), then select the preferred parent > PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then > PC> advertise Rank-Increase (Sec. 3.3). ... I think you made edits with regard to your initial interpretation of my comment. I did NOT want you change the sentence in Section 4.2.1, and actually, I liked the original wording of "As it scans ..." in draft-ietf-roll-of0-10 better. I was suggesting a sentence in what is now Section 4, before Section 4.1, stating the steps in the subsections MUST be executed in that order. It looks like there is nothing written about advertising the rank (a Section 4.3). I guess that's OK if you feel there is nothing to say. I would have preferred a short paragraph there for completeness. It might just restate the obvious, that advertisements are triggered by the Trickle timer or changes in the rank after it is recomputed. II. Regarding this point I made below: >> PC> On a related note, there's a recent discussion of using the ETX >> PC> directly (identity) as the rank, which doesn't match this >> PC> requirement that step_of_rank be a multiple of 0x100 in OF0. In >> PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a >> PC> multiple of 128, not 256 (0x100). >> PC> >> PC> Is it actually necessary to mention "rank-increase" in the >> PC> introduction, before the terminology section? Can we remove >> "The Rank >> of a node is obtained by adding a normalized scalar Rank-increase > to >> the Rank of a selected preferred parent. OF0 uses a unit of Rank- >> increase of 0x100 so that Rank value can be stored in one octet. >> This allows up to at least 28 hops even when default settings are >> used and each hop has the worst Rank-increase of 9." >> PC> Or move it some point later? It may be a bit confusing to bring > up >> PC> so much detail at this point in the text. I think JP's comments about pointing out where many of the variables are defined can be handled by not going into so much detail in the introduction, and stating the details later. III. I presume you will still add Configuration Options for the configurable parameters in 6.2? IV. As for any remaining comments I have after rereading the document, they are about how to present and explain OF0. Since I get the sense that there is some urgency to publish OF0, you can incorporate them if you have time - these comments shouldn't "hold the document hostage." A few points in addition to JP's comments: 0) I've had trouble understanding the consensus of the discussion on the mailing list on OF0 not being the default objective function. The last paragraph of Section 1 still doesn't make it clear to me. As far as I understand, OF0 is the default objective function when no objective function is specified - if an implementation does not support another objective function, it must support OF0. This is the definition of "default," right? If not, someone please define "default" to me... I must be missing something. I would be glad to propose shorter text if I understood the consensus. " Since there is no default OF or metric container in the RPL main specification, it might happen that, unless two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate. OF0 is designed to be common to all implementations that are not specifically designed to apply to a given case for which further guidance is provided. This is why it is very abstract as to how the link properties are transformed into a rank_increase and leaves that responsibility to implementation; rather, OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range, as opposed to formulating the details of its computation. This is also why OF0 ignores metric containers. " 1) You might consider adding a clarification to Section 4 is how the objective function is "triggered," when it enters the process of computing the rank, checking whether to change parents and successors, and readvertising the rank. I believe there are at least 2 entry points: 1) DIO processing 2) change in "step_of_rank", which is implementation dependent and may come from layer 2. The latter should be mentioned explicitly... it's only mentioned at the end of Section 3 in the last sentence. I'm not sure if the objective function code is triggered by other timer expirations, like when information becomes stale. Anyhow, it's your call if this is too much detail and should be left to the implementers to figure out on their own. 2) I think that the paragraph at the end of Section 3: " OF0 assigns a step_of_rank to each link to another node that it monitors. The exact method for computing the step_of_rank is implementation-dependent. " belongs somewhere in Section 4.1, maybe after the sentence: "An implementation MUST maintain the stretched step_of_rank between MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to reflect a large variation of link quality." 3) Search and replace all "rank-increase" with "rank_increase" for consistency. Search and replace "Rank-factor" with "rank_factor." Is there a convention of writing names for distinguishing variables from configurable parameters? I'm assuming that "lowercase with underscores" (e.g., rank_factor) can be used interchangeably with "a mix of capital letters and lowercase letters with no underscores" (e.g., MinHopRankIncrease). Do we care to distinguish the two, say using "a mix of capital letters and lowercase letters with no underscores" for parameters and "lowercase with underscores" for variables? 4) Typo, extra word "as": "One trivial OF0 implementation might compute the step_of_rank from as a classical administrative..." 5) Rewrite the equation: R(N) = R(P) + Ri where Ri = (Rf*Sp + Sr) * MinHopRankIncrease as R(N) = R(P) + rank_increase where rank_increase = (rank_factor * step_of_rank + stretch_of_rank) * MinHopRankIncrease So we have less new variables (Ri, Rf, Sp, Sr). 6) Defining the terms "higher order interface" and "RPL Core" in the ROLL terminology document. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 5/5/11 6:07 PM, Pascal Thubert (pthubert) wrote: > Hi Phoebus: > > I made editorial changes to follow your late but welcome advice, and > published a OF0-11. > > Please let me know if I covered your points as expected. > > Cheers, > > Pascal > http://www.xtranormal.com/watch/7011357/ > >> -----Original Message----- >> From: Phoebus Chen [mailto:phoebus@ieee.org] >> Sent: Thursday, April 21, 2011 4:56 PM >> To: Pascal Thubert (pthubert) >> Cc: roll@ietf.org >> Subject: Re: OF0 draft v9: preferred metric, Stretch-of-Rank, > configuring >> parameters, and editorial comments >> >> Pascal, >> >> Thanks for your responses. I've replied inline below, preceded > by >> PC>. >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> >> >> On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote: >>> Hello Phoebus : ) >>> >>> Where have you been? We've been missing your excellent comments. >>> >>>> Sorry these comments are coming so late, after last call. I >>> hope you >>>> can at least incorporate some of them. >>> >>> [Pascal] That's beyond me. I suppose that the shepherd has to > decide. >>> Let's see: >>> >>> >>>> >>>> My comments below are based on my current understanding that >>>> Phil and you are no longer using hop-count as the rank increment. >>> Instead, >>>> each node will have an implementation specific way of converting a >>> node or >>>> link cost to a rank. I'm still unclear if there is a preference > rule >>> to try to stick >>>> with using the same metrics as the metrics advertised in a received >>> DIO, if >>>> the current node has access to multiple types of metrics (energy, > LQI, >>> ETX, >>>> etc.). That would allow the root node to specify a preferred type > of >>> metric to >>>> use in the instance. >>>> >>>> >>>> Major Points: >>>> ************* >>>> 1) I'm still hoping that the format for writing Objective Function >>> specifications >>>> can be more uniform, as I mentioned in an earlier comment (point >>> number 7 >>>> in > http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). >>>> Comparing MRHOF and OF0, I think that the discussion on > Step-of-Rank / >>>> Stretch-of-Rank etc. can be moved to it's own subsection. >>>> >>>> I suggest the following reorganization of sections: >>>> >>>> 3. Objective Function 0 >>>> 3.1. Computing Rank-increase >>>> 3.2. Parent / Backup Successor Selection >>>> 3.2.1. Selection of the Preferred Parent >>>> 3.2.2. Selection of the backup feasible successor >>>> 3.3. Advertising Rank-increase >>>> 4. Interface with RPL core >>>> >>> [Pascal] Looks good. That much is doc organization and I suppose I > can >>> accommodate it at this stage. >>> It would certainly be beneficial if both OF drafts have a common >>> structure. >>> >>>> If you are allowing the root to specified a preferred metric type, >>> then Section >>>> 3.3. should state how to propagate this preference. I would have >>> assumed >>>> it's by propagating an empty DAG/Metric Container, but in (Section >>> 2.1, draft- >>>> ietf-roll-routing-metrics-19) it says "The object body carries one > or >>> more sub- >>>> objects defined later in this document" >>>> which means you cannot have empty containers. >>> >>> [Pascal] OF0 does not have metric containers at all, so they do not > need >>> to be empty. That's because OF0 is generic, for the better or the > worse. >>> Because we want all implementations to interop with OF0, regardless > of >>> the medium etc... >>> >>> So the idea is to have no constraint on what the implementation uses > to >>> derive the Rank, no container, no configuration option, just the > base >>> RPL spec. >>> >>> Rather, we normalize the resulting values so they can compare > between >>> implementations. >> >> PC> OK. I thought allowing the root to specify a preferred metric > would >> PC> be nice, but I see that it's not necessary for basic operations. >> >>> >>> Now, I understand that a configuration container could help make the > OF >>> more self-contained/autonomic. >>> >>>> Maybe the overview in Section 3 should also state explicitly that > the >>>> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that >>> order. >>> >>> [Pascal] Yes, and this is what we mean by >>> " As it scans all the candidate neighbors, OF0 keeps the parent > that >>> is >>> the best for the following criteria (in order):" >>> the language may not be perfect but I hardly think the reader can be >>> getting the text wrong. >>> I'm open to an editorial change if the sense is conserved. >>> >> >> PC> I think the text you quoted above is very clear, but given its >> PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or >> PC> Section 3.2.1 of the suggested new order), it applies to >> PC> parent selection. I'm saying there should be a sentence in the new >> PC> Section 3 (overview) saying that we first compute >> PC> Rank-Increase (Sec. 3.1), then select the preferred parent >> PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then >> PC> advertise Rank-Increase (Sec. 3.3). >> PC> >> PC> Maybe this is obvious, but I think it helps to state it > explicitly. >> PC> Especially since the guidelines given in >> PC> (Section 14.1, draft-ietf-roll-rpl-19) are suggestions, >> PC> rather than MUSTs: >> PC> "Most Objective Functions are expected to follow..." >> PC> And these suggestions don't say the steps must be followed in >> PC> order either. >> >>>> >>>> >>>> 2) There have been two variables and one parameter defined in the >>>> overview section, but they are not mentioned in Section 7, OF0 >>> Constants >>>> and Variables. >>>> Variables: Step-of-Rank, Stretch-of-Rank >>>> Parameters: Rank-factor >>>> (I noticed that there is no MINIMUM_RANK_STRETCH and >>>> DEFAULT_RANK_STRETCH and presume this is intentional.) >>>> >>> [Pascal] You're right. A stretch of 0 is acceptable so there is no >>> MINIMUM. >>> If there was a DEFAULT I expect it should be zero as well. By >>> compliance with the main spec. >>> I'm fine adding it. What do you think? >>> >> >> PC> That would be nice for clarity. I think most implementors will >> PC> use default values in a spec without a second thought unless they >> PC> have a strong reason to do otherwise. >> >>>> Also, it would be nice to use underscore instead of hyphen for >>>> variables, like in MRHOF (and use capital letters for parameters). >>>> >>> [Pascal] OK. I did not really mean those as variables, but why not. >>> >>>> Finally, how is Stretch-of-Rank computed? Implementation > dependent? >>> >>> [Pascal] It is not computed. It is configured and can be left to 0. > Does >>> not have to be there at all in an implementation. >>> I can clarify that. >>> >> >> PC> OK. >> >>>> 3) How does one configure the parameter(s) (Rank-Factor) from the >>> root? >>>> (I just realized that this same comment applies to the > parameters in >>>> MRHOF as well). Or is that not configurable from the root, but > must >>> be >>>> configured before deployment of the nodes? >>> >>> [Pascal] The Rank factor has to be a per node policy, like the >>> Stretch-of-Rank. Right now, we do not have config containers to >>> distribute it. >>> >>> >>>> >>>> 4) I think it would be nice to adopt the format of >>>> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of > for >>> the >>>> Terminology section. That is, write the word, then the definition >>> (this >>>> is not done for "feasible successor" in this section). Some other >>> words >>>> to define in this section are "Rank-increase," "RPL core," and > "higher >>>> order interface." Unless the last one is common IPv6 terminology > that >>> I >>>> am unaware of... I was unable to tell if that meant the higher > order >>>> bits of the interface are higher, or if the interface is somehow >>> preferred. >>> >>> I think that the RPL terminology is the place for having those in >>> common. >> >> PC> Do you mean you or JP will add those terms and definitions to >> PC> (draft-ietf-roll-terminology-05) or >> PC> (Section 2, draft-ietf-roll-rpl-19)? I think the definition of >> PC> "Rank-increase" belongs in OF0. >> >>> >>>> >>>> 5) Just a reminder that the discussion on Rank-increase in the >>>> introduction section >>>> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can > be >>>> stored in one octet." >>>> needs to be aligned with text in Section 3, >>>> "Ri = Rf*Sp + Sr" >>>> so that they are consistent. I see you are discussing this with >>> Omprakash. >>> >>> Sp and Sr are expressed as units of 0x100 and Rf is integer, so they > are >>> consistent. Do I miss something? >>> >> >> PC> I see. I didn't realize that step_of_rank had to be a multiple of >> PC> 0x100. You only mention at the bottom of page 3 that "The exact >> PC> method for computing the Step-of-Rank is implementation-dependent" >> PC> and give bounds MINIMUM_STEP_OF_RANK and >> MAXIMUM_STEP_OF_RANK >> PC> that are multiples of MinHopRankIncrease. >> PC> >> PC> On a related note, there's a recent discussion of using the ETX >> PC> directly (identity) as the rank, which doesn't match this >> PC> requirement that step_of_rank be a multiple of 0x100 in OF0. In >> PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a >> PC> multiple of 128, not 256 (0x100). >> PC> >> PC> Is it actually necessary to mention "rank-increase" in the >> PC> introduction, before the terminology section? Can we remove >> "The Rank >> of a node is obtained by adding a normalized scalar Rank-increase > to >> the Rank of a selected preferred parent. OF0 uses a unit of Rank- >> increase of 0x100 so that Rank value can be stored in one octet. >> This allows up to at least 28 hops even when default settings are >> used and each hop has the worst Rank-increase of 9." >> PC> Or move it some point later? It may be a bit confusing to bring > up >> PC> so much detail at this point in the text. >> >>>> >>>> 6) I like the "Abstract Interface with RPL core" section, but would > it >>>> be better to separate them into "Input" and "Output"? That would > end >>> up >>>> splitting up "Providing DAG information" and "Providing a Parent > List" >>>> into two pieces though. >>>> >>>> >>>> More minor editorial comments to follow below, preceded by PC>. >>> >>> Thanks for those. I'll include them in a rev. >>> >>>> >>>> -- >>>> Phoebus Chen >>>> Postdoctoral Researcher >>>> Automatic Control Lab, KTH (Royal Institute of Technology) >>>> http://www.ee.kth.se/~phoebus >>>> >>>> From phoebus@ieee.org Thu May 12 05:38:19 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9219E067A for ; Thu, 12 May 2011 05:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPVTVRDmhTzI for ; Thu, 12 May 2011 05:38:15 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1B528E0670 for ; Thu, 12 May 2011 05:38:14 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 75166156B7E; Thu, 12 May 2011 14:37:43 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id mn-KPh6DHRZw; Thu, 12 May 2011 14:37:18 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-10.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 5170B156B7C; Thu, 12 May 2011 14:36:53 +0200 (CEST) Message-ID: <4DCBD465.7040709@ieee.org> Date: Thu, 12 May 2011 14:36:53 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Omprakash Gnawali , "roll@ietf.org" References: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> In-Reply-To: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] draft-ietf-roll-minrank-hysteresis-of-03: editorial comments to metric maximization section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 12:38:19 -0000 Omprakash, I like the changes you made to the document. (Background: discussion leading to "4. Using MRHOF for Metric Maximization") http://www.ietf.org/mail-archive/web/roll/current/msg06066.html May I suggest alternate wording to the following text in Section 4: There is a fixed and well-known maximum metric value corresponding to the best path. This is the path cost for the DAG root. Example, the best link reliability has a value of 1. Metrics are all positive. Example, link reliability is always positive. Change to: There is a fixed and well-known maximum metric value corresponding to the best path. This is the path cost for the DAG root. For example, the logarithm of the best link reliability has a value of 0. The metrics in the maximization problem are all negative. For example, the logarithm of the link reliability is always negative. In the original text, the metrics are positive in the original maximization problem where we multiply the reliabilities, but the reader may not be thinking in that context since everything in the MRHOF document refers to additive metrics. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus P.S. while you're at it, I suggest this change to the last line of the abstract: s/determined by the metrics RPL Destination Information Object (DIO) messages advertise./determined by the metrics advertised by the RPL Destination Information Object (DIO) messages./ On 5/4/11 1:00 AM, 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 : The Minimum Rank Objective Function with Hysteresis > Author(s) : O. Gnawali, P. Levis > Filename : draft-ietf-roll-minrank-hysteresis-of-03.txt > Pages : 10 > Date : 2011-05-03 > > The Routing Protocol for Low Power and Lossy Networks (RPL) uses > objective functions to construct routes that optimize or constrain > the routes it selects and uses. This specification describes the > Minimum Rank Objective Function with Hysteresis (MRHOF), an objective > function that selects routes that minimize a metric, while using > hysteresis to reduce churn in response to small metric changes. > MRHOF works with metrics that are additive along a route, and the > metric it uses is determined by the metrics RPL Destination > Information Object (DIO) messages advertise. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-03.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 gnawali@cs.stanford.edu Thu May 12 09:13:40 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3602CE068E for ; Thu, 12 May 2011 09:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWcBnAaPEDsh for ; Thu, 12 May 2011 09:13:37 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 42E76E067A for ; Thu, 12 May 2011 09:13:37 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QKYW5-0000DD-Hq for roll@ietf.org; Thu, 12 May 2011 09:13:36 -0700 Received: by pvh1 with SMTP id 1so1031240pvh.31 for ; Thu, 12 May 2011 09:13:33 -0700 (PDT) Received: by 10.68.50.9 with SMTP id y9mr578326pbn.24.1305216813133; Thu, 12 May 2011 09:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Thu, 12 May 2011 09:13:13 -0700 (PDT) In-Reply-To: <4DCBD465.7040709@ieee.org> References: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> <4DCBD465.7040709@ieee.org> From: Omprakash Gnawali Date: Thu, 12 May 2011 09:13:13 -0700 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: "roll@ietf.org" Subject: Re: [Roll] draft-ietf-roll-minrank-hysteresis-of-03: editorial comments to metric maximization section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2011 16:13:40 -0000 On Thu, May 12, 2011 at 5:36 AM, Phoebus Chen wrote: > Omprakash, > > I like the changes you made to the document. > > > (Background: discussion leading to "4. Using MRHOF for Metric Maximizatio= n") > http://www.ietf.org/mail-archive/web/roll/current/msg06066.html > > May I suggest alternate wording to the following text in Section 4: > > =A0 =A0 =A0There is a fixed and well-known maximum metric value correspon= ding > =A0 =A0 =A0to the best path. =A0This is the path cost for the DAG root. > =A0 =A0 =A0Example, the best link reliability has a value of 1. > > =A0 =A0 =A0Metrics are all positive. =A0Example, link reliability is alwa= ys > =A0 =A0 =A0positive. > > Change to: > > =A0 =A0 =A0There is a fixed and well-known maximum metric value correspon= ding > =A0 =A0 =A0to the best path. =A0This is the path cost for the DAG root. > =A0 =A0 =A0For example, the logarithm of the best link reliability has a > =A0 =A0 =A0value of 0. > > =A0 =A0 =A0The metrics in the maximization problem are all negative. > =A0 =A0 =A0For example, the logarithm of the link reliability is always > =A0 =A0 =A0negative. > > > In the original text, the metrics are positive in the original maximizati= on > problem where we multiply the reliabilities, but the reader may not be > thinking in that context since everything in the MRHOF document refers to > additive metrics. I think you are pointing out a different generality of this MRHOF. I can change the title of this sub section to address both maximization and multiplicative metrics. The text for maximization can remain as it is. I can add a sentence at the end of that subsection saying we can use MRHOF with some multiplicative metrics by converting them to the additive version of that metric by taking their log. Does that satisfy your concern? - om_p From pal@cs.stanford.edu Thu May 12 09:54:41 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39082E06C3 for ; Thu, 12 May 2011 09:54:41 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwWoBf3APmzs for ; Thu, 12 May 2011 09:54:40 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB26AE069E for ; Thu, 12 May 2011 09:54:40 -0700 (PDT) Received: from dn0a21014c.sunet ([10.33.1.76]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QKZ9s-0007mP-KF; Thu, 12 May 2011 09:54:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 12 May 2011 08:53:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6B73F13A-CFCD-4DAE-8D65-B4373FF64256@cs.stanford.edu> References: <81DD6923-D3E7-4D9C-B015-5CE0C48DB9D5@cisco.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 Cc: ROLL WG Subject: Re: [Roll] MRHOF comments from JP - Using ETX without metric container X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2011 16:54:41 -0000 On May 9, 2011, at 4:23 PM, Omprakash Gnawali wrote: > > 3. etx-container and etx-no-container > > This is a problem because one network uses the etx metric with the > container and another uses the etx metric without the container. > > I believe you are concerned about the third case. > > One way to make these networks inter-operate is by saying if you want > to use the etx metric, you never use it inside a container. You use it > as rank directly. > > Other ideas are welcome. This makes the most sense to me. Phil From phoebus@ieee.org Thu May 12 10:26:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7EAE0798 for ; Thu, 12 May 2011 10:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXLcib4AZ5ZB for ; Thu, 12 May 2011 10:26:30 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by ietfa.amsl.com (Postfix) with ESMTP id 05EDAE078B for ; Thu, 12 May 2011 10:26:30 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id DE53D156B3A; Thu, 12 May 2011 19:25:58 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id pxL-xAxRqLmS; Thu, 12 May 2011 19:25:57 +0200 (CEST) X-KTH-Auth: phoebus [83.145.36.89] X-KTH-mail-from: phoebus@ieee.org Received: from catch-all.priv (swgc.sizeit.se [83.145.36.89]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 125B01563BD; Thu, 12 May 2011 19:25:55 +0200 (CEST) Message-ID: <4DCC1823.3070402@ieee.org> Date: Thu, 12 May 2011 19:25:55 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Omprakash Gnawali References: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> <4DCBD465.7040709@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] draft-ietf-roll-minrank-hysteresis-of-03: editorial comments to metric maximization section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 17:26:31 -0000 Response inline below. On 5/12/11 6:13 PM, Omprakash Gnawali wrote: > On Thu, May 12, 2011 at 5:36 AM, Phoebus Chen wrote: >> Omprakash, >> >> I like the changes you made to the document. >> >> >> (Background: discussion leading to "4. Using MRHOF for Metric Maximization") >> http://www.ietf.org/mail-archive/web/roll/current/msg06066.html >> >> May I suggest alternate wording to the following text in Section 4: >> >> There is a fixed and well-known maximum metric value corresponding >> to the best path. This is the path cost for the DAG root. >> Example, the best link reliability has a value of 1. >> >> Metrics are all positive. Example, link reliability is always >> positive. >> >> Change to: >> >> There is a fixed and well-known maximum metric value corresponding >> to the best path. This is the path cost for the DAG root. >> For example, the logarithm of the best link reliability has a >> value of 0. >> >> The metrics in the maximization problem are all negative. >> For example, the logarithm of the link reliability is always >> negative. >> >> >> In the original text, the metrics are positive in the original maximization >> problem where we multiply the reliabilities, but the reader may not be >> thinking in that context since everything in the MRHOF document refers to >> additive metrics. > > I think you are pointing out a different generality of this MRHOF. I > can change the title of this sub section to address both maximization > and multiplicative metrics. The text for maximization can remain as it > is. I can add a sentence at the end of that subsection saying we can > use MRHOF with some multiplicative metrics by converting them to the > additive version of that metric by taking their log. Does that satisfy > your concern? I'm still hesitant about the sentence "Metrics are all positive" in the context of the surrounding text. Even when I first read it, my first reaction was "Maximization with positive metrics? Just make your path as long as possible to add all the links. Why would there be a maximum?" Of course, this is because most of the document up to this point only refers to additive metrics and there isn't a clarification that the original optimization problem in the example was that of maximizing the product (where all link metrics are between 0 and 1), not the sum. It's important here that the link metrics are less than 1 so that log(reliability) is negative. You can say that this is implicit from the condition that there is a maximum path metric, but I think we should save the reader a littler thinking here and just state it. My suggestion is to only address maximization problems using additive metrics, and use the example of log(reliability) to indicate how one type of maximization problem with multiplicative metrics can be converted to one with additive metrics. The MRHOF document has been talking only about additive metrics thus far anyways, so I don't think we're restricting ourselves too much here. I know, I was arguing for more generality (include maximization!) and now I'm asking you to restrict it. I would have made a more clear recommendation in the beginning if I had thought it through a bit more. ;) > > - om_p -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pal@cs.stanford.edu Thu May 12 10:59:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97453130015 for ; Thu, 12 May 2011 10:59: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwrcWH9XKrlE for ; Thu, 12 May 2011 10:59:02 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id C080613000E for ; Thu, 12 May 2011 10:59:02 -0700 (PDT) Received: from dn0a21014c.sunet ([10.33.1.76]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QKaA9-0002yX-WF; Thu, 12 May 2011 10:59:02 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4DCC1823.3070402@ieee.org> Date: Thu, 12 May 2011 10:59:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110503230001.4944.40193.idtracker@ietfa.amsl.com> <4DCBD465.7040709@ieee.org> <4DCC1823.3070402@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 6c66c47a22907c63296a3ecdec1f9d62 Cc: "roll@ietf.org" Subject: Re: [Roll] draft-ietf-roll-minrank-hysteresis-of-03: editorial comments to metric maximization section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2011 17:59:03 -0000 On May 12, 2011, at 10:25 AM, Phoebus Chen wrote: > Response inline below. >=20 > On 5/12/11 6:13 PM, Omprakash Gnawali wrote: >> On Thu, May 12, 2011 at 5:36 AM, Phoebus Chen = wrote: >>> Omprakash, >>>=20 >>> I like the changes you made to the document. >>>=20 >>>=20 >>> (Background: discussion leading to "4. Using MRHOF for Metric = Maximization") >>> http://www.ietf.org/mail-archive/web/roll/current/msg06066.html >>>=20 >>> May I suggest alternate wording to the following text in Section 4: >>>=20 >>> There is a fixed and well-known maximum metric value = corresponding >>> to the best path. This is the path cost for the DAG root. >>> Example, the best link reliability has a value of 1. >>>=20 >>> Metrics are all positive. Example, link reliability is always >>> positive. >>>=20 >>> Change to: >>>=20 >>> There is a fixed and well-known maximum metric value = corresponding >>> to the best path. This is the path cost for the DAG root. >>> For example, the logarithm of the best link reliability has a >>> value of 0. >>>=20 >>> The metrics in the maximization problem are all negative. >>> For example, the logarithm of the link reliability is always >>> negative. >>>=20 >>>=20 >>> In the original text, the metrics are positive in the original = maximization >>> problem where we multiply the reliabilities, but the reader may not = be >>> thinking in that context since everything in the MRHOF document = refers to >>> additive metrics. >>=20 >> I think you are pointing out a different generality of this MRHOF. I >> can change the title of this sub section to address both maximization >> and multiplicative metrics. The text for maximization can remain as = it >> is. I can add a sentence at the end of that subsection saying we can >> use MRHOF with some multiplicative metrics by converting them to the >> additive version of that metric by taking their log. Does that = satisfy >> your concern? >=20 > I'm still hesitant about the sentence "Metrics are all positive" in = the context of the surrounding text. Even when I first read it, my = first reaction was "Maximization with positive metrics? Just make your = path as long as possible to add all the links. Why would there be a = maximum?" Of course, this is because most of the document up to this = point only refers to additive metrics and there isn't a clarification = that the original optimization problem in the example was that of = maximizing the product (where all link metrics are between 0 and 1), not = the sum. It's important here that the link metrics are less than 1 so = that log(reliability) is negative. You can say that this is implicit = from the condition that there is a maximum path metric, but I think we = should save the reader a littler thinking here and just state it. >=20 > My suggestion is to only address maximization problems using additive = metrics, and use the example of log(reliability) to indicate how one = type of maximization problem with multiplicative metrics can be = converted to one with additive metrics. The MRHOF document has been = talking only about additive metrics thus far anyways, so I don't think = we're restricting ourselves too much here. >=20 > I know, I was arguing for more generality (include maximization!) and = now I'm asking you to restrict it. I would have made a more clear = recommendation in the beginning if I had thought it through a bit more. = ;) Phoebus, we're well past last call now. If your = recommendations/suggestions are oscillating I'm not sure it's a good = idea to incorporate them at such a late point. We want to be converging = not spinning. Phil From yanjun@ti.com Thu May 12 11:25:52 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F618E06A1 for ; Thu, 12 May 2011 11:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2hL0nBY4-rd for ; Thu, 12 May 2011 11:25:50 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4E347E062A for ; Thu, 12 May 2011 11:25:49 -0700 (PDT) Received: from dlep33.itg.ti.com ([157.170.170.112]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id p4CIPnYE006989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2011 13:25:49 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep33.itg.ti.com (8.13.7/8.13.7) with ESMTP id p4CIPnUo021522 for ; Thu, 12 May 2011 13:25:49 -0500 (CDT) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p4CIPmNi004671 for ; Thu, 12 May 2011 13:25:49 -0500 (CDT) Received: from dlee04.ent.ti.com ([157.170.170.9]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Thu, 12 May 2011 13:25:48 -0500 From: "Sun, Yanjun" To: "roll@ietf.org" Date: Thu, 12 May 2011 13:25:47 -0500 Thread-Topic: On how to configure/run RPL on nodes with two interfaces Thread-Index: AcwQ0gOkk6+yLqPXSaO+cV+1RjSaYg== Message-ID: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2C1563023E232C49B9F505633D57C2DA272075B026dlee04enttico_" MIME-Version: 1.0 Subject: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2011 18:25:52 -0000 --_000_2C1563023E232C49B9F505633D57C2DA272075B026dlee04enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I'm new to this mailing list. I'm trying to figure out how to configure/run= RPL on a node with two interfaces. Following the rules of RPL, I came up w= ith several configurations even for a simple two node network below. Could = you please comment on whether they make sense and whether there is any bett= er alternative? As most discussion in RPL is focused on nodes with single i= nterface (though I strongly believe it'll work well for multiple interfaces= ), the configuration really puzzled me. So I would appreciate if anyone cou= ld help me out. I'd like to use a very simple network to describe my questions. Node 1 is = the root and node 2 is a leaf. Both nodes have two wired interfaces. A1 is = connected to A2 and B1 is connected to B2. we'd like to find out what's the= best way to configure RPL for such a network to forward packets on both li= nks. +-------------+ | Root | | | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ I could think of two possible configurations. In the first RPL configuratio= n, I let node 1 use only *one* instance, INST1. One DIO message with A1 as = DODAGID will be broadcast over both interfaces A1 and B1. Then another mess= age with B1 as DODAGID will be also broadcast over both interfaces. Based o= n the RPL draft that limits a node to join only one DODAG given an instance= ID, node 2 can only choose one link to join node 1 and leave the other lin= k *unused*. In the second configuration, I let node 1 to use *two* instances, INST1 and= INST2. One DIO message with A1 as DODAGID and INST1 will be broadcast over= both interfaces A1 and B1. Then another message with B1 as DODAGID and INS= T2 will be also broadcast over both interfaces. Some Objective Functions ma= y allow us to forward packets on both links now. But the control becomes ha= rd when the network has multiple hops. Ideally, I prefer node 2 to dynamica= lly choose a link because link qualities could change over time quickly. Any comment or suggestion would be appreciated and thank you for your time, Yanjun -- Yanjun Sun Systems and Applications R&D Center Texas Instruments, Inc, USA --_000_2C1563023E232C49B9F505633D57C2DA272075B026dlee04enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I’m new to this mailing list. I’m trying to figure out how= to configure/run RPL on a node with two interfaces. Following the rules of= RPL, I came up with several configurations even for a simple two node netw= ork below. Could you please comment on whether they make sense and whether there is any better alternative? As most discus= sion in RPL is focused on nodes with single interface (though I strongly be= lieve it’ll work well for multiple interfaces), the configuration rea= lly puzzled me. So I would appreciate if anyone could help me out.
 
I’d like to use a very simple network to describe my questions.&= nbsp; Node 1 is the root and node 2 is a leaf. Both nodes have two wired in= terfaces. A1 is connected to A2 and B1 is connected to B2. we’d like = to find out what’s the best way to configure RPL for such a network to forward packets on both links.
 
           &nbs= p;            &= nbsp;     +-------------+
           &nbs= p;            &= nbsp;     |    Root   &nb= sp; |
           &nbs= p;            &= nbsp;     |       &n= bsp;     |  
           &nbs= p;            &= nbsp; +---+A1    1    B1+----+= ;
           &nbs= p;            &= nbsp; |   |         =     |    |
           &nbs= p;            &= nbsp; |   |         =     |    |
           &nbs= p;            &= nbsp; |   +-------------+    |
           &nbs= p;            &= nbsp; |           &n= bsp;          |
           &nbs= p;            &= nbsp; |           &n= bsp;          |
           &nbs= p;            &= nbsp; |           &n= bsp;          |
           &nbs= p;            &= nbsp; |   +-------------+    |
           &nbs= p;            &= nbsp; |   |         =     |    |
           &nbs= p;            &= nbsp; +---+A2    2    B2+----+= ;
           &nbs= p;            &= nbsp;     |       &n= bsp;     |
           &nbs= p;            &= nbsp;     +------+------+
 
I could think of two possible configurations. In the first RPL configu= ration, I let node 1 use only *one* instance, INST1. One DIO message with A= 1 as DODAGID will be broadcast over both interfaces A1 and B1. Then another= message with B1 as DODAGID will be also broadcast over both interfaces. Based on the RPL draft that limits = a node to join only one DODAG given an instance ID, node 2 can only choose = one link to join node 1 and leave the other link *unused*.
 
In the second configuration, I let node 1 to use *two* instances, INST= 1 and INST2. One DIO message with A1 as DODAGID and INST1 will be broadcast= over both interfaces A1 and B1. Then another message with B1 as DODAGID an= d INST2 will be also broadcast over both interfaces. Some Objective Functions may allow us to forward packets o= n both links now. But the control becomes hard when the network has multipl= e hops. Ideally, I prefer node 2 to dynamically choose a link because link = qualities could change over time quickly.
 
Any comment or suggestio= n would be appreciated and thank you for your time,
 
Yanjun
 
--
Yanjun Sun
Systems and Applications R&D Center
Texas Instruments, Inc, USA
 
 
 --_000_2C1563023E232C49B9F505633D57C2DA272075B026dlee04enttico_-- From osk@exegin.com Thu May 12 13:17:09 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02752E0740 for ; Thu, 12 May 2011 13:17:09 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrDfkbWpn-Ln for ; Thu, 12 May 2011 13:17:08 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 40A35E072E for ; Thu, 12 May 2011 13:17:08 -0700 (PDT) Received: by pxi2 with SMTP id 2so1169989pxi.38 for ; Thu, 12 May 2011 13:17:08 -0700 (PDT) Received: by 10.68.68.79 with SMTP id u15mr835115pbt.316.1305231427840; Thu, 12 May 2011 13:17:07 -0700 (PDT) Received: from [172.16.1.66] ([216.251.130.154]) by mx.google.com with ESMTPS id k3sm872907pbc.0.2011.05.12.13.17.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 13:17:06 -0700 (PDT) Message-ID: <4DCC4040.8090200@exegin.com> Date: Thu, 12 May 2011 13:17:04 -0700 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Optimization to trickle-mcast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2011 20:17:09 -0000 Hi, I wrote this up a while back before trickle-mcast was adopted as a ROLL WG document, I think it could be used to optimize the multicast performance of a dense RPL network by eliminating unnecessary retransmissions. If it doesn't break anything, it only requires a small change to the multicast forwarding logic. Thanks, Owen Kirby The problem: ------------ With trickle multicast as it is current written, the number of frames resulting from a single multicast packet scales linearly with the number of devices on the network (eg: O(n)). This causes particular pain in dense networks where many devices are retransmitting within range each other. Excessive retransmissions increase battery life, network congestion, and the probability of channel-access collisions. Consider the case of a dense network consisting of many nodes all within one hop of the DAG root (A), or another mains-powered router (B) or (C): o o o (A) o / \ o / \ o o / o (C) o (B) o o o o The goal of a multicast packet, is to reach every node on the DAG, and to accomplish this goal we only need to retransmit the multicast from nodes (A), (B), and (C). By identifying these three nodes as mutlicast forwarders we can efficiently multicast to all devices in this network, regardless of the number of devices in this network. However, not all networks may be so convenient, and there may be cases where a few devices are not located in the "dense clump", yet are still interested in multicast transmissions. Such a network might look something like: o o o (A) o / \ o / \ o o / o (C) o (B) \ o (D) ------ (e) o o In this network, device (e) would form a route to the DAG root through its best parent (D), and informs the root by sending a DAO. A successful multicast packet now requires retransmissions from (A), (B), (C) and (D). If we had a mechanism to identify these key devices, then we can reduce the number of retransmission on a network (and the probability of collisions); thus increasing reliability and battery life. In a RPL network, we can identify these key devices by inspecting the routing messages. Routers which have child nodes can be considered key devices, and devices without children need not waste energy by retransmitting multicasts. The solution: ------------- By default, only the DAG root is considered a multicast forwarder. A multicast forwarder MUST retransmit multicast packets with non-local scope. Devices that are not forwarders SHOULD NOT retransmit multicast packets. Any member of the DAG that finds itself in a routing path MUST become a multicast forwarder. In this case, any device that is unable to reach the DAG root directly must select a suitable RPL parent, which also indicates that the parent may be required to retransmit multicasts from the DAG for the child to be able to receive them. We propose the following: 1) RPL devices have a boolean flag isMulticastForwarder. a) The DAG root MUST always have isMulticastForwarder==TRUE. b) RPL leaf nodes MUST always have isMulticastForwader==FALSE. c) RPL routers SHOULD initialize isMulticastForwader=FALSE. 2) When a RPL router identifies that it is in a routing path, it MUST set isMulticastForwader=TRUE. A router can determine this by one of the following: a) Receiving a DAO in storing mode. b) Forwarding a DAO in non-storing mode. c) Forwarding a packet containing the RPL hop-by-hop option. d) An explicit notification using a unicast DAO to the parent with a multicast target address (FF00::/8). We recommend this option to give room for future optimization, and to deal with link asymmetry. 3) When receiving a multicast packet with non-local scope, devices SHOULD NOT retransmit it unless isMulticastForwarder==TRUE. Devices that forward the packet MUST do so according to draft-ietf-trickle-mcast-01 to prevent flooding. 4) In the case of 2.d, every node must send a unicast DAO to its parent(s) with a target address of FF00::/8 when it joins a DAG. Using longer prefixes may allow for future optimizations by limiting the size of the multicast forwarding tree based on the multicast address. Link Asymmetry: --------------- RPL parent selection is based of the quality of link from the child to its parent (as defined by the objective function). However the multicast path use the link in both directions, depending on where the source is located. As such, strong link asymmetry may have adverse effects on the selection of multicast routers. If the objective function selects an asymmetric route to the DAG root, then multicast forwarding will work better if an explicit DAO with a multicast address is sent to a parent with a symmetric link. Network stability: ------------------ The efficiency of this proposal depends on minimizing the number of multicast forwarders. However, we have only defined a mechanism to set isMulticastForwarder and no mechanism to clear it. Therefore, in a network with significant routing churn, the ratio of multicast forwarders to routers in the DAG will increase towards 100% over time. If the ratio reaches 100% then this proposal will behave exactly the same as the trickle multicast draft. It is strongly recommended that a mechanism to clear isMulticastForwarder should be defined when a path is no longer used. As an example, if using an explicit notification, the DAO transit lifetime could specify a timeout and isMulticastForwarder could be replaced with a timer that tracks the maximum lifetime received from all children. From mcr@sandelman.ca Thu May 12 19:15:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC19C130019 for ; Thu, 12 May 2011 19:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDVB5OC4zWGf for ; Thu, 12 May 2011 19:15:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 05F94130014 for ; Thu, 12 May 2011 19:15:38 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 2F76734006; Thu, 12 May 2011 22:15:38 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9F6AE989D0; Thu, 12 May 2011 22:16:49 -0400 (EDT) From: Michael Richardson To: "Sun, Yanjun" In-Reply-To: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Thu, 12 May 2011 22:16:49 -0400 Message-ID: <30130.1305253009@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "roll@ietf.org" Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2011 02:15:43 -0000 >>>>> "Yanjun" == Yanjun Sun writes: Yanjun> I'm new to this mailing list. I'm trying to figure out how Yanjun> to configure/run RPL on a node with two Yanjun> interfaces. Following the rules of RPL, I came up with Yanjun> several configurations even for a simple two node network Yanjun> below. Could you please comment on whether they make sense Yanjun> and whether there is any better alternative? As most Yanjun> discussion in RPL is focused on nodes with single interface Yanjun> (though I strongly believe it'll work well for multiple Yanjun> interfaces), the configuration really puzzled me. So I would Yanjun> appreciate if anyone could help me out. So, RPL is not focused on a single interface. RPL is focused on connections where there is multiple access, just not really broadcast available. Yet, it's not ATM-like NBMA. A machine with two interfaces is just part of two broadcast domains where the ETX is 0 for any machines crossing that line. The two interfaces don't have to be two radios, it could also be a single radio with multiple frequencies. In my test bench, I use simulated ethernet, but since I don't have simulation of radio propogation issues, I just have a network with 7 or so ethernet broadcast domains. Yanjun> I'd like to use a very simple network to describe my Yanjun> questions. Node 1 is the root and node 2 is a leaf. Both Yanjun> nodes have two wired interfaces. A1 is connected to A2 and Yanjun> B1 is connected to B2. we'd like to find out what's the best Yanjun> way to configure RPL for such a network to forward packets Yanjun> on both links. I don't think you can. RPL doesn't promise you that you will be able to make the most amount of bandwidth available, but that you will get a minimal cost (by Objective Function) path. Yanjun> In the second configuration, I let node 1 to use *two* Yanjun> instances, INST1 and INST2. One DIO message with A1 as Yanjun> DODAGID and INST1 will be broadcast over both interfaces A1 Yanjun> and B1. Then another message with B1 as DODAGID and INST2 Yanjun> will be also broadcast over both interfaces. Some Objective Yanjun> Functions may allow us to forward packets on both links Yanjun> now. But the control becomes hard when the network has This is the only way I can see doing things. Yanjun> multiple hops. Ideally, I prefer node 2 to dynamically Yanjun> choose a link because link qualities could change over time Yanjun> quickly. if the ETX across the A links and the B links is significantly different, and this changes over time, then I expect that your DODAG may re-organize to always have the best working path. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From c.chauvenet@watteco.com Fri May 13 01:15:16 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7DAE06FB for ; Fri, 13 May 2011 01:15:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ5IDOjJE+47 for ; Fri, 13 May 2011 01:15:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 50A4EE06B7 for ; Fri, 13 May 2011 01:15:15 -0700 (PDT) Received: from mail86-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.8; Fri, 13 May 2011 08:15:14 +0000 Received: from mail86-ch1 (localhost.localdomain [127.0.0.1]) by mail86-ch1-R.bigfish.com (Postfix) with ESMTP id 45C08EC8209; Fri, 13 May 2011 08:15:14 +0000 (UTC) X-SpamScore: -15 X-BigFish: VPS-15(zz1436Kc3f2M14ffOzz1202hzzz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB022.red002.local; RD:none; EFVD:NLI Received: from mail86-ch1 (localhost.localdomain [127.0.0.1]) by mail86-ch1 (MessageSwitch) id 1305274513463815_17795; Fri, 13 May 2011 08:15:13 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail86-ch1.bigfish.com (Postfix) with ESMTP id 6E18588004C; Fri, 13 May 2011 08:15:13 +0000 (UTC) Received: from IE2RD2HUB022.red002.local (213.199.187.153) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 13 May 2011 08:15:12 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB022.red002.local ([10.43.198.100]) with mapi; Fri, 13 May 2011 01:14:57 -0700 From: C Chauvenet To: "Sun, Yanjun" Date: Fri, 13 May 2011 01:14:55 -0700 Thread-Topic: [Roll] On how to configure/run RPL on nodes with two interfaces Thread-Index: AcwRRdiMPWwLXO9PQzKPhKckNaiUbQ== Message-ID: <28301129-AC41-4702-96F9-203130D379A9@watteco.com> References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> In-Reply-To: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_28301129AC41470296F9203130D379A9wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2011 08:15:16 -0000 --_000_28301129AC41470296F9203130D379A9wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, RPL on muti-interfaces nodes is to my mind a very valuable feature. Jumping into the discussion, a thought came to my mind : If you have several interfaces on your nodes, you should have several MAC a= ddress (one for each interface), so you should have several IPv6 address. So in fact, would the problem of multi-interfaces be similar to multiple no= des (considering a node as a particular IPv6 address) ? So in your case, using both interfaces would result in doing some kind of m= ulticasting. Other thoughts ? C=E9dric. Le 12 mai 2011 =E0 20:25, Sun, Yanjun a =E9crit : Hello All, I=92m new to this mailing list. I=92m trying to figure out how to configure= /run RPL on a node with two interfaces. Following the rules of RPL, I came = up with several configurations even for a simple two node network below. Co= uld you please comment on whether they make sense and whether there is any = better alternative? As most discussion in RPL is focused on nodes with sing= le interface (though I strongly believe it=92ll work well for multiple inte= rfaces), the configuration really puzzled me. So I would appreciate if anyo= ne could help me out. I=92d like to use a very simple network to describe my questions. Node 1 i= s the root and node 2 is a leaf. Both nodes have two wired interfaces. A1 i= s connected to A2 and B1 is connected to B2. we=92d like to find out what= =92s the best way to configure RPL for such a network to forward packets on= both links. +-------------+ | Root | | | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ I could think of two possible configurations. In the first RPL configuratio= n, I let node 1 use only *one* instance, INST1. One DIO message with A1 as = DODAGID will be broadcast over both interfaces A1 and B1. Then another mess= age with B1 as DODAGID will be also broadcast over both interfaces. Based o= n the RPL draft that limits a node to join only one DODAG given an instance= ID, node 2 can only choose one link to join node 1 and leave the other lin= k *unused*. In the second configuration, I let node 1 to use *two* instances, INST1 and= INST2. One DIO message with A1 as DODAGID and INST1 will be broadcast over= both interfaces A1 and B1. Then another message with B1 as DODAGID and INS= T2 will be also broadcast over both interfaces. Some Objective Functions ma= y allow us to forward packets on both links now. But the control becomes ha= rd when the network has multiple hops. Ideally, I prefer node 2 to dynamica= lly choose a link because link qualities could change over time quickly. Any comment or suggestion would be appreciated and thank you for your time, Yanjun -- Yanjun Sun Systems and Applications R&D Center Texas Instruments, Inc, USA --_000_28301129AC41470296F9203130D379A9wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi,

RPL on muti-interfaces nodes is to my mind a very v= aluable feature.

Jumping into the discussion, a th= ought came to my mind :

If you have several interf= aces on your nodes, you should have several MAC address (one for each inter= face), so you should have several IPv6 address.
So in fact, would= the problem of multi-interfaces be similar to multiple nodes (considering = a node as a particular IPv6 address) ?

So in your = case, using both interfaces would result in doing some kind of multicasting= .

Other thoughts ?

C=E9dr= ic.

Le 12 mai 2011 =E0 20:25, Sun, Yanjun a =E9crit= :

<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; font-fa= mily: Helvetica; font-style: normal; font-variant: normal; font-weight: nor= mal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0p= x; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:= 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: a= uto; -webkit-text-stroke-width: 0px; font-size: medium; ">
Hello All,
 
<= div>I=92m new to this mailing list. I=92m trying to figure out how to confi= gure/run RPL on a node with two interfaces. Following the rules of RPL, I c= ame up with several configurations even for a simple two node network below= . Could you please comment on whether they make sense and whether there is = any better alternative? As most discussion in RPL is focused on nodes with = single interface (though I strongly believe it=92ll work well for multiple = interfaces), the configuration really puzzled me. So I would appreciate if = anyone could help me out.
&= nbsp;
I=92d like to use a very simple network to describe = my questions.  Node 1 is the root and node 2 is a leaf. Both nodes hav= e two wired interfaces. A1 is connected to A2 and B1 is connected to B2. we= =92d like to find out what=92s the best way to configure RPL for such a net= work to forward packets on both links.
 
 &nb= sp;            =             &nb= sp;   +-------------+
     &nb= sp;            =             | &= nbsp;  Root     |
   &nbs= p;            &= nbsp;           &nbs= p; |            = ; |  
        &= nbsp;           &nbs= p;     +---+A1    1    B1= +----+
         &nbs= p;            &= nbsp;   |   |       =       |    |
  =             &nb= sp;           | &nbs= p; |            = ; |    |
       = ;            &n= bsp;      |   +-------------+  = ;  |
         &= nbsp;           &nbs= p;    |         = ;             |=
          &nbs= p;            &= nbsp;  |          &n= bsp;           |
            &= nbsp;           &nbs= p; |            = ;          |
 &= nbsp;           &nbs= p;            | = ;  +-------------+    |
   &nb= sp;            =           |   | = ;            | =    |
        &n= bsp;            = ;     +---+A2    2    B2+= ----+
          = ;            &n= bsp;       |     &nb= sp;       |
    = ;            &n= bsp;            = ; +------+------+
 
I could think of two possible = configurations. In the first RPL configuration, I let node 1 use only *one*= instance, INST1. One DIO message with A1 as DODAGID will be broadcast over= both interfaces A1 and B1. Then another message with B1 as DODAGID will be= also broadcast over both interfaces. Based on the RPL draft that limits a = node to join only one DODAG given an instance ID, node 2 can only choose on= e link to join node 1 and leave the other link *unused*.
 
In the second configuration, I let node 1 to use *two* instances, = INST1 and INST2. One DIO message with A1 as DODAGID and INST1 will be broad= cast over both interfaces A1 and B1. Then another message with B1 as DODAGI= D and INST2 will be also broadcast over both interfaces. Some Objective Fun= ctions may allow us to forward packets on both links now. But the control b= ecomes hard when the network has multiple hops. Ideally, I prefer node 2 to= dynamically choose a link because link qualities could change over time qu= ickly.
 
Any comment or= suggestion would be appreciated and thank you for your time,
<= div> 
<= font face=3D"Calibri, sans-serif" size=3D"2">Yanjun
 
--&= nbsp;
Yanjun Sun
Systems and Applications R&D Center
Te= xas Instruments, Inc, USA
 
 
<ATT00001..txt>=

= --_000_28301129AC41470296F9203130D379A9wattecocom_-- From internet-drafts@ietf.org Fri May 13 06:11:41 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA71BE072B; Fri, 13 May 2011 06:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsSgZ206imb4; Fri, 13 May 2011 06:11:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B13E06D0; Fri, 13 May 2011 06:11:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513131141.7654.25421.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 06:11:41 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2011 13:11:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Robert Cragie Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-03.txt Pages : 22 Date : 2011-05-13 Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be suboptimal and may lead to traffic congestion near the DAG root. This document specifies a P2P route discovery mechanism, complementary to the RPL base functionality. This mechanism allows an IPv6 router or host to discover and establish, on demand, one or more routes to another IPv6 router or host in the LLN such that the discovered routes meet specified constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-03.txt From yanjun@ti.com Fri May 13 09:23:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BA3E0776 for ; Fri, 13 May 2011 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsnPWl7e0xlY for ; Fri, 13 May 2011 09:22:58 -0700 (PDT) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9CE06A6 for ; Fri, 13 May 2011 09:22:58 -0700 (PDT) Received: from dlep33.itg.ti.com ([157.170.170.112]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id p4DGMumr021696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 11:22:57 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep33.itg.ti.com (8.13.7/8.13.7) with ESMTP id p4DGMu4A016614; Fri, 13 May 2011 11:22:56 -0500 (CDT) Received: from dlee74.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p4DGMuqO003708; Fri, 13 May 2011 11:22:56 -0500 (CDT) Received: from dlee04.ent.ti.com ([157.170.170.9]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Fri, 13 May 2011 11:22:56 -0500 From: "Sun, Yanjun" To: C Chauvenet , "mcr@sandelman.ca" Date: Fri, 13 May 2011 11:22:55 -0500 Thread-Topic: [Roll] On how to configure/run RPL on nodes with two interfaces Thread-Index: AcwRRdiMPWwLXO9PQzKPhKckNaiUbQAQChyA Message-ID: <2C1563023E232C49B9F505633D57C2DA272089BCC9@dlee04.ent.ti.com> References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> <28301129-AC41-4702-96F9-203130D379A9@watteco.com> In-Reply-To: <28301129-AC41-4702-96F9-203130D379A9@watteco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2C1563023E232C49B9F505633D57C2DA272089BCC9dlee04enttico_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2011 16:23:03 -0000 --_000_2C1563023E232C49B9F505633D57C2DA272089BCC9dlee04enttico_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi C=E9dric, Michael, Thank you for your valuable inputs. C=E9dric: Our understanding is aligned on the IPv6 address usage. I could o= nly think of a tiny difference between multi-interfaces and multiple nodes = and please correct me if I'm wrong. Suppose only one root node creates one = RPLInstance in a network. In the multi-interface case, we see two types of = DIO messages, each corresponding to an IPv6 address of the root. A leaf nod= e can't tell that they're essentially from the same root node. In the multi= ple nodes case, we only see one type of DIO message. Michael: You're right, but I wonder if the following dynamic path selection= could possibly trigger some undesired control overhead at nodes below node= 1 and 2. >if the ETX across the A links and the B links is significantly >different, and this changes over time, then I expect that your DODAG may >re-organize to always have the best working path. Suppose node 1 and 2 are at the very top of a DODAG and there are many node= s below them. Also suppose node 1 created one RPLInstance and two DODAGIDs = (one for each interface, the configuration 1 I mentioned in my earlier emai= l). When node 2 picks a different link due to changed EXT metrics, the DODG= AID it belongs to may also change. I'm not sure if this will trigger all th= e nodes below node2 to update their "associations". Thank you, Yanjun From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Friday, May 13, 2011 3:15 AM To: Sun, Yanjun Cc: roll@ietf.org Subject: Re: [Roll] On how to configure/run RPL on nodes with two interface= s Hi, RPL on muti-interfaces nodes is to my mind a very valuable feature. Jumping into the discussion, a thought came to my mind : If you have several interfaces on your nodes, you should have several MAC a= ddress (one for each interface), so you should have several IPv6 address. So in fact, would the problem of multi-interfaces be similar to multiple no= des (considering a node as a particular IPv6 address) ? So in your case, using both interfaces would result in doing some kind of m= ulticasting. Other thoughts ? C=E9dric. Le 12 mai 2011 =E0 20:25, Sun, Yanjun a =E9crit : Hello All, I'm new to this mailing list. I'm trying to figure out how to configure/run= RPL on a node with two interfaces. Following the rules of RPL, I came up w= ith several configurations even for a simple two node network below. Could = you please comment on whether they make sense and whether there is any bett= er alternative? As most discussion in RPL is focused on nodes with single i= nterface (though I strongly believe it'll work well for multiple interfaces= ), the configuration really puzzled me. So I would appreciate if anyone cou= ld help me out. I'd like to use a very simple network to describe my questions. Node 1 is = the root and node 2 is a leaf. Both nodes have two wired interfaces. A1 is = connected to A2 and B1 is connected to B2. we'd like to find out what's the= best way to configure RPL for such a network to forward packets on both li= nks. +-------------+ | Root | | | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ I could think of two possible configurations. In the first RPL configuratio= n, I let node 1 use only *one* instance, INST1. One DIO message with A1 as = DODAGID will be broadcast over both interfaces A1 and B1. Then another mess= age with B1 as DODAGID will be also broadcast over both interfaces. Based o= n the RPL draft that limits a node to join only one DODAG given an instance= ID, node 2 can only choose one link to join node 1 and leave the other lin= k *unused*. In the second configuration, I let node 1 to use *two* instances, INST1 and= INST2. One DIO message with A1 as DODAGID and INST1 will be broadcast over= both interfaces A1 and B1. Then another message with B1 as DODAGID and INS= T2 will be also broadcast over both interfaces. Some Objective Functions ma= y allow us to forward packets on both links now. But the control becomes ha= rd when the network has multiple hops. Ideally, I prefer node 2 to dynamica= lly choose a link because link qualities could change over time quickly. Any comment or suggestion would be appreciated and thank you for your time, Yanjun -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] Sent: Thursday, May 12, 2011 9:17 PM To: Sun, Yanjun Cc: roll@ietf.org Subject: Re: [Roll] On how to configure/run RPL on nodes with two interface= s >>>>> "Yanjun" =3D=3D Yanjun Sun writes: Yanjun> I'm new to this mailing list. I'm trying to figure out how Yanjun> to configure/run RPL on a node with two Yanjun> interfaces. Following the rules of RPL, I came up with Yanjun> several configurations even for a simple two node network Yanjun> below. Could you please comment on whether they make sense Yanjun> and whether there is any better alternative? As most Yanjun> discussion in RPL is focused on nodes with single interface Yanjun> (though I strongly believe it'll work well for multiple Yanjun> interfaces), the configuration really puzzled me. So I would Yanjun> appreciate if anyone could help me out. So, RPL is not focused on a single interface. RPL is focused on connections where there is multiple access, just not really broadcast available. Yet, it's not ATM-like NBMA. A machine with two interfaces is just part of two broadcast domains where the ETX is 0 for any machines crossing that line. The two interfaces don't have to be two radios, it could also be a single radio with multiple frequencies. In my test bench, I use simulated ethernet, but since I don't have simulation of radio propogation issues, I just have a network with 7 or so ethernet broadcast domains. Yanjun> I'd like to use a very simple network to describe my Yanjun> questions. Node 1 is the root and node 2 is a leaf. Both Yanjun> nodes have two wired interfaces. A1 is connected to A2 and Yanjun> B1 is connected to B2. we'd like to find out what's the best Yanjun> way to configure RPL for such a network to forward packets Yanjun> on both links. I don't think you can. RPL doesn't promise you that you will be able to make the most amount of bandwidth available, but that you will get a minimal cost (by Objective Function) path. Yanjun> In the second configuration, I let node 1 to use *two* Yanjun> instances, INST1 and INST2. One DIO message with A1 as Yanjun> DODAGID and INST1 will be broadcast over both interfaces A1 Yanjun> and B1. Then another message with B1 as DODAGID and INST2 Yanjun> will be also broadcast over both interfaces. Some Objective Yanjun> Functions may allow us to forward packets on both links Yanjun> now. But the control becomes hard when the network has This is the only way I can see doing things. Yanjun> multiple hops. Ideally, I prefer node 2 to dynamically Yanjun> choose a link because link qualities could change over time Yanjun> quickly. if the ETX across the A links and the B links is significantly different, and this changes over time, then I expect that your DODAG may re-organize to always have the best working path. -- ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition. --_000_2C1563023E232C49B9F505633D57C2DA272089BCC9dlee04enttico_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi C=E9dric, Michael,

 

Thank you for your valuable inputs.

 

C=E9dric: Our understanding is aligned on the IPv6 address u= sage. I could only think of a tiny difference between multi-interfaces and multiple nodes and please correct me if I’m wrong. Suppose only one root node creates one RPLInstance in a network. In the multi-interface case, we see t= wo types of DIO messages, each corresponding to an IPv6 address of the root. A leaf node can’t tell that they’re essentially from the same roo= t node. In the multiple nodes case, we only see one type of DIO message.=

 

 

Michael: You’re right, but I wonder if the following dynamic path selection could possibly trigger some undesired control overhe= ad at nodes below node 1 and 2.

>if the ETX across the A links and the B links i= s significantly

>different, and this changes over time, then I e= xpect that your DODAG may

>re-organize to always have the best working pat= h.

 

Suppose node 1 and 2 are at the very top of a DODAG and ther= e are many nodes below them. Also suppose node 1 created one RPLInstance and = two DODAGIDs (one for each interface, the configuration 1 I mentioned in my ear= lier email). When node 2 picks a different link due to changed EXT metrics, the DODGAID it belongs to may also change. I’m not sure if this will trig= ger all the nodes below node2 to update their “associations”.<= /o:p>

 

Thank you,

 

Yanjun

 

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Friday, May 13, 2011 3:15 AM
To: Sun, Yanjun
Cc: roll@ietf.org
Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces

 

Hi,

 

RPL on muti-interfaces nodes is to my mind a very valu= able feature.

 

Jumping into the discussion, a thought came to my mind= :

 

If you have several interfaces on your nodes, you shou= ld have several MAC address (one for each interface), so you should have sever= al IPv6 address.

So in fact, would the problem of multi-interfaces be s= imilar to multiple nodes (considering a node as a particular IPv6 address) ?<= /o:p>

 

So in your case, using both interfaces would result in= doing some kind of multicasting.

 

Other thoughts ?

 

C=E9dric.

 

Le 12 mai 2011 =E0 20:25, Sun, Yanjun a =E9crit :=



= Hello All,

=  

= I’m new to this mailing list. I’m trying to figure out how to configure/r= un RPL on a node with two interfaces. Following the rules of RPL, I came up wi= th several configurations even for a simple two node network below. Could you please comment on whether they make sense and whether there is any better alternative? As most discussion in RPL is focused on nodes with single interface (though I strongly believe it’ll work well for multiple interfaces), the configuration really puzzled me. So I would appreciate if anyone could help me out.

 

= I’d like to use a very simple network to describe my questions.  Node 1 is= the root and node 2 is a leaf. Both nodes have two wired interfaces. A1 is connected to A2 and B1 is connected to B2. we’d like to find out what’s the best way to configure RPL for such a network to forward packets on both links.

=  

=             &nb= sp;            =      +-------------+

=             &nb= sp;            =      |    Root     |

=             &nb= sp;            =      |             |=   

=             &nb= sp;             +---+A1    1    B1+----+

=             &nb= sp;             |   |             |    |

=             &nb= sp;             |   |             |    |

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

=             &nb= sp;             |            &n= bsp;         |

=             &nb= sp;             |            &n= bsp;         |

=             &nb= sp;             |            &n= bsp;         |

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

=             &nb= sp;             |   |             |    |

=             &nb= sp;             +---+A2    2    B2+----+

=             &nb= sp;            =      |             |=

=             &nb= sp;            =      +------+------+

=  

= I could think of two possible configurations. In the first RPL configuration, I let node 1 use only *one* instance, INST1. One DIO message with A1 as DODAGID w= ill be broadcast over both interfaces A1 and B1. Then another message with B1 a= s DODAGID will be also broadcast over both interfaces. Based on the RPL draft that limits a node to join only one DODAG given an instance ID, node 2 can = only choose one link to join node 1 and leave the other link *unused*.

=  

= In the second configuration, I let node 1 to use *two* instances, INST1 and INST2.= One DIO message with A1 as DODAGID and INST1 will be broadcast over both interf= aces A1 and B1. Then another message with B1 as DODAGID and INST2 will be also b= roadcast over both interfaces. Some Objective Functions may allow us to forward pack= ets on both links now. But the control becomes hard when the network has multip= le hops. Ideally, I prefer node 2 to dynamically choose a link because link qualities could change over time quickly.

 

Any comment or suggestion would be appreciated and thank you for your time,

 

Yanjun

 

-----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Thursday, May 12, 2011 9:17 PM
To: Sun, Yanjun
Cc: roll@ietf.org
Subject: Re: [Roll] On how to configure/run RPL on nodes with two interface= s

 

 

>>>>> "Yanjun" =3D=3D Yanj= un Sun <Sun> writes:

=A0=A0=A0 Yanjun> I'm new to this mailing list. = I'm trying to figure out how

=A0=A0=A0 Yanjun> to configure/run RPL on a node= with two

=A0=A0=A0 Yanjun> interfaces. Following the rule= s of RPL, I came up with

=A0=A0=A0 Yanjun> several configurations even fo= r a simple two node network

=A0=A0=A0 Yanjun> below. Could you please commen= t on whether they make sense

=A0=A0=A0 Yanjun> and whether there is any bette= r alternative? As most

=A0=A0 =A0Yanjun> discussion in RPL is focused o= n nodes with single interface

=A0=A0=A0 Yanjun> (though I strongly believe it'= ll work well for multiple

=A0=A0=A0 Yanjun> interfaces), the configuration= really puzzled me. So I would

=A0=A0=A0 Yanjun> appreciate if anyone could hel= p me out.

 

So, RPL is not focused on a single interface.<= /o:p>

 

RPL is focused on connections where there is multip= le access, just not

really broadcast available. Yet, it's not ATM-like = NBMA.

A machine with two interfaces is just part of two broadcast domains

where the ETX is 0 for any machines crossing that l= ine.=A0 The two

interfaces don't have to be two radios, it could al= so be a single radio

with multiple frequencies.

 

In my test bench, I use simulated ethernet, but sin= ce I don't have

simulation of radio propogation issues, I just have= a network with 7 or

so ethernet broadcast domains.

 

=A0=A0=A0 Yanjun> I'd like to use a very simple = network to describe my

=A0=A0=A0 Yanjun> questions.=A0 Node 1 is the ro= ot and node 2 is a leaf. Both

=A0=A0=A0 Yanjun> nodes have two wired interface= s. A1 is connected to A2 and

=A0=A0=A0 Yanjun> B1 is connected to B2. we'd li= ke to find out what's the best

=A0=A0=A0 Yanjun> way to configure RPL for such = a network to forward packets

=A0=A0=A0 Yanjun> on both links.

 

I don't think you can.

RPL doesn't promise you that you will be able to ma= ke the most amount of

bandwidth available, but that you will get a minima= l cost (by Objective

Function) path.

 

=A0=A0=A0 Yanjun> In the second configuration, I= let node 1 to use *two*

=A0=A0=A0 Yanjun> instances, INST1 and INST2. On= e DIO message with A1 as

=A0=A0=A0 Yanjun> DODAGID and INST1 will be broa= dcast over both interfaces A1

=A0=A0=A0 Yanjun> and B1. Then another message w= ith B1 as DODAGID and INST2

=A0=A0=A0 Yanjun> will be also broadcast over bo= th interfaces. Some Objective

=A0=A0=A0 Yanjun> Functions may allow us to forw= ard packets on both links

=A0=A0=A0 Yanjun> now. But the control becomes h= ard when the network has

 

This is the only way I can see doing things.=A0

 

=A0=A0=A0 Yanjun> multiple hops. Ideally, I pref= er node 2 to dynamically

=A0=A0=A0 Yanjun> choose a link because link qua= lities could change over time

=A0=A0=A0 Yanjun> quickly.

 

if the ETX across the A links and the B links is significantly

different, and this changes over time, then I expec= t that your DODAG may

re-organize to always have the best working path.

 

--

]=A0=A0=A0=A0=A0=A0 He who is tired of Weird Al is = tired of life!=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 firewalls=A0 [

]=A0=A0 Michael Richardson, Sandelman Software Work= s, Ottawa, ON=A0=A0=A0 |net architect[

] mcr@sandelman.ottawa.on.ca http://www.sandelman.o= ttawa.on.ca/ |device driver[

=A0=A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1ycLXQSE>

=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 then sign the petition.

 

--_000_2C1563023E232C49B9F505633D57C2DA272089BCC9dlee04enttico_-- From prvs=10849dfc9=mukul@uwm.edu Sat May 14 09:31:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60850E06C9 for ; Sat, 14 May 2011 09:31:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x7UZjXEu4EN for ; Sat, 14 May 2011 09:31:13 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C9F17E068B for ; Sat, 14 May 2011 09:31:13 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 14 May 2011 11:31:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C10F42B3F4E for ; Sat, 14 May 2011 11:31:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwI8meS5xkAS for ; Sat, 14 May 2011 11:31:12 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 91AF92B3F26 for ; Sat, 14 May 2011 11:31:12 -0500 (CDT) Date: Sat, 14 May 2011 11:31:12 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <410883323.317156.1305390672451.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <336788793.316800.1305385250523.JavaMail.root@mail05.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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Changes in p2p-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2011 16:31:14 -0000 Hi all, Here are the main differences between the new draft and the previous version: 1. Eliminated "route" constraints. The previous version supported two types of constraints: propagation constraints were to be applied by all the routers receiving a DIO whereas the route constraints were to be applied by only the target. The idea was to simplify the task of intermediate nodes that had to apply only the propagation constraints. However, there were issues with how to distinguish the two sets of constraints. Now, all the routers have to apply all the constraints. We can always mark some constraints as optional if we dont want all the nodes to apply them. 2. Similarly, eliminated the optional OCP from the Route Discovery Option. Now, the same OCP is to be used for DAG formation and route comparison. 3. Combined Source Route Option with Route Discovery Option. Now, both DIOs and DROs have to carry one Route Discovery Option. The Route Discovery Option allows carrying the target address and the addresses in the accumulated route in the compressed fashion. 4. DRO propagation: Previous version allowed lot of flexibility in sending DROs from the target to the origin. This would have certainly led to interoperability issues. This version allows just one way for DROs to travel: via link-local multicast along a route specified in the route discovery option contained in the DRO. Sending DROs via link-local multicast allows the DRO message to convey the completion of route discovery to nodes in the LLN (via the stop bit). 5. Route accumulation in DIO: Since the DRO is not going to travel using RH4, there was not much incentive to use RRH to accumulate the route travelled by a DIO. Since the DRO is going to travel along a route specified in the Route Discovery Option, it makes sense to accumulate the route travelled by a DIO in the Route Discovery Option itself. When the target generates a DRO, it can simply copy the Route Discovery Option from the DIO into the DRO. 6. Changes have been suggested to Trickle operation to meet the needs for low latency in route discovery while avoiding DIO storms. We will work with Trickle authors to see if we can achieve the desired results in a more compliant manner. Thanks Mukul From pthubert@cisco.com Tue May 17 08:42:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4495DE073C for ; Tue, 17 May 2011 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.999 X-Spam-Level: X-Spam-Status: No, score=-11.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq7zl+JXUkKr for ; Tue, 17 May 2011 08:41:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 35254E069C for ; Tue, 17 May 2011 08:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=22109; q=dns/txt; s=iport; t=1305646918; x=1306856518; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yaCvr5ZM7UvAr/AdwPVUZLxVp6cAgkQlnVdXUb4bheE=; b=VRM3YSLZGhhVzPwTbLGrtAHizeiz2WdsywPklmvxIRLQR4I7n48m8hLc 4p2irzMgeSBCzyMNOhbkIR4uq6CRwzeeppHA2Rw7Vqumh4m3ldKNWCXUk tR0g58JNZmrxyU32C/dpfwFcGwegP8XimUILVDlvMu4ngtQCi6x0OXNdA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAG+W0k2Q/khNgWdsb2JhbAAwlx6OThQBARYmJYhwoRSeJoMVgwQElEmKPw X-IronPort-AV: E=Sophos;i="4.65,226,1304294400"; d="scan'208";a="30699102" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 17 May 2011 15:41:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4HFfmMd016374; Tue, 17 May 2011 15:41:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 17:41:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 May 2011 17:41:46 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com> In-Reply-To: <4DC939BB.50406@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: AcwPE/LPjVEvibrjTQqZou5YLiTRBAE1OAxA References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> <4DC939BB.50406@ieee.org> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 17 May 2011 15:41:48.0730 (UTC) FILETIME=[EF36A9A0:01CC14A8] Cc: roll@ietf.org Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 May 2011 15:42:01 -0000 Hi Phoebus: =20 [Pascal] I posted a 12 to resync with you. I try to address the below as follows: > I. >=20 > I think you made edits with regard to your initial interpretation of my > comment. I did NOT want you change the sentence in Section 4.2.1, and > actually, I liked the original wording of "As it scans ..." in > draft-ietf-roll-of0-10 better. I was suggesting a sentence in what is now > Section 4, before Section 4.1, stating the steps in the subsections MUST be > executed in that order. [Pascal] I'll restore then. I did prefer the original too. > It looks like there is nothing written about advertising the rank (a Section > 4.3). I guess that's OK if you feel there is nothing to say. I would have > preferred a short paragraph there for completeness. It might just restate > the obvious, that advertisements are triggered by the Trickle timer or > changes in the rank after it is recomputed. [Pascal] There's text in the end of the ' Abstract Interface with RPL core' section that I thought would cover this. >=20 >=20 >=20 > II. > Regarding this point I made below: > >> PC> On a related note, there's a recent discussion of using the ETX >> > PC> directly (identity) as the rank, which doesn't match this >> PC> > requirement that step_of_rank be a multiple of 0x100 in OF0. In >> PC> > (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a >> PC> multiple of > 128, not 256 (0x100). > >> PC> > >> PC> Is it actually necessary to mention "rank-increase" in the >> PC> > introduction, before the terminology section? Can we remove > >> "The Rank > >> of a node is obtained by adding a normalized scalar Rank-increase > > to > >> the Rank of a selected preferred parent. OF0 uses a unit of Rank- > >> increase of 0x100 so that Rank value can be stored in one octet. > >> This allows up to at least 28 hops even when default settings are > >> used and each hop has the worst Rank-increase of 9." > >> PC> Or move it some point later? It may be a bit confusing to bring > up > >> PC> so much detail at this point in the text. >=20 > I think JP's comments about pointing out where many of the variables are > defined can be handled by not going into so much detail in the introduction, > and stating the details later. [Pascal] Agreed >=20 >=20 > III. > I presume you will still add Configuration Options for the configurable > parameters in 6.2? >=20 [Pascal] That would be beyond what I can do after last call. I'm only fixing editorials now. > IV. > As for any remaining comments I have after rereading the document, they > are about how to present and explain OF0. Since I get the sense that > there is some urgency to publish OF0, you can incorporate them if you > have time - these comments shouldn't "hold the document hostage." A few > points in addition to JP's comments: >=20 > 0) I've had trouble understanding the consensus of the discussion on the > mailing list on OF0 not being the default objective function. The last > paragraph of Section 1 still doesn't make it clear to me. As far as I > understand, OF0 is the default objective function when no objective > function is specified - if an implementation does not support another > objective function, it must support OF0. This is the definition of > "default," right? If not, someone please define "default" to me... I > must be missing something. I would be glad to propose shorter text if I > understood the consensus. [Pascal]=20 I think that those words for that belong to RPL.=20 We negotiated them with the IESG reviewers who raised the issue. I'm not sure we all have the same understanding of those words though. My understanding was that the AD wished that 2 implementations would always have at least one OF in common. If those implementations follow a given guidance that's outside RPL, fine. Otherwise they have to implement OF0. I suspect that some conformance test will verify that.=20 >=20 > " Since there is no default OF or metric container in the RPL main > specification, it might happen that, unless two given implementations > follow the same guidance for a specific problem or environment, those > implementations will not support a common OF with which they could > interoperate. OF0 is designed to be common to all implementations > that are not specifically designed to apply to a given case for which > further guidance is provided. This is why it is very abstract as to > how the link properties are transformed into a rank_increase and > leaves that responsibility to implementation; rather, OF0 enforces > normalized values for the rank_increase of a normal link and its > acceptable range, as opposed to formulating the details of its > computation. This is also why OF0 ignores metric containers. > " >=20 [Pascal] What do you think of: " Since there is no default OF or metric container in the RPL main specification, it might happen that, unless two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate. OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. This is why it is not specific as to how the link properties are transformed into a rank_increase and leaves that responsibility to the implementation; rather, OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range, as opposed to formulating the details of its computation. This is also why OF0 ignores metric containers." >=20 > 1) You might consider adding a clarification to Section 4 is how the > objective function is "triggered," when it enters the process of > computing the rank, checking whether to change parents and successors, > and readvertising the rank. I believe there are at least 2 entry points: > 1) DIO processing > 2) change in "step_of_rank", which is implementation dependent > and may > come from layer 2. >=20 [Pascal] What about: " 5. Abstract Interface with RPL core Objective Function 0 interacts with the RPL core in the following ways: Processing DIO: When a new DIO is received, the RPL core calls the OF that corresponds to the Objective Code Point OCP) in the DIO . OF0 corresponds to the OCP 0 (to be validated by IANA). Providing DAG information: The OF0 support provides an interface that returns information about a given instance. This includes material from the DIO base header, the role (router, leaf), and the Rank of this node. Providing a Parent List: The OF0 support provide an interface that returns the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry. Calling back: The RPL core provides a call back interface for the OF0 support to inform it that a change in DAG information or Parent List as occurred. This can be caused by an interaction with another system component such as configuration, timers, and device drivers, and the change may cause the RPL core to fire a new DIO or reset trickle timers. " > The latter should be mentioned explicitly... it's only mentioned at the > end of Section 3 in the last sentence. >=20 > I'm not sure if the objective function code is triggered by other timer > expirations, like when information becomes stale. Anyhow, it's your > call if this is too much detail and should be left to the implementers > to figure out on their own. >=20 >=20 > 2) I think that the paragraph at the end of Section 3: > " OF0 assigns a step_of_rank to each link to another node that it > monitors. The exact method for computing the step_of_rank is > implementation-dependent. " > belongs somewhere in Section 4.1, maybe after the sentence: > "An implementation MUST maintain the stretched step_of_rank between > MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows > to > reflect a large variation of link quality." >=20 [Pascal] I do not follow you on that. This section has been talking about rank increase and now it points at the place where it is defined (following JP's suggestion) " OF0 assigns a rank_increase to each link to another node that it monitors. Though the exact method for computing the rank_increase is implementation-dependent, the computation must follow the rules that are specified in Section 4.1. " >=20 > 3) Search and replace all "rank-increase" with "rank_increase" for > consistency. Search and replace "Rank-factor" with "rank_factor." >=20 [Pascal] OK > Is there a convention of writing names for distinguishing variables from > configurable parameters? I'm assuming that "lowercase with underscores" > (e.g., rank_factor) can be used interchangeably with "a mix of capital > letters and lowercase letters with no underscores" (e.g., > MinHopRankIncrease). Do we care to distinguish the two, say using "a > mix of capital letters and lowercase letters with no underscores" for > parameters and "lowercase with underscores" for variables? >=20 >=20 [Pascal] Not that I know of. I made separate subsections to differentiate them. > 4) Typo, extra word "as": > "One trivial OF0 implementation might compute the step_of_rank from > as a classical administrative..." >=20 [Pascal] Thanks >=20 > 5) Rewrite the equation: > R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease > as >=20 > R(N) =3D R(P) + rank_increase > where > rank_increase =3D (rank_factor * step_of_rank + stretch_of_rank) * > MinHopRankIncrease >=20 > So we have less new variables (Ri, Rf, Sp, Sr). >=20 [Pascal] OK... >=20 > 6) Defining the terms "higher order interface" and "RPL Core" in the > ROLL terminology document. >=20 [Pascal] I'll pass that that to JP. >=20 >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 >=20 > On 5/5/11 6:07 PM, Pascal Thubert (pthubert) wrote: > > Hi Phoebus: > > > > I made editorial changes to follow your late but welcome advice, and > > published a OF0-11. > > > > Please let me know if I covered your points as expected. > > > > Cheers, > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > >> -----Original Message----- > >> From: Phoebus Chen [mailto:phoebus@ieee.org] > >> Sent: Thursday, April 21, 2011 4:56 PM > >> To: Pascal Thubert (pthubert) > >> Cc: roll@ietf.org > >> Subject: Re: OF0 draft v9: preferred metric, Stretch-of-Rank, > > configuring > >> parameters, and editorial comments > >> > >> Pascal, > >> > >> Thanks for your responses. I've replied inline below, preceded > > by > >> PC>. > >> > >> -- > >> Phoebus Chen > >> Postdoctoral Researcher > >> Automatic Control Lab, KTH (Royal Institute of Technology) > >> http://www.ee.kth.se/~phoebus > >> > >> > >> On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote: > >>> Hello Phoebus : ) > >>> > >>> Where have you been? We've been missing your excellent comments. > >>> > >>>> Sorry these comments are coming so late, after last call. I > >>> hope you > >>>> can at least incorporate some of them. > >>> > >>> [Pascal] That's beyond me. I suppose that the shepherd has to > > decide. > >>> Let's see: > >>> > >>> > >>>> > >>>> My comments below are based on my current understanding that > >>>> Phil and you are no longer using hop-count as the rank increment. > >>> Instead, > >>>> each node will have an implementation specific way of converting a > >>> node or > >>>> link cost to a rank. I'm still unclear if there is a preference > > rule > >>> to try to stick > >>>> with using the same metrics as the metrics advertised in a received > >>> DIO, if > >>>> the current node has access to multiple types of metrics (energy, > > LQI, > >>> ETX, > >>>> etc.). That would allow the root node to specify a preferred type > > of > >>> metric to > >>>> use in the instance. > >>>> > >>>> > >>>> Major Points: > >>>> ************* > >>>> 1) I'm still hoping that the format for writing Objective Function > >>> specifications > >>>> can be more uniform, as I mentioned in an earlier comment (point > >>> number 7 > >>>> in > > http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). > >>>> Comparing MRHOF and OF0, I think that the discussion on > > Step-of-Rank / > >>>> Stretch-of-Rank etc. can be moved to it's own subsection. > >>>> > >>>> I suggest the following reorganization of sections: > >>>> > >>>> 3. Objective Function 0 > >>>> 3.1. Computing Rank-increase > >>>> 3.2. Parent / Backup Successor Selection > >>>> 3.2.1. Selection of the Preferred Parent > >>>> 3.2.2. Selection of the backup feasible successor > >>>> 3.3. Advertising Rank-increase > >>>> 4. Interface with RPL core > >>>> > >>> [Pascal] Looks good. That much is doc organization and I suppose I > > can > >>> accommodate it at this stage. > >>> It would certainly be beneficial if both OF drafts have a common > >>> structure. > >>> > >>>> If you are allowing the root to specified a preferred metric type, > >>> then Section > >>>> 3.3. should state how to propagate this preference. I would have > >>> assumed > >>>> it's by propagating an empty DAG/Metric Container, but in (Section > >>> 2.1, draft- > >>>> ietf-roll-routing-metrics-19) it says "The object body carries one > > or > >>> more sub- > >>>> objects defined later in this document" > >>>> which means you cannot have empty containers. > >>> > >>> [Pascal] OF0 does not have metric containers at all, so they do not > > need > >>> to be empty. That's because OF0 is generic, for the better or the > > worse. > >>> Because we want all implementations to interop with OF0, regardless > > of > >>> the medium etc... > >>> > >>> So the idea is to have no constraint on what the implementation uses > > to > >>> derive the Rank, no container, no configuration option, just the > > base > >>> RPL spec. > >>> > >>> Rather, we normalize the resulting values so they can compare > > between > >>> implementations. > >> > >> PC> OK. I thought allowing the root to specify a preferred metric > > would > >> PC> be nice, but I see that it's not necessary for basic operations. > >> > >>> > >>> Now, I understand that a configuration container could help make the > > OF > >>> more self-contained/autonomic. > >>> > >>>> Maybe the overview in Section 3 should also state explicitly that > > the > >>>> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that > >>> order. > >>> > >>> [Pascal] Yes, and this is what we mean by > >>> " As it scans all the candidate neighbors, OF0 keeps the parent > > that > >>> is > >>> the best for the following criteria (in order):" > >>> the language may not be perfect but I hardly think the reader can be > >>> getting the text wrong. > >>> I'm open to an editorial change if the sense is conserved. > >>> > >> > >> PC> I think the text you quoted above is very clear, but given its > >> PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or > >> PC> Section 3.2.1 of the suggested new order), it applies to > >> PC> parent selection. I'm saying there should be a sentence in the new > >> PC> Section 3 (overview) saying that we first compute > >> PC> Rank-Increase (Sec. 3.1), then select the preferred parent > >> PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then > >> PC> advertise Rank-Increase (Sec. 3.3). > >> PC> > >> PC> Maybe this is obvious, but I think it helps to state it > > explicitly. > >> PC> Especially since the guidelines given in > >> PC> (Section 14.1, draft-ietf-roll-rpl-19) are suggestions, > >> PC> rather than MUSTs: > >> PC> "Most Objective Functions are expected to follow..." > >> PC> And these suggestions don't say the steps must be followed in > >> PC> order either. > >> > >>>> > >>>> > >>>> 2) There have been two variables and one parameter defined in the > >>>> overview section, but they are not mentioned in Section 7, OF0 > >>> Constants > >>>> and Variables. > >>>> Variables: Step-of-Rank, Stretch-of-Rank > >>>> Parameters: Rank-factor > >>>> (I noticed that there is no MINIMUM_RANK_STRETCH and > >>>> DEFAULT_RANK_STRETCH and presume this is intentional.) > >>>> > >>> [Pascal] You're right. A stretch of 0 is acceptable so there is no > >>> MINIMUM. > >>> If there was a DEFAULT I expect it should be zero as well. By > >>> compliance with the main spec. > >>> I'm fine adding it. What do you think? > >>> > >> > >> PC> That would be nice for clarity. I think most implementors will > >> PC> use default values in a spec without a second thought unless they > >> PC> have a strong reason to do otherwise. > >> > >>>> Also, it would be nice to use underscore instead of hyphen for > >>>> variables, like in MRHOF (and use capital letters for parameters). > >>>> > >>> [Pascal] OK. I did not really mean those as variables, but why not. > >>> > >>>> Finally, how is Stretch-of-Rank computed? Implementation > > dependent? > >>> > >>> [Pascal] It is not computed. It is configured and can be left to 0. > > Does > >>> not have to be there at all in an implementation. > >>> I can clarify that. > >>> > >> > >> PC> OK. > >> > >>>> 3) How does one configure the parameter(s) (Rank-Factor) from the > >>> root? > >>>> (I just realized that this same comment applies to the > > parameters in > >>>> MRHOF as well). Or is that not configurable from the root, but > > must > >>> be > >>>> configured before deployment of the nodes? > >>> > >>> [Pascal] The Rank factor has to be a per node policy, like the > >>> Stretch-of-Rank. Right now, we do not have config containers to > >>> distribute it. > >>> > >>> > >>>> > >>>> 4) I think it would be nice to adopt the format of > >>>> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of > > for > >>> the > >>>> Terminology section. That is, write the word, then the definition > >>> (this > >>>> is not done for "feasible successor" in this section). Some other > >>> words > >>>> to define in this section are "Rank-increase," "RPL core," and > > "higher > >>>> order interface." Unless the last one is common IPv6 terminology > > that > >>> I > >>>> am unaware of... I was unable to tell if that meant the higher > > order > >>>> bits of the interface are higher, or if the interface is somehow > >>> preferred. > >>> > >>> I think that the RPL terminology is the place for having those in > >>> common. > >> > >> PC> Do you mean you or JP will add those terms and definitions to > >> PC> (draft-ietf-roll-terminology-05) or > >> PC> (Section 2, draft-ietf-roll-rpl-19)? I think the definition of > >> PC> "Rank-increase" belongs in OF0. > >> > >>> > >>>> > >>>> 5) Just a reminder that the discussion on Rank-increase in the > >>>> introduction section > >>>> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can > > be > >>>> stored in one octet." > >>>> needs to be aligned with text in Section 3, > >>>> "Ri =3D Rf*Sp + Sr" > >>>> so that they are consistent. I see you are discussing this with > >>> Omprakash. > >>> > >>> Sp and Sr are expressed as units of 0x100 and Rf is integer, so they > > are > >>> consistent. Do I miss something? > >>> > >> > >> PC> I see. I didn't realize that step_of_rank had to be a multiple of > >> PC> 0x100. You only mention at the bottom of page 3 that "The exact > >> PC> method for computing the Step-of-Rank is implementation- > dependent" > >> PC> and give bounds MINIMUM_STEP_OF_RANK and > >> MAXIMUM_STEP_OF_RANK > >> PC> that are multiples of MinHopRankIncrease. > >> PC> > >> PC> On a related note, there's a recent discussion of using the ETX > >> PC> directly (identity) as the rank, which doesn't match this > >> PC> requirement that step_of_rank be a multiple of 0x100 in OF0. In > >> PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a > >> PC> multiple of 128, not 256 (0x100). > >> PC> > >> PC> Is it actually necessary to mention "rank-increase" in the > >> PC> introduction, before the terminology section? Can we remove > >> "The Rank > >> of a node is obtained by adding a normalized scalar Rank-increase > > to > >> the Rank of a selected preferred parent. OF0 uses a unit of Rank- > >> increase of 0x100 so that Rank value can be stored in one octet. > >> This allows up to at least 28 hops even when default settings are > >> used and each hop has the worst Rank-increase of 9." > >> PC> Or move it some point later? It may be a bit confusing to bring > > up > >> PC> so much detail at this point in the text. > >> > >>>> > >>>> 6) I like the "Abstract Interface with RPL core" section, but would > > it > >>>> be better to separate them into "Input" and "Output"? That would > > end > >>> up > >>>> splitting up "Providing DAG information" and "Providing a Parent > > List" > >>>> into two pieces though. > >>>> > >>>> > >>>> More minor editorial comments to follow below, preceded by PC>. > >>> > >>> Thanks for those. I'll include them in a rev. > >>> > >>>> > >>>> -- > >>>> Phoebus Chen > >>>> Postdoctoral Researcher > >>>> Automatic Control Lab, KTH (Royal Institute of Technology) > >>>> http://www.ee.kth.se/~phoebus > >>>> > >>>> From internet-drafts@ietf.org Tue May 17 08:45:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5916E073C; Tue, 17 May 2011 08:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFrOoPY5avHe; Tue, 17 May 2011 08:45:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16102E06D9; Tue, 17 May 2011 08:45:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110517154558.27325.73120.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2011 08:45:58 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 May 2011 15:45:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-12.txt Pages : 11 Date : 2011-05-17 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of a specific Objective Function. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-12.txt From internet-drafts@ietf.org Tue May 17 12:52:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B004E078A; Tue, 17 May 2011 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWGRwGziq44Y; Tue, 17 May 2011 12:52:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FD8E06CE; Tue, 17 May 2011 12:52:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110517195253.27340.98291.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2011 12:52:53 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 May 2011 19:52:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : The Minimum Rank Objective Function with Hysteresis Author(s) : Omprakash Gnawali Philip Levis Filename : draft-ietf-roll-minrank-hysteresis-of-04.txt Pages : 10 Date : 2011-05-17 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0= 4.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-04= .txt From gnawali@cs.stanford.edu Tue May 17 12:57:46 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA5E0783 for ; Tue, 17 May 2011 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmf7L4+LNFzF for ; Tue, 17 May 2011 12:57:43 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id F11A0E06CA for ; Tue, 17 May 2011 12:57:42 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QMQOk-0003sH-Fk for roll@ietf.org; Tue, 17 May 2011 12:57:42 -0700 Received: by pvh18 with SMTP id 18so524600pvh.31 for ; Tue, 17 May 2011 12:57:42 -0700 (PDT) Received: by 10.68.21.231 with SMTP id y7mr1596323pbe.493.1305662262046; Tue, 17 May 2011 12:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Tue, 17 May 2011 12:57:22 -0700 (PDT) From: Omprakash Gnawali Date: Tue, 17 May 2011 12:57:22 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: f033b90f7cba6c0793427b12797f2d01 Subject: [Roll] updated draft-ietf-roll-minrank-hysteresis-of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 May 2011 19:57:46 -0000 -04 includes these changes: - JP's and Phoebus's editorial changes - Require that ETX is used without the container so we don't end up with "ETX inside a container" and "ETX as Rank" situation. - Manageability section that lists the parameters that can be configured. - om_p From pthubert@cisco.com Wed May 18 03:41:36 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0BE0679 for ; Wed, 18 May 2011 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=-1.417, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50JsfI-mSN1a for ; Wed, 18 May 2011 03:41:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E249E06C9 for ; Wed, 18 May 2011 03:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=107939; q=dns/txt; s=iport; t=1305715281; x=1306924881; h=mime-version:subject:date:message-id:from:to:cc; bh=B52hjXL2tORn4G5ytdLKimX3wKt6j9tP5XCJdq4Zkgg=; b=CNTH4cSmMifJA7EEWveMSEnb8CORVVT3G0WB8e3SzMZj2rSpcaLyw+kj /8o36aAKC19aEAnmzHcmu4Qk1lK+IZNzyRwABx9UlxrN4PECBxibd4rR+ Xeih97sOoiJeHiQZL/k8PtbWJre6qJvGwYYo+w9cwbh0FO66io2KZTcrD 4=; X-IronPort-AV: E=Sophos;i="4.65,230,1304294400"; d="scan'208,217";a="89189962" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 10:41:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4IAfJpc019155; Wed, 18 May 2011 10:41:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 12:41:19 +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_01CC1548.1F3BBB96" Date: Wed, 18 May 2011 12:41:16 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D049BC9EC@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Few comments on OF0 before publication request Thread-Index: AcwVSB0xNJtDWxcrS16rAOWpbECivA== From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 18 May 2011 10:41:19.0799 (UTC) FILETIME=[1F8BDC70:01CC1548] Cc: roll@ietf.org Subject: Re: [Roll] Few comments on OF0 before publication request X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 10:41:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1548.1F3BBB96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello JP: =20 Please see inline =20 Hi Pascal, =20 Here they are: =20 ROLL P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track May 5, 2011 Expires: November 6, 2011 =20 =20 RPL Objective Function 0 draft-ietf-roll-of0-11 =20 Abstract =20 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic=20 JP> Remove "generic" [Pascal] It is generic because it is instantiated by adding an OF. We reworded this with Phil already. =20 Distance Vector protocol that is adapted to such networks. JP> s/such networks/Low power and Lossy Networks (LLNs) [Pascal] ? that would give a quite convoluted: The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol that is adapted to for Low Power and Lossy Networks (LLNs) =20 =20 =20 RPL requires a specific Objective Function to establish a desired routing topology. This document specifies a basic Objective Function that relies only on RPL's basic Protocol Data Units JP> What do you mean by "protocol data units" ? [Pascal] what about : =20 This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. =20 =20 ; it does not use extensions such as RPL metric containers. JP> it does not require the use of routing metrics [Pascal] It does use metrics, static or dynamic. But it does not expose them on the wire(less). Again we've been through this at length with Phil.=20 =20 =20 Requirements Language =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. =20 Status of this Memo =20 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. =20 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. =20 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." =20 This Internet-Draft will expire on November 6, 2011. =20 Copyright Notice =20 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. =20 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents =20 =20 =20 Thubert Expires November 6, 2011 [Page 1] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. =20 =20 Table of Contents =20 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4 4. OF0 operations . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Feasible successors selection . . . . . . . . . . . . . . 6 4.2.1. Selection of the Preferred Parent . . . . . . . . . . 6 4.2.2. Selection of the backup feasible successor . . . . . . 7 5. Abstract Interface with RPL core . . . . . . . . . . . . . . . 8 6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Configurable parameters . . . . . . . . . . . . . . . . . 8 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 2] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 1. Introduction =20 The Routing Protocol for Low Power and Lossy Networks [I-D.ietf-roll-rpl] was designed as a generic core=20 JP> s/generic core/modular distance vector routing protocol [Pascal] I need the term core to differentiate what comes from the main engine and what's in the OF. =20 that is agnostic to metrics=20 JP>s/agnostic to metrics/that may not may not require the use of=20 routing metrics. and that is adapted to a given problem using Objective Functions (OF). This separation of Objective Functions from the core protocol specification allows RPL to adapt to meet the different optimization criteria required by the wide range of use cases. =20 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed in a new Version to enable a global reoptimization of the graph. =20 An Objective Function selects the DODAG Version that a device joins within an instance, and a number of neighbor routers within that DODAG Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by the generic RPL core=20 JP> avoid using the term "core" ...=20 [Pascal] same as above to enable a degree of loop avoidance and verify forward progression towards a destination, as specified in [I-D.ietf-roll-rpl]. =20 The Objective Function 0 (OF0) corresponds to the Objective Code Point 0 (OCP0).=20 JP> Code point can be defined later. [Pascal] ok OF0 only requires the information in the RPL DIO base container, such as Rank and the DODAGPreference field that describes an administrative preference [I-D.ietf-roll-rpl]. The Rank of a node is obtained by adding a normalized scalar, rank_increase, to the Rank of a selected preferred parent. OF0 uses a unit MinHopRankIncrease of rank_increase of 0x100 so that Rank value can be stored in one octet. This allows up to at least 28 hops even when default settings are used and each hop has the worst rank_increase of 9. JP> Clear for RPL designer but ... please elaborate on the last two sentences. [Pascal] ok Since there is no default OF or metric container in the RPL main specification, it might happen that, unless two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate. OF0 is designed to be common to all implementations that are not specifically designed to apply to a given case for which further guidance is provided. =20 JP> Confusing wording ... IMO you can remove the last sentence This is why it is very abstract=20 JP> Very abstract? [Pascal] very unspecific : ) =20 as to how the link properties are transformed into a rank_increase and leaves that responsibility to implementation; rather, OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range, as opposed to formulating the details of its computation. This is also why OF0 ignores metric containers. =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 3] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 2. Terminology =20 The terminology used in this document is consistent with and incorporates that described in `Terminology in Low power And Lossy Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. =20 The term feasible successor is used to refer to a neighbor that can possibly be used as a next-hop for upwards traffic following the loop avoidance and forwarding rules that the nodes implements and that are defined outside of this specification, in particular in the RPL specification. =20 JP> s/defined outside of this specification, in particular in the RPL specification./defined in [I-D.ietf-roll-rpl] [Pascal] ok =20 3. Objective Function 0 Overview =20 The core RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors. All parents are feasible successors for upgoing traffic (towards the root). Additionally, RPL allows the use of parents in a subsequent Version of a same DODAG as feasible successors, in which case this node acts as a leaf in the subsequent DODAG Version. Further specifications might extend the set of feasible successors, for instance to nodes of a same Rank, aka siblings. JP> Remove previous sentence, out of the scope. [Pascal] ok =20 The Goal=20 JP> s/Goal/objective [Pascal] can't. Comes from RPL: =20 Goal: The Goal is an application specific goal that is defined outside the scope of RPL. Any node that roots a DODAG will need to know about this Goal to decide if the Goal can be satisfied or not. A typical Goal is to construct the DODAG according to a specific objective function and to keep connectivity to a set of hosts (e.g. to use an objective function that minimizes a metric and to be connected to a specific database host to store the collected data). =20 of the OF0 is for a node to join a DODAG Version that offers connectivity to a specific set of nodes or to a larger routing infrastructure. =20 JP> Add "with no attempt to optimize the path according to a specific routing metric" [Pascal] OK =20 For the purpose of OF0, Grounded thus means that the root provides such connectivity. How that connectivity is asserted and maintained is out of scope. =20 Objective Function 0 is designed to find the nearest Grounded root. This can be achieved if the Rank of a node represents closely=20 JP> closely ? [Pascal] the more stretch the less close its distance to the root. This need is balanced with the other need of maintaining some path diversity. =20 JP> what do you mean by "balanced with the other need of maintaining some path diversity" ? [Pascal] Phil and I agreed on this text. Adding more =20 OF0 implementation might compute the step_of_rank from as a classical administrative cost that is assigned to the link. Using a metric similar to hop count implies that the OF0 implementation only considers neighbors with good enough connectivity, for instance neighbors that are reachable over an Ethernet link, or a WIFI link in infrastructure mode. JP> Not necesarily ... furthermore, why are you referring to Ethernet/Wifi links? =20 [Pascal] OK; removed. =20 =20 =20 In most wireless networks JP> s/in most wireless networks/in most LLNs , a Rank that is analogous to an unweighted hop count favors paths with long distance links=20 JP> Long distance links ? [Pascal] That's worst path first. Rewording again =20 and poor connectivity properties. Other link properties such as the expected transmission count metric (ETX) [DeCouto03] should be used=20 JP> should be used for what ? instead to compute the step_of_rank.=20 [Pascal] just above. Reworded again. =20 =20 =20 For instance, the Minimum Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how link cost can be computed and on how hysteresis can improve Rank stability. =20 An implementation MAY allow to stretch the step_of_rank with a stretch_of_rank=20 JP> refer to the section where this is defined [Pascal] OK up to no more than MAXIMUM_RANK_STRETCH in order to enable the selection of a feasible successor and maintain path diversity. =20 JP> you do no explain the implication on path diversity? =20 [Pascal] OK =20 The use of a stretch_of_rank augments the apparent distance from the node to the root and distorts the DODAG; it should be used with care so as to avoid instabilities due to greedy behaviours. JP> paragraph above too cryptic ...=20 =20 [Pascal] OK, rewording =20 The step_of_rank is expressed in units of MINIMUM_STEP_OF_RANK. As a result, the least significant octet in the RPL Rank is not used. The default step_of_rank is DEFAULT_STEP_OF_RANK for each hop. An implementation MUST maintain the stretched step_of_rank between MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to reflect a large variation of link quality. =20 The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. =20 An implementation SHOULD allow a configurable factor called Rank- factor and to apply the factor on all links and peers. JP> Factor used where and how ? =20 [Pascal] OK =20 An implementation MAY recognizes sub-categories of peers and links, such as different MAC types, in which case it SHOULD be able to configure a more specific Rank-factor to those categories. The Rank- factor SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. =20 =20 =20 Thubert Expires November 6, 2011 [Page 5] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 The step_of_rank Sp that is computed for that link is multiplied by the Rank-factor Rf and then possibly stretched by a stretch_of_rank Sr. The resulting rank_increase Ri is added to the Rank of preferred parent R(P) to obtain that of this node R(N): =20 R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease JP> Add a short example in appendix for clarity =20 [Pascal] I split based on Phoebus discussion. I think that's enough. =20 =20 Optionally, the administrative preference of a root MAY be configured to supersede the goal to join a Grounded DODAG. In that case, nodes will associate to the root with the highest preference available, regardless of whether that root is Grounded or not. Compared to a deployment with a multitude of Grounded roots that would result in a same multitude of DODAGs, such a configuration may result in possibly less but larger DODAGs, as many as roots configured with the highest priority in the reachable vicinity. =20 4.2. Feasible successors selection =20 4.2.1. Selection of the Preferred Parent =20 As it scans all the candidate neighbors, OF0 performs in order the following checks and keeps the parent that is the best for the first criterion that makes a difference: =20 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to reparent and in particular the boundaries to augment its Rank within a DODAG Version. =20 JP> point to the section in RPL core specification =20 [Pascal] ??? =20 A candidate that would not satisfy those rules MUST NOT be considered. =20 2. An implementation should=20 JP> should or SHOULD ? =20 [Pascal] deferred to RPL. So not SHOULDed here. =20 validate a router prior to selecting it as preferred. This validation process is implementation and link type dependent, and is out of scope. A router that has been validated is preferable. JP> You mean "ensure that the link is sufficiently stable" not "Validate the router" =20 [Pascal] deferred to RPL.=20 =20 =20 3. When multiple interfaces are available, a policy might be locally configured to order them and that policy applies first; that is a router on a higher order interface in the policy is preferable. =20 4. If the administrative preference of the root is configured to supersede the goal to join a Grounded DODAG, a router that offers connectivity to a more preferable root SHOULD be preferred. =20 5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not. =20 =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 6] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 6. A router that offers connectivity to a more preferable root SHOULD be preferred. =20 7. When comparing 2 routers=20 JP> s/2/two JP>s/routers/parents [Pascal] OK =20 that belong to the same DODAG, a router that offers connectivity to the freshest DODAG=20 JP>freshed =3D> higher Version =20 [Pascal] OK =20 Version SHOULD be preferred. =20 8. The parent that causes the lesser resulting Rank for this node, as specified in Section 4.1, SHOULD be preferred. =20 9. A DODAG Version for which there is an alternate parent SHOULD be preferred. This check is optional. It is performed by computing the backup feasible successor while assuming that the router that is currently examined is finally selected as preferred parent. =20 10. The preferred parent that was in use already SHOULD be preferred. =20 11. A router that has announced a DIO message more recently SHOULD be preferred. =20 4.2.2. Selection of the backup feasible successor =20 When selecting a backup feasible successor, the OF performs in order the following checks: =20 1. When multiple interfaces are available, a router on a higher order interface is preferable. =20 2. The backup feasible successor MUST NOT be the preferred parent. =20 3. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent DODAG Version. =20 4. Along with RPL rules, a Router in the same DODAG Version as this node and with a Rank that is higher than the Rank computed for this node MUST NOT be selected as a feasible successor. =20 5. A router with a lesser Rank SHOULD be preferred. =20 6. A router that has been validated as usable by an implementation dependant validation process SHOULD be preferred. =20 7. The backup feasible successor that was in use already SHOULD be preferred. =20 =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 7] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 5. Abstract Interface with RPL core =20 Objective Function 0 interacts with the core RPL in the following ways: =20 Processing DIO: This core RPL=20 JP> core RPL triggers ?? =20 [Pascal] OK, reworded =20 triggers the OF when a new DIO was received. OF0 analyses the information in the DIO and may select the source as a parent or sibling. JP> Remove sibling =20 [Pascal] OK =20 Providing DAG information: The OF is called to provide information about a given instance. This includes material from the DIO base header, the role (router, leaf), and the Rank of this node. JP> what are you defining here ? =20 Providing a Parent List: The OF0 support can be required=20 JP> required by who ? =20 [Pascal] OK, reworded =20 to provide the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry. =20 Trigger: The OF0 support may trigger the RPL core to inform it that a change occurred. This can be used to indicate whether the change requires a new DIO to be fired or whether trickle timers need to be reset. JP> Part of this section belong to a manageability section =20 [Pascal] ? =20 6. OF0 Operands =20 6.1. Variables =20 OF0 uses the following variables: =20 step_of_rank (unsigned integer): an intermediate computation based on the link properties with a certain neighbor. =20 rank-increase (unsigned integer): delta between the Rank of the preferred parent and self =20 6.2. Configurable parameters =20 OF0 can use the following optional parameters: =20 stretch_of_rank (unsigned integer): an optional augmentation to the step-of-rank of the preferred parent to allow the selection of additional parents. =20 rank_factor (unsigned integer): A configurable factor that is used to multiply the effect of the link properties in the rank_increase computation. =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 8] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 6.3. Constants =20 OF0 fixes the following constants: =20 MinHopRankIncrease: 256 =20 DEFAULT_STEP_OF_RANK: 3 =20 MINIMUM_STEP_OF_RANK: 1 =20 MAXIMUM_STEP_OF_RANK: 9 =20 DEFAULT_RANK_STRETCH: 0 =20 MAXIMUM_RANK_STRETCH: 5 =20 DEFAULT_RANK_FACTOR: 1 =20 MINIMUM_RANK_FACTOR: 1 =20 MAXIMUM_RANK_FACTOR: 4 =20 =20 7. IANA Considerations =20 This specification requires the assignment of an OCP for OF0. The value of 0 is suggested. =20 =20 8. Security Considerations =20 Security Considerations for OCP/OF are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. =20 =20 9. Acknowledgements =20 Most specific thanks to Philip Levis and Phoebus Chen for their help in finalizing this document. =20 Many thanks also to Tim Winter, JP Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in-depth review and first hand implementer's feedback. =20 =20 10. References =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 9] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 10.1. Normative References =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. =20 10.2. Informative References =20 [DeCouto03] De Couto, Aguayo, Bicket, and Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03 The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California,, 2003, . =20 [I-D.ietf-roll-minrank-hysteresis-of] Gnawali, O. and P. Levis, "The Minimum Rank Objective Function with Hysteresis", draft-ietf-roll-minrank-hysteresis-of-03 (work in progress), May 2011. =20 [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-19 (work in progress), March 2011. JP> Note referenced anywhere in the document. =20 [Pascal] OK, removed =20 =20 =20 [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. =20 [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-05 (work in progress), March 2011. =20 [I-D.tsao-roll-security-framework] Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-02 (work in progress), March 2010. =20 =20 JP> ID NITS: =20 [Pascal] ??? =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 10] =20 Internet-Draft draft-ietf-roll-of0 May 2011 =20 =20 Author's Address =20 Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE =20 Phone: +33 497 23 26 34 Email: pthubert@cisco.com =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Thubert Expires November 6, 2011 [Page 11] =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CC1548.1F3BBB96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello JP:

 

Please see inline

 

Hi = Pascal,

 

Here they are:

 

ROLL  &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =
  P. Thubert, =
Ed.
Internet-Draft     &nbs=
p;            =
;            =
            &=
nbsp;  Cisco Systems
Intended status: =
Standards =
Track           &n=
bsp;        =
         May 5, =
2011
Expires: November 6, =
2011
 
 
          &nbs=
p;            =
; RPL Objective Function =
0
        &n=
bsp;           &nb=
sp;    =
draft-ietf-roll-of0-11
 
A=
bstract
 
   =
The Routing Protocol for Low Power and Lossy Networks (RPL) defines =
a
   =
generic 
JP> =
Remove "generic"
[Pascal] It is generic because it is instantiated by adding an OF. We =
reworded this with Phil already.
 
Distance Vector protocol that is =
adapted to such networks.
JP> =
s/such networks/Low power and Lossy Networks =
(LLNs)
[Pascal] ? that would give a quite convoluted:
    The Routing =
Protocol for Low Power and Lossy Networks (RPL) defines =
a
   generic Distance Vector =
protocol that is adapted to for Low =
Power
   and Lossy Networks =
(LLNs)
 
 
 
   RPL requires a =
specific Objective Function to establish a =
desired
   routing topology.  This =
document specifies a basic Objective =
Function
   that relies only on RPL's =
basic Protocol Data Units
JP> What =
do you mean by "protocol data units" ?
[Pascal] what =
about :
 
   =
            &=
nbsp;           &n=
bsp;          This =
document specifies a basic
   =
Objective Function that relies only on the objects that are =
defined
   in RPL =
and does not use any extension.
 
 
; it does not =
use
   extensions such as RPL metric =
containers.
JP> it =
does not require the use of routing metrics
[Pascal] It does use metrics, static or dynamic. But it does not =
expose them on the wire(less).
Again we’ve been through this at length with Phil. =

 
 
Require=
ments =
Language
 
   =
The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL =
NOT",
   "SHOULD", =
"SHOULD NOT", "RECOMMENDED", "MAY", and =
"OPTIONAL" in this
   document =
are to be interpreted as described in RFC 2119 =
[RFC2119].
 
Status of =
this Memo
 
   =
This Internet-Draft is submitted in full conformance with =
the
   provisions of BCP 78 and BCP =
79.
 
   =
Internet-Drafts are working documents of the Internet =
Engineering
   Task Force (IETF).  =
Note that other groups may also =
distribute
   working documents as =
Internet-Drafts.  The list of current =
Internet-
   Drafts is at http://datatracker.i=
etf.org/drafts/current/.
 
=

   Internet-Drafts are draft documents valid for a =
maximum of six months
   and may be =
updated, replaced, or obsoleted by other documents at =
any
   time.  It is inappropriate to =
use Internet-Drafts as reference
   =
material or to cite them other than as "work in =
progress."
 
 &n=
bsp; This Internet-Draft will expire on November 6, =
2011.
 
Copyright =
Notice
 
   =
Copyright (c) 2011 IETF Trust and the persons identified as =
the
   document authors.  All rights =
reserved.
 
   =
This document is subject to BCP 78 and the IETF Trust's =
Legal
   Provisions Relating to IETF =
Documents
 
 
 
Thubert    =
             =
Expires November 6, =
2011           &nb=
sp;    [Page =
1]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
   (http://trustee.ietf.org/lic=
ense-info) in effect on the date =
of
   publication of this document.  =
Please review these documents
   =
carefully, as they describe your rights and restrictions with =
respect
   to this document.  Code =
Components extracted from this document =
must
   include Simplified BSD License =
text as described in Section 4.e of
   =
the Trust Legal Provisions and are provided without warranty =
as
   described in the Simplified BSD =
License.
 
 
Table of =
Contents
 
   =
1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . =
.  3
   2.  Terminology  . =
. . . . . . . . . . . . . . . . . . . . . . . .  =
4
   3.  Objective Function 0 =
Overview  . . . . . . . . . . . . . . . .  =
4
   4.  OF0 operations . . . . . . =
. . . . . . . . . . . . . . . . . .  =
5
     4.1.  Computing =
Rank . . . . . . . . . . . . . . . . . . . . . .  =
5
     4.2.  Feasible =
successors selection  . . . . . . . . . . . . . .  =
6
       4.2.1.  =
Selection of the Preferred Parent  . . . . . . . . . .  =
6
       4.2.2.  =
Selection of the backup feasible successor . . . . . .  =
7
   5.  Abstract Interface with RPL =
core . . . . . . . . . . . . . . .  =
8
   6.  OF0 Operands . . . . . . . =
. . . . . . . . . . . . . . . . . .  =
8
     6.1.  =
Variables  . . . . . . . . . . . . . . . . . . . . . . . .  =
8
     6.2.  Configurable =
parameters  . . . . . . . . . . . . . . . . .  =
8
     6.3.  =
Constants  . . . . . . . . . . . . . . . . . . . . . . . .  =
9
   7.  IANA Considerations  . =
. . . . . . . . . . . . . . . . . . . .  =
9
   8.  Security =
Considerations  . . . . . . . . . . . . . . . . . . .  =
9
   9.  Acknowledgements . . . . . =
. . . . . . . . . . . . . . . . . .  =
9
   10. References . . . . . . . . . . . =
. . . . . . . . . . . . . . . =
10
     10.1. Normative =
References . . . . . . . . . . . . . . . . . . . =
10
     10.2. Informative =
References . . . . . . . . . . . . . . . . . . =
10
   Author's Address . . . . . . . . . =
. . . . . . . . . . . . . . . . =
10
 
 
 
 
 =
;
 
 
 
 
 
 
 
=
 
 
 
 
 
 =

 
 
=
Thubert           =
      Expires November 6, =
2011           &nb=
sp;    [Page =
2]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
1.  =
Introduction
 
  =
; The Routing Protocol for Low Power and Lossy =
Networks
   [I-D.ietf-roll-rpl] was =
designed as a generic core 
JP> =
s/generic core/modular distance vector routing =
protocol
[Pascal] I need the term core to differentiate what comes from the =
main engine and what’s in the =
OF.
 
that is =
agnostic
   to =
metrics 
JP>s/agno=
stic to metrics/that may not may not require the use =
of 
routing =
metrics.
and that is adapted to a =
given problem using Objective
   =
Functions (OF).  This separation of Objective Functions from the =
core
   protocol specification allows RPL =
to adapt to meet the different
   =
optimization criteria required by the wide range of use =
cases.
 
   RPL =
forms Destination Oriented Directed Acyclic Graphs =
(DODAGs)
   within instances of the =
protocol.  Each instance is associated with =
a
   specialized Objective =
Function.  A DODAG is =
periodically
   reconstructed in a new =
Version to enable a global reoptimization =
of
   the =
graph.
 
   An =
Objective Function selects the DODAG Version that a device =
joins
   within an instance, and a number =
of neighbor routers within that
   DODAG =
Version as parents or feasible successors.  The OF =
generates
   the Rank of the device, that =
represents an abstract distance to the
   =
root within the DODAG.  In turn, the Rank is used by the generic =
RPL
   =
core 
JP> =
avoid using the term "core" ... 
[Pascal] same as above
to enable a degree of loop avoidance and =
verify forward
   progression towards a =
destination, as specified in
   =
[I-D.ietf-roll-rpl].
 
&nb=
sp;  The Objective Function 0 (OF0) corresponds to the Objective =
Code
   Point 0 =
(OCP0). 
JP> Code =
point can be defined later.
[Pascal] ok
 OF0 only requires the information in =
the RPL DIO
   base container, such as =
Rank and the DODAGPreference field =
that
   describes an administrative =
preference [I-D.ietf-roll-rpl].  The =
Rank
   of a node is obtained by adding a =
normalized scalar, rank_increase,
   to =
the Rank of a selected preferred parent.  OF0 uses a =
unit
   MinHopRankIncrease of =
rank_increase of 0x100 so that Rank value =
can
   be stored in one octet.  This =
allows up to at least 28 hops even =
when
   default settings are used and =
each hop has the worst rank_increase =
of
   9.
JP> =
Clear for RPL designer but ... please elaborate on the last two =
sentences.
[Pascal] ok
   Since there is no default =
OF or metric container in the RPL main
   =
specification, it might happen that, unless two given =
implementations
   follow the same =
guidance for a specific problem or environment, =
those
   implementations will not support =
a common OF with which they could
   =
interoperate.  OF0 is designed to be common to all =
implementations
   that are not =
specifically designed to apply to a given case for =
which
   further guidance is provided. =
 
JP> =
Confusing wording ... IMO you can remove the last =
sentence
This is why it is very =
abstract 
JP> Very =
abstract?
[Pascal] very unspecific : )
 
as =
to
   how the link properties are =
transformed into a rank_increase and
   =
leaves that responsibility to implementation; rather, OF0 =
enforces
   normalized values for the =
rank_increase of a normal link and its
   =
acceptable range, as opposed to formulating the details of =
its
   computation.  This is also =
why OF0 ignores metric =
containers.
 
 <=
/o:p>
 
 
T=
hubert           &=
nbsp;     Expires November 6, =
2011           &nb=
sp;    [Page =
3]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
2.  =
Terminology
 
  =
 The terminology used in this document is consistent with =
and
   incorporates that described in =
`Terminology in Low power And Lossy
   =
Networks' [I-D.ietf-roll-terminology] and =
[I-D.ietf-roll-rpl].
 
&nb=
sp;  The term feasible successor is used to refer to a neighbor =
that can
   possibly be used as a =
next-hop for upwards traffic following the =
loop
   avoidance and forwarding rules =
that the nodes implements and that are
   =
defined outside of this specification, in particular in the =
RPL
   =
specification.
 
JP> =
s/defined outside of this specification, in particular =
in the RPL
   specification./defined in =
[I-D.ietf-roll-rpl]
 [Pascal] ok
 
3.  Objective Function 0 =
Overview
 
   =
The core RPL specification describes constraints on how nodes =
select
   potential parents, called a =
parent set, from their neighbors.  =
All
   parents are feasible successors =
for upgoing traffic (towards the
   =
root).  Additionally, RPL allows the use of parents in a =
subsequent
   Version of a same DODAG as =
feasible successors, in which case =
this
   node acts as a leaf in the =
subsequent DODAG Version.  =
Further
   specifications might extend =
the set of feasible successors, for
   =
instance to nodes of a same Rank, aka =
siblings.
JP> =
Remove previous sentence, out of the scope.
[Pascal] ok
 
   =
The Goal 
JP> =
s/Goal/objective
[Pascal] can’t. Comes from RPL:
 
   Goal: =
The Goal is an application specific goal that is =
defined
         outside the scope =
of RPL.  Any node that roots a DODAG will
         need to know =
about this Goal to decide if the Goal can be
         satisfied or =
not.  A typical Goal is to construct the =
DODAG
         according to a =
specific objective function and to keep
         connectivity to a =
set of hosts (e.g. to use an objective
         function that =
minimizes a metric and to be connected to a
         specific database =
host to store the collected data).
 
of the OF0 is for a node to join a =
DODAG Version that offers
   connectivity =
to a specific set of nodes or to a larger =
routing
   infrastructure. =
 
JP> Add =
"with no attempt to optimize the path according to a =
specific
routing =
metric"
[Pascal] OK
 
For the purpose of OF0, Grounded =
thus means that the
   root provides such =
connectivity.  How that connectivity is =
asserted
   and maintained is out of =
scope.
 
   =
Objective Function 0 is designed to find the nearest Grounded =
root.
   This can be achieved if the Rank =
of a node represents closely 
JP> =
closely ?
[Pascal] the more stretch the less close
its
   =
distance to the root.  This need is balanced with the other need =
of
   maintaining some path diversity. =
 
JP> what =
do you mean by "balanced with the other need of =
maintaining
some<=
/i> path =
diversity" ?
[Pascal] Phil and I agreed on this text. Adding more
 
OF0 implementation might compute =
the step_of_rank from as
   a classical =
administrative cost that is assigned to the link.  =
Using
   a metric similar to hop count =
implies that the OF0 implementation
   =
only considers neighbors with good enough connectivity, for =
instance
   neighbors that are reachable =
over an Ethernet link, or a WIFI link =
in
   infrastructure =
mode.
JP> Not =
necesarily ... furthermore, why are you referring to Ethernet/Wifi =
links?
 
[Pascal] OK; removed.
 
&nbs=
p;
 
   In most =
wireless networks
JP> s/in =
most wireless networks/in most =
LLNs
, a Rank that is analogous =
to an unweighted
   hop count favors =
paths with long distance links 
JP> Long =
distance links ?
[Pascal] That’s worst path first. Rewording =
again<=
/span>
 
and poor =
connectivity
   properties.  Other =
link properties such as the expected =
transmission
   count metric (ETX) =
[DeCouto03] should be used 
JP> =
should be used for what ?
instead =
to compute the
   step_of_rank. =

[Pascal] just above. Reworded again.
 
&nbs=
p;
 
 For instance, the =
Minimum Rank Objective Function with
   =
Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance =
on
   how link cost can be computed and =
on how hysteresis can improve Rank
   =
stability.
 
   =
An implementation MAY allow to stretch the step_of_rank with =
a
   =
stretch_of_rank 
JP> =
refer to the section where this is =
defined
[Pascal] OK
up to no more than =
MAXIMUM_RANK_STRETCH in order to
   =
enable the selection of a feasible successor and maintain =
path
   diversity. =
 
JP> you =
do no explain the implication on path =
diversity?
 <=
/o:p>
[Pascal] =
OK
 
The =
use of a stretch_of_rank augments the =
apparent
   distance from the node to the =
root and distorts the DODAG; it should
   =
be used with care so as to avoid instabilities due to =
greedy
   =
behaviours.
JP> =
paragraph above too cryptic =
... 
 <=
/o:p>
[Pascal] OK, =
rewording
 
   The step_of_rank is expressed in units of =
MINIMUM_STEP_OF_RANK.  As a
   =
result, the least significant octet in the RPL Rank is not used.  =
The
   default step_of_rank is =
DEFAULT_STEP_OF_RANK for each hop.  =
An
   implementation MUST maintain the =
stretched step_of_rank between
   =
MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows =
to
   reflect a large variation of link =
quality.
 
   =
The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may =
not
   be sufficient in every case to =
strongly distinguish links of
   =
different types or categories in order to favor, say, powered =
over
   battery-operated or wired over =
wireless, within a same =
DAG.
 
   An =
implementation SHOULD allow a configurable factor called =
Rank-
   factor and to apply the factor =
on all links and peers.
JP> =
Factor used where and how ?
 <=
/o:p>
[Pascal] =
OK
 
 =
  An implementation MAY recognizes sub-categories of peers and =
links,
   such as different MAC types, in =
which case it SHOULD be able to
   =
configure a more specific Rank-factor to those categories.  The =
Rank-
   factor SHOULD be set between =
MINIMUM_RANK_FACTOR and
   =
MAXIMUM_RANK_FACTOR.
 
 
 
Thubert  &=
nbsp;           &n=
bsp;  Expires November 6, =
2011           &nb=
sp;    [Page =
5]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
   The step_of_rank Sp that is computed for that link =
is multiplied by
   the Rank-factor Rf =
and then possibly stretched by a stretch_of_rank
 =
  Sr. The resulting rank_increase Ri is added to the Rank of =
preferred
   parent R(P) to obtain that =
of this node =
R(N):
 
   R(N) =
=3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * =
MinHopRankIncrease
JP> Add =
a short example in appendix for =
clarity
 <=
/o:p>
[Pascal] I split based on Phoebus discussion. I think that’s =
enough.
 
<=
o:p> 
   Optionally, the administrative =
preference of a root MAY be configured
   =
to supersede the goal to join a Grounded DODAG.  In that case, =
nodes
   will associate to the root with =
the highest preference available,
   =
regardless of whether that root is Grounded or not.  Compared to =
a
   deployment with a multitude of =
Grounded roots that would result in a
   =
same multitude of DODAGs, such a configuration may result in =
possibly
   less but larger DODAGs, as =
many as roots configured with the =
highest
   priority in the reachable =
vicinity.
 
4.2.  =
Feasible successors =
selection
 
4.2.1.  =
Selection of the Preferred =
Parent
 
   As =
it scans all the candidate neighbors, OF0 performs in order =
the
   following checks and keeps the =
parent that is the best for the first
   =
criterion that makes a =
difference:
 
  =
 1.   [I-D.ietf-roll-rpl] spells out the generic rules for a =
node to
        =
reparent and in particular the boundaries to augment its =
Rank
        =
within a DODAG Version.  
JP> =
point to the section in RPL core =
specification
 <=
/o:p>
[Pascal] =
???
 
A =
candidate that would not =
satisfy
        =
those rules MUST NOT be =
considered.
 
  =
 2.   An implementation =
should 
JP> =
should or SHOULD ?
 <=
/o:p>
[Pascal] deferred to RPL. So not SHOULDed =
here.
 
val=
idate a router prior to selecting =
it
        as =
preferred.  This validation process is implementation =
and
        link =
type dependent, and is out of scope.  A router that =
has
        been =
validated is preferable.
JP> You =
mean "ensure that the link is sufficiently stable" not =
"Validate
the =
router"
 <=
/o:p>
[Pascal] deferred to RPL. =

 
&nb=
sp;
   3.   When multiple interfaces =
are available, a policy might =
be
        =
locally configured to order them and that policy applies =
first;
        =
that is a router on a higher order interface in the policy =
is
        =
preferable.
 
  =
 4.   If the administrative preference of the root is =
configured =
to
        =
supersede the goal to join a Grounded DODAG, a router =
that
        =
offers connectivity to a more preferable root SHOULD =
be
        =
preferred.
 
   =
5.   A router that offers connectivity to a grounded DODAG =
Version
        =
SHOULD be preferred over one that does =
not.
 
 
 
 
&nb=
sp;
Thubert       &nbs=
p;         Expires November 6, =
2011           &nb=
sp;    [Page =
6]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
   6.   A router that offers connectivity =
to a more preferable =
root
        =
SHOULD be =
preferred.
 
   =
7.   When comparing 2 routers 
JP> =
s/2/two
JP>s/rout=
ers/parents
[Pascal] =
OK
 
that =
belong to the same DODAG, a =
router
        =
that offers connectivity to the freshest =
DODAG 
JP>freshe=
d =3D> higher Version
 <=
/o:p>
[Pascal] =
OK
 
Versio=
n SHOULD =
be
        =
preferred.
 
   =
8.   The parent that causes the lesser resulting Rank for this =
node,
        as =
specified in Section 4.1, SHOULD be =
preferred.
 
   =
9.   A DODAG Version for which there is an alternate parent =
SHOULD =
be
        =
preferred.  This check is optional.  It is performed =
by
        =
computing the backup feasible successor while assuming that =
the
        =
router that is currently examined is finally selected =
as
        =
preferred =
parent.
 
   =
10.  The preferred parent that was in use already SHOULD =
be
        =
preferred.
 
   =
11.  A router that has announced a DIO message more recently =
SHOULD
        =
be =
preferred.
 
4.2.2.  =
Selection of the backup feasible =
successor
 
   =
When selecting a backup feasible successor, the OF performs in =
order
   the following =
checks:
 
   =
1.  When multiple interfaces are available, a router on a =
higher
       order =
interface is =
preferable.
 
  =
 2.  The backup feasible successor MUST NOT be the preferred =
parent.
 
   =
3.  The backup feasible successor MUST be either in the same =
DODAG
       Version =
as this node or in an subsequent DODAG =
Version.
 
   =
4.  Along with RPL rules, a Router in the same DODAG Version as =
this
       node and =
with a Rank that is higher than the Rank computed =
for
       this node =
MUST NOT be selected as a feasible =
successor.
 
   =
5.  A router with a lesser Rank SHOULD be =
preferred.
 
   =
6.  A router that has been validated as usable by an =
implementation
       =
dependant validation process SHOULD be =
preferred.
 
   =
7.  The backup feasible successor that was in use already SHOULD =
be
       =
preferred.
 
 
 
 
 
Thubert      &nbs=
p;          Expires =
November 6, =
2011           &nb=
sp;    [Page =
7]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
5.  Abstract Interface with RPL =
core
 
   =
Objective Function 0 interacts with the core RPL in the =
following
   =
ways:
 
   =
Processing DIO:  This core RPL 
JP> core =
RPL triggers ??
 <=
/o:p>
[Pascal] OK, =
reworded
 
=
triggers the OF when a new DIO =
was
      received.  =
OF0 analyses the information in the DIO and may =
select
      the source as =
a parent or sibling.
JP> =
Remove sibling
 <=
/o:p>
[Pascal] =
OK
 
 =
  Providing DAG information:  The OF is called to provide =
information
      about a =
given instance.  This includes material from the DIO =
base
      header, the =
role (router, leaf), and the Rank of this =
node.
JP> what =
are you defining here =
?
 
&nbs=
p;  Providing a Parent List:  The OF0 support can be =
required 
JP> =
required by who ?
 <=
/o:p>
[Pascal] OK, =
reworded
 
=
to provide
      the =
ordered list of the parents and feasible successors for =
a
      given instance to =
the RPL core.  This includes the material =
that
      is contained in =
the transit option for each =
entry.
 
   =
Trigger:  The OF0 support may trigger the RPL core to inform it =
that
      a change =
occurred.  This can be used to indicate whether =
the
      change requires =
a new DIO to be fired or whether trickle =
timers
      need to be =
reset.
JP> Part =
of this section belong to a manageability =
section
 <=
/o:p>
[Pascal] =
?
 
6. =
; OF0 =
Operands
 
6.1.  =
Variables
 
   =
OF0 uses the following =
variables:
 
   =
step_of_rank (unsigned integer):  an intermediate computation =
based
      on the link =
properties with a certain =
neighbor.
 
   =
rank-increase (unsigned integer):  delta between the Rank of =
the
      preferred parent =
and self
 
6.2.  =
Configurable =
parameters
 
   =
OF0 can use the following optional =
parameters:
 
  =
 stretch_of_rank (unsigned integer):  an optional augmentation to =
the
      step-of-rank of =
the preferred parent to allow the selection =
of
      additional =
parents.
 
   =
rank_factor (unsigned integer):  A configurable factor that is =
used
      to multiply the =
effect of the link properties in the =
rank_increase
      =
computation.
 
 =

 
 
=
Thubert           =
      Expires November 6, =
2011           &nb=
sp;    [Page =
8]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
6.3.  =
Constants
 
   =
OF0 fixes the following =
constants:
 
   =
MinHopRankIncrease:  =
256
 
   =
DEFAULT_STEP_OF_RANK:  =
3
 
   =
MINIMUM_STEP_OF_RANK:  =
1
 
   =
MAXIMUM_STEP_OF_RANK:  =
9
 
   =
DEFAULT_RANK_STRETCH:  =
0
 
   =
MAXIMUM_RANK_STRETCH:  =
5
 
   =
DEFAULT_RANK_FACTOR:  =
1
 
   =
MINIMUM_RANK_FACTOR:  =
1
 
   =
MAXIMUM_RANK_FACTOR:  =
4
 
 
7.  IANA =
Considerations
 
 &nb=
sp; This specification requires the assignment of an OCP for OF0.  =
The
   value of 0 is =
suggested.
 
 
8.  Security =
Considerations
 
 &nb=
sp; Security Considerations for OCP/OF are to be developed in =
accordance
   with recommendations laid =
out in, for example,
   =
[I-D.tsao-roll-security-framework].
 
 
9.  =
Acknowledgements
 
 &=
nbsp; Most specific thanks to Philip Levis and Phoebus Chen for their =
help
   in finalizing this =
document.
 
   =
Many thanks also to Tim Winter, JP Vasseur, Julien Abeille, =
Mathilde
   Durvy, Teco Boot, Navneet =
Agarwal and Henning Rogge for in-depth
   =
review and first hand implementer's =
feedback.
 
 
10.  =
References
 
 
 
 
Th=
ubert       =
          Expires =
November 6, =
2011           &nb=
sp;    [Page =
9]
 
Internet-Draft &=
nbsp;           =
draft-ietf-roll-of0         =
         May =
2011
 
 
10.1.  Normative =
References
 
   =
[RFC2119]  Bradner, S., "Key words for use in RFCs to =
Indicate
       &=
nbsp;      Requirement Levels", BCP 14, =
RFC 2119, March =
1997.
 
10.2.  =
Informative =
References
 
   =
[DeCouto03]
      &nbs=
p;       De Couto, Aguayo, Bicket, and =
Morris, "A =
High-Throughput
      =
        Path Metric for Multi-Hop =
Wireless Routing", =
MobiCom
       &n=
bsp;      '03 The 9th ACM International =
Conference on =
Mobile
       &nb=
sp;      Computing and Networking, San Diego, =
California,, 2003, =
<h
       &nbs=
p;      ttp://p=
dos.csail.mit.edu/papers/grid:mobicom03/paper.pdf>.
 
   =
[I-D.ietf-roll-minrank-hysteresis-of]
  &n=
bsp;           =
Gnawali, O. and P. Levis, "The Minimum Rank =
Objective
       =
       Function with =
Hysteresis",
     &nbs=
p;        =
draft-ietf-roll-minrank-hysteresis-of-03 (work =
in
        &=
nbsp;     progress), May =
2011.
 
   =
[I-D.ietf-roll-routing-metrics]
   &n=
bsp;          Vasseur, J., =
Kim, M., Pister, K., Dejean, N., and =
D.
        &=
nbsp;     Barthel, "Routing Metrics used for =
Path Calculation in =
Low
        =
      Power and Lossy =
Networks",
      =
        =
draft-ietf-roll-routing-metrics-19 (work in =
progress),
       =
;       March =
2011.
JP> Note =
referenced anywhere in the =
document.
 <=
/o:p>
[Pascal] OK, =
removed
 
<=
o:p> 
 
   =
[I-D.ietf-roll-rpl]
     &n=
bsp;        Winter, T., Thubert, P., =
Brandt, A., Clausen, T., Hui, =
J.,
        =
      Kelsey, R., Levis, P., Pister, K., =
Struik, R., and =
J.
        &=
nbsp;     Vasseur, "RPL: IPv6 Routing Protocol =
for Low power =
and
        =
      Lossy Networks", =
draft-ietf-roll-rpl-19 (work =
in
        &=
nbsp;     progress), March =
2011.
 
   =
[I-D.ietf-roll-terminology]
    =
          Vasseur, J., =
"Terminology in Low power And =
Lossy
       &nbs=
p;      Networks", =
draft-ietf-roll-terminology-05 (work =
in
        &=
nbsp;     progress), March =
2011.
 
   =
[I-D.tsao-roll-security-framework]
   =
;           Tsao, T., =
Alexander, R., Daza, V., and A. Lozano, =
"A
       &n=
bsp;      Security Framework for Routing over =
Low Power and =
Lossy
       &nbs=
p;      Networks", =
draft-tsao-roll-security-framework-02 (work =
in
        &=
nbsp;     progress), March =
2010.
 
 <=
/pre>
JP> ID =
NITS:
 
=
[Pascal] =
 ???
 
 
 
 
Thubert         =
        Expires November 6, =
2011           &nb=
sp;   [Page =
10]
 
Internet-Draft =
            =
draft-ietf-roll-of0         =
         May =
2011
 
 
Author's =
Address
 
   =
Pascal Thubert (editor)
   Cisco Systems
   Village d'Entreprises Green =
Side
   400, =
Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  =
06410
   =
FRANCE
 
   Phone: +33 497 23 26 =
34
   Email: =
pthubert@cisco.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Thubert         &n=
bsp;       Expires November 6, =
2011           &nb=
sp;   [Page 11]
 
 

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

 

------_=_NextPart_001_01CC1548.1F3BBB96-- From alexandru.petrescu@gmail.com Wed May 18 07:13:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87CDE06A1 for ; Wed, 18 May 2011 07:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd5yxPRzwopC for ; Wed, 18 May 2011 07:13:31 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C9518E067B for ; Wed, 18 May 2011 07:13:30 -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.2) with ESMTP id p4IEDSDY019151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 May 2011 16:13:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p4IEDS9D011626; Wed, 18 May 2011 16:13:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p4IEDSss009723; Wed, 18 May 2011 16:13:28 +0200 Message-ID: <4DD3D408.6050404@gmail.com> Date: Wed, 18 May 2011 16:13:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: roll@ietf.org References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> In-Reply-To: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 14:13:31 -0000 I think that, in the network you depicted, where a node has several real IP-enabled interfaces, RPL should not be forced into using more than one instance. +-------------+ | Root | | | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ (by comparison, OSPF running on this network does not _need_ several instances. It has a single daemon per machine, with a single view of the network as reflected in its database.) (my two cents worth). Alex Le 12/05/2011 20:25, Sun, Yanjun a écrit : > Hello All, I’m new to this mailing list. I’m trying to figure out how > to configure/run RPL on a node with two interfaces. Following the > rules of RPL, I came up with several configurations even for a simple > two node network below. Could you please comment on whether they make > sense and whether there is any better alternative? As most discussion > in RPL is focused on nodes with single interface (though I strongly > believe it’ll work well for multiple interfaces), the configuration > really puzzled me. So I would appreciate if anyone could help me > out. I’d like to use a very simple network to describe my questions. > Node 1 is the root and node 2 is a leaf. Both nodes have two wired > interfaces. A1 is connected to A2 and B1 is connected to B2. we’d > like to find out what’s the best way to configure RPL for such a > network to forward packets on both links. +-------------+ | Root | | > | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | > | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ I > could think of two possible configurations. In the first RPL > configuration, I let node 1 use only *one* instance, INST1. One DIO > message with A1 as DODAGID will be broadcast over both interfaces A1 > and B1. Then another message with B1 as DODAGID will be also > broadcast over both interfaces. Based on the RPL draft that limits a > node to join only one DODAG given an instance ID, node 2 can only > choose one link to join node 1 and leave the other link *unused*. In > the second configuration, I let node 1 to use *two* instances, INST1 > and INST2. One DIO message with A1 as DODAGID and INST1 will be > broadcast over both interfaces A1 and B1. Then another message with > B1 as DODAGID and INST2 will be also broadcast over both interfaces. > Some Objective Functions may allow us to forward packets on both > links now. But the control becomes hard when the network has multiple > hops. Ideally, I prefer node 2 to dynamically choose a link because > link qualities could change over time quickly. Any comment or > suggestion would be appreciated and thank you for your time, Yanjun > -- Yanjun Sun Systems and Applications R&D Center Texas Instruments, > Inc, USA > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yanjun@ti.com Wed May 18 08:43:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137BEE06FB for ; Wed, 18 May 2011 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiEf5q1ZlkXk for ; Wed, 18 May 2011 08:43:50 -0700 (PDT) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by ietfa.amsl.com (Postfix) with ESMTP id 08942E06A0 for ; Wed, 18 May 2011 08:43:49 -0700 (PDT) Received: from dlep36.itg.ti.com ([157.170.170.91]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id p4IFhmQx031484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 May 2011 10:43:48 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id p4IFhmpb010752; Wed, 18 May 2011 10:43:48 -0500 (CDT) Received: from dlee74.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p4IFhmfg018956; Wed, 18 May 2011 10:43:48 -0500 (CDT) Received: from dlee04.ent.ti.com ([157.170.170.9]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Wed, 18 May 2011 10:43:48 -0500 From: "Sun, Yanjun" To: Alexandru Petrescu , "roll@ietf.org" Date: Wed, 18 May 2011 10:43:46 -0500 Thread-Topic: [Roll] On how to configure/run RPL on nodes with two interfaces Thread-Index: AcwVZckN32nQ0DXFTO2sWivQttGcKAAC6Mew Message-ID: <2C1563023E232C49B9F505633D57C2DA2738163340@dlee04.ent.ti.com> References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> <4DD3D408.6050404@gmail.com> In-Reply-To: <4DD3D408.6050404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 15:43:51 -0000 Alex, Thanks a lot for your inputs. Could you please comment more on the reasons = behind "RPL should not be forced into using more than one instance"? Could = there be any risk such as loops?=20 I totally agree with you on OSPF's behavior. I prefer RPL to OSPF-like prot= ocols for our project because of RPL's small memory footprint. However, we = have nodes with two interfaces, so I'd like to make sure it's well handled = by RPL before moving forward. Best regards, Yanjun -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: Wednesday, May 18, 2011 9:13 AM To: roll@ietf.org Subject: Re: [Roll] On how to configure/run RPL on nodes with two interface= s I think that, in the network you depicted, where a node has several real IP-enabled interfaces, RPL should not be forced into using more than one instance. +-------------+ | Root | | | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ (by comparison, OSPF running on this network does not _need_ several instances. It has a single daemon per machine, with a single view of the network as reflected in its database.) (my two cents worth). Alex Le 12/05/2011 20:25, Sun, Yanjun a =E9crit : > Hello All, I'm new to this mailing list. I'm trying to figure out how > to configure/run RPL on a node with two interfaces. Following the > rules of RPL, I came up with several configurations even for a simple > two node network below. Could you please comment on whether they make > sense and whether there is any better alternative? As most discussion > in RPL is focused on nodes with single interface (though I strongly > believe it'll work well for multiple interfaces), the configuration > really puzzled me. So I would appreciate if anyone could help me > out. I'd like to use a very simple network to describe my questions. > Node 1 is the root and node 2 is a leaf. Both nodes have two wired > interfaces. A1 is connected to A2 and B1 is connected to B2. we'd > like to find out what's the best way to configure RPL for such a > network to forward packets on both links. +-------------+ | Root | | > | +---+A1 1 B1+----+ | | | | | | | | | +-------------+ | | | | | | | > | +-------------+ | | | | | +---+A2 2 B2+----+ | | +------+------+ I > could think of two possible configurations. In the first RPL > configuration, I let node 1 use only *one* instance, INST1. One DIO > message with A1 as DODAGID will be broadcast over both interfaces A1 > and B1. Then another message with B1 as DODAGID will be also > broadcast over both interfaces. Based on the RPL draft that limits a > node to join only one DODAG given an instance ID, node 2 can only > choose one link to join node 1 and leave the other link *unused*. In > the second configuration, I let node 1 to use *two* instances, INST1 > and INST2. One DIO message with A1 as DODAGID and INST1 will be > broadcast over both interfaces A1 and B1. Then another message with > B1 as DODAGID and INST2 will be also broadcast over both interfaces. > Some Objective Functions may allow us to forward packets on both > links now. But the control becomes hard when the network has multiple > hops. Ideally, I prefer node 2 to dynamically choose a link because > link qualities could change over time quickly. Any comment or > suggestion would be appreciated and thank you for your time, Yanjun > -- Yanjun Sun Systems and Applications R&D Center Texas Instruments, > Inc, USA > > > > _______________________________________________ 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=112868010=mukul@uwm.edu Wed May 18 10:59:32 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3BFE072C; Wed, 18 May 2011 10:59:32 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ZMMXU7Yo4p; Wed, 18 May 2011 10:59:31 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 99822E06CF; Wed, 18 May 2011 10:59:31 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip2mta.uwm.edu with ESMTP; 18 May 2011 12:59:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D6CE11FD036; Wed, 18 May 2011 12:59:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnKP0pu1T07R; Wed, 18 May 2011 12:59:30 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6B67A1FD034; Wed, 18 May 2011 12:59:30 -0500 (CDT) Date: Wed, 18 May 2011 12:59:30 -0500 (CDT) From: Mukul Goyal To: 6lowpan <6lowpan@ietf.org> Message-ID: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <20110518175020.12308.62008.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 17:59:32 -0000 Hi all Fragmentation of RPL control messages has emerged as one of the key concerns when RPL is run over IEEE 802.15.4 networks. The submitted draft specifies a compression mechanism for RPL control messages. We have currently specified compression formats for DIO messages and some of the options that sit inside a DIO. Future versions of this draft may include compression formats for other DIO options as well as other RPL control messages. The mechanism can even be extended to ICMPv6 messages in general. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: mukul@uwm.edu Cc: "jerald p martocci" , "emmanuel baccelli" , mukul@uwm.edu, "matthias philipp" , abr@sdesigns.dk Sent: Wednesday, May 18, 2011 12:50:20 PM Subject: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt A new version of I-D, draft-goyal-6lowpan-rpl-compression-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-6lowpan-rpl-compression Revision: 00 Title: A Compression Format for RPL Control Messages Over a 6lowpan Creation date: 2011-05-17 WG ID: Individual Submission Number of pages: 10 Abstract: This document specifies a compression format for ICMPv6 RPL control messages over a 6lowpan. The specified format is in accordance with IPv6 header compression framework defined for a 6lowpan. The IETF Secretariat From jonhui@cisco.com Wed May 18 13:07:24 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46B5E076D; Wed, 18 May 2011 13:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ccVmfMexcFt; Wed, 18 May 2011 13:07:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 000D1E0748; Wed, 18 May 2011 13:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=2050; q=dns/txt; s=iport; t=1305749243; x=1306958843; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+rGTbqzodCSfNwkS7+LUDgbf+J7/ChTOFmm8j23Hv/Q=; b=fF/1z1z1M0EJfHFDUbSkCZtEG8Uosf8B7kkJVUfAVwq22U3d3JSAsQj4 aJeKVo4xFRmqgneRKhRbH7PYYY4OEZhKZR5Rq+8WuGhDy0Fxms93rI4xH WGQsVbo5fLUL2voo0FmpBS39XdyVIZ1nq78z3z2wkU7zdrSnDIp/P7eMl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAABUm1E2rRDoI/2dsb2JhbACXT45Nd4hwn2+dfoYZBIZQiUGOQFU X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="318689013" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 18 May 2011 20:07:23 +0000 Received: from dhcp-128-107-155-214.cisco.com (dhcp-128-107-155-214.cisco.com [128.107.155.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4IK7NnT014903; Wed, 18 May 2011 20:07:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 18 May 2011 13:07:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 20:07:24 -0000 How does this compare to draft-bormann-6lowpan-ghc? It seems most of = the gain will be from compressing out prefixes and zeros, which ghc = should handle quite well. -- Jonathan Hui On May 18, 2011, at 10:59 AM, Mukul Goyal wrote: > Hi all >=20 > Fragmentation of RPL control messages has emerged as one of the key = concerns when RPL is run over IEEE 802.15.4 networks. The submitted = draft specifies a compression mechanism for RPL control messages. We = have currently specified compression formats for DIO messages and some = of the options that sit inside a DIO. Future versions of this draft may = include compression formats for other DIO options as well as other RPL = control messages. The mechanism can even be extended to ICMPv6 messages = in general. >=20 > Thanks > Mukul >=20 > ----- Forwarded Message ----- > From: internet-drafts@ietf.org > To: mukul@uwm.edu > Cc: "jerald p martocci" , "emmanuel = baccelli" , mukul@uwm.edu, "matthias = philipp" , abr@sdesigns.dk > Sent: Wednesday, May 18, 2011 12:50:20 PM > Subject: New Version Notification for = draft-goyal-6lowpan-rpl-compression-00.txt >=20 > A new version of I-D, draft-goyal-6lowpan-rpl-compression-00.txt has = been successfully submitted by Mukul Goyal and posted to the IETF = repository. >=20 > Filename: draft-goyal-6lowpan-rpl-compression > Revision: 00 > Title: A Compression Format for RPL Control Messages = Over a 6lowpan > Creation date: 2011-05-17 > WG ID: Individual Submission > Number of pages: 10 >=20 > Abstract: > This document specifies a compression format for ICMPv6 RPL control > messages over a 6lowpan. The specified format is in accordance with > IPv6 header compression framework defined for a 6lowpan. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From phoebus@ieee.org Wed May 18 14:07:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB1E0766 for ; Wed, 18 May 2011 14:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGRog8xjBvs3 for ; Wed, 18 May 2011 14:07:34 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id D5314E074A for ; Wed, 18 May 2011 14:07:33 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 415B014DCA3; Wed, 18 May 2011 23:07:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id azNrIEqlxQit; Wed, 18 May 2011 23:06:59 +0200 (CEST) X-KTH-Auth: phoebus [83.145.36.89] X-KTH-mail-from: phoebus@ieee.org Received: from catch-all.priv (swgc.sizeit.se [83.145.36.89]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0E42814DC8B; Wed, 18 May 2011 23:06:58 +0200 (CEST) Message-ID: <4DD434F2.7080902@ieee.org> Date: Wed, 18 May 2011 23:06:58 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: roll@ietf.org, yanjun@ti.com References: <2C1563023E232C49B9F505633D57C2DA272075B026@dlee04.ent.ti.com> <28301129-AC41-4702-96F9-203130D379A9@watteco.com> <2C1563023E232C49B9F505633D57C2DA272089BCC9@dlee04.ent.ti.com> In-Reply-To: <2C1563023E232C49B9F505633D57C2DA272089BCC9@dlee04.ent.ti.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] On how to configure/run RPL on nodes with two interfaces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:07:35 -0000 Yanjun, I think using a Virtual Root, as described in (Section 3.1.3. draft-ietf-roll-rpl-19) bullet point number 3, may solve your problem. In your case, "backbone network" doesn't apply since both interfaces are on one node. So you have a perfect connection. Effectively, can advertise an ETX of 1 on both interfaces (path ETX from each interface to virtual root). And you can use one RPLInstanceID and DODAGID. Since what happens within your root node is all your own code, you probably don't have to simulate all the details of sending DIOs from your virtual root to the interfaces, etc., so long as the behavior seen at the interfaces looks like that of an RPL DAG with two nodes with perfect links to a root. Good luck, -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 5/13/11 6:22 PM, Sun, Yanjun wrote: > Hi Cédric, Michael, > > Thank you for your valuable inputs. > > Cédric: Our understanding is aligned on the IPv6 address usage. I could > only think of a tiny difference between multi-interfaces and multiple > nodes and please correct me if I’m wrong. Suppose only one root node > creates one RPLInstance in a network. In the multi-interface case, we > see two types of DIO messages, each corresponding to an IPv6 address of > the root. A leaf node can’t tell that they’re essentially from the same > root node. In the multiple nodes case, we only see one type of DIO message. > > Michael: You’re right, but I wonder if the following dynamic path > selection could possibly trigger some undesired control overhead at > nodes below node 1 and 2. > > >if the ETX across the A links and the B links is significantly > > >different, and this changes over time, then I expect that your DODAG may > > >re-organize to always have the best working path. > > Suppose node 1 and 2 are at the very top of a DODAG and there are many > nodes below them. Also suppose node 1 created one RPLInstance and two > DODAGIDs (one for each interface, the configuration 1 I mentioned in my > earlier email). When node 2 picks a different link due to changed EXT > metrics, the DODGAID it belongs to may also change. I’m not sure if this > will trigger all the nodes below node2 to update their “associations”. > > Thank you, > > Yanjun > > *From:*C Chauvenet [mailto:c.chauvenet@watteco.com] > *Sent:* Friday, May 13, 2011 3:15 AM > *To:* Sun, Yanjun > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] On how to configure/run RPL on nodes with two > interfaces > > Hi, > > RPL on muti-interfaces nodes is to my mind a very valuable feature. > > Jumping into the discussion, a thought came to my mind : > > If you have several interfaces on your nodes, you should have several > MAC address (one for each interface), so you should have several IPv6 > address. > > So in fact, would the problem of multi-interfaces be similar to multiple > nodes (considering a node as a particular IPv6 address) ? > > So in your case, using both interfaces would result in doing some kind > of multicasting. > > Other thoughts ? > > Cédric. > > Le 12 mai 2011 à 20:25, Sun, Yanjun a écrit : > > > > Hello All, > > I’m new to this mailing list. I’m trying to figure out how to > configure/run RPL on a node with two interfaces. Following the rules of > RPL, I came up with several configurations even for a simple two node > network below. Could you please comment on whether they make sense and > whether there is any better alternative? As most discussion in RPL is > focused on nodes with single interface (though I strongly believe it’ll > work well for multiple interfaces), the configuration really puzzled me. > So I would appreciate if anyone could help me out. > > I’d like to use a very simple network to describe my questions. Node 1 > is the root and node 2 is a leaf. Both nodes have two wired interfaces. > A1 is connected to A2 and B1 is connected to B2. we’d like to find out > what’s the best way to configure RPL for such a network to forward > packets on both links. > > +-------------+ > > | Root | > > | | > > +---+A1 1 B1+----+ > > | | | | > > | | | | > > | +-------------+ | > > | | > > | | > > | | > > | +-------------+ | > > | | | | > > +---+A2 2 B2+----+ > > | | > > +------+------+ > > I could think of two possible configurations. In the first RPL > configuration, I let node 1 use only *one* instance, INST1. One DIO > message with A1 as DODAGID will be broadcast over both interfaces A1 and > B1. Then another message with B1 as DODAGID will be also broadcast over > both interfaces. Based on the RPL draft that limits a node to join only > one DODAG given an instance ID, node 2 can only choose one link to join > node 1 and leave the other link *unused*. > > In the second configuration, I let node 1 to use *two* instances, INST1 > and INST2. One DIO message with A1 as DODAGID and INST1 will be > broadcast over both interfaces A1 and B1. Then another message with B1 > as DODAGID and INST2 will be also broadcast over both interfaces. Some > Objective Functions may allow us to forward packets on both links now. > But the control becomes hard when the network has multiple hops. > Ideally, I prefer node 2 to dynamically choose a link because link > qualities could change over time quickly. > > Any comment or suggestion would be appreciated and thank you for your time, > > Yanjun > > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: Thursday, May 12, 2011 9:17 PM > To: Sun, Yanjun > Cc: roll@ietf.org > Subject: Re: [Roll] On how to configure/run RPL on nodes with two > interfaces > > >>>>> "Yanjun" == Yanjun Sun writes: > > Yanjun> I'm new to this mailing list. I'm trying to figure out how > > Yanjun> to configure/run RPL on a node with two > > Yanjun> interfaces. Following the rules of RPL, I came up with > > Yanjun> several configurations even for a simple two node network > > Yanjun> below. Could you please comment on whether they make sense > > Yanjun> and whether there is any better alternative? As most > > Yanjun> discussion in RPL is focused on nodes with single interface > > Yanjun> (though I strongly believe it'll work well for multiple > > Yanjun> interfaces), the configuration really puzzled me. So I would > > Yanjun> appreciate if anyone could help me out. > > So, RPL is not focused on a single interface. > > RPL is focused on connections where there is multiple access, just not > > really broadcast available. Yet, it's not ATM-like NBMA. > > A machine with two interfaces is just part of two broadcast domains > > where the ETX is 0 for any machines crossing that line. The two > > interfaces don't have to be two radios, it could also be a single radio > > with multiple frequencies. > > In my test bench, I use simulated ethernet, but since I don't have > > simulation of radio propogation issues, I just have a network with 7 or > > so ethernet broadcast domains. > > Yanjun> I'd like to use a very simple network to describe my > > Yanjun> questions. Node 1 is the root and node 2 is a leaf. Both > > Yanjun> nodes have two wired interfaces. A1 is connected to A2 and > > Yanjun> B1 is connected to B2. we'd like to find out what's the best > > Yanjun> way to configure RPL for such a network to forward packets > > Yanjun> on both links. > > I don't think you can. > > RPL doesn't promise you that you will be able to make the most amount of > > bandwidth available, but that you will get a minimal cost (by Objective > > Function) path. > > Yanjun> In the second configuration, I let node 1 to use *two* > > Yanjun> instances, INST1 and INST2. One DIO message with A1 as > > Yanjun> DODAGID and INST1 will be broadcast over both interfaces A1 > > Yanjun> and B1. Then another message with B1 as DODAGID and INST2 > > Yanjun> will be also broadcast over both interfaces. Some Objective > > Yanjun> Functions may allow us to forward packets on both links > > Yanjun> now. But the control becomes hard when the network has > > This is the only way I can see doing things. > > Yanjun> multiple hops. Ideally, I prefer node 2 to dynamically > > Yanjun> choose a link because link qualities could change over time > > Yanjun> quickly. > > if the ETX across the A links and the B links is significantly > > different, and this changes over time, then I expect that your DODAG may > > re-organize to always have the best working path. > > -- > > ] He who is tired of Weird Al is tired of life! | firewalls [ > > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > > Kyoto Plus: watch the video > > then sign the petition. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Wed May 18 14:17:52 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05508E0770 for ; Wed, 18 May 2011 14:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU-Utum-c9gK for ; Wed, 18 May 2011 14:17:51 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id B6ECDE074A for ; Wed, 18 May 2011 14:17:50 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id CEA9014DC41; Wed, 18 May 2011 22:51:35 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id uIVAb5m0SmXq; Wed, 18 May 2011 22:51:33 +0200 (CEST) X-KTH-Auth: phoebus [83.145.36.89] X-KTH-mail-from: phoebus@ieee.org Received: from catch-all.priv (swgc.sizeit.se [83.145.36.89]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 5D79014C137; Wed, 18 May 2011 22:51:33 +0200 (CEST) Message-ID: <4DD43154.6000209@ieee.org> Date: Wed, 18 May 2011 22:51:32 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: roll@ietf.org, "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> <4DC939BB.50406@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:17:52 -0000 Pascal, Your changes look good enough. I have some minor comments, but maybe you're tired of respinning the document. Anyhow, answers to some of your questions inline below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 5/17/11 5:41 PM, Pascal Thubert (pthubert) wrote: ... >> It looks like there is nothing written about advertising the rank (a > Section >> 4.3). I guess that's OK if you feel there is nothing to say. I would > have >> preferred a short paragraph there for completeness. It might just > restate >> the obvious, that advertisements are triggered by the Trickle timer or >> changes in the rank after it is recomputed. > > [Pascal] There's text in the end of the ' Abstract Interface with RPL > core' section that I thought would cover this. PC> OK. I guess the recommendations in the "Abstract Interface with RPL PC> core" together with "Section 8.3 DIO Transmissions" in PC> (draft-ietf-roll-rpl-19) will be good enough. ... >> III. >> I presume you will still add Configuration Options for the > configurable >> parameters in 6.2? >> > > [Pascal] That would be beyond what I can do after last call. I'm only > fixing editorials now. > PC> OK. >> IV. >> As for any remaining comments I have after rereading the document, > they >> are about how to present and explain OF0. Since I get the sense that >> there is some urgency to publish OF0, you can incorporate them if you >> have time - these comments shouldn't "hold the document hostage." A > few >> points in addition to JP's comments: >> >> 0) I've had trouble understanding the consensus of the discussion on > the >> mailing list on OF0 not being the default objective function. The > last >> paragraph of Section 1 still doesn't make it clear to me. As far as I >> understand, OF0 is the default objective function when no objective >> function is specified - if an implementation does not support another >> objective function, it must support OF0. This is the definition of >> "default," right? If not, someone please define "default" to me... I >> must be missing something. I would be glad to propose shorter text if > I >> understood the consensus. > > [Pascal] > I think that those words for that belong to RPL. > We negotiated them with the IESG reviewers who raised the issue. > I'm not sure we all have the same understanding of those words though. > My understanding was that the AD wished that 2 implementations would > always have at least one OF in common. > If those implementations follow a given guidance that's outside RPL, > fine. Otherwise they have to implement OF0. > I suspect that some conformance test will verify that. >> >> " Since there is no default OF or metric container in the RPL main >> specification, it might happen that, unless two given > implementations >> follow the same guidance for a specific problem or environment, > those >> implementations will not support a common OF with which they could >> interoperate. OF0 is designed to be common to all implementations >> that are not specifically designed to apply to a given case for > which >> further guidance is provided. This is why it is very abstract as > to >> how the link properties are transformed into a rank_increase and >> leaves that responsibility to implementation; rather, OF0 enforces >> normalized values for the rank_increase of a normal link and its >> acceptable range, as opposed to formulating the details of its >> computation. This is also why OF0 ignores metric containers. >> " >> > [Pascal] What do you think of: > > " Since there is no default OF or metric container in the RPL main > specification, it might happen that, unless two given implementations > follow the same guidance for a specific problem or environment, those > implementations will not support a common OF with which they could > interoperate. OF0 is designed as a default OF that will allow > interoperation between implementations in a wide spectrum of use > cases. This is why it is not specific as to how the link properties > are transformed into a rank_increase and leaves that responsibility > to the implementation; rather, OF0 enforces normalized values for the > rank_increase of a normal link and its acceptable range, as opposed > to formulating the details of its computation. This is also why OF0 > ignores metric containers." >> PC> The reader will have to figure out what is meant by "guidance," but PC> again, OK, good enough. ... >> >> 2) I think that the paragraph at the end of Section 3: >> " OF0 assigns a step_of_rank to each link to another node that it >> monitors. The exact method for computing the step_of_rank is >> implementation-dependent. " >> belongs somewhere in Section 4.1, maybe after the sentence: >> "An implementation MUST maintain the stretched step_of_rank between >> MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows >> to >> reflect a large variation of link quality." >> > [Pascal] I do not follow you on that. This section has been talking > about rank increase and now it points at the place where it is defined > (following JP's suggestion) > " > OF0 assigns a rank_increase to each link to another node that it > monitors. Though the exact method for computing the rank_increase is > implementation-dependent, the computation must follow the rules that > are specified in Section 4.1. > > " PC> OK. ... >> >> 5) Rewrite the equation: >> R(N) = R(P) + Ri where Ri = (Rf*Sp + Sr) * MinHopRankIncrease >> as >> >> R(N) = R(P) + rank_increase >> where >> rank_increase = (rank_factor * step_of_rank + stretch_of_rank) * >> MinHopRankIncrease >> >> So we have less new variables (Ri, Rf, Sp, Sr). >> > [Pascal] OK... PC> ?? I don't see the changes in version 12. You will add them in 13, I presume. PC> And three more typos (look at Diff2 between 11 and 12 to spot them): (pg. 3, around line 28) ...OF0 only requires the information in the RPL DIO obtained from provisionning ... s/provisionning/provisioning/ (pg. 7 around line 57) text in "Processing DIO:" s/Objective Code Point OCP)/Objective Code Point (OCP)/ (pg. 7) text in "Calling back:" s/Parent List as occurred/Parent List has occurred/ From mounir.kellil@cea.fr Thu May 19 02:37:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4D8E0795 for ; Thu, 19 May 2011 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppz8lkKpcylG for ; Thu, 19 May 2011 02:37:00 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3F395E0736 for ; Thu, 19 May 2011 02:36:59 -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.2) with ESMTP id p4J9aq1A011486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 May 2011 11:36:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p4J9aqdw018574; Thu, 19 May 2011 11:36:52 +0200 (envelope-from mounir.kellil@cea.fr) Received: from EXCAH-A2.intra.cea.fr (excah-a2.intra.cea.fr [132.166.88.76]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p4J9aq2r009078; Thu, 19 May 2011 11:36:52 +0200 Received: from levau.intra.cea.fr (132.166.88.52) by EXCAH-A2.intra.cea.fr (132.166.88.76) with Microsoft SMTP Server id 14.1.270.1; Thu, 19 May 2011 11:36:51 +0200 Received: from LODERI.intra.cea.fr ([132.166.64.47]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 11:36:50 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 11:36:49 +0200 Message-ID: In-Reply-To: <20110411161502.2668.56179.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A question on Trickle multicast: [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt Thread-Index: Acv4Y6O+tbZcEYHYSjymvxJX/1DVQAdn6dYQ References: <20110411161502.2668.56179.idtracker@localhost> From: KELLIL Mounir To: , X-OriginalArrivalTime: 19 May 2011 09:36:50.0608 (UTC) FILETIME=[47BDEB00:01CC1608] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.500.1024-18144.002 X-TM-AS-Result: No--3.172100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: [Roll] A question on Trickle multicast: I-D Action:draft-ietf-roll-trickle-mcast-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 09:37:01 -0000 Hi Jonathan and Richard,=20 I have a question regarding the trickle multicast draft. It concerns = section 6.4 "Trickle ICMP Processing". Could you please explain which = transmitter/receiver you are referring to? If the transmitter is the one = who transmits the ICMP message, it is not clear how it can claim to have = "a new multicast message to offer if the (SeedID, Sequence) pair falls = within an existing sliding window for SeedID but does not have an = associated entry" (BTW, the transmitter's entry ?) ? My understanding is that a transmitter (of an ICMP message) cannot = advertise a sequence number of a new message for which it has not an = entry. Or maybe it can do that upon receiving the said new message (and = just before forwarding it to other nodes)? Or, maybe the transmitter/receiver is the transmitter/receiver of = multicast packets...In all cases, maybe if you could clarify the terms = "transmitter" and "receiver", this should provide a better comprehension = of section 6.4. Best regards Mounir Mounir KELLIL CEA LIST Ing=E9nieur Chercheur web : http://www-list.cea.fr =20 > -----Message d'origine----- > De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de > Internet-Drafts@ietf.org > Envoy=E9=A0: lundi 11 avril 2011 18:15 > =C0=A0: i-d-announce@ietf.org > Cc=A0: roll@ietf.org > Objet=A0: [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt >=20 > 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. >=20 >=20 > Title : Multicast Forwarding Using Trickle > Author(s) : J. Hui, R. Kelsey > Filename : draft-ietf-roll-trickle-mcast-00.txt > Pages : 19 > Date : 2011-04-11 >=20 > Low power and Lossy Networks (LLNs) are typically composed of resource > constrained nodes communicating over links that have dynamic > characteristics. Memory constraints coupled with temporal variations > in link connectivity makes the use of topology maintenance to support > IPv6 multicast challenging. This document describes the use of = Trickle > to efficiently forward multicast messages without the need for = topology > maintenance. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-mcast- > 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From pthubert@cisco.com Thu May 19 05:37:34 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568F9E069A for ; Thu, 19 May 2011 05:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exb+W6eUy7ii for ; Thu, 19 May 2011 05:37:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E29B8E0656 for ; Thu, 19 May 2011 05:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1497; q=dns/txt; s=iport; t=1305808650; x=1307018250; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=csmo7bq9BHo6iDYr9G9RmpMI/kqVnSLSG12hgfsA0z8=; b=IlvP2IzHhc7MZy1vuCe7+U62nfSyEnsSqASiMvw7+tVkp9Yd+YEPPYOb 8S99G3yPsen+q2hZ19yof74gN9li/yKT553e/Z/sNRn4hFF27JSTDsyCY 6N0yqV26kVtZPrO8/349HlwZTfXzZbE0PyzlYTXOpco298LNVitU3zpNi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIDAFEO1U2Q/khLgWdsb2JhbACmDRQBARYmJYhwoxKeEIYZBJRJij8 X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="31130327" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 May 2011 12:37:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4JCbSDM016843; Thu, 19 May 2011 12:37:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 14:37:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 14:37:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D049BCE0F@XMB-AMS-107.cisco.com> In-Reply-To: <4DD43154.6000209@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: AcwVnWm7aVFJo301Qc6OAdBQxoYUlQAg5eZg References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> <4DC939BB.50406@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com> <4DD43154.6000209@ieee.org> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 19 May 2011 12:37:28.0736 (UTC) FILETIME=[83C50200:01CC1621] Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 12:37:34 -0000 Hello Phoebus, > >> 5) Rewrite the equation: > >> R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease > >> as > >> > >> R(N) =3D R(P) + rank_increase > >> where > >> rank_increase =3D (rank_factor * step_of_rank + stretch_of_rank) * > >> MinHopRankIncrease > >> > >> So we have less new variables (Ri, Rf, Sp, Sr). > >> > > [Pascal] OK... >=20 > PC> ?? I don't see the changes in version 12. You will add them in 13, > I presume. [Pascal] I did half of the way actually;=20 The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then possibly stretched by a stretch_of_rank Sr. The resulting rank_increase is added to the Rank of preferred parent R(P) to obtain that of this node R(N): R(N) =3D R(P) + rank_increase where: rank_increase =3D (Rf*Sp + Sr) * MinHopRankIncrease [Pascal]=20 The full version was harder to read IMHO. >=20 > PC> > And three more typos (look at Diff2 between 11 and 12 to spot them): >=20 > (pg. 3, around line 28) ...OF0 only requires the information in the RPL > DIO obtained from provisionning ... > s/provisionning/provisioning/ >=20 > (pg. 7 around line 57) text in "Processing DIO:" > s/Objective Code Point OCP)/Objective Code Point (OCP)/ >=20 >=20 > (pg. 7) text in "Calling back:" > s/Parent List as occurred/Parent List has occurred/ [Pascal] Sorry for those. We can still fix that with the RCF editor. Pascal From axelcdv@gmail.com Thu May 19 06:26:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3FAE07B3 for ; Thu, 19 May 2011 06:26:04 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpcvOk17GqEf for ; Thu, 19 May 2011 06:26:02 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3ABE066A for ; Thu, 19 May 2011 06:26:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so1962690qwc.31 for ; Thu, 19 May 2011 06:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Sf5A0vWASWQCzKMg1id0IwEsFRJHGY9DiTgGjhOhUwM=; b=q5MBKT4h5+PxS1D7aeVJHfB64atO9idvbVgNcHUUYLitf6vkJ1jCCPmfuvzJB2EXYU 3rIQGB1J1QL7kFAw+2ABz3MEbzvPnxDxy9C8HUviQmWrGSmxRGsOaqkmCeRnqQBxrxcD 0cNMVOuptIw5FHgoEVs77janCayIHyoqIQOWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ZxsXFMzP1m8BjlPNZJP42LhQ1dOmGNJmdNYpN71N0hVBM5BBWt5pNF5L8gImUT9eZC aAB7FLe8Z19d4XS2Kj1p4GdATr/yn19Y84+8PrHUTUVn/SxUYNUnjOWhUO1Pz12tFvvK sfqQndys5HIFDl5A5wcnAoHf8Gf+1/N7+SYt0= Received: by 10.229.105.162 with SMTP id t34mr2348996qco.14.1305811560182; Thu, 19 May 2011 06:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.249.144 with HTTP; Thu, 19 May 2011 06:25:40 -0700 (PDT) In-Reply-To: References: <20110411161502.2668.56179.idtracker@localhost> From: axel cdv Date: Thu, 19 May 2011 15:25:40 +0200 Message-ID: To: KELLIL Mounir Content-Type: multipart/alternative; boundary=00235429dbc03034c004a3a0f2ae Cc: roll@ietf.org, kelsey@ember.com Subject: Re: [Roll] A question on Trickle multicast: I-D Action:draft-ietf-roll-trickle-mcast-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 13:26:04 -0000 --00235429dbc03034c004a3a0f2ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mounir, Please correct me if you feel I'm wrong here, but I think I have an explanation as to what Jonathan and Richard meant in this section. I think that the transmitter is indeed the one who transmits the ICMP message, but it is only the receiver (i.e. the one who receives the message) who can determine if the transmitter has a new multicast to offer. The (SeedID, Sequence) pair refers to one listed in the ICMP message, while the "existin= g sliding window" refers to one buffered by the receiver. I think this solves your problem: a transmitter transmit an ICMP listing every message it knows, and only the receiver can determine whether one of the two nodes has any new message to offer to the other. Best regards, Axel Colin de Verdi=E8re 2011/5/19 KELLIL Mounir > Hi Jonathan and Richard, > > I have a question regarding the trickle multicast draft. It concerns > section 6.4 "Trickle ICMP Processing". Could you please explain which > transmitter/receiver you are referring to? If the transmitter is the one = who > transmits the ICMP message, it is not clear how it can claim to have "a n= ew > multicast message to offer if the (SeedID, Sequence) pair falls within an > existing sliding window for SeedID but does not have an associated entry" > (BTW, the transmitter's entry ?) ? > > My understanding is that a transmitter (of an ICMP message) cannot > advertise a sequence number of a new message for which it has not an entr= y. > Or maybe it can do that upon receiving the said new message (and just bef= ore > forwarding it to other nodes)? > > Or, maybe the transmitter/receiver is the transmitter/receiver of multica= st > packets...In all cases, maybe if you could clarify the terms "transmitter= " > and "receiver", this should provide a better comprehension of section 6.4= . > > Best regards > > Mounir > > > Mounir KELLIL > CEA LIST > Ing=E9nieur Chercheur > web : http://www-list.cea.fr > > > > -----Message d'origine----- > > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > > Internet-Drafts@ietf.org > > Envoy=E9 : lundi 11 avril 2011 18:15 > > =C0 : i-d-announce@ietf.org > > Cc : roll@ietf.org > > Objet : [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt > > > > 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 : Multicast Forwarding Using Trickle > > Author(s) : J. Hui, R. Kelsey > > Filename : draft-ietf-roll-trickle-mcast-00.txt > > Pages : 19 > > Date : 2011-04-11 > > > > Low power and Lossy Networks (LLNs) are typically composed of resource > > constrained nodes communicating over links that have dynamic > > characteristics. Memory constraints coupled with temporal variations > > in link connectivity makes the use of topology maintenance to support > > IPv6 multicast challenging. This document describes the use of Trickle > > to efficiently forward multicast messages without the need for topology > > maintenance. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-mcast- > > 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 > --00235429dbc03034c004a3a0f2ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mounir,

Please correct me if you feel I'm wrong h= ere, but I think I have an explanation as to what Jonathan and Richard mean= t in this section. I think that the transmitter is indeed the one who trans= mits the ICMP message, but it is only the receiver (i.e. the one who receiv= es the message) who can determine if the transmitter has a new multicast to= offer. The (SeedID, Sequence) pair refers to one listed in the ICMP messag= e, while the "existing sliding window" refers to one buffered by = the receiver.

I think this solves your problem: a transmitter transmi= t an ICMP listing every message it knows, and only the receiver can determi= ne whether one of the two nodes has any new message to offer to the other.<= /div>

Best regards,

Axel Colin de Ve= rdi=E8re

2011/5/19 KELLIL Mounir <mounir.kellil@cea.fr<= /a>>
Hi Jonathan and Richard,

I have a question regarding the trickle multicast draft. It concerns sectio= n =A06.4 "Trickle ICMP Processing". Could you please explain whic= h transmitter/receiver you are referring to? If the transmitter is the one = who transmits the ICMP message, it is not clear how it can claim to have &q= uot;a new multicast message to offer if the (SeedID, Sequence) pair falls w= ithin an existing sliding window for SeedID but does not have an associated= entry" (BTW, the transmitter's entry ?) ?

My understanding is that a transmitter (of an ICMP message) cannot advertis= e a sequence number of a new message for which it has not an entry. Or mayb= e it can do that upon receiving the said new message (and just before forwa= rding it to other nodes)?

Or, maybe the transmitter/receiver is the transmitter/receiver of multicast= packets...In all cases, maybe if you could clarify the terms "transmi= tter" and "receiver", this should provide a better comprehen= sion of section 6.4.

Best regards

Mounir


Mounir KELLIL
CEA LIST
Ing=E9nieur Chercheur
web : http://www-list.= cea.fr


> -----Message d'origine-----
> De=A0: roll-bounces@ietf.org<= /a> [mailto:roll-bounces@ietf.org<= /a>] De la part de
> Internet-Drafts@ietf.org
> Envoy=E9=A0: lundi 11 avril 2011 18:15
> =C0=A0: i-d-announce@ietf.org=
> Cc=A0: roll@ietf.org
> Objet=A0: [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt
>
> 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.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Multicast Forwarding Using Tri= ckle
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Hui, R. Kelsey
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-roll-trickle-mcast-00= .txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-11
>
> Low power and Lossy Networks (LLNs) are typically composed of resource=
> constrained nodes communicating over links that have dynamic
> characteristics. =A0Memory constraints coupled with temporal variation= s
> in link connectivity makes the use of topology maintenance to support<= br> > IPv6 multicast challenging. =A0This document describes the use of Tric= kle
> to efficiently forward multicast messages without the need for topolog= y
> maintenance.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-r= oll-trickle-mcast-
> 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
ht= tps://www.ietf.org/mailman/listinfo/roll

--00235429dbc03034c004a3a0f2ae-- From mounir.kellil@cea.fr Thu May 19 08:02:02 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70D2E07E5 for ; Thu, 19 May 2011 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAKIbspF+oE3 for ; Thu, 19 May 2011 08:02:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACCAE07DC for ; Thu, 19 May 2011 08:01:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p4JExxWe016542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 May 2011 16:59:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p4JExwwi017149; Thu, 19 May 2011 16:59:58 +0200 (envelope-from mounir.kellil@cea.fr) Received: from EXCAH-A0.intra.cea.fr (excah-a0.intra.cea.fr [132.166.88.74]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p4JExwEw010693; Thu, 19 May 2011 16:59:58 +0200 Received: from mansart.intra.cea.fr (132.166.88.54) by EXCAH-A0.intra.cea.fr (132.166.88.74) with Microsoft SMTP Server id 14.1.270.1; Thu, 19 May 2011 16:59:58 +0200 Received: from LODERI.intra.cea.fr ([132.166.64.47]) by mansart.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 16:59:58 +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_01CC1635.6B95F530" Date: Thu, 19 May 2011 16:59:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] A question on Trickle multicast: I-D Action:draft-ietf-roll-trickle-mcast-00.txt Thread-Index: AcwWKFFeveDE6PJjSjurO1nYOCihrAACg8Jg References: <20110411161502.2668.56179.idtracker@localhost> From: KELLIL Mounir To: axel cdv X-OriginalArrivalTime: 19 May 2011 14:59:58.0266 (UTC) FILETIME=[6BAFC1A0:01CC1635] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.500.1024-18144.005 X-TM-AS-Result: No--25.805700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, kelsey@ember.com Subject: Re: [Roll] A question on Trickle multicast: I-D Action:draft-ietf-roll-trickle-mcast-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 15:02:02 -0000 ------_=_NextPart_001_01CC1635.6B95F530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Axel, =20 Thanks for your explanations. That makes sense. And, this was my = understanding as well. But, again I feel that section 6.4 text is a bit = misleading. Well, for instance, the first paragraph can be slightly = modified as follows: =20 The transmitter has new multicast messages to offer if any (SeedID, Sequence) pair falls within an existing *receiver's* sliding window = for SeedID but does not have an associated entry *on the receiver's side*. =20 Just a suggestion... =20 Best regards =20 =20 Mounir KELLIL CEA LIST Ing=E9nieur Chercheur web : http://www-list.cea.fr =20 =20 De : axel cdv [mailto:axelcdv@gmail.com]=20 Envoy=E9 : jeudi 19 mai 2011 15:26 =C0 : KELLIL Mounir Cc : jonhui@cisco.com; kelsey@ember.com; roll@ietf.org Objet : Re: [Roll] A question on Trickle multicast: I-D = Action:draft-ietf-roll-trickle-mcast-00.txt =20 Hi Mounir, =20 Please correct me if you feel I'm wrong here, but I think I have an = explanation as to what Jonathan and Richard meant in this section. I = think that the transmitter is indeed the one who transmits the ICMP = message, but it is only the receiver (i.e. the one who receives the = message) who can determine if the transmitter has a new multicast to = offer. The (SeedID, Sequence) pair refers to one listed in the ICMP = message, while the "existing sliding window" refers to one buffered by = the receiver. =20 I think this solves your problem: a transmitter transmit an ICMP listing = every message it knows, and only the receiver can determine whether one = of the two nodes has any new message to offer to the other. =20 Best regards, =20 Axel Colin de Verdi=E8re 2011/5/19 KELLIL Mounir Hi Jonathan and Richard, I have a question regarding the trickle multicast draft. It concerns = section 6.4 "Trickle ICMP Processing". Could you please explain which = transmitter/receiver you are referring to? If the transmitter is the one = who transmits the ICMP message, it is not clear how it can claim to have = "a new multicast message to offer if the (SeedID, Sequence) pair falls = within an existing sliding window for SeedID but does not have an = associated entry" (BTW, the transmitter's entry ?) ? My understanding is that a transmitter (of an ICMP message) cannot = advertise a sequence number of a new message for which it has not an = entry. Or maybe it can do that upon receiving the said new message (and = just before forwarding it to other nodes)? Or, maybe the transmitter/receiver is the transmitter/receiver of = multicast packets...In all cases, maybe if you could clarify the terms = "transmitter" and "receiver", this should provide a better comprehension = of section 6.4. Best regards Mounir Mounir KELLIL CEA LIST Ing=E9nieur Chercheur web : http://www-list.cea.fr > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de > Internet-Drafts@ietf.org > Envoy=E9 : lundi 11 avril 2011 18:15 > =C0 : i-d-announce@ietf.org > Cc : roll@ietf.org > Objet : [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt > > 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 : Multicast Forwarding Using Trickle > Author(s) : J. Hui, R. Kelsey > Filename : draft-ietf-roll-trickle-mcast-00.txt > Pages : 19 > Date : 2011-04-11 > > Low power and Lossy Networks (LLNs) are typically composed of resource > constrained nodes communicating over links that have dynamic > characteristics. Memory constraints coupled with temporal variations > in link connectivity makes the use of topology maintenance to support > IPv6 multicast challenging. This document describes the use of = Trickle > to efficiently forward multicast messages without the need for = topology > maintenance. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-mcast- > 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 =20 ------_=_NextPart_001_01CC1635.6B95F530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Axel,

 

Thanks for your explanations. That makes sense. And, this was my = understanding as well. =A0But, again I feel that section 6.4 text is a = bit misleading. Well, for instance, the first paragraph can be slightly = modified as follows:

 

The transmitter has new multicast messages to offer if any = (SeedID,

=A0=A0 Sequence) pair falls within an existing = *receiver’s* sliding window for SeedID = but

=A0=A0 does not have an associated entry *on the receiver’s = side*.

 

Just a suggestion…

 

Best regards

 

 

Mo= unir KELLIL

CE= A LIST

In= g=E9nieur Chercheur

we= b : = http://www-list.cea.fr

 

De : axel cdv = [mailto:axelcdv@gmail.com]
Envoy=E9 : jeudi 19 mai 2011 = 15:26
=C0 : KELLIL Mounir
Cc : = jonhui@cisco.com; kelsey@ember.com; roll@ietf.org
Objet : = Re: [Roll] A question on Trickle multicast: I-D = Action:draft-ietf-roll-trickle-mcast-00.txt

 

Hi = Mounir,

 

Please correct me if you feel I'm wrong here, but I = think I have an explanation as to what Jonathan and Richard meant in = this section. I think that the transmitter is indeed the one who = transmits the ICMP message, but it is only the receiver (i.e. the one = who receives the message) who can determine if the transmitter has a new = multicast to offer. The (SeedID, Sequence) pair refers to one listed in = the ICMP message, while the "existing sliding window" refers = to one buffered by the receiver.

 

I = think this solves your problem: a transmitter transmit an ICMP listing = every message it knows, and only the receiver can determine whether one = of the two nodes has any new message to offer to the = other.

 

Best regards,

 

Axel Colin de = Verdi=E8re

2011/5/19 KELLIL = Mounir <mounir.kellil@cea.fr>

Hi Jonathan and Richard,

I have a = question regarding the trickle multicast draft. It concerns section =  6.4 "Trickle ICMP Processing". Could you please explain = which transmitter/receiver you are referring to? If the transmitter is = the one who transmits the ICMP message, it is not clear how it can claim = to have "a new multicast message to offer if the (SeedID, Sequence) = pair falls within an existing sliding window for SeedID but does not = have an associated entry" (BTW, the transmitter's entry ?) = ?

My understanding is that a transmitter (of an ICMP message) = cannot advertise a sequence number of a new message for which it has not = an entry. Or maybe it can do that upon receiving the said new message = (and just before forwarding it to other nodes)?

Or, maybe the = transmitter/receiver is the transmitter/receiver of multicast = packets...In all cases, maybe if you could clarify the terms = "transmitter" and "receiver", this should provide a = better comprehension of section 6.4.

Best = regards

Mounir


Mounir KELLIL
CEA = LIST
Ing=E9nieur Chercheur
web : http://www-list.cea.fr


> = -----Message d'origine-----
> De : roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] De la = part de
> Internet-Drafts@ietf.org
= > Envoy=E9 : lundi 11 avril 2011 18:15
> =C0 : i-d-announce@ietf.org
> = Cc : roll@ietf.org
> = Objet : [Roll] I-D = Action:draft-ietf-roll-trickle-mcast-00.txt
>
> 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     =       : Multicast Forwarding Using Trickle
>   =     Author(s)       : J. Hui, R. Kelsey
> =       Filename        : = draft-ietf-roll-trickle-mcast-00.txt
>       Pages =           : 19
>       = Date            : = 2011-04-11
>
> Low power and Lossy Networks (LLNs) are = typically composed of resource
> constrained nodes communicating = over links that have dynamic
> characteristics.  Memory = constraints coupled with temporal variations
> in link = connectivity makes the use of topology maintenance to support
> = IPv6 multicast challenging.  This document describes the use of = Trickle
> to efficiently forward multicast messages without the = need for topology
> maintenance.
>
> A URL for this = Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-roll-tri= ckle-mcast-
> 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.
_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

 

------_=_NextPart_001_01CC1635.6B95F530-- From prvs=11397edf3=mukul@uwm.edu Thu May 19 08:28:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844BE07C4; Thu, 19 May 2011 08:28:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOv1zlbygir4; Thu, 19 May 2011 08:28:58 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id E1468E0751; Thu, 19 May 2011 08:28:57 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip1mta.uwm.edu with ESMTP; 19 May 2011 10:28:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 2FCFBE6AB8; Thu, 19 May 2011 10:28:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckyh5ipflGRO; Thu, 19 May 2011 10:28:56 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B8B21E6A71; Thu, 19 May 2011 10:28:56 -0500 (CDT) Date: Thu, 19 May 2011 10:28:56 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1428052733.376700.1305818936603.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 15:28:58 -0000 I would be able to do a comparative analysis of two methods as soon as I understand the mechanism described in draft-bormann-6lowpan-ghc. I have already spent a couple of hours trying to understand draft-bormann. At the moment, I cant figure out how the compression mechanism (Section 2) works and how was it applied to the examples listed in the draft. I suspect the draft does not have sufficient level of explanatory text at the moment. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "6lowpan" <6lowpan@ietf.org>, "roll" Sent: Wednesday, May 18, 2011 3:07:24 PM Subject: Re: [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt How does this compare to draft-bormann-6lowpan-ghc? It seems most of the gain will be from compressing out prefixes and zeros, which ghc should handle quite well. -- Jonathan Hui On May 18, 2011, at 10:59 AM, Mukul Goyal wrote: > Hi all > > Fragmentation of RPL control messages has emerged as one of the key concerns when RPL is run over IEEE 802.15.4 networks. The submitted draft specifies a compression mechanism for RPL control messages. We have currently specified compression formats for DIO messages and some of the options that sit inside a DIO. Future versions of this draft may include compression formats for other DIO options as well as other RPL control messages. The mechanism can even be extended to ICMPv6 messages in general. > > Thanks > Mukul > > ----- Forwarded Message ----- > From: internet-drafts@ietf.org > To: mukul@uwm.edu > Cc: "jerald p martocci" , "emmanuel baccelli" , mukul@uwm.edu, "matthias philipp" , abr@sdesigns.dk > Sent: Wednesday, May 18, 2011 12:50:20 PM > Subject: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt > > A new version of I-D, draft-goyal-6lowpan-rpl-compression-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. > > Filename: draft-goyal-6lowpan-rpl-compression > Revision: 00 > Title: A Compression Format for RPL Control Messages Over a 6lowpan > Creation date: 2011-05-17 > WG ID: Individual Submission > Number of pages: 10 > > Abstract: > This document specifies a compression format for ICMPv6 RPL control > messages over a 6lowpan. The specified format is in accordance with > IPv6 header compression framework defined for a 6lowpan. > > > > > The IETF Secretariat > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu May 19 09:06:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DC5E06D5; Thu, 19 May 2011 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdPaYcHSbGtC; Thu, 19 May 2011 09:06:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F3CE3E06B8; Thu, 19 May 2011 09:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4JG6DuH013468; Thu, 19 May 2011 18:06:13 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62ED.dip.t-dialin.net [91.62.98.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 82D49E19; Thu, 19 May 2011 18:06:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1428052733.376700.1305818936603.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Thu, 19 May 2011 18:06:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7727E31C-5F3D-499C-9B3D-8939A415B7D8@tzi.org> References: <1428052733.376700.1305818936603.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 16:06:27 -0000 On May 19, 2011, at 17:28, Mukul Goyal wrote: > I would be able to do a comparative analysis of two methods as soon as = I understand the mechanism described in draft-bormann-6lowpan-ghc. I = have already spent a couple of hours trying to understand draft-bormann. = At the moment, I cant figure out how the compression mechanism (Section = 2) works and how was it applied to the examples listed in the draft. I = suspect the draft does not have sufficient level of explanatory text at = the moment. Hi Mukul, as usual for compression specs, the spec defines the *de*compressor (on = one page, because that's all that's needed -- ignore the experimental = nibblecode part, as that doesn't seem to be too popular). The spec does assume some basic familiarity with compression technology = (it does not use anything that has not been known since the late 1970s, = though), which you may want to look up. As with most compression technologies, there are many ways to write a = compressor, so specifying a compressor would be overspecification; of = course, with the rather limited set of elements in the spec, there = aren't *that* many ways of doing it. When approaching such a specification, it is probably best to look at = the examples and satisfy yourself that your understanding of the = decompressor indeed generates the uncompressed bits. The annotated = example on slide 38 of the Prague 6LoWPAN tutorial slides = (http://www.iab.org/about/workshops/smartobjects/tutorial/Bormann.pdf) = might help, too. Then go ahead and think about a good way (reasonably = efficient, but not complex) to generate the compressed bits. The compressor I used for generating the examples is a bit simple-minded = at about 50 lines of code (the decompressor is 30 lines). It = essentially runs through the uncompressed bytes, finding sequences of = zeros and prefix matches in previous uncompressed bytes, and then (if = both are the case) deciding somewhat naively which of the two are more = compact; if none are the case, it generates a copy element up to the = next useful match. I you have pcaps of the kind of RPL messages that you want to compress = with your spec, I could also simply run them through my example code. Gruesse, Carsten From cabo@tzi.org Thu May 19 09:27:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15889E0720; Thu, 19 May 2011 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLQjgB-xt89V; Thu, 19 May 2011 09:27:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 19868E06E0; Thu, 19 May 2011 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4JGQtB8019659; Thu, 19 May 2011 18:26:55 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62ED.dip.t-dialin.net [91.62.98.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6143AE2B; Thu, 19 May 2011 18:26:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Thu, 19 May 2011 18:26:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 16:27:06 -0000 Mukul, I just looked at your draft in a little more detail. Certainly, a purpose-built spec to squeeze out redundancy from a = specific packet format will generally be more efficient than the generic = compression I have written up. However, the arguments in section 1.1 of = draft-bormann-6lowpan-ghc-02.txt apply to the fullest here. Since the HC spec needs to be understood by all nodes, it creates a = powerful obstacle in evolving the subject protocol. The strong coupling = between the subject protocol and the compression spec also creates = opportunity for interesting interoperability problems. As a distant observer of the ROLL WG, one thing I don't understand is = why this is necessary in the first place. As far as I understand, the domain of RPL is low-power (i.e., = constrained) networks. 6LoWPAN is just one of the network types RPL will be used on, and = redoing this work for every other type (that benefits from compactness) = sounds wasteful to me. Why doesn't RPL itself define a reasonably compact representation then? Gruesse, Carsten From c.chauvenet@watteco.com Thu May 19 10:01:06 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B765E073B for ; Thu, 19 May 2011 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTNmwnE74egj for ; Thu, 19 May 2011 10:01:05 -0700 (PDT) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id CC81CE0706 for ; Thu, 19 May 2011 10:01:03 -0700 (PDT) Received: from mail52-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 19 May 2011 17:01:03 +0000 Received: from mail52-tx2 (localhost.localdomain [127.0.0.1]) by mail52-tx2-R.bigfish.com (Postfix) with ESMTP id 23F9210195; Thu, 19 May 2011 17:01:03 +0000 (UTC) X-SpamScore: -83 X-BigFish: VPS-83(zz1432N15caKJ14ffOzz1202hzz8275dh1033ILz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB019.red002.local; RD:none; EFVD:NLI Received: from mail52-tx2 (localhost.localdomain [127.0.0.1]) by mail52-tx2 (MessageSwitch) id 1305824444978891_25846; Thu, 19 May 2011 17:00:44 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.252]) by mail52-tx2.bigfish.com (Postfix) with ESMTP id D6D461848191; Thu, 19 May 2011 16:59:31 +0000 (UTC) Received: from IE2RD2HUB019.red002.local (213.199.187.153) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 19 May 2011 16:59:29 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB019.red002.local ([10.43.198.97]) with mapi; Thu, 19 May 2011 09:58:33 -0700 From: C Chauvenet To: "Pascal Thubert (pthubert)" , "phoebus@ieee.org" Date: Thu, 19 May 2011 10:01:00 -0700 Thread-Topic: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: AcwVnWm7aVFJo301Qc6OAdBQxoYUlQAg5eZgAAjwMYA= Message-ID: References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> <4DB04573.7060302@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com> <4DC939BB.50406@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com> <4DD43154.6000209@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BCE0F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D049BCE0F@XMB-AMS-107.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 17:01:06 -0000 Hi all,=20 About the step_of_rank computation :=20 I understand it means but I fail to see how to compute it. There is a reference to the MRHOF draft in the beginning of section 4.1 of = OF0. Does it means that we should refer to that draft to compute it ? or it is voluntary not to define it and let to the implementation ? I'm wondering about interoperability issues between different implementatio= ns using OF0. Best,=20 C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de P= ascal Thubert (pthubert) Envoy=E9=A0: jeudi 19 mai 2011 14:37 =C0=A0: phoebus@ieee.org; roll@ietf.org Objet=A0: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, confi= guring parameters, and editorial comments Hello Phoebus, > >> 5) Rewrite the equation: > >> R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease as > >> > >> R(N) =3D R(P) + rank_increase > >> where > >> rank_increase =3D (rank_factor * step_of_rank + stretch_of_rank) * > >> MinHopRankIncrease > >> > >> So we have less new variables (Ri, Rf, Sp, Sr). > >> > > [Pascal] OK... >=20 > PC> ?? I don't see the changes in version 12. You will add them in 13, > I presume. [Pascal] I did half of the way actually;=20 The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then possibly stretched by a stretch_of_rank Sr. The resulting rank_increase is added to the Rank of preferred parent R(P) to obtain that of this node R(N): R(N) =3D R(P) + rank_increase where: rank_increase =3D (Rf*Sp + Sr) * MinHopRankIncrease [Pascal]=20 The full version was harder to read IMHO. >=20 > PC> > And three more typos (look at Diff2 between 11 and 12 to spot them): >=20 > (pg. 3, around line 28) ...OF0 only requires the information in the RPL > DIO obtained from provisionning ... > s/provisionning/provisioning/ >=20 > (pg. 7 around line 57) text in "Processing DIO:" > s/Objective Code Point OCP)/Objective Code Point (OCP)/ >=20 >=20 > (pg. 7) text in "Calling back:" > s/Parent List as occurred/Parent List has occurred/ [Pascal] Sorry for those. We can still fix that with the RCF editor. Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=11397edf3=mukul@uwm.edu Thu May 19 11:49:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15299E06BE; Thu, 19 May 2011 11:49:25 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+542kT8MnZC; Thu, 19 May 2011 11:49:24 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 43DB6E06AD; Thu, 19 May 2011 11:49:23 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip1mta.uwm.edu with ESMTP; 19 May 2011 13:49:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A973112E3AF; Thu, 19 May 2011 13:49:09 -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 QxAvI1moFpac; Thu, 19 May 2011 13:49:09 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 2A5EA12E3AE; Thu, 19 May 2011 13:49:09 -0500 (CDT) Date: Thu, 19 May 2011 13:49:09 -0500 (CDT) From: Mukul Goyal To: Carsten Bormann Message-ID: <1440112826.380330.1305830949067.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2011 18:49:25 -0000 >As a distant observer of the ROLL WG, one thing I don't understand is why this is necessary in the first place. >As far as I understand, the domain of RPL is low-power (i.e., constrained) networks. >6LoWPAN is just one of the network types RPL will be used on, and redoing this work for every other type (that benefits from >compactness) sounds wasteful to me. >Why doesn't RPL itself define a reasonably compact representation then? I think that is a good idea. The reasons I targetted 6lowpan: 1) In my view, RPL over 6lowpan is a common case. 2) 6lowpan already has a mechanism for next header compression, that we could use. Thanks Mukul ----- Original Message ----- From: "Carsten Bormann" To: "Mukul Goyal" Cc: "6lowpan" <6lowpan@ietf.org>, "roll" Sent: Thursday, May 19, 2011 11:26:54 AM Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt Mukul, I just looked at your draft in a little more detail. Certainly, a purpose-built spec to squeeze out redundancy from a specific packet format will generally be more efficient than the generic compression I have written up. However, the arguments in section 1.1 of draft-bormann-6lowpan-ghc-02.txt apply to the fullest here. Since the HC spec needs to be understood by all nodes, it creates a powerful obstacle in evolving the subject protocol. The strong coupling between the subject protocol and the compression spec also creates opportunity for interesting interoperability problems. As a distant observer of the ROLL WG, one thing I don't understand is why this is necessary in the first place. As far as I understand, the domain of RPL is low-power (i.e., constrained) networks. 6LoWPAN is just one of the network types RPL will be used on, and redoing this work for every other type (that benefits from compactness) sounds wasteful to me. Why doesn't RPL itself define a reasonably compact representation then? Gruesse, Carsten From pthubert@cisco.com Thu May 19 23:50:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E01E06A7 for ; Thu, 19 May 2011 23:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTWbe+OHWo1s for ; Thu, 19 May 2011 23:50:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 983B1E0655 for ; Thu, 19 May 2011 23:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3505; q=dns/txt; s=iport; t=1305874249; x=1307083849; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JFMabJ1n6t8+g41mfMSj/+KYxVgTPwr3c/dSDN3nneU=; b=lRcuFV/ysUEWzmGsW1I5LpwFU7feyKCfxoNgYEsVmix9IwDgOYBIoBOG wIiAeRmh8i1KezZbCH0Q+lsKN9G8xm1wBsXKg8zhkVoVqSJu+O8q06gPe lUbW53bfKdBDMHhltHBiUU45Puri8xN5I/VjTngWyI1dMkdBHQ1GpE+uW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAPIO1k2Q/khRgWdsb2JhbACXXI49FAEBFiYlqDieA4YZBJRJij8 X-IronPort-AV: E=Sophos;i="4.65,241,1304294400"; d="scan'208";a="89627794" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 20 May 2011 06:50:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4K6oWrJ008433; Fri, 20 May 2011 06:50:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 May 2011 08:50: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: Fri, 20 May 2011 08:50:21 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D049BCFC8@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: AcwVnWm7aVFJo301Qc6OAdBQxoYUlQAg5eZgAAjwMYAAHRcJIA== References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com><4DB04573.7060302@ieee.org><6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com><4DC939BB.50406@ieee.org><6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com><4DD43154.6000209@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BCE0F@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , X-OriginalArrivalTime: 20 May 2011 06:50:32.0261 (UTC) FILETIME=[3698BF50:01CC16BA] Cc: roll@ietf.org Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2011 06:50:51 -0000 Hi Cedric: The spec explicitly DOES NOT tell you how to compute step_of_rank. You = get to implement what you prefer. What allows interop is that the = whatever qualifies has best has a step of 1, worst acceptable a step of = 9, and the normal expected a step of 3. So you compare normal with = normal but you do not know how a different implementation computes = normal. The rationale behind this is that OF0 must be applicable regardless of = the Link layer. So we cannot be any specific in that regard. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com] > Sent: Thursday, May 19, 2011 7:01 PM > To: Pascal Thubert (pthubert); phoebus@ieee.org > Cc: roll@ietf.org > Subject: RE: [Roll] OF0 draft v9: preferred metric, = Stretch-of-Rank,configuring > parameters, and editorial comments >=20 > Hi all, >=20 > About the step_of_rank computation : >=20 > I understand it means but I fail to see how to compute it. >=20 > There is a reference to the MRHOF draft in the beginning of section = 4.1 of > OF0. > Does it means that we should refer to that draft to compute it ? > or it is voluntary not to define it and let to the implementation ? >=20 > I'm wondering about interoperability issues between different > implementations using OF0. >=20 > Best, >=20 > C=E9dric. >=20 > -----Message d'origine----- > De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de Pascal > Thubert (pthubert) Envoy=E9=A0: jeudi 19 mai 2011 14:37 =C0=A0: = phoebus@ieee.org; > roll@ietf.org Objet=A0: Re: [Roll] OF0 draft v9: preferred metric, = Stretch-of- > Rank, configuring parameters, and editorial comments >=20 > Hello Phoebus, >=20 >=20 > > >> 5) Rewrite the equation: > > >> R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease = as > > >> > > >> R(N) =3D R(P) + rank_increase > > >> where > > >> rank_increase =3D (rank_factor * step_of_rank + stretch_of_rank) = * > > >> MinHopRankIncrease > > >> > > >> So we have less new variables (Ri, Rf, Sp, Sr). > > >> > > > [Pascal] OK... > > > > PC> ?? I don't see the changes in version 12. You will add them in > 13, > > I presume. >=20 > [Pascal] I did half of the way actually; >=20 > The step_of_rank Sp that is computed for that link is multiplied by > the rank_factor Rf and then possibly stretched by a stretch_of_rank > Sr. The resulting rank_increase is added to the Rank of preferred > parent R(P) to obtain that of this node R(N): >=20 > R(N) =3D R(P) + rank_increase where: >=20 > rank_increase =3D (Rf*Sp + Sr) * MinHopRankIncrease [Pascal] >=20 > The full version was harder to read IMHO. >=20 > > > > PC> > > And three more typos (look at Diff2 between 11 and 12 to spot them): > > > > (pg. 3, around line 28) ...OF0 only requires the information in the > RPL > > DIO obtained from provisionning ... > > s/provisionning/provisioning/ > > > > (pg. 7 around line 57) text in "Processing DIO:" > > s/Objective Code Point OCP)/Objective Code Point (OCP)/ > > > > > > (pg. 7) text in "Calling back:" > > s/Parent List as occurred/Parent List has occurred/ >=20 > [Pascal] Sorry for those. We can still fix that with the RCF editor. >=20 > Pascal >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From c.chauvenet@watteco.com Fri May 20 00:14:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D4EE0686 for ; Fri, 20 May 2011 00:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAjrgPc4Eyl7 for ; Fri, 20 May 2011 00:14:02 -0700 (PDT) Received: from VA3EHSOBE001.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 48A43E06D7 for ; Fri, 20 May 2011 00:14:01 -0700 (PDT) Received: from mail161-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 20 May 2011 07:14:00 +0000 Received: from mail161-va3 (localhost.localdomain [127.0.0.1]) by mail161-va3-R.bigfish.com (Postfix) with ESMTP id C8B351B7064F; Fri, 20 May 2011 07:14:00 +0000 (UTC) X-SpamScore: -92 X-BigFish: VPS-92(z37d5kz9371O542M1432N15caKJ14ffOzz1202hzz8275bh8275dh1033ILz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB017.red002.local; RD:none; EFVD:NLI Received: from mail161-va3 (localhost.localdomain [127.0.0.1]) by mail161-va3 (MessageSwitch) id 1305875639493051_31932; Fri, 20 May 2011 07:13:59 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.236]) by mail161-va3.bigfish.com (Postfix) with ESMTP id 72CFE7E804E; Fri, 20 May 2011 07:13:59 +0000 (UTC) Received: from IE2RD2HUB017.red002.local (213.199.187.153) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 20 May 2011 07:13:56 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB017.red002.local ([10.43.198.95]) with mapi; Fri, 20 May 2011 00:13:38 -0700 From: C Chauvenet To: "Pascal Thubert (pthubert)" , "phoebus@ieee.org" Date: Fri, 20 May 2011 00:16:10 -0700 Thread-Topic: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank,configuring parameters, and editorial comments Thread-Index: AcwVnWm7aVFJo301Qc6OAdBQxoYUlQAg5eZgAAjwMYAAHRcJIAABId9A Message-ID: References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com><4DB04573.7060302@ieee.org><6A2A459175DABE4BB11DE2026AA50A5D0487C408@XMB-AMS-107.cisco.com><4DC939BB.50406@ieee.org><6A2A459175DABE4BB11DE2026AA50A5D049BC78F@XMB-AMS-107.cisco.com><4DD43154.6000209@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D049BCE0F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D049BCFC8@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D049BCFC8@XMB-AMS-107.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2011 07:14:04 -0000 Hi Pascal,=20 Thank you for this explanation,=20 It is now very clear. C=E9dric. -----Message d'origine----- De=A0: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Envoy=E9=A0: vendredi 20 mai 2011 08:50 =C0=A0: C Chauvenet; phoebus@ieee.org Cc=A0: roll@ietf.org Objet=A0: RE: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank,config= uring parameters, and editorial comments Hi Cedric: The spec explicitly DOES NOT tell you how to compute step_of_rank. You get = to implement what you prefer. What allows interop is that the whatever qual= ifies has best has a step of 1, worst acceptable a step of 9, and the norma= l expected a step of 3. So you compare normal with normal but you do not kn= ow how a different implementation computes normal. The rationale behind this is that OF0 must be applicable regardless of the = Link layer. So we cannot be any specific in that regard. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com] > Sent: Thursday, May 19, 2011 7:01 PM > To: Pascal Thubert (pthubert); phoebus@ieee.org > Cc: roll@ietf.org > Subject: RE: [Roll] OF0 draft v9: preferred metric,=20 > Stretch-of-Rank,configuring parameters, and editorial comments >=20 > Hi all, >=20 > About the step_of_rank computation : >=20 > I understand it means but I fail to see how to compute it. >=20 > There is a reference to the MRHOF draft in the beginning of section=20 > 4.1 of OF0. > Does it means that we should refer to that draft to compute it ? > or it is voluntary not to define it and let to the implementation ? >=20 > I'm wondering about interoperability issues between different=20 > implementations using OF0. >=20 > Best, >=20 > C=E9dric. >=20 > -----Message d'origine----- > De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part=20 > de Pascal Thubert (pthubert) Envoy=E9=A0: jeudi 19 mai 2011 14:37 =C0=A0:= =20 > phoebus@ieee.org; roll@ietf.org Objet=A0: Re: [Roll] OF0 draft v9:=20 > preferred metric, Stretch-of- Rank, configuring parameters, and=20 > editorial comments >=20 > Hello Phoebus, >=20 >=20 > > >> 5) Rewrite the equation: > > >> R(N) =3D R(P) + Ri where Ri =3D (Rf*Sp + Sr) * MinHopRankIncrease as > > >> > > >> R(N) =3D R(P) + rank_increase > > >> where > > >> rank_increase =3D (rank_factor * step_of_rank + stretch_of_rank) * > > >> MinHopRankIncrease > > >> > > >> So we have less new variables (Ri, Rf, Sp, Sr). > > >> > > > [Pascal] OK... > > > > PC> ?? I don't see the changes in version 12. You will add them in > 13, > > I presume. >=20 > [Pascal] I did half of the way actually; >=20 > The step_of_rank Sp that is computed for that link is multiplied by > the rank_factor Rf and then possibly stretched by a stretch_of_rank > Sr. The resulting rank_increase is added to the Rank of preferred > parent R(P) to obtain that of this node R(N): >=20 > R(N) =3D R(P) + rank_increase where: >=20 > rank_increase =3D (Rf*Sp + Sr) * MinHopRankIncrease [Pascal] >=20 > The full version was harder to read IMHO. >=20 > > > > PC> > > And three more typos (look at Diff2 between 11 and 12 to spot them): > > > > (pg. 3, around line 28) ...OF0 only requires the information in the > RPL > > DIO obtained from provisionning ... > > s/provisionning/provisioning/ > > > > (pg. 7 around line 57) text in "Processing DIO:" > > s/Objective Code Point OCP)/Objective Code Point (OCP)/ > > > > > > (pg. 7) text in "Calling back:" > > s/Parent List as occurred/Parent List has occurred/ >=20 > [Pascal] Sorry for those. We can still fix that with the RCF editor. >=20 > Pascal >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From vincent.brillault@imag.fr Thu May 26 08:01:02 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50CE074A for ; Thu, 26 May 2011 08:01:02 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHbBVNWCBJZJ for ; Thu, 26 May 2011 08:00:53 -0700 (PDT) Received: from mx.lerya.net (lerya.net [213.251.186.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC74E0657 for ; Thu, 26 May 2011 08:00:53 -0700 (PDT) Received: from fea.lerya.net (fea.lerya.net [10.9.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.lerya.net (Postfix) with ESMTPS id D85BE62A04 for ; Thu, 26 May 2011 17:00:47 +0200 (CEST) Received: by fea.lerya.net (Postfix, from userid 1042) id 51A7E20038; Thu, 26 May 2011 17:00:46 +0200 (CEST) Date: Thu, 26 May 2011 17:00:46 +0200 From: Vincent Brillault To: roll@ietf.org Message-ID: <20110526150046.GE3300@Fea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline X-Mailer: Mutt 1.5.x User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Roll] draft-ietf-roll-rpl X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 May 2011 15:01:02 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I have a little comment on the draft-ietf-roll-rpl : On section 7 of the current version, the Sequence Counters are defined. Shouldn't the Destination Advertisement Trigger Sequence Number (DTSN) be described in this section as well ? Sincerely yours, Vincent --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk3eax4ACgkQZq4yYBXMAIATmAEAuKHGN5xSEO7xhHpracJuFQJY OPKnekhO/LWhR1S6NW0A/2m9sBfmIgSPXRKdG6OIvkMz+B73Shg2eCaAZScypmAN =3Clo -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From prvs=122fb4a35=mukul@uwm.edu Fri May 27 18:03:45 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A267E068C; Fri, 27 May 2011 18:03:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9PPvhuUfNjD; Fri, 27 May 2011 18:03:44 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8875FE0618; Fri, 27 May 2011 18:03:44 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip2mta.uwm.edu with ESMTP; 27 May 2011 20:03:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1340412E3AF; Fri, 27 May 2011 20:03:44 -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 KJGguR8Pc8Ye; Fri, 27 May 2011 20:03:43 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A79AD12E3AE; Fri, 27 May 2011 20:03:43 -0500 (CDT) Date: Fri, 27 May 2011 20:03:43 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <808531535.452646.1306544623563.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <20110528005817.15421.8794.idtracker@ietfa.amsl.com> 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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: 6lowpan <6lowpan@ietf.org> Subject: [Roll] Fwd: New Version Notification for draft-goyal-roll-rpl-compression-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2011 01:03:45 -0000 Hi all This draft is an update on draft-goyal-6lowpan-rpl-compression-00. It consists of the following changes: 1) Made the compression scheme independent of 6lowpan header compression 2) Included the compressed versions of metric/constraint objects 3) Included examples of DIO size with and without compression. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: mukul@uwm.edu Cc: "jerald p martocci" , "emmanuel baccelli" , mukul@uwm.edu, "matthias philipp" , abr@sdesigns.dk Sent: Friday, May 27, 2011 7:58:17 PM Subject: New Version Notification for draft-goyal-roll-rpl-compression-00.txt A new version of I-D, draft-goyal-roll-rpl-compression-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-rpl-compression Revision: 00 Title: A Compression Format for RPL Control Messages Creation date: 2011-05-28 WG ID: Individual Submission Number of pages: 15 Abstract: This document specifies a compression format for RPL ICMPv6 RPL control messages. The IETF Secretariat From m.pouillot@watteco.com Tue May 31 00:10:50 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D9E068B for ; Tue, 31 May 2011 00:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.434 X-Spam-Level: ** X-Spam-Status: No, score=2.434 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM70E7BIJTvn for ; Tue, 31 May 2011 00:10:47 -0700 (PDT) Received: from VA3EHSOBE001.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7FFE073E for ; Tue, 31 May 2011 00:10:46 -0700 (PDT) Received: from mail186-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 31 May 2011 07:10:45 +0000 Received: from mail186-va3 (localhost.localdomain [127.0.0.1]) by mail186-va3-R.bigfish.com (Postfix) with ESMTP id 482D16E8170 for ; Tue, 31 May 2011 07:10:45 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzz8275bh8275dhz2dh54h49h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB022.red002.local; RD:none; EFVD:NLI Received: from mail186-va3 (localhost.localdomain [127.0.0.1]) by mail186-va3 (MessageSwitch) id 1306825844382785_13030; Tue, 31 May 2011 07:10:44 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.248]) by mail186-va3.bigfish.com (Postfix) with ESMTP id 5374E17D8051 for ; Tue, 31 May 2011 07:10:44 +0000 (UTC) Received: from IE2RD2HUB022.red002.local (213.199.187.153) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 31 May 2011 07:10:43 +0000 Received: from IE2RD2XVS151.red002.local ([10.43.202.15]) by IE2RD2HUB022.red002.local ([10.43.198.100]) with mapi; Tue, 31 May 2011 00:10:37 -0700 From: M Pouillot To: "roll@ietf.org" Date: Tue, 31 May 2011 00:11:48 -0700 Thread-Topic: Non-Storing vs Storing Thread-Index: AcwfYBOPZ/sRXbTORhqzMl4VQOA63g== Message-ID: <555DED900DD42348B2995D1005EF166202614F03B9@IE2RD2XVS151.red002.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/related; boundary="_005_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: [Roll] Non-Storing vs Storing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 May 2011 07:10:50 -0000 --_005_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_ Content-Type: multipart/alternative; boundary="_000_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_" --_000_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGVsbG8gZXZlcnkgYm9keSwNCg0KSSdtIGxvb2tpbmcgZm9yIHN0dWRpZXMsIHBhcGVycywgb3Ig ZmVlZGJhY2sgYWJvdXQgcmVjb21tZW5kYXRpb24gb24gbm9uLXN0b3JpbmcgYWdhaW5zdCBzdG9y aW5nIG1vZGUgIGluIHRoZSBjb250ZXh0IHdoZXJlIHRoZSBtZW1vcnkgc2l6ZSBpcyBub3QgYSBw cm9ibGVtLg0KDQpDb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIHJlZmVyZW5jZXMgb3Igc29tZSBwcmVj b25pemF0aW9ucyBhYm91dCBpdD8NCg0KVGhhbmtzIGEgbG90LA0KDQpNYXRoaWV1DQoNCi0tDQpb Y2lkOmltYWdlMDAxLmpwZ0AwMUNDMUY3MS5ENTMwNzUzMF0NCg0KTWF0aGlldSBQT1VJTExPVA0K UiZEIEVuZ2luZWVyDQoNCm0ucG91aWxsb3RAd2F0dGVjby5jb208bWFpbHRvOm0ucG91aWxsb3RA d2F0dGVjby5jb20+DQoNCkRpcmVjdCBsaW5lIDogKzMzKDApNCA5OCAwMSA2MCAwNQ0KDQpUZWwg OiArMzMoMCk0IDk4IDAxIDYwIDA1DQpGYXggOiArMzMoMCk0IDk0IDE0IDEwIDgwDQoNCjE3NjYg Q2hlbWluIGRlIGxhIFBsYW5xdWV0dGUNCjgzMTMwIExBIEdBUkRFIC0gRnJhbmNlDQp3d3cud2F0 dGVjby5jb208aHR0cDovL3d3dy53YXR0ZWNvLmNvbT4NCg0KW2NpZDppbWFnZTAwMi5naWZAMDFD QzFGNzEuRDUzMDc1MzBdQmVmb3JlIHByaW50aW5nIHRoaW5rIGFib3V0IGVudmlyb25tZW50IGFu ZCBjb3N0cw0KVGhpcyBNZXNzYWdlIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUgbmFtZWQgYWJvdmUu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBieSBtaXN0YWtlLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkgcmVwbHkgZW1haWwgaW1tZWRpYXRlbHkuIFBsZWFzZSBjb25kdWN0IHlvdXIgb3du IHZpcnVzIGNoZWNrcyBiZWZvcmUgb3BlbmluZyBhbnkgYXR0YWNobWVudCBhcyBXYXR0ZWNvIGRv ZXMgbm90IGd1YXJhbnRlZSB0aGUgaW50ZWdyaXR5IG9mIHRoaXMgZW1haWwgb3IgYXR0YWNoZWQg ZmlsZXMgaGFzIGJlZW4gbWFpbnRhaW5lZCBub3IgdGhpcyBjb21tdW5pY2F0aW9uIGlzIGZyZWUg b2YgdmlydXNlcywgaW50ZXJjZXB0aW9ucyBvciBpbnRlcmZlcmVuY2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIg YW5kIG1heSBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmlld3Mgb2YgV2F0dGVjby4gV2F0 dGVjbyBzaGFsbCBub3QgYmUgcmVzcG9uc2libGUgbm9yIGxpYWJsZSBmb3IgdGhlIGltcHJvcGVy IGFuZCBpbmNvbXBsZXRlIHRyYW5zbWlzc2lvbiBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgY29tbXVuaWNhdGlvbiBub3IgZm9yIGFueSBkZWxheSBpbiBpdHMgcmVjZWlwdCBv ciBkYW1hZ2UgdG8geW91ciBzeXN0ZW0uDQoNCg0KDQo= --_000_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48 c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K LnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0t PjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMg Q2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFt ZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD5IZWxsbyBldmVyeSBib2R5LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SSdtIGxvb2tpbmcgZm9yIHN0dWRp ZXMsIHBhcGVycywgb3IgZmVlZGJhY2sgYWJvdXQgcmVjb21tZW5kYXRpb24gb24gbm9uLXN0b3Jp bmcgYWdhaW5zdCBzdG9yaW5nIG1vZGUgJm5ic3A7aW4gdGhlIGNvbnRleHQgd2hlcmUgdGhlIG1l bW9yeSBzaXplIGlzIG5vdCBhIHByb2JsZW0uIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Q291bGQgeW91IGdp dmUgbWUgc29tZSByZWZlcmVuY2VzIG9yIHNvbWUgcHJlY29uaXphdGlvbnMgYWJvdXQgaXQ/PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD5UaGFua3MgYSBsb3QsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5NYXRoaWV1PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkZS Jz4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJv cmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NjE3IHN0eWxlPSd3aWR0aDo0NjIuNzVwdCc+PHRy Pjx0ZCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Njttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PGltZyB3 aWR0aD0yNTIgaGVpZ2h0PTE2MCBpZD0iSW1hZ2VfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEu anBnQDAxQ0MxRjcxLkQ1MzA3NTMwIiBhbHQ9IkRlc2NyaXB0aW9uJm5ic3A7OiBjaWQ6cGFydDEu MDEwNDA1MDIuMDQwNzA5MDFAd2F0dGVjby5jb20iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3Rk Pjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MjIuNXB0O21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlInPk1hdGhpZXUgUE9VSUxMT1QgPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjgu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlInPjxicj5SJmFtcDtEIEVuZ2luZWVyIDxicj48YnI+PGEgaHJlZj0i bWFpbHRvOm0ucG91aWxsb3RAd2F0dGVjby5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz5t LnBvdWlsbG90QHdhdHRlY28uY29tPC9zcGFuPjwvYT4gPGJyPjxicj48Yj5EaXJlY3QgbGluZTwv Yj4gOiArMzMoMCk0IDk4IDAxIDYwIDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCB2 YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MjIuNXB0O21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjMwLjBwdCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2O21zby1mYXJl YXN0LWxhbmd1YWdlOkZSJz5UZWw8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Njttc28tZmFy ZWFzdC1sYW5ndWFnZTpGUic+IDogKzMzKDApNCA5OCAwMSA2MCAwNTxicj48Yj5GYXg8L2I+IDog KzMzKDApNCA5NCAxNCAxMCA4MDxicj48YnI+MTc2NiBDaGVtaW4gZGUgbGEgUGxhbnF1ZXR0ZTxi cj44MzEzMCBMQSBHQVJERSAmIzgyMTE7IEZyYW5jZSA8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy53 YXR0ZWNvLmNvbSI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPnd3dy53YXR0ZWNvLmNvbTwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxpbWcgYm9yZGVyPTAgd2lkdGg9MjQgaGVpZ2h0 PTIzIGlkPSJJbWFnZV94MDAyMF8yIiBzcmM9ImNpZDppbWFnZTAwMi5naWZAMDFDQzFGNzEuRDUz MDc1MzAiIGFsdD0iRGVzY3JpcHRpb24mbmJzcDs6IGNpZDpwYXJ0Mi4wNjAyMDYwMi4wMDAwMDIw OUB3YXR0ZWNvLmNvbSI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwOTkwMDttc28tZmFyZWFzdC1s YW5ndWFnZTpGUic+QmVmb3JlIHByaW50aW5nIHRoaW5rIGFib3V0PGI+IGVudmlyb25tZW50IDwv Yj5hbmQgPGI+Y29zdHM8L2I+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOkZSJz4gPG86cD48L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1N c29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9 NjIwIHN0eWxlPSd3aWR0aDo0NjUuMHB0O2JhY2tncm91bmQ6d2hpdGUnPjx0cj48dGQgc3R5bGU9 J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt YWxpZ246anVzdGlmeSc+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlInPlRoaXMgTWVzc2FnZSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG5hbWVkIGFib3Zl LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgbWVzc2FnZSB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHByb2hpYml0ZWQuIElm IHlvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgYnkgbWlzdGFrZSwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGltbWVkaWF0ZWx5LiBQbGVhc2UgY29uZHVjdCB5b3VyIG93 biB2aXJ1cyBjaGVja3MgYmVmb3JlIG9wZW5pbmcgYW55IGF0dGFjaG1lbnQgYXMgV2F0dGVjbyBk b2VzIG5vdCBndWFyYW50ZWUgdGhlIGludGVncml0eSBvZiB0aGlzIGVtYWlsIG9yIGF0dGFjaGVk IGZpbGVzIGhhcyBiZWVuIG1haW50YWluZWQgbm9yIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBmcmVl IG9mIHZpcnVzZXMsIGludGVyY2VwdGlvbnMgb3IgaW50ZXJmZXJlbmNlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy IGFuZCBtYXkgbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgdGhlIHZpZXdzIG9mIFdhdHRlY28uIFdh dHRlY28gc2hhbGwgbm90IGJlIHJlc3BvbnNpYmxlIG5vciBsaWFibGUgZm9yIHRoZSBpbXByb3Bl ciBhbmQgaW5jb21wbGV0ZSB0cmFuc21pc3Npb24gb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGNvbW11bmljYXRpb24gbm9yIGZvciBhbnkgZGVsYXkgaW4gaXRzIHJlY2VpcHQg b3IgZGFtYWdlIHRvIHlvdXIgc3lzdGVtLjwvc3Bhbj48L2k+PGk+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjtjb2xvcjoj NjY2NjY2O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSJz48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9w PjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_-- --_005_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=7606; creation-date="Tue, 31 May 2011 00:10:36 GMT"; modification-date="Tue, 31 May 2011 00:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== --_005_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=490; creation-date="Tue, 31 May 2011 00:10:36 GMT"; modification-date="Tue, 31 May 2011 00:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --_005_555DED900DD42348B2995D1005EF166202614F03B9IE2RD2XVS151r_--