From trac@tools.ietf.org Thu Apr 1 00:53:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055B03A6A48 for ; Thu, 1 Apr 2010 00:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.876 X-Spam-Level: X-Spam-Status: No, score=-100.876 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyP2OwJnHyw6 for ; Thu, 1 Apr 2010 00:53:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2942A3A6A0E for ; Thu, 1 Apr 2010 00:53:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxFDk-0001oQ-EP; Thu, 01 Apr 2010 00:53:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: richard.kelsey@ember.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 01 Apr 2010 07:53:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/32 Message-ID: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.kelsey@ember.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.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, 01 Apr 2010 07:53:14 -0000 #32: Asymetric Link --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: richard.kelsey@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- In a network with asymmetric links, DODAGs can be formed to optimize upward, downward, or bidirectional routes. There needs to be some way to indicate how asymmetric link metrics are to be used when forming a particular DODAG. A DODAG meant for routing upwards would want to use the upward metric values, for example. A DODAG meant for use in both directions might want the average of the upward and downward values, or the max or min, depending on the metric. -- Ticket URL: roll From jpv@cisco.com Thu Apr 1 00:53:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6053A6A97 for ; Thu, 1 Apr 2010 00:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.93 X-Spam-Level: X-Spam-Status: No, score=-7.93 tagged_above=-999 required=5 tests=[AWL=1.539, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlcxS+UZS-To for ; Thu, 1 Apr 2010 00:53:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8C6B93A6A0E for ; Thu, 1 Apr 2010 00:53:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfts0urR7Ht/2dsb2JhbACbOnGaTZkehQEE X-IronPort-AV: E=Sophos;i="4.51,346,1267401600"; d="scan'208";a="175785751" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2010 07:54:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o317sHMf008313; Thu, 1 Apr 2010 07:54:20 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:54:02 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:54:02 +0200 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87mxxo2n1i.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 09:54:01 +0200 References: <87mxxo2n1i.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Apr 2010 07:54:02.0683 (UTC) FILETIME=[7EC480B0:01CAD170] Cc: roll@ietf.org Subject: Re: [Roll] ticket for handling asymmetric link metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 07:53:49 -0000 THanks Richard. Ticket opened. Cheers. JP. On Mar 31, 2010, at 11:34 PM, Richard Kelsey wrote: > JP, > > An issue has come up that I think merits a ticket. > > In a network with asymmetric links, DODAGs can be formed to > optimize upward, downward, or bidirectional routes. There > needs to be some way to indicate how asymmetric link metrics > are to be used when forming a particular DODAG. A DODAG > meant for routing upwards would want to use the upward > metric values, for example. A DODAG meant for use in both > directions might want the average of the upward and downward > values, or the max or min, depending on the metric. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Thu Apr 1 04:01:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF3D3A67B4 for ; Thu, 1 Apr 2010 04:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sAmdYW336jo for ; Thu, 1 Apr 2010 04:01:48 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 61D773A67AE for ; Thu, 1 Apr 2010 04:01:48 -0700 (PDT) Received: from source ([74.125.82.49]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKS7R9OyTtCsaD2HGYu7NHyhGFamloH2nK@postini.com; Thu, 01 Apr 2010 04:02:21 PDT Received: by mail-ww0-f49.google.com with SMTP id 36so645362wwa.8 for ; Thu, 01 Apr 2010 04:02:19 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> In-Reply-To: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrRcHrICFhMScq1R7WN0k9DejqTrAAGiDHQ Date: Thu, 1 Apr 2010 14:02:21 +0300 Received: by 10.216.90.130 with SMTP id e2mr312051wef.210.1270119739592; Thu, 01 Apr 2010 04:02:19 -0700 (PDT) Message-ID: <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> To: roll@ietf.org, richard.kelsey@ember.com, jpv@cisco.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 11:01:49 -0000 Hi, Maybe occasional unicast DIS to a parent(s) from the parent set can be used to solve this? This coincides with the issue of DIS options. Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of rol= l issue tracker Sent: Thursday, April 01, 2010 10:54 AM To: richard.kelsey@ember.com; jpv@cisco.com Cc: roll@ietf.org Subject: [Roll] [roll] #32: Asymetric Link #32: Asymetric Link --------------------------------+------------------------------------------= - Reporter: jpv@=85 | Owner: richard.kelsey@=85 Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------= - In a network with asymmetric links, DODAGs can be formed to optimize upward, downward, or bidirectional routes. There needs to be some way to indicate how asymmetric link metrics are to be used when forming a particular DODAG. A DODAG meant for routing upwards would want to use the upward metric values, for example. A DODAG meant for use in both directions might want the average of the upward and downward values, or the max or min, depending on the metric. --=20 Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Thu Apr 1 04:14:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F8F3A67B4 for ; Thu, 1 Apr 2010 04:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC-qAcGbM8j0 for ; Thu, 1 Apr 2010 04:14:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0E23F3A69BD for ; Thu, 1 Apr 2010 04:14:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A8B233235875; Thu, 1 Apr 2010 04:15:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 87BB63228034; Thu, 1 Apr 2010 04:15:06 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Yoav Ben-Yehezkel In-Reply-To: <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 13:15:04 +0200 References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 11:14:40 -0000 Just a related thought here.... If the L2 employs any kind of bi-directional signaling RPL may need to =20= specifically exclude uni-directional links. This is not just =20 hypothetic: if, for example, a L2 employs ACKs for unicast, but not =20 for broadcast, the use of an uni-directional link should be excluded. =20= This may be particularly relevant for NUD (which is suggested used for =20= detecting when a preferred parent is unreachable), where absence of an =20= L2 ack may be interpreted as such. This, of course, leads to the question of below which =20 "metric" (quality, ...) a link should be considered "uni-directional" =20= rather than just "asymmetric"? To take an abstract example, assuming a =20= L2 employing ack's for each unicast transmission: if the probability =20 of getting a transmission from A to B is 100% and from B to A is 10%, =20= is the link A->B "asymmetric" or "uni-directional"? Can the metric for =20= A->B be considered without also considering the metric in the opposite =20= direction B->A? It's a rather common occurrence in the wireless networks I've seen -- =20= and presumably something we want RPL to handle correctly (other than =20 by having NUD flag an error 9 times out of 10, and then hunt around =20 for a new preferred parent, etc....) I guess my point is: the metric A->B can not be universally considered =20= independent of the metric B->A, especially considering the reliance on =20= NUD. Thomas On Apr 1, 2010, at 13:02 PM, Yoav Ben-Yehezkel wrote: > Hi, > > Maybe occasional unicast DIS to a parent(s) from the parent set can =20= > be used > to solve this? > This coincides with the issue of DIS options. > > Thanks, > Yoav > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of roll > issue tracker > Sent: Thursday, April 01, 2010 10:54 AM > To: richard.kelsey@ember.com; jpv@cisco.com > Cc: roll@ietf.org > Subject: [Roll] [roll] #32: Asymetric Link > > #32: Asymetric Link > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=85 | Owner: richard.kelsey@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > In a network with asymmetric links, DODAGs can be formed to > optimize upward, downward, or bidirectional routes. There > needs to be some way to indicate how asymmetric link metrics > are to be used when forming a particular DODAG. A DODAG > meant for routing upwards would want to use the upward > metric values, for example. A DODAG meant for use in both > directions might want the average of the upward and downward > values, or the max or min, depending on the metric. > > --=20 > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=7008652d0=mukul@uwm.edu Thu Apr 1 04:54:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC5A3A69B2 for ; Thu, 1 Apr 2010 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63P0rXjecyNJ for ; Thu, 1 Apr 2010 04:54:08 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 7B3C03A6912 for ; Thu, 1 Apr 2010 04:54:08 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 01 Apr 2010 06:54:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4F996C085A1; Thu, 1 Apr 2010 06:54:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul 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 NeuT8EnkpDbH; Thu, 1 Apr 2010 06:54:39 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id DB30DC085A0; Thu, 1 Apr 2010 06:54:39 -0500 (CDT) Date: Thu, 1 Apr 2010 06:54:39 -0500 (CDT) From: Mukul Goyal To: Thomas Heide Clausen Message-ID: <457555097.2572451270122879803.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1866790063.2572281270122787548.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 11:54:09 -0000 Hi Thomas I guess we have to distinguish between L3 and L2 metrics. It sees to me tha= t RPL is concerned with L3 metrics and how they relate to L2 metrics should= not bother RPL. [Thomas] This, of course, leads to the question of below which =20 "metric" (quality, ...) a link should be considered "uni-directional" =20 rather than just "asymmetric"? To take an abstract example, assuming a =20 L2 employing ack's for each unicast transmission: if the probability =20 of getting a transmission from A to B is 100% and from B to A is 10%, =20 is the link A->B "asymmetric" or "uni-directional"? Can the metric for =20 A->B be considered without also considering the metric in the opposite =20 direction B->A? [Mukul] In this case, I guess L3 metric A->B would automatically be quite p= oor because of its dependence of L2 metrics A->B and B->A. But, still L3 me= tric A->B is independent of the L3 metric B->A. Thanks, Mukul On Apr 1, 2010, at 13:02 PM, Yoav Ben-Yehezkel wrote: > Hi, > > Maybe occasional unicast DIS to a parent(s) from the parent set can =20 > be used > to solve this? > This coincides with the issue of DIS options. > > Thanks, > Yoav > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20 > Of roll > issue tracker > Sent: Thursday, April 01, 2010 10:54 AM > To: richard.kelsey@ember.com; jpv@cisco.com > Cc: roll@ietf.org > Subject: [Roll] [roll] #32: Asymetric Link > > #32: Asymetric Link > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=E2=80=A6 | Owner: richard.kelsey@=E2= =80=A6 > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > In a network with asymmetric links, DODAGs can be formed to > optimize upward, downward, or bidirectional routes. There > needs to be some way to indicate how asymmetric link metrics > are to be used when forming a particular DODAG. A DODAG > meant for routing upwards would want to use the upward > metric values, for example. A DODAG meant for use in both > directions might want the average of the upward and downward > values, or the max or min, depending on the metric. > > --=20 > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Thu Apr 1 05:55:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4F33A699E for ; Thu, 1 Apr 2010 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y799TgkmdzVb for ; Thu, 1 Apr 2010 05:55:01 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id B47163A6BE1 for ; Thu, 1 Apr 2010 05:45:44 -0700 (PDT) Received: from source ([74.125.82.174]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS7SVmOS6bequ6e7R3PP+04p5e53zJ8A8@postini.com; Thu, 01 Apr 2010 05:46:17 PDT Received: by wyb39 with SMTP id 39so493917wyb.19 for ; Thu, 01 Apr 2010 05:46:16 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrRjJgL4dbZbnuKSwmk6kuhnHQ6IQACfb9Q Date: Thu, 1 Apr 2010 15:46:18 +0300 Received: by 10.216.87.194 with SMTP id y44mr384951wee.157.1270125976096; Thu, 01 Apr 2010 05:46:16 -0700 (PDT) Message-ID: <003601cad199$53222ab0$f9668010$@com> To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 12:55:02 -0000 Thomas, I agree with you completely. In PLC networks, there's no way to ensure that the metric is the same or even close in both directions. Noise variations between sockets are *completely* different (consider a switch with a modem trying to transmit to a modem near a working washing machine, dryer and TV). The variation can reach more than 20dB. This is why I was suggesting to use a DIS/DIO exchange between child and parent to get the twofold advantage: i.e. exchange L3 metric between these nodes, and also ensuring a bi-directional link exists (since the child receives DIOs, the bad link well could be from child->parent, in which case the DIS from the child will not be received by the parent). RPL suggestion to use L2 ACK cannot provide any L3 metric exchange from child to parent (up), which could be an important factor since the traffic is going that way and not down from parent to child, though this is the metric on which the OF relies in the child. Thanks, Yoav -----Original Message----- From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] Sent: Thursday, April 01, 2010 2:15 PM To: Yoav Ben-Yehezkel Cc: roll@ietf.org; richard.kelsey@ember.com; jpv@cisco.com Subject: Re: [Roll] [roll] #32: Asymetric Link Just a related thought here.... If the L2 employs any kind of bi-directional signaling RPL may need to specifically exclude uni-directional links. This is not just hypothetic: if, for example, a L2 employs ACKs for unicast, but not for broadcast, the use of an uni-directional link should be excluded. This may be particularly relevant for NUD (which is suggested used for detecting when a preferred parent is unreachable), where absence of an L2 ack may be interpreted as such. This, of course, leads to the question of below which "metric" (quality, ...) a link should be considered "uni-directional" rather than just "asymmetric"? To take an abstract example, assuming a L2 employing ack's for each unicast transmission: if the probability of getting a transmission from A to B is 100% and from B to A is 10%, is the link A->B "asymmetric" or "uni-directional"? Can the metric for A->B be considered without also considering the metric in the opposite direction B->A? It's a rather common occurrence in the wireless networks I've seen -- and presumably something we want RPL to handle correctly (other than by having NUD flag an error 9 times out of 10, and then hunt around for a new preferred parent, etc....) I guess my point is: the metric A->B can not be universally considered independent of the metric B->A, especially considering the reliance on NUD. Thomas On Apr 1, 2010, at 13:02 PM, Yoav Ben-Yehezkel wrote: > Hi, > > Maybe occasional unicast DIS to a parent(s) from the parent set can > be used > to solve this? > This coincides with the issue of DIS options. > > Thanks, > Yoav > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of roll > issue tracker > Sent: Thursday, April 01, 2010 10:54 AM > To: richard.kelsey@ember.com; jpv@cisco.com > Cc: roll@ietf.org > Subject: [Roll] [roll] #32: Asymetric Link > > #32: Asymetric Link > -------------------------------- > +------------------------------------------- > Reporter: jpv@. | Owner: richard.kelsey@. > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > -------------------------------- > +------------------------------------------- > In a network with asymmetric links, DODAGs can be formed to > optimize upward, downward, or bidirectional routes. There > needs to be some way to indicate how asymmetric link metrics > are to be used when forming a particular DODAG. A DODAG > meant for routing upwards would want to use the upward > metric values, for example. A DODAG meant for use in both > directions might want the average of the upward and downward > values, or the max or min, depending on the metric. > > -- > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Apr 1 06:18:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D523A69E5 for ; Thu, 1 Apr 2010 06:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.729 X-Spam-Level: X-Spam-Status: No, score=0.729 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCXQ+hydOqQI for ; Thu, 1 Apr 2010 06:18:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B84FB3A68B6 for ; Thu, 1 Apr 2010 06:18:31 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 39CB1346FB for ; Thu, 1 Apr 2010 09:16:40 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 27A904E798 for ; Thu, 1 Apr 2010 09:19:03 -0400 (EDT) From: Michael Richardson To: 'roll' X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 01 Apr 2010 09:19:03 -0400 Message-ID: <8073.1270127943@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:18:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote: mcr> This is a VERY HARD problem to solve, because really, if the attacker mcr> just installed a high-gain antenna in one part of the building, a coax mcr> cable, and another antenna in another part of the building, it's really mcr> the same thing! The difference is perhaps that the totally passive mcr> system will relay packets usefully. In another thread, Kris Pister wrote: Kris> This is a nice example, in that it's akin to the sort of weird RF Kris> behavior that occurs naturally. Nodes far apart in the network Kris> suddenly hear each other quite well for some period of time, and Kris> then just as mysteriously don't hear each other anymore. RPL had Kris> better be able to deal with this, or we're in deep trouble. And then Philip Levis replies: Philip> It does not seem an undue burden to me for a node to send a Philip> request/response that demonstrates another node's real presence Philip> before making that node its preferred parent. Or are there Philip> simpler mechanisms? I wondered if the ACK from the parent could not simply be the fact that the parent sends an DAO to it's parent. If that DAO is multicast rather than unicast, and it contains a list of children nodes that it is serving, then it serves as an ACK that the parent has seen, and accepted the child's DAO. This is a group ACK, piggy backed on a packet that the parent already has to send. As it's now multicast, it needs to actually now contain an indication of which parent it was really for. The downside is that many children have to wake up to hear this multicast, but they might also have to listen for the unicast ACK. Alternatively, if one wants to keep the DAO unicast, then the subsequent DIO could contain that list, but this is data that otherwise does not need to be transmitted. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS7SdRYCLcPvd0N1lAQIyJwf8DmixOJJwK8SnUS/7oHocEH5SggAr46qO V+4XSIZqwqqBzW5iJSb7WD671PTIysXJ5JZc0/MKe9YmqSqhyqsO0XHyofwnCQlK yBp8yGRNSLC09yzLgyASHb1M2RWC8uGAbMESsSwZrhkZ/hNgK5IFQNlzEhUgzvzT H2QRu9bfxOJRFNpmiiR4X3UKclJFOIvJbb+lwyOivp4/L4HUXoumELpi0jprW0u4 wNewVqfthIOfdZUkf/NAm1b9iQB2XY97NgHEPmlaavejoYECbHNU8JljEpoElZpx FZfNhDjOjQSxA+gPeYWlns7ZzqLW3Pyk43To2wpLanJaTqYbM1+dIQ== =J0qH -----END PGP SIGNATURE----- From mcr@sandelman.ca Thu Apr 1 06:43:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69093A6784 for ; Thu, 1 Apr 2010 06:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2Yb3nOkxJde for ; Thu, 1 Apr 2010 06:43:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0E78B3A6829 for ; Thu, 1 Apr 2010 06:43:49 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D3BBF3470C; Thu, 1 Apr 2010 09:41:58 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A625A4E7E6; Thu, 1 Apr 2010 09:44:21 -0400 (EDT) From: Michael Richardson To: Thomas Heide Clausen In-Reply-To: References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 01 Apr 2010 09:44:21 -0400 Message-ID: <9784.1270129461@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 13:43:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Thomas" == Thomas Heide Clausen writes: Thomas> Just a related thought here.... Thomas> If the L2 employs any kind of bi-directional signaling RPL Thomas> may need to specifically exclude uni-directional links. This This ticket/topic, is not about *uni*-directional links (no bandwidth in one direction), it's about asymmetric links (some bandwidth only). - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS7SjM4CLcPvd0N1lAQLr7Qf+M9Cq2Fn4kAVXH09j6UWYNZRVChfsv4n1 C07RJ6SgYNi4iy9/KBij9gNcLAwk2MAbQvDcp8ENbdhqNCLwna3Khgix6mKPsgM4 ZtDxuBAn3p+0mGYLG+2Q9o8Rwaa7gSEythEsuSVu0YTrxL6FzBDy3L7dqp+xtqX4 wRIwQL0gU1AKwNb551GDGIyEES5fx88CwIhw7E+8kEafWdj31bYQMZDDqOWeSh2K grCxYc1v4EFQVujJi/hlrN9YLSnlGaXHjOI9UrgZTdmZ5WM1d0uFd2fP7G7+zA03 1LGQ2rf7XMEuN3RpABqsjc15ote30WmtMl5vE9km7ouYki29pSQ+Aw== =T+wA -----END PGP SIGNATURE----- From pthubert@cisco.com Thu Apr 1 07:32:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C533A6829 for ; Thu, 1 Apr 2010 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-3.511, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrzAM-sarsze for ; Thu, 1 Apr 2010 07:32:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 289233A6821 for ; Thu, 1 Apr 2010 07:32:40 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBALdLtEuQ/uCWe2dsb2JhbACbPhUBAQsLIgYcnFWLNI1jhQEE X-IronPort-AV: E=Sophos;i="4.51,348,1267401600"; d="scan'208";a="5080564" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2010 13:58:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o31EXBX8004355; Thu, 1 Apr 2010 14:33:11 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:33:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 16:32:16 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> In-Reply-To: <8073.1270127943@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] acknowledgements from parents Thread-Index: AcrRnfPN/b5R5ouwTmqvB1VdmjES+AACcKKQ References: <8073.1270127943@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "roll" X-OriginalArrivalTime: 01 Apr 2010 14:33:11.0342 (UTC) FILETIME=[4147DCE0:01CAD1A8] Subject: Re: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 14:32:42 -0000 Hi Michael: This sort of promiscuous ack inference has been proposed in a number of papers on the 802.11 mesh world.=20 It implies a number of things like the fact that the child can listen to a packet from Pa to Grand Pa. This is not always the case. The Pa to Gpa link might be 802.11 while child to Pa could be 802.15.4. Or a different crypto could be in place. Or the time slots might be affected in such a fashion that child is sleeping when Pa send to Grand Pa. In any fashion, this can hardly be generalized at L3... Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Thursday, April 01, 2010 3:19 PM > To: 'roll' > Subject: [Roll] acknowledgements from parents >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > I wrote: > mcr> This is a VERY HARD problem to solve, because really, if the > mcr> attacker just installed a high-gain antenna in one part of the > mcr> building, a coax cable, and another antenna in another part of the > mcr> building, it's really the same thing! The difference is perhaps > mcr> that the totally passive system will relay packets usefully. >=20 > In another thread, Kris Pister wrote: > Kris> This is a nice example, in that it's akin to the sort of weird RF > Kris> behavior that occurs naturally. Nodes far apart in the network > Kris> suddenly hear each other quite well for some period of time, and > Kris> then just as mysteriously don't hear each other anymore. RPL had > Kris> better be able to deal with this, or we're in deep trouble. >=20 > And then Philip Levis replies: >=20 > Philip> It does not seem an undue burden to me for a node to send a > Philip> request/response that demonstrates another node's real presence > Philip> before making that node its preferred parent. Or are there > Philip> simpler mechanisms? >=20 > I wondered if the ACK from the parent could not simply be the fact that the > parent sends an DAO to it's parent. If that DAO is multicast rather than > unicast, and it contains a list of children nodes that it is serving, then it serves > as an ACK that the parent has seen, and accepted the child's DAO. >=20 > This is a group ACK, piggy backed on a packet that the parent already has to > send. As it's now multicast, it needs to actually now contain an indication of > which parent it was really for. >=20 > The downside is that many children have to wake up to hear this multicast, > but they might also have to listen for the unicast ACK. >=20 > Alternatively, if one wants to keep the DAO unicast, then the subsequent > DIO could contain that list, but this is data that otherwise does not need to be > transmitted. >=20 > - -- > ] 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. >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys >=20 > iQEVAwUBS7SdRYCLcPvd0N1lAQIyJwf8DmixOJJwK8SnUS/7oHocEH5SggAr46 > qO > V+4XSIZqwqqBzW5iJSb7WD671PTIysXJ5JZc0/MKe9YmqSqhyqsO0XHyofwnC > QlK > yBp8yGRNSLC09yzLgyASHb1M2RWC8uGAbMESsSwZrhkZ/hNgK5IFQNlzEhUg > zvzT > H2QRu9bfxOJRFNpmiiR4X3UKclJFOIvJbb+lwyOivp4/L4HUXoumELpi0jprW0u4 > wNewVqfthIOfdZUkf/NAm1b9iQB2XY97NgHEPmlaavejoYECbHNU8JljEpoElZp > x > FZfNhDjOjQSxA+gPeYWlns7ZzqLW3Pyk43To2wpLanJaTqYbM1+dIQ=3D=3D > =3DJ0qH > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu Apr 1 08:34:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5838A3A6A1B for ; Thu, 1 Apr 2010 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9+QJFIZvkb8 for ; Thu, 1 Apr 2010 08:34:37 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 414823A6AE0 for ; Thu, 1 Apr 2010 08:34:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 06A53AF9AB; Thu, 1 Apr 2010 08:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7V975rEm+hW; Thu, 1 Apr 2010 08:34:45 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 0D504AF923; Thu, 1 Apr 2010 08:34:45 -0700 (PDT) Message-Id: <75137A08-69B5-4D44-8956-7F498DE7467F@archrock.com> From: Jonathan Hui To: Thomas Heide Clausen In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 08:34:44 -0700 References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 15:34:38 -0000 The specific metric that led to the opening of this ticket was latency =20= - I'm not sure where that falls in your definitions of asymmetric vs. =20= uni-directional. It would seem the latter if infinite latency is =20 considered, but it's one example where the two directions may be =20 viewed as independent. Addressing your specific thought: I think it's reasonable to say that =20= any link metrics used should also be responsible for also considering =20= specific properties of the link. Extending that notion, if, at the =20 link layer, communication from A -> B requires some from of =20 communication from B -> A, then metrics used should consider the full =20= process of communicating from A -> B -> A if that's important to the =20 metric (e.g. reliability, margin, etc.). I'm not sure I prefer to =20 rely on L3 to communicate such metrics back and forth simply to be =20 combined into some aggregate link-layer metric. -- Jonathan Hui On Apr 1, 2010, at 4:15 AM, Thomas Heide Clausen wrote: > Just a related thought here.... > > If the L2 employs any kind of bi-directional signaling RPL may need =20= > to specifically exclude uni-directional links. This is not just =20 > hypothetic: if, for example, a L2 employs ACKs for unicast, but not =20= > for broadcast, the use of an uni-directional link should be =20 > excluded. This may be particularly relevant for NUD (which is =20 > suggested used for detecting when a preferred parent is =20 > unreachable), where absence of an L2 ack may be interpreted as such. > > This, of course, leads to the question of below which =20 > "metric" (quality, ...) a link should be considered "uni-=20 > directional" rather than just "asymmetric"? To take an abstract =20 > example, assuming a L2 employing ack's for each unicast =20 > transmission: if the probability of getting a transmission from A to =20= > B is 100% and from B to A is 10%, is the link A->B "asymmetric" or =20 > "uni-directional"? Can the metric for A->B be considered without =20 > also considering the metric in the opposite direction B->A? > > It's a rather common occurrence in the wireless networks I've seen =20 > -- and presumably something we want RPL to handle correctly (other =20 > than by having NUD flag an error 9 times out of 10, and then hunt =20 > around for a new preferred parent, etc....) > > I guess my point is: the metric A->B can not be universally =20 > considered independent of the metric B->A, especially considering =20 > the reliance on NUD. > > Thomas > > On Apr 1, 2010, at 13:02 PM, Yoav Ben-Yehezkel wrote: > >> Hi, >> >> Maybe occasional unicast DIS to a parent(s) from the parent set can =20= >> be used >> to solve this? >> This coincides with the issue of DIS options. >> >> Thanks, >> Yoav >> >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Thursday, April 01, 2010 10:54 AM >> To: richard.kelsey@ember.com; jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #32: Asymetric Link >> >> #32: Asymetric Link >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: richard.kelsey@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> In a network with asymmetric links, DODAGs can be formed to >> optimize upward, downward, or bidirectional routes. There >> needs to be some way to indicate how asymmetric link metrics >> are to be used when forming a particular DODAG. A DODAG >> meant for routing upwards would want to use the upward >> metric values, for example. A DODAG meant for use in both >> directions might want the average of the upward and downward >> values, or the max or min, depending on the metric. >> >> --=20 >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu Apr 1 08:38:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AE33A69C3 for ; Thu, 1 Apr 2010 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IiCUwr7h5N9 for ; Thu, 1 Apr 2010 08:38:01 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4538E3A69EE for ; Thu, 1 Apr 2010 08:37:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D37E8AF923; Thu, 1 Apr 2010 08:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1eAPrD3qlXI; Thu, 1 Apr 2010 08:38:03 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 13796AF99C; Thu, 1 Apr 2010 08:38:03 -0700 (PDT) Message-Id: <6C282829-65B1-4C7A-8B4A-19C43157AB2A@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 08:38:02 -0700 References: <8073.1270127943@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll Subject: Re: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:38:03 -0000 I agree with Pascal here. Even if we could assume operation on the same link, another difficulty is dealing with the widely varying properties of multicast. As you mentioned, multicast can be expensive especially in duty-cycled networks. The cost of delivering a message via multicast can easily vary by 1-2 orders of magnitude depending on whether or not routers duty-cycle their radios. Even DIO transmissions should be as slow a process as possible. For deeply duty-cycled networks, I much prefer to rely on unicast whenever possible and multicast only for basic discovery. -- Jonathan Hui On Apr 1, 2010, at 7:32 AM, Pascal Thubert (pthubert) wrote: > Hi Michael: > > This sort of promiscuous ack inference has been proposed in a number > of > papers on the 802.11 mesh world. > It implies a number of things like the fact that the child can > listen to > a packet from Pa to Grand Pa. > This is not always the case. The Pa to Gpa link might be 802.11 while > child to Pa could be 802.15.4. > Or a different crypto could be in place. Or the time slots might be > affected in such a fashion that child is sleeping when Pa send to > Grand > Pa. > In any fashion, this can hardly be generalized at L3... > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Michael Richardson >> Sent: Thursday, April 01, 2010 3:19 PM >> To: 'roll' >> Subject: [Roll] acknowledgements from parents >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> I wrote: >> mcr> This is a VERY HARD problem to solve, because really, if the >> mcr> attacker just installed a high-gain antenna in one part of the >> mcr> building, a coax cable, and another antenna in another part of > the >> mcr> building, it's really the same thing! The difference is perhaps >> mcr> that the totally passive system will relay packets usefully. >> >> In another thread, Kris Pister wrote: >> Kris> This is a nice example, in that it's akin to the sort of weird > RF >> Kris> behavior that occurs naturally. Nodes far apart in the network >> Kris> suddenly hear each other quite well for some period of time, >> and >> Kris> then just as mysteriously don't hear each other anymore. RPL > had >> Kris> better be able to deal with this, or we're in deep trouble. >> >> And then Philip Levis replies: >> >> Philip> It does not seem an undue burden to me for a node to send a >> Philip> request/response that demonstrates another node's real > presence >> Philip> before making that node its preferred parent. Or are there >> Philip> simpler mechanisms? >> >> I wondered if the ACK from the parent could not simply be the fact > that the >> parent sends an DAO to it's parent. If that DAO is multicast rather > than >> unicast, and it contains a list of children nodes that it is serving, > then it serves >> as an ACK that the parent has seen, and accepted the child's DAO. >> >> This is a group ACK, piggy backed on a packet that the parent already > has to >> send. As it's now multicast, it needs to actually now contain an > indication of >> which parent it was really for. >> >> The downside is that many children have to wake up to hear this > multicast, >> but they might also have to listen for the unicast ACK. >> >> Alternatively, if one wants to keep the DAO unicast, then the > subsequent >> DIO could contain that list, but this is data that otherwise does not > need to be >> transmitted. >> >> - -- >> ] 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. >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Finger me for keys >> >> iQEVAwUBS7SdRYCLcPvd0N1lAQIyJwf8DmixOJJwK8SnUS/7oHocEH5SggAr46 >> qO >> V+4XSIZqwqqBzW5iJSb7WD671PTIysXJ5JZc0/MKe9YmqSqhyqsO0XHyofwnC >> QlK >> yBp8yGRNSLC09yzLgyASHb1M2RWC8uGAbMESsSwZrhkZ/hNgK5IFQNlzEhUg >> zvzT >> H2QRu9bfxOJRFNpmiiR4X3UKclJFOIvJbb+lwyOivp4/L4HUXoumELpi0jprW0u4 >> wNewVqfthIOfdZUkf/NAm1b9iQB2XY97NgHEPmlaavejoYECbHNU8JljEpoElZp >> x >> FZfNhDjOjQSxA+gPeYWlns7ZzqLW3Pyk43To2wpLanJaTqYbM1+dIQ== >> =J0qH >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Thu Apr 1 08:39:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A241A3A6A92 for ; Thu, 1 Apr 2010 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.818 X-Spam-Level: X-Spam-Status: No, score=-4.818 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hw7HYyrF2Ii for ; Thu, 1 Apr 2010 08:39:02 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 562B83A68D5 for ; Thu, 1 Apr 2010 08:39:00 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o31FdUpu009163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Apr 2010 08:39:31 -0700 (PDT) Message-ID: <4BB4BE32.5040406@eecs.berkeley.edu> Date: Thu, 01 Apr 2010 08:39:30 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Michael Richardson References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <15752.1270060965@marajade.sandelman.ca> In-Reply-To: <15752.1270060965@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary="------------080004040305000100060601" Cc: 'roll' Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 15:39:03 -0000 This is a multi-part message in MIME format. --------------080004040305000100060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's configurable, but for a full 127B 15.4 packet plus secure ACK you can get the slot down to under 6ms. HART uses 10ms because they wanted to make sure that people could do it with existing off-the-shelf chips. ksjp Michael Richardson wrote: >>>>>> "Kris" == Kris Pister writes: >>>>>> > Kris> For those using TSCH (802.15.4E), there's built-in replay > Kris> protection because all nodes in the network share a common > Kris> sense of time. Absolute Slot Number is a monotonic > Kris> representation of time, and acts like a nonce in the MIC > Kris> calculation, so replaying a packet in a different time slot > Kris> doesn't work. > > Thanks, that's good to know. > How long is the time slot? > > --------------080004040305000100060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It's configurable, but for a full 127B 15.4 packet plus secure ACK you can get the slot down to under 6ms. 
HART uses 10ms because they wanted to make sure that people could do it with existing off-the-shelf chips.

ksjp

Michael Richardson wrote: 
"Kris" == Kris Pister <pister@eecs.berkeley.edu> writes:
            
    Kris> For those using TSCH (802.15.4E), there's built-in replay
    Kris> protection because all nodes in the network share a common
    Kris> sense of time.  Absolute Slot Number is a monotonic
    Kris> representation of time, and acts like a nonce in the MIC
    Kris> calculation, so replaying a packet in a different time slot
    Kris> doesn't work.

Thanks, that's good to know.
How long is the time slot?
--------------080004040305000100060601-- From ietf@thomasclausen.org Thu Apr 1 08:40:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B203A69B9 for ; Thu, 1 Apr 2010 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFjzvYyz0+Fr for ; Thu, 1 Apr 2010 08:40:34 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CEBCC3A69CC for ; Thu, 1 Apr 2010 08:40:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0A4CE3235A7A; Thu, 1 Apr 2010 08:40:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D81923235A5D; Thu, 1 Apr 2010 08:40:42 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Jonathan Hui In-Reply-To: <75137A08-69B5-4D44-8956-7F498DE7467F@archrock.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 17:40:40 +0200 References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> <75137A08-69B5-4D44-8956-7F498DE7467F@archrock.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 15:40:35 -0000 On Apr 1, 2010, at 17:34 PM, Jonathan Hui wrote: > > The specific metric that led to the opening of this ticket was =20 > latency - I'm not sure where that falls in your definitions of =20 > asymmetric vs. uni-directional. It would seem the latter if =20 > infinite latency is considered, but it's one example where the two =20 > directions may be viewed as independent. Presumably, this would depend on the value of infinity ..... or =20 rather, the time after which a L2 "gives up waiting for an =20 ack" (again, assuming that an L2 uses such) and NUD takes it to mean =20 that "somethin's up".... > Addressing your specific thought: I think it's reasonable to say =20 > that any link metrics used should also be responsible for also =20 > considering specific properties of the link. Extending that notion, =20= > if, at the link layer, communication from A -> B requires some from =20= > of communication from B -> A, then metrics used should consider the =20= > full process of communicating from A -> B -> A if that's important =20 > to the metric (e.g. reliability, margin, etc.). I'm not sure I =20 > prefer to rely on L3 to communicate such metrics back and forth =20 > simply to be combined into some aggregate link-layer metric. I do not have any specific opinions on this matter -- other than that =20= my experience has been that expecting sensible L2 behavior in a =20 wireless world, or even coherence between different L2 =20 implementations, usually has let me down..... I'd therefore suggest =20 that we're able to "handle" this correctly, regardless of what =20 caprices an L2 might have, on L3. Thomas > -- > Jonathan Hui > > On Apr 1, 2010, at 4:15 AM, Thomas Heide Clausen wrote: > >> Just a related thought here.... >> >> If the L2 employs any kind of bi-directional signaling RPL may need =20= >> to specifically exclude uni-directional links. This is not just =20 >> hypothetic: if, for example, a L2 employs ACKs for unicast, but not =20= >> for broadcast, the use of an uni-directional link should be =20 >> excluded. This may be particularly relevant for NUD (which is =20 >> suggested used for detecting when a preferred parent is =20 >> unreachable), where absence of an L2 ack may be interpreted as such. >> >> This, of course, leads to the question of below which =20 >> "metric" (quality, ...) a link should be considered "uni-=20 >> directional" rather than just "asymmetric"? To take an abstract =20 >> example, assuming a L2 employing ack's for each unicast =20 >> transmission: if the probability of getting a transmission from A =20 >> to B is 100% and from B to A is 10%, is the link A->B "asymmetric" =20= >> or "uni-directional"? Can the metric for A->B be considered without =20= >> also considering the metric in the opposite direction B->A? >> >> It's a rather common occurrence in the wireless networks I've seen =20= >> -- and presumably something we want RPL to handle correctly (other =20= >> than by having NUD flag an error 9 times out of 10, and then hunt =20 >> around for a new preferred parent, etc....) >> >> I guess my point is: the metric A->B can not be universally =20 >> considered independent of the metric B->A, especially considering =20 >> the reliance on NUD. >> >> Thomas >> >> On Apr 1, 2010, at 13:02 PM, Yoav Ben-Yehezkel wrote: >> >>> Hi, >>> >>> Maybe occasional unicast DIS to a parent(s) from the parent set =20 >>> can be used >>> to solve this? >>> This coincides with the issue of DIS options. >>> >>> Thanks, >>> Yoav >>> >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >>> Behalf Of roll >>> issue tracker >>> Sent: Thursday, April 01, 2010 10:54 AM >>> To: richard.kelsey@ember.com; jpv@cisco.com >>> Cc: roll@ietf.org >>> Subject: [Roll] [roll] #32: Asymetric Link >>> >>> #32: Asymetric Link >>> --------------------------------=20 >>> +------------------------------------------- >>> Reporter: jpv@=85 | Owner: richard.kelsey@=85 >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: rpl | Version: >>> Severity: Active WG Document | Keywords: >>> --------------------------------=20 >>> +------------------------------------------- >>> In a network with asymmetric links, DODAGs can be formed to >>> optimize upward, downward, or bidirectional routes. There >>> needs to be some way to indicate how asymmetric link metrics >>> are to be used when forming a particular DODAG. A DODAG >>> meant for routing upwards would want to use the upward >>> metric values, for example. A DODAG meant for use in both >>> directions might want the average of the upward and downward >>> values, or the max or min, depending on the metric. >>> >>> --=20 >>> Ticket URL: >>> roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From pete.st.pierre@oracle.com Thu Apr 1 08:41:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B063A681C for ; Thu, 1 Apr 2010 08:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMjXhJFRDUx3 for ; Thu, 1 Apr 2010 08:41:16 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id A9A6C3A6892 for ; Thu, 1 Apr 2010 08:41:06 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o31FfKPL026393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Apr 2010 15:41:33 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31CkNGD027184; Thu, 1 Apr 2010 15:41:19 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 138527211270136438; Thu, 01 Apr 2010 08:40:38 -0700 Received: from [192.168.1.56] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 08:40:38 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Pete St. Pierre" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> Date: Thu, 1 Apr 2010 08:40:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8073.1270127943@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1078) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB4BEA0.0088:SCFMA4539814,ss=1,fgs=0 Cc: roll Subject: Re: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:41:18 -0000 Additionally, I would also be concerned about the intended parent having = a greater chance of missing the RPL ACK due to using multicast over = unicast. For some L2s (like 15.4), unicast traffic benefits from an L2 = ACK, which is not present when using multicast (or broadcast in the case = of 15.4). I'm hesitant to optimize this if it lowers reliability of the message = getting through to the intended recipient. ...Pete On Apr 1, 2010, at 7:32 AM, Pascal Thubert (pthubert) wrote: > Hi Michael: >=20 > This sort of promiscuous ack inference has been proposed in a number = of > papers on the 802.11 mesh world.=20 > It implies a number of things like the fact that the child can listen = to > a packet from Pa to Grand Pa. > This is not always the case. The Pa to Gpa link might be 802.11 while > child to Pa could be 802.15.4. > Or a different crypto could be in place. Or the time slots might be > affected in such a fashion that child is sleeping when Pa send to = Grand > Pa. > In any fashion, this can hardly be generalized at L3... >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Michael Richardson >> Sent: Thursday, April 01, 2010 3:19 PM >> To: 'roll' >> Subject: [Roll] acknowledgements from parents >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >>=20 >> I wrote: >> mcr> This is a VERY HARD problem to solve, because really, if the >> mcr> attacker just installed a high-gain antenna in one part of the >> mcr> building, a coax cable, and another antenna in another part of > the >> mcr> building, it's really the same thing! The difference is perhaps >> mcr> that the totally passive system will relay packets usefully. >>=20 >> In another thread, Kris Pister wrote: >> Kris> This is a nice example, in that it's akin to the sort of weird > RF >> Kris> behavior that occurs naturally. Nodes far apart in the network >> Kris> suddenly hear each other quite well for some period of time, = and >> Kris> then just as mysteriously don't hear each other anymore. RPL > had >> Kris> better be able to deal with this, or we're in deep trouble. >>=20 >> And then Philip Levis replies: >>=20 >> Philip> It does not seem an undue burden to me for a node to send a >> Philip> request/response that demonstrates another node's real > presence >> Philip> before making that node its preferred parent. Or are there >> Philip> simpler mechanisms? >>=20 >> I wondered if the ACK from the parent could not simply be the fact > that the >> parent sends an DAO to it's parent. If that DAO is multicast rather > than >> unicast, and it contains a list of children nodes that it is serving, > then it serves >> as an ACK that the parent has seen, and accepted the child's DAO. >>=20 >> This is a group ACK, piggy backed on a packet that the parent already > has to >> send. As it's now multicast, it needs to actually now contain an > indication of >> which parent it was really for. >>=20 >> The downside is that many children have to wake up to hear this > multicast, >> but they might also have to listen for the unicast ACK. >>=20 >> Alternatively, if one wants to keep the DAO unicast, then the > subsequent >> DIO could contain that list, but this is data that otherwise does not > need to be >> transmitted. >>=20 >> - -- >> ] 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. >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Finger me for keys >>=20 >> iQEVAwUBS7SdRYCLcPvd0N1lAQIyJwf8DmixOJJwK8SnUS/7oHocEH5SggAr46 >> qO >> V+4XSIZqwqqBzW5iJSb7WD671PTIysXJ5JZc0/MKe9YmqSqhyqsO0XHyofwnC >> QlK >> yBp8yGRNSLC09yzLgyASHb1M2RWC8uGAbMESsSwZrhkZ/hNgK5IFQNlzEhUg >> zvzT >> H2QRu9bfxOJRFNpmiiR4X3UKclJFOIvJbb+lwyOivp4/L4HUXoumELpi0jprW0u4 >> wNewVqfthIOfdZUkf/NAm1b9iQB2XY97NgHEPmlaavejoYECbHNU8JljEpoElZp >> x >> FZfNhDjOjQSxA+gPeYWlns7ZzqLW3Pyk43To2wpLanJaTqYbM1+dIQ=3D=3D >> =3DJ0qH >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 -- Pete St. Pierre Pete.St.Pierre@oracle.com Sun Labs Oracle=20 16 Network Circle Menlo Park, CA 94025 From jhui@archrock.com Thu Apr 1 08:45:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B59E3A6898 for ; Thu, 1 Apr 2010 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeaqqMTFgGe4 for ; Thu, 1 Apr 2010 08:45:51 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 20A853A684F for ; Thu, 1 Apr 2010 08:45:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E75BBAF923; Thu, 1 Apr 2010 08:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w99BwqJEuQz1; Thu, 1 Apr 2010 08:46:19 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 41440AF81F; Thu, 1 Apr 2010 08:46:19 -0700 (PDT) Message-Id: <0A48C897-132C-4C28-B7CA-E1CEB3C78FB6@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923A3D@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 08:46:18 -0700 References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AAE9@XMB-AMS-107.cisco.com> <68E6C8D6-65C6-4ED7-9927-1DEEB078A404@cs.jhu.edu><6A2A459175DABE4BB11DE2026AA50A5D0188AAFB@XMB-AMS-107.cisco.com><006f01cacf87$273db310$75b91930$@alexander@ekasystems.com><5A5438DD-F6D3-4E09-A3E4-A269319F8EEC@cs.jhu.edu><007201cacf8b$00817b90$018472b0$@alexander@ekasystems.com><207C6B80-B20B-4553-B04C-CC88841E1002@cs.jhu.edu><009201cacf8f$95d779c0$c1866d40$@alexander@ekasystems.com><0146F5F5-5D51-443D-A18F-F0333759BC83@cs.jhu.edu><010301cad059$b8017350$280459f0$@alexander@ekasystems.com><322B249E-6EE0-4FC8-8AC2-9AC227E4B66C@archrock.com><45AE56C8-66D7-466C-8E5E-89DAC23BE196@cs.jhu.edu><03A6E62B-5EF5-497F-98DC-6B38E882918D@archrock.com><87vdcc374j.fsf@kelsey-ws.hq.ember.com><74BABD6C-D44A-48FD-A636-B65D425CE507@archrock.com><87pr2k30pz.fsf@kelsey-ws.hq.ember.c om> <8AA C1025-AA82-4 772-BEDB-A40154A173D9@archrock.com><87oci42njd.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01923A3D@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 15:45:52 -0000 Hi Pascal, On Mar 31, 2010, at 11:57 PM, Pascal Thubert (pthubert) wrote: > The default route is needed as soon as you do some P2P along the DAG, > because you cannot switch instance on the way. This is somewhat > unrelated to the discussion here. Fully agree. I would classify a P2P RPL instance as needing to deal with both upward and downward routes. > The question is rather which instance is applied to a packet before > the > packet is sent out. > > The application in a RPL node needs to be (abstractly) aware of > instances, and it should tag the packets with the proper instance ID > so > that the DAG that is computed to optimize the upstream is used. Even > if > multiple DAGs have a default route, we still use the right one. If this is our working assumption, then we need to document it clearly. It implies that host nodes that do not participate in RPL will need to understand which RPL instances are available, what properties they have, and what RPL instance IDs map to them. At some level, I would feel more comfortable saying that an app is knowledgeable of what kind of services it wants (e.g. deliver this packet with low latency). But note in that last example, 'low latency' may mean traversing two separate instances if I have separate instances for upwards and downwards routes. Another concern may be for provisioning - can/should a router use default routes setup by an instance purely intended for downward routing? At this point, I guess I would need to see this fleshed out more to see how this would work... -- Jonathan Hui From trac@tools.ietf.org Thu Apr 1 09:16:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615D13A6973 for ; Thu, 1 Apr 2010 09:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.889 X-Spam-Level: X-Spam-Status: No, score=-100.889 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1j78nX2YpHL for ; Thu, 1 Apr 2010 09:16:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F0D003A6911 for ; Thu, 1 Apr 2010 09:16:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxN4h-0000vA-MD; Thu, 01 Apr 2010 09:16:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 01 Apr 2010 16:16:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/17#comment:1 Message-ID: <064.7ea9a542ae275aeb6a2263ed2f13e2d0@tools.ietf.org> References: <055.17284056a1873989dfcef0e53c684a63@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <055.17284056a1873989dfcef0e53c684a63@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #17: Path Digest X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.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, 01 Apr 2010 16:16:34 -0000 #17: Path Digest --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: This ticket is obsoleted by #26 - www.ietf.org/mail-archive/web/roll/current/msg03449.html -- Ticket URL: roll From pal@cs.stanford.edu Thu Apr 1 09:40:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881463A69C3 for ; Thu, 1 Apr 2010 09:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suAv9P28jpJZ for ; Thu, 1 Apr 2010 09:40:15 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C9CA13A68C2 for ; Thu, 1 Apr 2010 09:40:15 -0700 (PDT) Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxNRm-0007Z5-Nz; Thu, 01 Apr 2010 09:40:48 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <457555097.2572451270122879803.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 1 Apr 2010 08:59:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17BF289E-708F-45BB-9245-DD292A3BB8B0@cs.stanford.edu> References: <457555097.2572451270122879803.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 16:40:16 -0000 On Apr 1, 2010, at 4:54 AM, Mukul Goyal wrote: > Hi Thomas >=20 > I guess we have to distinguish between L3 and L2 metrics. It sees to = me that RPL is concerned with L3 metrics and how they relate to L2 = metrics should not bother RPL. >=20 > [Thomas] This, of course, leads to the question of below which =20 > "metric" (quality, ...) a link should be considered "uni-directional" =20= > rather than just "asymmetric"? To take an abstract example, assuming a = =20 > L2 employing ack's for each unicast transmission: if the probability =20= > of getting a transmission from A to B is 100% and from B to A is 10%, =20= > is the link A->B "asymmetric" or "uni-directional"? Can the metric for = =20 > A->B be considered without also considering the metric in the opposite = =20 > direction B->A? >=20 > [Mukul] In this case, I guess L3 metric A->B would automatically be = quite poor because of its dependence of L2 metrics A->B and B->A. But, = still L3 metric A->B is independent of the L3 metric B->A. I think the discussion is a bit clearer once you consider the "metric" = may not be delivery. I.e., it is possible to have a link that has 100% = delivery in both directions yet highly asymmetric metrics. One simple = case is latency. I think that unidirectional links or links with very poor delivery in = one direction are a diversion when it comes to routing. As Thomas points = out, it is absolutely critical that a routing protocol be able to = identify and ignore/avoid them: this isn't too hard. Trying to use them = effectively, however, requires a lot of complexity with very little = gain, so let's not go down that path. Phil= From pal@cs.stanford.edu Thu Apr 1 09:41:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824183A6973 for ; Thu, 1 Apr 2010 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.175 X-Spam-Level: X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4FD-WNGBxyV for ; Thu, 1 Apr 2010 09:41:24 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id BDF6D3A68C2 for ; Thu, 1 Apr 2010 09:41:24 -0700 (PDT) Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxNSv-0007XP-5G; Thu, 01 Apr 2010 09:41:57 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <75137A08-69B5-4D44-8956-7F498DE7467F@archrock.com> Date: Thu, 1 Apr 2010 09:41:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.4fc3ec504a24fd2c8b478a74b06782f4@tools.ietf.org> <4252bd96aa5258423f57d08df527d4b7@mail.gmail.com> <75137A08-69B5-4D44-8956-7F498DE7467F@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 16:41:25 -0000 On Apr 1, 2010, at 8:34 AM, Jonathan Hui wrote: >=20 > The specific metric that led to the opening of this ticket was latency = - I'm not sure where that falls in your definitions of asymmetric vs. = uni-directional. It would seem the latter if infinite latency is = considered, but it's one example where the two directions may be viewed = as independent. >=20 > Addressing your specific thought: I think it's reasonable to say that = any link metrics used should also be responsible for also considering = specific properties of the link. Extending that notion, if, at the link = layer, communication from A -> B requires some from of communication = from B -> A, then metrics used should consider the full process of = communicating from A -> B -> A if that's important to the metric (e.g. = reliability, margin, etc.). I'm not sure I prefer to rely on L3 to = communicate such metrics back and forth simply to be combined into some = aggregate link-layer metric. I agree -- this is really a link metric concern, which we want to = separate from the core workings of RPL.=20 Phil= From mcr@sandelman.ca Thu Apr 1 12:09:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBF13A6A13 for ; Thu, 1 Apr 2010 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.955 X-Spam-Level: * X-Spam-Status: No, score=1.955 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V3bbS3Jmbuv for ; Thu, 1 Apr 2010 12:09:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 49DE73A696A for ; Thu, 1 Apr 2010 12:08:59 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id ACA3234739; Thu, 1 Apr 2010 15:07:09 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 84FC04E7EC; Thu, 1 Apr 2010 15:09:31 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> References: <8073.1270127943@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 01 Apr 2010 15:09:31 -0400 Message-ID: <1743.1270148971@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll Subject: Re: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:09:01 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> This sort of promiscuous ack inference has been proposed in Pascal> a number of papers on the 802.11 mesh world. It implies a Pascal> number of things like the fact that the child can listen to Pascal> a packet from Pa to Grand Pa. This is not always the Pascal> case. The Pa to Gpa link might be 802.11 while child to Pa Pascal> could be 802.15.4. Or a different crypto could be in Pascal> place. Or the time slots might be affected in such a fashion Pascal> that child is sleeping when Pa send to Grand Pa. In any Pascal> fashion, this can hardly be generalized at L3... So the alternative is what? In the case you mention, where the links are the not the same, then I'd say just gratuitously send the multicast on both networks. Isn't that still cheaper than sending individual ACKs? Do you ACK every DAO? Or just the first? The alternative seems to Unicast ACK of every single message, right? Isn't that at least as costly to the intermediate node as a link-local multicast? It's true --- the child might be asleep. Why should we think the child is awake to get the unicast ACK? Hey --- the parent might be asleep when the child unicasts it's DAO! -- ] 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 roger.alexander@ekasystems.com Thu Apr 1 14:47:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E430B3A68B8 for ; Thu, 1 Apr 2010 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.15 X-Spam-Level: *** X-Spam-Status: No, score=3.15 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_GIF_ATTACH=1.42, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK-le8bwxgyz for ; Thu, 1 Apr 2010 14:47:33 -0700 (PDT) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 2092A3A68A3 for ; Thu, 1 Apr 2010 14:47:33 -0700 (PDT) Received: (qmail 96150 invoked from network); 1 Apr 2010 21:48:03 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 01 Apr 2010 14:48:03 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: CNRE99kVM1nQojZw5r8VENzv_s77yJyuYPrzp.OjYM4qFcXeUhYCExQ30EsMcNnou8kaHHRmrrcdGn.mE4IINMmGVcaE74qwxFTFvCxbLmvpRCJmKIkzz7zsQEo2A9C3evSwdslzc5kHcbeAYV0_tOievQ2JpzgcbewBk4qaOEE_R_i8ILAlPPLY36Kt51SpvVQPoJM4Zz9iTNJeNQJgruO8s0uNscsSi_OcrwteoYThGgpyqAwgHPptI0qLGTFE3w_T6YnECVVu7nRn3suIQCiZoUSXBWG3sKRx.lIFmo8gEeq4vEJ9TOMgwF8cSzn5CpJMN_46RREM34SKZo8.BkuEDKyMMd_xtBATkaTSZeiGoHwjQc.eGN2e72CzrXBLLOOyPw3B X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Pascal Thubert \(pthubert\)'" , References: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> <006301cac059$b2da3e30$188eba90$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5D0188AF8D@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AF8D@XMB-AMS-107.cisco.com> Date: Thu, 1 Apr 2010 17:46:49 -0400 Message-ID: <020f01cad1e4$d5926410$80b72c30$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0210_01CAD1C3.4E80C410" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAPfPIyxeYBGuWTw+gDRQ3zVwt/QAGegBQA90urwAAeBGT8A== Content-Language: en-us Subject: Re: [Roll] Ack the DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2010 21:47:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0210_01CAD1C3.4E80C410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0211_01CAD1C3.4E80C410" ------=_NextPart_001_0211_01CAD1C3.4E80C410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 There will need to be some additional specification work to complete the = picture. Nonetheless, the basic idea for the support of DAO ACKs stems = from the fact that in large urban networks there are long periods of = time over which network connectivity for large segments of the network = may remain largely stable. Under those circumstances it would be = beneficial for improved scalability to maintain cache coherency without = the need to repeat unchanged state information between nodes. The idea = is to be able to limit the amount of information that is sent between a = node and its DAO Parents by providing implicit updates and sending = specific information only when a change in routing database or = connectivity occurs. A la RFC 2091 (Triggered RIP), if a router has = exchanged all routing information with its Parent and some routing = information subsequently changes, only the changed information needs to = be sent to the Parent. The DAO ACK will be an element to support this = type of mechanism. =20 Roger =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Tuesday, March 30, 2010 1:49 AM To: Roger Alexander; roll@ietf.org Subject: RE: [Roll] Ack the DAO? =20 Hi Roger: =20 This looks interesting. Could you please refine your ideas on this = subject?=20 =20 Pascal =20 From: Roger Alexander [mailto:roger.alexander@ekasystems.com]=20 Sent: Wednesday, March 10, 2010 2:58 PM To: Pascal Thubert (pthubert); roll@ietf.org Subject: RE: [Roll] Ack the DAO? =20 Hi Pascal, WG, =20 I do think DAOs should be acknowledged. From the perspective of a system = employing =E2=80=98storing=E2=80=99 nodes, there will be additional = benefits in terms of optimizations that reduce the overhead of exchanged = state information if the DAO messages are reliably transmitted. This may = require some additional update to the DAO message structure but will = open the possibility for implementations to further reduce RPL overhead. =20 Roger =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Wednesday, March 10, 2010 5:39 AM To: roll@ietf.org Subject: [Roll] Ack the DAO? =20 WG: =20 RPL 07 provides means for a node to advertise some reachability using a = DAO mechanism. The DAO can be triggered by the node to match its own = needs. It can also be stimulated by a parent, by incrementing the DTSN, = or by the root, by setting the T bit that causes the DTSN increment to = span the whole DODAG. =20 The DTSN was added as a replacement to a single bit because, due to the = nature of an LLN, we thought that the bit might be lost whereas a DTSN = increment must be seen at some point. But the other way around, the DAO = message is not acknowledged so a node might not obtain the service that = it expects, and a route propagation might be inappropriately delayed. =20 So the simple question is, should we make the DAO a bit more reliable by = adding an ack?=20 =20 =20 =09 Pascal Thubert Engineer.software Engineering Product Development pthubert@cisco.com Phone: +33 4 9723 2634 Mobile: +33 6 1998 2985 Cisco Systems France Village d'Entreprises Green Side 400 Avenue de Roumanille=20 Batiment T 3=20 06410=20 BIOT - SOPHIA ANTIPOLIS France Cisco.com =20 =20 Think before you print.Think before you print. Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 = limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum = Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, = 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel = Givone, For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 =20 ------=_NextPart_001_0211_01CAD1C3.4E80C410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Pascal,

 

There will need to be = some additional specification work to complete the picture. Nonetheless, the = basic idea for the support of DAO ACKs stems from the fact that in large urban networks there are long periods of time over which network connectivity = for large segments of the network may remain largely stable. Under those circumstances it would be beneficial for improved scalability to = maintain cache coherency without the need to repeat unchanged state information between = nodes. The idea is to be able to limit the amount of information that is sent = between a node and its DAO Parents by providing implicit updates and sending = specific information only when a change in routing database or connectivity occurs. A la RFC = 2091 (Triggered RIP), if a router has exchanged all routing information with its Parent = and some routing information subsequently changes, only the changed = information needs to be sent to the Parent. The DAO ACK will be an element to support this = type of mechanism.

 

Roger

 

From:= Pascal = Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, March 30, 2010 1:49 AM
To: Roger Alexander; roll@ietf.org
Subject: RE: [Roll] Ack the DAO?

 

Hi = Roger:

 

This looks = interesting. Could you please refine your ideas on this subject?

 

Pascal

 

From:= Roger = Alexander [mailto:roger.alexander@ekasystems.com]
Sent: Wednesday, March 10, 2010 2:58 PM
To: Pascal Thubert (pthubert); roll@ietf.org
Subject: RE: [Roll] Ack the DAO?

 

Hi Pascal, = WG,

 

I do think DAOs = should be acknowledged. From the perspective of a system employing = =E2=80=98storing=E2=80=99 nodes, there will be additional benefits in terms of optimizations that reduce the = overhead of exchanged state information if the DAO messages are reliably = transmitted. This may require some additional update to the DAO message structure but = will open the possibility for implementations to further reduce RPL = overhead.

 

Roger

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: Wednesday, March 10, 2010 5:39 AM
To: roll@ietf.org
Subject: [Roll] Ack the DAO?

 

WG:

 

RPL 07 provides means for a node to advertise some = reachability using a DAO mechanism. The DAO can be triggered by the node to match its = own needs. It can also be stimulated by a parent, by incrementing the DTSN, = or by the root, by setting the T bit that causes the DTSN increment to span = the whole DODAG.

 

The DTSN was added as a replacement to a single bit = because, due to the nature of an LLN, we thought that the bit might be lost = whereas a DTSN increment must be seen at some point. But the other way around, the = DAO message is not acknowledged so a node might not obtain the service that = it expects, and a route propagation might be inappropriately = delayed.

 

So the simple question is, should we make the DAO a = bit more reliable by adding an ack?

 

 

= Pascal Thubert
Engineer.software Engineering
Product Development
pthubert@cisco.com
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

= Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille
Batiment T 3
06410
BIOT - SOPHIA ANTIPOLIS
France
Cisco.com

 

 

3D"ThinkThink before you print.

Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 = responsabiit=C3=A9 limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal = information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html= =

 

 

------=_NextPart_001_0211_01CAD1C3.4E80C410-- ------=_NextPart_000_0210_01CAD1C3.4E80C410 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgHSURBVHja 7Z0HfJRF+sdV7Gc5xbuzoVLEBqKnByignHd6KDaw0FWK54mKQgBDB2kiCEhI7yQBEgKppIcQ0kgo 6YWQkN573WRTfv/nGXbTG5D83ZV5Pp8hIdmdd/ad7zx15s0NkCJFM+SnTZs23XCDvA9SJJBSpEgg pUggpUiRQEqRQEqRIoGUIoGUIkUCKUUCKUWKBFKKBFICKUUCKUWKBFKKBFKKFAmkFAmkFCkSSCkS SClSJJBSJJBSpEggpUiRQEqRQP6/S2NTE5qam7Vy7M00bh6/BPIPInXKBqTlFyG7qBRNWjaxvIhy isuQllcERb1SAqntolAqEZ+RCzu/0zh66hwyCkrQ0NCoFWNvaGxEVmEpnILOw8Y3DLFp2aitq5dA arOwdrHyDsGCnVb4Zp8d3MKiUV5VoxVjr6xRwCM8Ft/pHcT8Xyxh7hEkAJVAarGcu5COb36zwz8W b8GEJT/jpwNuSM8v1oqxZxN8W22PY+L3O/Dy11vw1R4bhCdckkBqsxwPj8HkZTsxbO4qDKU2Y7Mx olOztGLsCeRqzNlqiqFzVonxT/phB5yCIyWQ2ixHTp3Fi1/9hMfn6OLRmSvxH909OHMhTSvGHkUL Z+rq3/DojJUEpS6e/3Ij7PxPSyC1WY4GnxfmjrXjY7N/xDs0weeS07Vi7DGXsvH+Wj0MmfWj0JC8 sA4FREggtVmOEZD/WLy1Bcipa/ZpFZAfrNuPx1RA/v1/m3FYAimBlEBKIHsVrrk096HycrVANg9w Vacv/V8tkNy1lhaltBfIovIqFJZW9FoOvBog65WNyC0pR3l17YCMvaKmFrnF5airb+h3IPl2FJZV iqalTGoXkFzTzS+pgPeZOBwPi0FmYQmUjY39BiRXdhIz8uBE7wuKSUZZVU2/1cC5G4Y8JO6iqL7E p+f0WA68UiC5spNdVCaS6Z7UcovLtLEGrl1AVtQo4HM2HitNHLHUwB7OIZEorqjqNyAzCoph6RUs kumbbdwQkZgmauH9IfUNjeLaW+3csZj6N/U4JWrU/QVkSWU13MOioWPogOVGDgRlDC0A7ahKaS2Q 6fkl2H7QA//U2YVJP/yCNRZOpNFy+w1I1opcEXnlu+14d/U+mHsEo7yqf0x3Za0CB3xCRSpn/Hfb sHCXNQIik/oNyOSsfGy0dsHrS3fi9WU7xYJKzS2UQA6kRF7MxMzNJhjx2WoMn7ca7xJgJ6Mu9BuQ vInh1SXbRd9PfbFOaGH2J/tDCssrhWZ/ev46Mf6x32yFuWdwvwEZHJuCaev1MYLGPpz6/3ijIWl4 rSs1agaQ7KX1xd8JjU/BG8t3YcislXicABv37Va4n47pNyD1nE4QiGsFAFwhmbvdDBnkp/YmfRk7 gz1/p6WoGA2ft0pAucvBp9+AZFdmwvc/i/vCn/W1pb/QYk3qdVy8Ja9Zc8JyzQCStUdGfjFFnspe gfzXil9pkhhIXWH6jvcjkPudTwgNNoy0zBACZ97P5iJw6kkqKWpmX7C3qDyPgFywy0osJobxyc/X YNeR/gVy4g87WoBks90bkOwf85a8grIKCaRYnbQy2RnnqPmQfzgSMnJ6DCLCElLx5srd4qY/MUdX mFeOKvsLSH2XADy7YL0w2QzC5zssegSyWlGHcDKLtmTqebFUKRQ9ArnoV2sxDgaSNfFuR99+A9L3 XILQinxfuHbPfnZgdPfuDAdZSZl5OHwiAp4RsSii4FADdtX/vkByFOgQeEYEEnO2mWELRaA97cbR JCAbyNQFkP/KfuHsraYiuvU7nwBlNxuANQ1ITjv9fMgDc+m+/3f3ARw8ES6Uw3UN5CUydexXXZ6g dXh58RYc8A3VCiA5h7jZ1l28/un5a/E0AbbO0rlbLalpQHJf477dhpE0jhHz1gh/OSkr7/oGMjmr AB9u0MdfP1oqfLZh5Owbup3UCiBrCMgVpB0f+kSH+l6JBz/Wwff7D4lKjDYAaUERPvuxj8xcQfd/ Gaau3oe4tOzrG8iUnELM2moighSGYNSiDTD3DNIKIGsJyLWkERkWBoz3LLL55nyjNgDJKa4x/90k lABf4+NNhmJT8HUP5IwtxqQdVwgInl24HmYep7p9fWh8amuUPWfgouzhfYiyGcjVFk4CRAbsCep/ ufGRHoHsGGX/OiBRti59Vt1eo2xO0o/+ciOGEpD8WadvNBAH4q5rIC9mF+LTzUZ4dMYKcdOfWbAO psd7AlJz8pAM5CrzY2Icw4WWWQkdI4dugRzoPKS3Kg/Jn3NIH/KQ1t6hwiINnXt5N/00cp040Lmu geQcGJ8GHEnagrUSH2iyP3mm29efv5gpzsWIagS1qf1cqTngEybKhqJS8/la/KDffaWG01MM1Jgv N4nXj164AdsOeohUUFdyuVJzhIKfdaKSwpUaM4+gfgMyOPYiPlyvL8bC/X+00VCkpLoT3kDC542G f7YKT362RkTaKTkF1zeQvDHC0PUkpujuFSDwpoMwMsvdCdeyt9l5iBvJ8K42d+rR77lSIE/FJIuJ 4bGwk292PAhl3dSyeXeNa0gUZm4xEdHqJ5uMcCzoPOq7yaOy5rT2DsF7a/QwjlwNPpp7IjKx34C8 kJWPDVYueO2HX4R25BOWqTnd17LPJKVjCQVh7Ie/tXIPWQd/FJT+7gny3xfI2vp6hJAZ5nTJ4r12 sPYJ6fHsMVdDvCLisNzoCEW0hwVwRRWV/QYkH5Hl889f77HFJmtXcey0u0Q9l9sSMvKw96gvvtpt g18dvBGXnt3t0zE4Ec0HzHjTw/+of2P3QFzqYfPD1ez2cQ2NwlLS6ssM7Mm3jhbb57oT3pNp6xcm djatoYV9KuYCahS/+4MINKNSE0C+Du8RvJCV12OlhmvGHBx4EpRuodHC5Pe0H5JPHb7Q5tThW72c OuTcYkJ6Lo6dOodT0b3vh2TzzIA7Bp5FRFIaqmq7r9QwwPyQgqDYZPEUjbhenkTBpw7fEacOV4jA aXQvpw6VqidduIfFwIP8an5IQkNj9zX2+oYG8uHz4RwcCf/zicJaNTVd55UatZTSRPGGUr5JvYpq V3RBH3aMu4ZFkaO/Q2hIhpIjyaiUzB7fwyaXJ7Osj9vOagjKnKJSVHXjO3al5XOKynqt23OA8elP RhS96woNOf7b7XAkkHtb4AUtO8Z7h4urSrzAS3//Co1mAanWIH1/bd9ez/4oP4aE8218HFbX9Gif 9gheaU13IF6fQf4ym1IeNwdO87abIyjmYp/u45XdS4067PDHPnXIO8ANXAJEZP7FDgs4UASvAfXa Pgm7C6wRF9CCYk25j4KOS7lFf9Spuj6ArK6rw1ny8YzcTooIN5l8pvp+OpIw0MLm9CJFyTY+oSIT Ed6LjyqB1AJhc8S+HW9rSyEYlQ3aAWMLlBSopOYUCH+S00YaZl4lkFc9sQRiQ6N2PBeyozRSpFyv ZQtJAilFAilFigRSigRSk6VRoUBDTQ0aKZoW31dXo3kAfUW+jvp6Ddd4vSalUry/sbZWNP6+qf7K S3fiveox0VdlVRWatdfn1D4gxZFZmriqrCxk+/sjzcUFGcePI93NjZo7iiIjxcQ0d1VT5j+xQRNX X14ORXGxaPw9w9zcw1HWpoZGVOflIefkydbrubsj3dUVBWfPor6yCk19BLOJYFGUlCAvNEyMOcPD Q7Q0+j4vOFiMqS9A8fWqc3ORzWOicYgxieaBoqgo8ZkkkAOtEZUNKE5JxQUnZ4Ru+gmes2bB+bXX cGzcOBwbOxYu/5mCwKVLkerkBEVhYTsQ1RqVJ/C0ri48P/wQHtRCdXSQ4eWF+oqud7oo6OcZQcEI 37kLXnPntVzPiZrrW2/B/+vFiLG0QnHihR61JadsKnPzkObnh7O7d8NnwUK4vjMVzm++JRqP3W/h IsSbmqE0IZGAa+p2QXI/OcEhiDE0gt+XX8F58mQa03g4UT/HP5mBkNVrkEoLp+zSJTRqyV+d0Dog 60jrpZ8IQNCKlThKN9562HCY3HMP9tPwf1M1/RtvhPXwEQj4bglKEhI6AamsrES8mRnsR4/Gbnr9 r9QOjhiBqD17UFPQeS9gFU184mF7eM37HDbPjoLJn++DHr1nr+p6fG2j++6Hw6sTkHTYAQ3d1Kcb yDznx8Ti7N59cJs+HbbPPgfT+wfD4OabRX/c9tPYzR98CO7TP0KKiyu5BJ1r44xo0YVkRO7Xhw8t jiMEocVDj0Cf3r9PNR6Te/4Mm5FPwW3KFISuW4+MgJPic0sg+0mYJQXd0BRvb3jOmwfze++FAU2e EQ3bQNUMVV95Ygxvuw2un3yK/PPnO/XFE5NobY1j48eLyWMQHMaMQYy+PmqK2pfl6qqqkezsAud3 3oXJ3XeLa3Dj6xoPGgRjgsn4llugd9NNMKeFEfXbPiiVyi60uhI5ZNYD16yD7egxMKT3GbYZs/r7 /ar/HyTIYqwPQNnhQVGsfQtj4xC6eQsOvfQyjG+7XYyl7WfXb9OnMd0ji4cehve8z5BOLkF9hVZA qflA1pGzn+LtA4+ZM0mr3C8mTr8NjKYEixVpS8vHHhcTxL9znjYNeefOddaQ5PAn2djAacKElkl0 fOklxBoaorYDkKyJgtaug+XfHhTg6qtgtBk2DMf+/SacyNxys3l+jNB4cabmncws+3m55NMG/Pgj rEeMhD6B3HbsxrffDotHH4P10OEwvvNO8Tvbv7+EaAtLGmtrzZ1HX5aWhpCVP8LqiSdgSAuhbT8t C3PQzZ0ANX/gAXiTNs0MPCVcHgnkNUrJxRSc0FkBs8EPCBgNVTeatZM9aQrf/36F0J+2CHi82Kec 8jYCdVehSG2y2zxStq9AcuCR6ucPtxm0CEgTCRjpejYjRyJo1SqkenmTL+iPSz5+iLWwwvl9+5EX foYCo/alPQUFTGf26cH6uVHtFpLRLbfC9pln4TFnLoLIrPL4fRd9Cdd334M3fU1mk93mOK2Cxp14 1AkOBOtvbfshLXjgiaFweeMN+M2aDW/6/EdemQBzWrhqzcuLyfLhRxBOmrUiPUMCeS3CqZFU9+M4 MvE1GJBpVJtMI9ImjuS3RRqbIC86BhXZ2SglBz737DmkeHoi3f8EqvMLrhrIhrp6MteucCZA1ECy NrOfNAmxVtaoKSkVpliMkSCsJ22mrK1tF6kLE0t+o9dnn8PojjtbTf6tt+EgLaSQrduQERKKMoKk PDML+fQ50vz9keLhiaK4eDS28UcL4+Lg/+0SAZbaJDPUB0kzn9JdjUtkkktjY5F/+jSizS3gSn6o Ofm2hgQsj9301ltx/P33ke7pJYG8FqnIyUbE9p9hRc6+WjuaEJiOr7+OKIpGqygQUR8ZEOkggoDB YECaujBPfdaQ1GeGrx+8Pv0U5ipTakTXtSDz5zV7LmJt7JAVFobKnJxujyzUlpUh0f4Ijk6c2M7X tR01SsBYlJzcLgjifpSckqIxNjDcqkXE/3LEfHjUaOy/+ZbL/uENN8LmmecQsmEjWYJE8Zl50TU1 KFFdWIT4g4fg/Pbbwp1RX9fmqacRbWDYY3pLAtmLcGR64tvvYH7X3QJIbqZkOoPJl6rIu/ITcj0B 2TGoKSVggnWWw4Sut7dN8GH5wF9gP3Yc3D/4QKSYEg4dRllm513orLUjdu8hLfZsa8B14w3wJDcg 93xkn8dcT9o61sQU1oMHC3NtIBblIFoYc5AV3vUZG9a4ETt3wvbJJ1vMu8l9g4XZbtbsTSaaDWQ2 mWAf8hHN775H3Fj2h8zIdMbpG1xVf1cCZD1pnWRHRxybMBEm5L8atgkUWib5rrvg8NrrCN+2HcXx CcL3VEtZejpC6ecHRoxoeY8RARmioyMS6X2V2vIKRO3Xx4EHLwdX6kUZtnoNqgq73rCrVNQh2c0N jq+80hqQ3XkXTq9fL4EcCCDjjY0HHEg2lTWFhUhxdYXfd0vIRD4jzHbHyNaAfELbxx/HGXItyrOy OwOp0lLqKD10xYouc4w9Aqm3v2sgCwq7B5LG7Th+fCuQf/qTBPJaJZ+c+YAl37c32eSgR2zahNrS kivu70qAbHlPfT25DjGItbREII3F48NpOESQGauA1FN9dX3vfVyiyLtZVRmpIP/yzN7fcPC551pN NjW/z78QmYO+Sl2tQlRkrEhLqyNsk0GD4P/FfBRGRXX5norcPETs2QO7kU+1LAbje+/FabpvEshr kPKsLIRTAGD10MMtiWNOSru9/wGZJHfUdfFXBjj3xxFwi/PeZpf11QDZVjiIygkNQ/iGDbAdNlxU WgxV6ZfD5FfGmFuKTReXNVu58C8dOaih36s1qsPYsSI7UJnX+dF3fPiLxy5Mv7rcSZ8n2fEoDnHq iK6nTvc4vPgionbvbs0mqIRdjYvuHhRpT4fZvX9uua4FafGze/ZKIK9F6gm4RHsHHJk4SVQ4DFRm j9Mf3gsWihQJBw+KsnIBVHlaOvIjo1AQHYM6inIvz3JTn9I+7YDkiJV34/BOnA47cBiY7KBguHzw IYxVUSyP6eALLyKSNFl99eWENteQswhezjUak6+pTlmZEiROU99F7AEblKSkorakFApqFWTuC+MS kHvuPAUlme38Uf5MnG+1+NvfWqs7t92KY6++igRbO5RnZKCOTDu/jytavl8vhtUjjwhwxSKme+f4 zzeQRGBr+DEIzQaSE82cywv45htYUpSpNnt8oy0ffhgu//43gsmXOkcgnKHVH7RmLU3GNwjbsg0l SUmtGvIK85CsXRn0jJOBSDrqhBRPb2SdOYOcyEgBRxxFvfb0Pi5TqgFhIKOMTaGsbq2wVOXn48yO HbB96qmWKJ2b2X33w3HyP3FyxUqcJf/wrJ6+2CziTy5BAP2MF5pI5ahEQYsryc4OR154ocVFEPnF O+7A0VcnULS/jKLq3QhetwFu06bD+rHHxD1SlyTN//pXBFK/BfEJmgyj5gMptGRFBVIo2nX9zxQY UUCzv0NQYfHgQ6LcZjNqNCyGDIEJOf/ONCm5ERHtNN6VAClKfgRgyPqNcJ76HpzJb/ReuEg0X/Ld nCh6NSWt0+Kfcf2cNGbKcc92GlX0ExIC/0WLRAlPr40vyUlrMx47lx7HvADLJ4bClDSg3bjxIsfK +cg2HwDlyckI+v57mD7wQKfyKZtm6+FPwnLI4zCmIEu/DbQm99wLt+kf4ZKnF+prNP4PKWnHbp/q vHzSPiYiIW56Z2vVQ7+rzRUErevHnyDvXPebK46OG9e6ueL558Xmio6J8azAQPjyZg6O8G8aJPKR 6mbcRtsZ33IrDr34d5zdvUfk/zr+5UveJMG7d47PmAmzRx6lvm5qGW+nzRX0O7ux4xFjZd1pcwWb 8PRTQcJVseSdQjQmwy7q2QZtyopcbnWlxcRuT01xiaZPs/YAyVJBkx1vYwsvilJtnn9BlOP0VNuu 9rXZgmZ02+3wnL+A/LH4zkCSto03N4f9mDHYQ6/lLWgHKWKO2rtXpHhaFWozMkmzecyeLSZ3l2rL WdumpzKFTlPewentO8i1iBMbebuS2tJSpJKGCli+EodemQDTwX9pN3ZuPB49gszhX28i0fGYKF92 lDoy41nkvwYtXwH71ydTP4MFyOo+1Gkhzo8eevll+H71NS4cc0ZtcbE2TLF2ASkmlnypzJBQnDc0 xgly3F0nT4YzmV+XSZPgTNEsm2KfWbMFuFWkVTsKb/fPOXUKERQl+8yYAW9qp1etQqavL+o77Bks TU8XWtlj6lQRPPA11I2v40raOkhHBxecXVBM5rRR2fOzepS1CuSRPxx7wBZBuqvgTibeiYI1Fxo3 t6PUp/u0j0QkXECv664kydAXJSYh/rA9Apctg9sbb7TcA9EXjctv/nxEk9nPDo+Aolxj/gbNHw9I ob1oohpJe1RR0JETEIBMDw9kEVCZFF1meHqiOCrqci24myMMInrmsycEIDf+nn/W0dTy+9mM5wUF iSMGfA114+vw8YlKim7ZlPY1cG1WpXUUpDHzw8NFP1k+PqLxNfLDwsTvejsOIer21E91To44VtH2 HmR6efV8DySQAycMAx9L4EBCHPSqq+v3azS3vYa60XWaetGIvQ++qX2/fK7nKnKEne4B50G19wkX 8hisFAmkFCkSSCkSSClSJJBSJJBSpEggpUggpUiRQEqRQEqRIoGUIkUCKUUCKUWKBFKKBFKKFAmk FAmkFCkSSCkSSClSJJBSJJBSpPyOsl0CKUUjgdwmm2wa0N4UQPI/ssmmKe3/AK1EJLq9bcSBAAAA AElFTkSuQmCC ------=_NextPart_000_0210_01CAD1C3.4E80C410 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_000_0210_01CAD1C3.4E80C410-- From jhui@archrock.com Thu Apr 1 19:09:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227E63A6960 for ; Thu, 1 Apr 2010 19:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVJtYPrlkdkb for ; Thu, 1 Apr 2010 19:09:28 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C6E1D3A6A1E for ; Thu, 1 Apr 2010 19:09:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 966D8AF90F; Thu, 1 Apr 2010 19:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kv9FWeBQzx0; Thu, 1 Apr 2010 19:09:50 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-87-253.dsl.pltn13.pacbell.net [71.142.87.253]) by mail.sf.archrock.com (Postfix) with ESMTP id DD8C9AF835; Thu, 1 Apr 2010 19:09:49 -0700 (PDT) Message-Id: <43648C3B-C500-4A40-9878-3C0ABA14DE64@archrock.com> From: Jonathan Hui To: Michael Richardson In-Reply-To: <1743.1270148971@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Apr 2010 19:09:49 -0700 References: <8073.1270127943@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01923C94@XMB-AMS-107.cisco.com> <1743.1270148971@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) Cc: roll Subject: Re: [Roll] acknowledgements from parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 02:09:29 -0000 On Apr 1, 2010, at 12:09 PM, Michael Richardson wrote: > The alternative seems to Unicast ACK of every single message, right? > Isn't that at least as costly to the intermediate node as a link-local > multicast? This really depends on the properties of the link layer. A link-local multicast really maps to a broadcast operation for most low-power radio networks. For links that idle-listen all the time, broadcast is no more expensive than a unicast but does lack a synchronous acknowledgement as Pete pointed out. For duty-cycled networks that attempt to eliminate idle listening, supporting broadcast either requires (i) all nodes to be on at the same time and scheduling a broadcast slot or (ii) sending a long preamble to wakeup all neighboring nodes for a data packet. For these duty-cycled networks, both options are *very* costly and should be used as sparingly as possible. Hence the use of Trickle within RPL. -- Jonathan Hui From pthubert@cisco.com Fri Apr 2 02:29:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B3D3A6966 for ; Fri, 2 Apr 2010 02:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-2.841, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnuwNCAei9w4 for ; Fri, 2 Apr 2010 02:29:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E960A3A67EF for ; Fri, 2 Apr 2010 02:29:06 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,352,1267401600"; d="scan'208";a="5111137" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 02 Apr 2010 08:54:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o329Tdxp024545; Fri, 2 Apr 2010 09:29:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 11:29:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Apr 2010 11:29:36 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com> In-Reply-To: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #29: DIS packet format Thread-Index: AcrO8nj8sQuokPlcTg66NYyJ3jHUYwDVCz1w References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 02 Apr 2010 09:29:39.0506 (UTC) FILETIME=[0497F920:01CAD247] Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 09:29:08 -0000 SGk6DQoNCkZyb20gdGhlYWRzIGFuZCBkaXNjdXNzaW9ucywgSSdkIHRoaW5rIHRoYXQgdGhlIGNv bmNsdXNpb24gY291bGQgYmUgdG8gbWFrZSBzdXJlIHdlIGRvIG5vdCBkaXNhbGxvdyBvcHRpb25z IGluIHRoZSBmdXR1cmUsIGJ1dCBmb3IgdGhlIHNob3J0IHRlcm0gdG8gb25seSBzcGVjaWZ5IHdo YXQgd2UgcmVhbGx5IG5lZWQuDQpXaGF0IHdlIHJlYWxseSBuZWVkIHRvIHByb2JhYmx5IHRoZSBE T0RBRyBJRCAoVU5TUEVDSUZJRUQgaWYgbm9uZSkgYW5kIHRoZSBpbnN0YW5jZSBJRCAoMCBieSBk ZWZhdWx0KS4gSSB0aGluayB0aG9zZSAyIHNob3VsZCBiZSBpbiB0aGUgY29tbW9uIGhlYWRlciBh bmQgbm90IGluIGFuIG9wdGlvbi4NCg0KQWR2aWNlPw0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJvbGwNCj4gaXNzdWUgdHJhY2tl cg0KPiBTZW50OiBNb25kYXksIE1hcmNoIDI5LCAyMDEwIDU6NDcgQU0NCj4gVG86IHdpbnRlcnRA YWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBb Um9sbF0gW3JvbGxdICMyOTogRElTIHBhY2tldCBmb3JtYXQNCj4gDQo+ICMyOTogRElTIHBhY2tl dCBmb3JtYXQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0NCj4gIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAgICAgIHwgICAgICAg T3duZXI6ICB3aW50ZXJ0QOKApg0KPiAgICAgIFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgIHwg ICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICB8ICAg TWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBycGwgICAgICAgICAgICAgICAgIHwgICAgIFZlcnNp b246DQo+ICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgICBLZXl3b3JkczoNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0N Cj4gIENvbnNlbnN1cyBvbiB0aGUgUk9MTCBNTCB0byBjaGFuZ2UgdGhlIERJUyBwYWNrZXQgZm9y bWF0IGFuZCBtYWtlIHRoZQ0KPiBib2R5ICBjYXBhYmxlIG9mIGNhcnJ5aW5nIFRMVnMsIHdpdGgg bm8gVExWIGRlZmluZWQgaW4gdGhlIGNvcmUgc3BlY2lmaWNhdGlvbi4NCj4gDQo+IC0tDQo+IFRp Y2tldCBVUkw6IDxodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tl dC8yOT4NCj4gcm9sbCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3JvbGwvPg0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWls aW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwNCg== From pal@cs.stanford.edu Fri Apr 2 10:00:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED0A3A69BD for ; Fri, 2 Apr 2010 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKab47NrH2pp for ; Fri, 2 Apr 2010 10:00:36 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0FFE53A6829 for ; Fri, 2 Apr 2010 10:00:36 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxkF3-0000JI-0A for roll@ietf.org; Fri, 02 Apr 2010 10:01:10 -0700 From: Philip Levis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 18:39:50 -0700 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Subject: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 17:00:41 -0000 Can someone remind me why DODAGID is in the DIO? IIRC, someone told me = that DODAGID is necessary due to application requirements that a node = can avoid choosing a new preferred parent that goes to a different DODAG = root. Can someone point me at this requirement? DODAGIDs add a lot of = complexity and greatly increase message sizes. If they're needed, all's good, but I can't seem to find the application = requirement (in a requirements doc) that calls for this. I figure = anything we can do to simplify things is desirable. In the case of = DODAGIDs, the presence of RPL instances and the destination prefix = suggests to me connectivity is already handled. Phil= From pal@cs.stanford.edu Fri Apr 2 10:01:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3D93A69F3 for ; Fri, 2 Apr 2010 10:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDVO3IwUreS0 for ; Fri, 2 Apr 2010 10:01:09 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id E9B7B3A69D9 for ; Fri, 2 Apr 2010 10:01:06 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxkFY-0007lb-RH for roll@ietf.org; Fri, 02 Apr 2010 10:01:41 -0700 From: Philip Levis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 10:01:22 -0700 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Subject: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 17:01:10 -0000 (Trying to restart the thread) In -07, nodes always respond to DIS messages by resetting their Trickle = timers. A few people on the list have pointed out that this is = problematic. If an environment has multiple RPL instances, for example, = when a node solicits information it must do so from *all* instances, = even if it knows the one it wants to join. The basic issue is that a node may wish to solicit DIOs from only a = subset of nodes; it's wasteful to force a lot of nodes to reset their = trickle timers unnecessarily. I propose that we add a new suboption to RPL, which is only valid for = DIS messages. The Solicited Information Filter suboption specifies a set = of predicates; if a node satisfies the predicates, it MUST reset its = timer in response to the message. If it does not satisfy the predicates, = it MUST NOT reset its timer in response to the message. The trick is to make this a simple, fixed-length suboption; forcing = nodes to parse all kinds of suboptions is problematic in terms of code = size. Similarly, we'd like the suboption to cover the compelling cases = but not be so complete that it wastes space on useless fields. So the = question is: what information do nodes want to filter on? The one that immediately comes to mind is a DODAG Iteration: this would = imply the RPLInstanceID, Sequence, and DODAGID.=20 There have been a few mentions of Rank. I personally think it makes more = sense to handle this through trickle suppression (you generally want = low-Rank messages more than high-Rank ones), but this seems like a good = point of discussion. So my current proposal is that the Solicited Information Suboption has = the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Reserved | Sequence | RPLInstanceID = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | DODAGID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Furthermore, we should reserve values for Sequence, RPLInstanceID, and = DODAGID as wildcards ("any value matches"). This would indicate that = such values can't be used normally. Alternatively, the reserved region = could have bits stating which of the three fields to match on. Thoughts? Phil= From jhui@archrock.com Fri Apr 2 10:06:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691B93A67B4 for ; Fri, 2 Apr 2010 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMBorygvDxcv for ; Fri, 2 Apr 2010 10:06:09 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 99E673A6898 for ; Fri, 2 Apr 2010 10:06:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A9FD7AF90F; Fri, 2 Apr 2010 10:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OGRYu5HikPw; Fri, 2 Apr 2010 10:06:39 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id ADB0EAF83E; Fri, 2 Apr 2010 10:06:39 -0700 (PDT) Message-Id: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Apr 2010 10:06:38 -0700 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 17:06:10 -0000 The DODAGID scopes the DODAG sequence. Without the DODAGID, you'd have to coordinate sequence numbers between all roots within the same instance. -- Jonathan Hui On Apr 1, 2010, at 6:39 PM, Philip Levis wrote: > Can someone remind me why DODAGID is in the DIO? IIRC, someone told > me that DODAGID is necessary due to application requirements that a > node can avoid choosing a new preferred parent that goes to a > different DODAG root. Can someone point me at this requirement? > DODAGIDs add a lot of complexity and greatly increase message sizes. > > If they're needed, all's good, but I can't seem to find the > application requirement (in a requirements doc) that calls for this. > I figure anything we can do to simplify things is desirable. In the > case of DODAGIDs, the presence of RPL instances and the destination > prefix suggests to me connectivity is already handled. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Fri Apr 2 10:08:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C4B3A6A39 for ; Fri, 2 Apr 2010 10:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvgw1oiePwTU for ; Fri, 2 Apr 2010 10:08:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D2F1F3A6A3F for ; Fri, 2 Apr 2010 10:08:03 -0700 (PDT) Received: by gwaa18 with SMTP id a18so82822gwa.31 for ; Fri, 02 Apr 2010 10:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=JC4tZM7Lx+RmTZw/VlzFLH/oMeLSZWVxQfeWoIWEjNc=; b=ZuZtTECMbl3L2ybwrQelH3Tn9HJ/uH5007RrU3EtJtGCcSdwJdOFSeymdxIG4jfKK7 DeCWCgGMn69zYSsz8z6wHe0iah2cxWFtaHzr5R2WKDu3w3MFPzZXt9iRClGDG7+5mjaB 9Yn9EChgVsDJfTr2mg998YY+UuvQA/yhFyBBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=lquLIukil2FaWUJE7eXmO/0bq5ZVf6VDL6UyAfsgwm8rKDSaloi7sSOhmQJiBEVV3S xudEx/n6OPJH1Gedcsx0TITWJu17jrEW302FEUU9DbISEjMtL6Qv2ca3BVvPyXKRdSta a59+KKrA/cMvOsTNk73viuKFzZjKgw3Tcb2Zo= Received: by 10.101.131.17 with SMTP id i17mr2161848ann.36.1270228102594; Fri, 02 Apr 2010 10:08:22 -0700 (PDT) Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 14sm6120417gxk.15.2010.04.02.10.08.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 10:08:21 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: Date: Fri, 2 Apr 2010 10:08:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8696DBDB-4ADE-46BE-A87C-690C2E288F1D@cs.jhu.edu> References: To: Philip Levis X-Mailer: Apple Mail (2.1078) Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 17:08:07 -0000 Correct me if I am wrong but I read that the prefix container was for = 'additional' prefixes and therefore, I assumed that the default prefix = that the DODAG root was supporting was in the DODOAGID. The specs said = that the DODAGID was derived from the IP address of the DODAG root so I = was assuming this would be okay. One less message container to carry by = default. - John On Apr 1, 2010, at 6:39 PM, Philip Levis wrote: > Can someone remind me why DODAGID is in the DIO? IIRC, someone told me = that DODAGID is necessary due to application requirements that a node = can avoid choosing a new preferred parent that goes to a different DODAG = root. Can someone point me at this requirement? DODAGIDs add a lot of = complexity and greatly increase message sizes. >=20 > If they're needed, all's good, but I can't seem to find the = application requirement (in a requirements doc) that calls for this. I = figure anything we can do to simplify things is desirable. In the case = of DODAGIDs, the presence of RPL instances and the destination prefix = suggests to me connectivity is already handled. >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jhui@archrock.com Fri Apr 2 10:44:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072083A69C6 for ; Fri, 2 Apr 2010 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEJug-LRo7Z1 for ; Fri, 2 Apr 2010 10:44:21 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DEA693A69D5 for ; Fri, 2 Apr 2010 10:34:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EB7A5AF92E; Fri, 2 Apr 2010 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CenF6if0whW5; Fri, 2 Apr 2010 10:35:29 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 99E95AF834; Fri, 2 Apr 2010 10:35:29 -0700 (PDT) Message-Id: <66E3A1FC-1B33-4FD9-93F7-A97E3F4BFEA9@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Apr 2010 10:35:28 -0700 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 17:44:22 -0000 The assumption (which you stated) is that there are a number of instances and overlapping DODAGs. If you have neither, then I'm not sure there is much value in scoping to a particular DODAG Iteration (instance, sequence, id). For the highly constrained networks that I'm familiar with, the number of instances is small and the number of overlapping DODAG IDs is also small. In many cases, both are 1. In some cases, maybe 2. Instead, the concern is usually with node density. If large numbers of instances and overlapping DODAGs is a concern to some then I can see this useful. Of course, an additional assumption here is that a node would prefer to stay within the same DODAG. To complete the picture, we'd also need to think through how exactly to use the filter. One obvious use case is for a node to start with a small scope, then expand the scope by setting wildcards when discovery fails. The question is how best to indicate what is the intended behavior - does this need to be network-wide (e.g. through some config option in the DIO), something that is part of the OCP, or something completely node/implementation independent? Minor comments: Type 5 is taken by the OCP option. I'd prefer to use flags to indicate what parameters are in use. -- Jonathan Hui On Apr 2, 2010, at 10:01 AM, Philip Levis wrote: > (Trying to restart the thread) > > In -07, nodes always respond to DIS messages by resetting their > Trickle timers. A few people on the list have pointed out that this > is problematic. If an environment has multiple RPL instances, for > example, when a node solicits information it must do so from *all* > instances, even if it knows the one it wants to join. > > The basic issue is that a node may wish to solicit DIOs from only a > subset of nodes; it's wasteful to force a lot of nodes to reset > their trickle timers unnecessarily. > > I propose that we add a new suboption to RPL, which is only valid > for DIS messages. The Solicited Information Filter suboption > specifies a set of predicates; if a node satisfies the predicates, > it MUST reset its timer in response to the message. If it does not > satisfy the predicates, it MUST NOT reset its timer in response to > the message. > > The trick is to make this a simple, fixed-length suboption; forcing > nodes to parse all kinds of suboptions is problematic in terms of > code size. Similarly, we'd like the suboption to cover the > compelling cases but not be so complete that it wastes space on > useless fields. So the question is: what information do nodes want > to filter on? > > The one that immediately comes to mind is a DODAG Iteration: this > would imply the RPLInstanceID, Sequence, and DODAGID. > > There have been a few mentions of Rank. I personally think it makes > more sense to handle this through trickle suppression (you generally > want low-Rank messages more than high-Rank ones), but this seems > like a good point of discussion. > > So my current proposal is that the Solicited Information Suboption > has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 5 | Reserved | Sequence | RPLInstanceID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | DODAGID | > + + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Furthermore, we should reserve values for Sequence, RPLInstanceID, > and DODAGID as wildcards ("any value matches"). This would indicate > that such values can't be used normally. Alternatively, the reserved > region could have bits stating which of the three fields to match on. > > Thoughts? > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri Apr 2 12:03:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B6B3A6CC7 for ; Fri, 2 Apr 2010 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR82hiISVYhp for ; Fri, 2 Apr 2010 12:03:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3DB0B3A6C59 for ; Fri, 2 Apr 2010 11:35:12 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAHjVtUurR7H+/2dsb2JhbAAsmx1xm2WYYoUFBA X-IronPort-AV: E=Sophos;i="4.51,354,1267401600"; d="scan'208";a="507781333" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2010 18:35:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o32IZj0x001411; Fri, 2 Apr 2010 18:35:46 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 20:35:45 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 20:35:44 +0200 Message-Id: <988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> From: JP Vasseur To: roll WG , "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Apr 2010 16:39:03 +0200 References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Apr 2010 18:35:44.0666 (UTC) FILETIME=[4E269FA0:01CAD293] Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 19:03:04 -0000 I think that the consensus was also to slightly change the DIS packet =20= format to allow for future options to be carried in the form of TLV =20 (as we do in many other protocols) , which is not possible with the =20 current packet format. WG ? JP. On Apr 2, 2010, at 11:29 AM, Pascal Thubert (pthubert) wrote: > Hi: > > =46rom theads and discussions, I'd think that the conclusion could be =20= > to make sure we do not disallow options in the future, but for the =20 > short term to only specify what we really need. > What we really need to probably the DODAG ID (UNSPECIFIED if none) =20 > and the instance ID (0 by default). I think those 2 should be in the =20= > common header and not in an option. > > Advice? > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Monday, March 29, 2010 5:47 AM >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #29: DIS packet format >> >> #29: DIS packet format >> --------------------------------=20 >> +--------------------------------------- >> --------------------------------+---- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: task | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +--------------------------------------- >> --------------------------------+---- >> Consensus on the ROLL ML to change the DIS packet format and make the >> body capable of carrying TLVs, with no TLV defined in the core =20 >> specification. >> >> -- >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Apr 2 12:55:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F078E3A6D38 for ; Fri, 2 Apr 2010 12:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.107 X-Spam-Level: X-Spam-Status: No, score=-5.107 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmRAF0yJ2sSz for ; Fri, 2 Apr 2010 12:54:59 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 018A33A6D87 for ; Fri, 2 Apr 2010 12:19:10 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxmPA-0007aX-0s; Fri, 02 Apr 2010 12:19:44 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <66E3A1FC-1B33-4FD9-93F7-A97E3F4BFEA9@archrock.com> Date: Fri, 2 Apr 2010 12:19:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <66E3A1FC-1B33-4FD9-93F7-A97E3F4BFEA9@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 6890477ab20817755420d5b1edd0addc Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2010 19:55:01 -0000 On Apr 2, 2010, at 10:35 AM, Jonathan Hui wrote: >=20 > The assumption (which you stated) is that there are a number of = instances and overlapping DODAGs. If you have neither, then I'm not = sure there is much value in scoping to a particular DODAG Iteration = (instance, sequence, id). For the highly constrained networks that I'm = familiar with, the number of instances is small and the number of = overlapping DODAG IDs is also small. In many cases, both are 1. In = some cases, maybe 2. Instead, the concern is usually with node density. Agreed -- trickle suppression should handle the node density (until = link-layer collapse). I think the intention is that this suboption is = not necessarily used that often, but that there will be situations where = it's helpful. >=20 > If large numbers of instances and overlapping DODAGs is a concern to = some then I can see this useful. Of course, an additional assumption = here is that a node would prefer to stay within the same DODAG. To = complete the picture, we'd also need to think through how exactly to use = the filter. One obvious use case is for a node to start with a small = scope, then expand the scope by setting wildcards when discovery fails. =20= Makes sense. But let's also think about when a node might want to do = this. When a node comes up, it can't really use the filters, as it = doesn't know what values are in use (unless there's prior configuration, = but that's going to be difficult given the nature of the fields). Things = like pre-initialized keys (as is common for secure LLNs) can also scope = the query/response. The information filter is useful when a node that has been operating in = RPL network needs additional DIOs from neighbors. E.g., its current = parent set may all have issued NUDs so it wants to trigger discovery. = I'd argue that exactly the order a node goes through in relaxing = predicates isn't too important, and standardization probably isn't = necessary. Some nodes might just default to all wildcards: others might = try Sequence, DODAGID, then RPLInstance.=20 > The question is how best to indicate what is the intended behavior - = does this need to be network-wide (e.g. through some config option in = the DIO), something that is part of the OCP, or something completely = node/implementation independent? I think implementation dependent is fine. >=20 > Minor comments: Type 5 is taken by the OCP option. I'd prefer to use = flags to indicate what parameters are in use. Grazie. Phil= From pal@cs.stanford.edu Fri Apr 2 17:30:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8B53A6A1D for ; Fri, 2 Apr 2010 17:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.13 X-Spam-Level: X-Spam-Status: No, score=-5.13 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOhjTBZSAQcU for ; Fri, 2 Apr 2010 17:30:49 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id E1FA63A693B for ; Fri, 2 Apr 2010 17:30:49 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NxrGm-0007yN-It; Fri, 02 Apr 2010 17:31:24 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> Date: Fri, 2 Apr 2010 17:31:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2010 00:30:51 -0000 On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote: >=20 > The DODAGID scopes the DODAG sequence. Without the DODAGID, you'd = have to coordinate sequence numbers between all roots within the same = instance. Makes sense, but 16 bytes seems like a lot of state for such as simple = problem... Phil= From jpv@cisco.com Sat Apr 3 09:24:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC803A682F for ; Sat, 3 Apr 2010 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.87 X-Spam-Level: X-Spam-Status: No, score=-6.87 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBovpBJJ0-56 for ; Sat, 3 Apr 2010 09:24:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 71ECA3A677C for ; Sat, 3 Apr 2010 09:24:45 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALoIt0urR7H+/2dsb2JhbACbSnGeC5gDhQcE X-IronPort-AV: E=Sophos;i="4.51,357,1267401600"; d="scan'208";a="508356225" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2010 16:24:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o33GOi3X006604 for ; Sat, 3 Apr 2010 16:24:44 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Apr 2010 18:24:43 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Apr 2010 18:24:43 +0200 Message-Id: <2475FA71-FC89-4477-9AEC-466F01199CCB@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 3 Apr 2010 18:24:42 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Apr 2010 16:24:43.0403 (UTC) FILETIME=[2AE2D5B0:01CAD34A] Subject: [Roll] Draft Minutes IETF-77 ROLL Working Group X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2010 16:24:46 -0000 Dear all, The draft minutes of the IETF-77 WG meeting have been posted: http://www.ietf.org/proceedings/10mar/minutes/roll.txt Let us know by April 10, ET noon if you have any comments. Many thanks to Bob power for his help taking the minutes. JP. From wintert@acm.org Sat Apr 3 10:09:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8213A68C5 for ; Sat, 3 Apr 2010 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.869 X-Spam-Level: X-Spam-Status: No, score=-98.869 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVCT3dKCgIBU for ; Sat, 3 Apr 2010 10:09:18 -0700 (PDT) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 0CD703A659A for ; Sat, 3 Apr 2010 10:09:14 -0700 (PDT) Received: (qmail 94074 invoked from network); 3 Apr 2010 17:09:11 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 03 Apr 2010 10:09:11 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: ocsqBlAVM1mmdOsZ7vYWj.JLQAiZcpXtGA4PjdC.kdhE2IE29QZ1bnp7BZgY1pDiex4jQCofFa2TirWSusT4w514v08hMDlyGNtEhc_AVFYKN_F0DcriyLf6NqBHLyV1zE6ng4hihqlEsOQzUmYphOc4poavmQyIjKW1yxXn8ND_3_bSqCZX4RhVyT0HIlAtWNjPOSMohEEkaWMW3SIi6vVoPJpj2vFFhxtlIyHd3OEWnmhhEvT5SEeQiO7yneBuCTXXet26zBJxtWOujNNCsOTvyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB77631.20503@acm.org> Date: Sat, 03 Apr 2010 13:09:05 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: roll@ietf.org References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> In-Reply-To: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2010 17:09:19 -0000 WG, >From Anaheim and the list it seems that there is support to proceed on RPL with storing and non-storing modes of operation, and not to elaborate mixed mode operation at this time (while allowing room for future specification of mixed mode). The summary approach would be to signal the mode of operation through the DIO, that all nodes MUST be capable to support a non-storing mode of operation, and that nodes who are incapable of acting as routers in a storing mode may participate in the DODAG as hosts (leaves). (The suitable behavior when a routing table in a storing node becomes saturated is still under consideration). Would you please confirm this approach to the list? Then we may proceed to refine RPL accordingly for the next revision, -08, and to take this into account when working the other tickets. Thanks, -Tim roll issue tracker wrote: > #26: Establishing downward routes in RPL : storing / non-storing / mixed modes > of operation > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: wintert@… > Type: task | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------+------------------------------------------- > In the RPL-07 proposal the DAO mechanism described in Section 6 attempts > to support > operation with a mix of storing nodes and non-storing nodes- where storing > nodes may > be provisioned with enough memory that they are capable to provision hop- > by-hop > downward routes learned from DAO messages, and non-storing nodes would > rely on source > routing for downward routes. The present proposal describes operation in > a mixed > mode operation, with both storing and non-storing nodes, where each node > may > provision downward routing state as according to its capabilities and > largely > independent of its position in the LLN topology. > > It has been noted that operation in the case where all nodes (except > possibly the > root) are non-storing nodes allows for certain optimizations, and that the > case where > all nodes (except possibly leaves) are storing leads to other > optimizations. It has > also been noted that in the mixed cases the ability to provide an optimal > solution > may break down. In particular there are concerns about the complexity and > correctness of mixed-mode operation as proposed by RPL-07. > > With this in mind, should RPL allow for operation in a mixture of storing > /non-storing > nodes? Or should each RPL Instance be exclusively operating in either > storing or > non-storing mode (with the provision that operation as a leaf is always an > option)? > (The non-mixed case may imply some control flag or equivalent given in the > DIO to > signal the mode of operation). > > Tim Winter. > From pal@cs.stanford.edu Sat Apr 3 11:11:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDEC23A6963 for ; Sat, 3 Apr 2010 11:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_60=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNB8LcxhEGlU for ; Sat, 3 Apr 2010 11:11:55 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id DBB4C3A67F6 for ; Sat, 3 Apr 2010 11:11:54 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ny7p4-00070P-7M; Sat, 03 Apr 2010 11:11:54 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BB77631.20503@acm.org> Date: Sat, 3 Apr 2010 11:11:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38324B91-8952-4A00-BC4D-BD00637C8130@cs.stanford.edu> References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> To: Tim Winter X-Mailer: Apple Mail (2.1077) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2010 18:11:59 -0000 On Apr 3, 2010, at 10:09 AM, Tim Winter wrote: > WG, >=20 > =46rom Anaheim and the list it seems that there is support to proceed = on RPL with > storing and non-storing modes of operation, and not to elaborate mixed = mode operation > at this time (while allowing room for future specification of mixed = mode). >=20 > The summary approach would be to signal the mode of operation through = the DIO, that > all nodes MUST be capable to support a non-storing mode of operation, = and that nodes > who are incapable of acting as routers in a storing mode may = participate in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a = storing node > becomes saturated is still under consideration). >=20 > Would you please confirm this approach to the list? Then we may = proceed to refine > RPL accordingly for the next revision, -08, and to take this into = account when > working the other tickets. +1 Phil= From d.sturek@att.net Sat Apr 3 16:23:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F50D3A6819 for ; Sat, 3 Apr 2010 16:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k56YRRcxO8Ls for ; Sat, 3 Apr 2010 16:23:37 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id AEA053A67FC for ; Sat, 3 Apr 2010 16:23:37 -0700 (PDT) Received: (qmail 18680 invoked from network); 3 Apr 2010 23:23:35 -0000 Received: from adsl-69-232-85-138.dsl.sndg02.pacbell.net (d.sturek@69.232.85.138 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 03 Apr 2010 16:23:35 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ODyx2RUVM1nngYp9nF3a7VDPD8TxJnSWUurSU2F_qMTd3Rh9J77cjqmt3xdrycAgC7uU_LYoiHuH3ObZytwOZcifwP_eI19SdMLpIAbuxtLXXm78z3GVjNMwfb6__sYieRLhDdSG8lWmKnz.7VqKFwhcA66YckDn_UKP2m3eJFT2A2XnyRsy44tmExd0_uv9goCHkzi_QQn6YJhC8FzAEKtZETdu8J2YqvabQLWHo0H_3C2GDkdm2Y6yG6VFdyRskU.s8GnayW50XZpU.KDWxY7W3ygmaGS9AdTMXcMgKX8TSJItRDoLnQO.uDTwbg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Tim Winter'" , References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> In-Reply-To: <4BB77631.20503@acm.org> Date: Sat, 3 Apr 2010 16:23:31 -0700 Message-ID: <003901cad384$acdf9c80$069ed580$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrTUGgMPWsgzuamSgaP42YxqBE7wwANDwBw Content-Language: en-us Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 23:23:40 -0000 +1 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Tim Winter Sent: Saturday, April 03, 2010 10:09 AM To: roll@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : = storing / non-storing / mixed modes of operation WG, >From Anaheim and the list it seems that there is support to proceed on = RPL with storing and non-storing modes of operation, and not to elaborate mixed = mode operation at this time (while allowing room for future specification of mixed = mode). The summary approach would be to signal the mode of operation through = the DIO, that all nodes MUST be capable to support a non-storing mode of operation, = and that nodes who are incapable of acting as routers in a storing mode may participate = in the DODAG as hosts (leaves). (The suitable behavior when a routing table in a = storing node becomes saturated is still under consideration). Would you please confirm this approach to the list? Then we may proceed = to refine RPL accordingly for the next revision, -08, and to take this into = account when working the other tickets. Thanks, -Tim roll issue tracker wrote: > #26: Establishing downward routes in RPL : storing / non-storing / = mixed modes > of operation > = --------------------------------+----------------------------------------= --- > Reporter: jpv@=E2=80=A6 | Owner: = wintert@=E2=80=A6 =20 > Type: task | Status: new =20 > Priority: major | Milestone: =20 > Component: rpl | Version: =20 > Severity: Active WG Document | Keywords: =20 > = --------------------------------+----------------------------------------= --- > In the RPL-07 proposal the DAO mechanism described in Section 6 = attempts > to support > operation with a mix of storing nodes and non-storing nodes- where = storing > nodes may > be provisioned with enough memory that they are capable to provision = hop- > by-hop > downward routes learned from DAO messages, and non-storing nodes = would > rely on source > routing for downward routes. The present proposal describes = operation in > a mixed > mode operation, with both storing and non-storing nodes, where each = node > may > provision downward routing state as according to its capabilities and > largely > independent of its position in the LLN topology. >=20 > It has been noted that operation in the case where all nodes (except > possibly the > root) are non-storing nodes allows for certain optimizations, and = that the > case where > all nodes (except possibly leaves) are storing leads to other > optimizations. It has > also been noted that in the mixed cases the ability to provide an = optimal > solution > may break down. In particular there are concerns about the = complexity and > correctness of mixed-mode operation as proposed by RPL-07. >=20 > With this in mind, should RPL allow for operation in a mixture of = storing > /non-storing > nodes? Or should each RPL Instance be exclusively operating in = either > storing or > non-storing mode (with the provision that operation as a leaf is = always an > option)? > (The non-mixed case may imply some control flag or equivalent given = in the > DIO to > signal the mode of operation). >=20 > Tim Winter. >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=7039ff48a=mukul@uwm.edu Sat Apr 3 17:47:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3303A68BD for ; Sat, 3 Apr 2010 17:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2-374Thfobs for ; Sat, 3 Apr 2010 17:47:45 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id BF2993A687B for ; Sat, 3 Apr 2010 17:47:45 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 03 Apr 2010 19:47:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6EBA21958005; Sat, 3 Apr 2010 19:47:44 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul 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 WNJeJsA0cFSP; Sat, 3 Apr 2010 19:47:44 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3BDBE1958001; Sat, 3 Apr 2010 19:47:44 -0500 (CDT) Date: Sat, 3 Apr 2010 19:47:44 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <2052536908.3603531270342064000.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1183365625.3602111270341481258.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Apr 2010 00:47:46 -0000 Phil: Please see my response below. Thanks Mukul [Phil] I'm not sure I understand the concern. Is it that if this isn't stated explicitly, then an implementation might put a neighbor in the parent set for which it cannot compute DAGRank from the OF? How would it ever compute its own DAGRank? Can you explain the failure condition? [Mukul] Consider the situation where node A receives a DIO from node B and knows the cost of link B->A (either it already knew this cost or DIO carries this cost or it assumes a value for this cost) but not that of link A->B. Then, node A may be able to compute its DAG rank via node B and thus possibly select node B as a DIO parent. But, even if B becomes a DIO parent, A should not consider B as a candidate for DAO parenthood because A does not know the cost of link A->B. [Phil] So a node A MUST NOT select node B as a parent if the OF cannot compute the DAGRank of the resulting route? [Mukul] Node A may have sufficient information to calculate its DAG rank via B but still may not have the information to calculate B's suitability as a DAO parent (e.g. if OF just considers the upwards costs in calculating the DAG rank and such costs are known to A but requires knowledge of downwards costs for a parent's selection as DAO parent and these downwards costs (from B to A) are not known to A). [Phil] Does it say yes my sentence is correct or no it is not correct? [Mukul] It says that your sentence is not correct. This is because your sentence assumes that the DAGrank calculation requires knowledge of all sorts of costs that the node may need to choose its DAG or DAO parents. This assumption is not true. A DAGrank is simply a loop avoidance mechanism that may not be a very good indicator of actual routing costs in either direction. I know you would disagree with me (based on my understanding of your point of view from your previous posts). [Phil] Ah -- I think this is why we can't seem to agree: we're coming from different assumptions. There was a change in -07; Richard noted that having Rank *not* reflect a metric is problematic, as it constrains parent selection. I.e., if Rank does not directly reflect a metric, it's possible that a node can't pick a better (lower metric) parent because it has a higher Rank. This led to the inclusion of MinHopRankIncrease, elevating Rank to 16-bits, and the introduction of DAGRank, such that Rank could still reflect a good fidelity metric but DAGRank can provide good loop avoidance and topology constraints. The operating assumption is that since Rank constrains the set of parents a node can select, then separating it from metrics is problematic. The OF computes the Rank (this has always been the case): it should have all of the needed information. Or is there something in the draft that says it won't? [Mukul] I can see that RPL-7 talks about 16-bit rank and MinHopRankIncrease. But I could find no text in the draft that says that the rank should represent the routing cost. In fact, Section 3.6.2 clearly says that the rank represents a node's position in the DAG and that "The rank is not a cost metric, although its value can be derived from and influenced by metrics." (2nd paragraph in 3.6.2). Rank can be made to reflect the routing costs if desired. But, it is not mandatory to do so (atleast as per RPL-7). It should not be mandatory to do so. Rank's primary objective is to indicate node's position in the DAG. Whether it reflects the routing costs as well is secondary/optional. Hence, OF need not consider the costs in both directions while choosing the rank. So, the rank of a parent may not indicate its suitability to serve as a DAO parent. In fact, second bullet point in Section 6.2.3 makes it clear: "The selection of DAO parents is implementation specific and may be based on selecting the DODAG Parents that offer the best upwards cost (as opposed to downwards or mixed), as determined by the metrics in use and the Objective Function. " I guess it wont hurt to mention in the draft that if a DAG plans to support downwards routes then the DIOs should carry downwards routing metrics (both aggregated and local values, i.e. a DIO from A should carry aggregated routing cost from root till A and local cost from A to specific neighbors). Thanks Mukul From prvs=7039ff48a=mukul@uwm.edu Sat Apr 3 18:14:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F8E3A68BE for ; Sat, 3 Apr 2010 18:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.25 X-Spam-Level: ** X-Spam-Status: No, score=2.25 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_60=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9ESCQh3Yc7V for ; Sat, 3 Apr 2010 18:14:57 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 688B03A68AA for ; Sat, 3 Apr 2010 18:14:57 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 03 Apr 2010 20:14:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 329271958002; Sat, 3 Apr 2010 20:14:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul 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 tXfRp0GXMpaO; Sat, 3 Apr 2010 20:14:56 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0831E1958001; Sat, 3 Apr 2010 20:14:56 -0500 (CDT) Date: Sat, 3 Apr 2010 20:14:55 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <149650392.3607081270343695937.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1705363883.3605961270343380363.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] [roll] #32: Asymetric Link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Apr 2010 01:14:58 -0000 Phil: Please see response below. Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "Thomas Heide Clausen" , roll@ietf.org Sent: Thursday, April 1, 2010 10:59:27 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] [roll] #32: Asymetric Link On Apr 1, 2010, at 4:54 AM, Mukul Goyal wrote: > Hi Thomas > > I guess we have to distinguish between L3 and L2 metrics. It sees to me that RPL is concerned with L3 metrics and how they relate to L2 metrics should not bother RPL. > > [Thomas] This, of course, leads to the question of below which > "metric" (quality, ...) a link should be considered "uni-directional" > rather than just "asymmetric"? To take an abstract example, assuming a > L2 employing ack's for each unicast transmission: if the probability > of getting a transmission from A to B is 100% and from B to A is 10%, > is the link A->B "asymmetric" or "uni-directional"? Can the metric for > A->B be considered without also considering the metric in the opposite > direction B->A? > > [Mukul] In this case, I guess L3 metric A->B would automatically be quite poor because of its dependence of L2 metrics A->B and B->A. But, still L3 metric A->B is independent of the L3 metric B->A. [Phil] I think the discussion is a bit clearer once you consider the "metric" may not be delivery. I.e., it is possible to have a link that has 100% delivery in both directions yet highly asymmetric metrics. One simple case is latency. I think that unidirectional links or links with very poor delivery in one direction are a diversion when it comes to routing. As Thomas points out, it is absolutely critical that a routing protocol be able to identify and ignore/avoid them: this isn't too hard. Trying to use them effectively, however, requires a lot of complexity with very little gain, so let's not go down that path. [Mukul] I agree. But such links should be filtered out by the metrics definition rather than by the routing protocol. RPL should certainly provide guidance in this regard (perhaps in section 10 "Guidelines for objective functions"). Thanks Mukul From pthubert@cisco.com Sun Apr 4 11:57:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446CA3A68C5 for ; Sun, 4 Apr 2010 11:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef+ZLNT2VqRy for ; Sun, 4 Apr 2010 11:57:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 623793A6452 for ; Sun, 4 Apr 2010 11:57:52 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANt9uEtAaHte/2dsb2JhbACbT3GZeJdUgmkIghYEjio X-IronPort-AV: E=Sophos;i="4.51,363,1267401600"; d="scan'208";a="110012092" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2010 18:57:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o34IvmNc014230; Sun, 4 Apr 2010 18:57:49 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 20:57: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: Sun, 4 Apr 2010 20:57:35 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F09@XMB-AMS-107.cisco.com> In-Reply-To: <38324B91-8952-4A00-BC4D-BD00637C8130@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #26: Establishing downward routes in RPL :storing / non-storing / mixed modes of operation Thread-Index: AcrTWSspKcO6CbH0RNefvHFm2iT6LwAz4Cyw References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org><4BB77631.20503@acm.org> <38324B91-8952-4A00-BC4D-BD00637C8130@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Tim Winter" X-OriginalArrivalTime: 04 Apr 2010 18:57:48.0100 (UTC) FILETIME=[B7CE2040:01CAD428] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL :storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Apr 2010 18:57:53 -0000 Me 2 :) Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Saturday, April 03, 2010 8:12 PM > To: Tim Winter > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL :storing / > non-storing / mixed modes of operation >=20 >=20 > On Apr 3, 2010, at 10:09 AM, Tim Winter wrote: >=20 > > WG, > > > > From Anaheim and the list it seems that there is support to proceed on > > RPL with storing and non-storing modes of operation, and not to > > elaborate mixed mode operation at this time (while allowing room for > future specification of mixed mode). > > > > The summary approach would be to signal the mode of operation through > > the DIO, that all nodes MUST be capable to support a non-storing mode > > of operation, and that nodes who are incapable of acting as routers in > > a storing mode may participate in the DODAG as hosts (leaves). (The > > suitable behavior when a routing table in a storing node becomes saturated > is still under consideration). > > > > Would you please confirm this approach to the list? Then we may > > proceed to refine RPL accordingly for the next revision, -08, and to > > take this into account when working the other tickets. >=20 > +1 >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Apr 4 12:03:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491493A6948 for ; Sun, 4 Apr 2010 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9OmdNlVulcL for ; Sun, 4 Apr 2010 12:02:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9E15B3A698B for ; Sun, 4 Apr 2010 12:02:51 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZ/uEurR7H+/2dsb2JhbACbT3GZfJdShQcEjio X-IronPort-AV: E=Sophos;i="4.51,363,1267401600"; d="scan'208";a="249194334" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2010 19:02:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o34J2nlr028068; Sun, 4 Apr 2010 19:02:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 21:02: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: Sun, 4 Apr 2010 21:02:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F0A@XMB-AMS-107.cisco.com> In-Reply-To: <8696DBDB-4ADE-46BE-A87C-690C2E288F1D@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DODAGID Thread-Index: AcrShzNIETqbt85qR2uYlkfk3sxUggBoaD+w References: <8696DBDB-4ADE-46BE-A87C-690C2E288F1D@cs.jhu.edu> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" , "Philip Levis" X-OriginalArrivalTime: 04 Apr 2010 19:02:48.0912 (UTC) FILETIME=[6B1A6500:01CAD429] Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Apr 2010 19:03:00 -0000 Hi John: The DODAGID is expected to be an IPv6 address of the root. The prefix option normally indicates a prefix that can be reached via the DODAGID. Interestingly, there is a strong need to also indicateand maintain availability of a prefix that would be deployed over the DODAG, when the subnet spans the DAG (6LoWPAN & Autoconf). A simple bit in the option could indicate that. In either case, the prefix ends up in the RAs, either for not-onlink SLAAC, or for the purpose of RFC 4191.=20 Advice? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JeongGil Ko (John) > Sent: Friday, April 02, 2010 7:08 PM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] DODAGID >=20 > Correct me if I am wrong but I read that the prefix container was for > 'additional' prefixes and therefore, I assumed that the default prefix that the > DODAG root was supporting was in the DODOAGID. The specs said that the > DODAGID was derived from the IP address of the DODAG root so I was > assuming this would be okay. One less message container to carry by default. >=20 > - John >=20 >=20 > On Apr 1, 2010, at 6:39 PM, Philip Levis wrote: >=20 > > Can someone remind me why DODAGID is in the DIO? IIRC, someone told > me that DODAGID is necessary due to application requirements that a node > can avoid choosing a new preferred parent that goes to a different DODAG > root. Can someone point me at this requirement? DODAGIDs add a lot of > complexity and greatly increase message sizes. > > > > If they're needed, all's good, but I can't seem to find the application > requirement (in a requirements doc) that calls for this. I figure anything we > can do to simplify things is desirable. In the case of DODAGIDs, the presence > of RPL instances and the destination prefix suggests to me connectivity is > already handled. > > > > Phil > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Sun Apr 4 13:50:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148003A6A69 for ; Sun, 4 Apr 2010 13:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Wapd+mfcjG for ; Sun, 4 Apr 2010 13:50:21 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 660813A6A06 for ; Sun, 4 Apr 2010 13:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 0B4931558EE for ; Sun, 4 Apr 2010 22:49:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id btxWqWW7Il7O for ; Sun, 4 Apr 2010 22:49:31 +0200 (CEST) X-KTH-Auth: phoebus [213.100.62.72] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from c213-100-62-72.swipnet.se (c213-100-62-72.swipnet.se [213.100.62.72]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 729721549F5 for ; Sun, 4 Apr 2010 22:49:30 +0200 (CEST) Message-ID: <4BB8FB5A.9000400@ieee.org> Date: Sun, 04 Apr 2010 22:49:30 +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.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org><4BB77631.20503@acm.org> <38324B91-8952-4A00-BC4D-BD00637C8130@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923F09@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F09@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL :storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 04 Apr 2010 20:50:23 -0000 +1 -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 4/4/10 8:57 PM, Pascal Thubert (pthubert) wrote: > Me 2 :) > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Philip Levis >> Sent: Saturday, April 03, 2010 8:12 PM >> To: Tim Winter >> Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL > :storing / >> non-storing / mixed modes of operation >> >> >> On Apr 3, 2010, at 10:09 AM, Tim Winter wrote: >> >>> WG, >>> >>> From Anaheim and the list it seems that there is support to proceed > on >>> RPL with storing and non-storing modes of operation, and not to >>> elaborate mixed mode operation at this time (while allowing room for >> future specification of mixed mode). >>> >>> The summary approach would be to signal the mode of operation > through >>> the DIO, that all nodes MUST be capable to support a non-storing > mode >>> of operation, and that nodes who are incapable of acting as routers > in >>> a storing mode may participate in the DODAG as hosts (leaves). (The >>> suitable behavior when a routing table in a storing node becomes > saturated >> is still under consideration). >>> >>> Would you please confirm this approach to the list? Then we may >>> proceed to refine RPL accordingly for the next revision, -08, and to >>> take this into account when working the other tickets. >> >> +1 >> >> Phil >> _______________________________________________ >> 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 phoebus@ieee.org Sun Apr 4 14:53:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0786D3A69ED for ; Sun, 4 Apr 2010 14:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.4 X-Spam-Level: X-Spam-Status: No, score=-103.4 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpS3dN+8rbww for ; Sun, 4 Apr 2010 14:53:14 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 7A3C33A6856 for ; Sun, 4 Apr 2010 14:53:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id E35C215588C for ; Sun, 4 Apr 2010 23:52:42 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IcrV9oFkUKSR for ; Sun, 4 Apr 2010 23:52:39 +0200 (CEST) X-KTH-Auth: phoebus [213.100.62.72] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from c213-100-62-72.swipnet.se (c213-100-62-72.swipnet.se [213.100.62.72]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 02AB31549F5 for ; Sun, 4 Apr 2010 23:52:36 +0200 (CEST) Message-ID: <4BB90A23.5000301@ieee.org> Date: Sun, 04 Apr 2010 23:52:35 +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.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "roll@ietf.org" References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com> <988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> In-Reply-To: <988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 04 Apr 2010 21:53:16 -0000 JP and WG, Maybe this should be a standard option instead of a TLV, but as I mentioned in an earlier email, I think it's clearer to use flags or options in the DIS to specify that a node is a) requesting a DODAG Configuration Object (or some other suboptions in the DIO), and b) not wanting to reset the Trickle timer, rather than define that as the functionality of a unicast DIS message (as opposed to a multicast DIS message, RPLv7, Sec. 5.3.5., pg. 36). Just putting this back on the table with the other DIS suboptions being discussed, to help with the decision of a packet format. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 4/2/10 4:39 PM, JP Vasseur wrote: > I think that the consensus was also to slightly change the DIS packet > format to allow for future options to be carried in the form of TLV > (as we do in many other protocols) , which is not possible with the > current packet format. > > WG ? > > JP. > > On Apr 2, 2010, at 11:29 AM, Pascal Thubert (pthubert) wrote: > >> Hi: >> >> From theads and discussions, I'd think that the conclusion could be >> to make sure we do not disallow options in the future, but for the >> short term to only specify what we really need. >> What we really need to probably the DODAG ID (UNSPECIFIED if none) >> and the instance ID (0 by default). I think those 2 should be in the >> common header and not in an option. >> >> Advice? >> >> Pascal >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of roll >>> issue tracker >>> Sent: Monday, March 29, 2010 5:47 AM >>> To: wintert@acm.org; jpv@cisco.com >>> Cc: roll@ietf.org >>> Subject: [Roll] [roll] #29: DIS packet format >>> >>> #29: DIS packet format >>> -------------------------------- >>> +--------------------------------------- >>> --------------------------------+---- >>> Reporter: jpv@… | Owner: wintert@… >>> Type: task | Status: new >>> Priority: major | Milestone: >>> Component: rpl | Version: >>> Severity: Active WG Document | Keywords: >>> -------------------------------- >>> +--------------------------------------- >>> --------------------------------+---- >>> Consensus on the ROLL ML to change the DIS packet format and make the >>> body capable of carrying TLVs, with no TLV defined in the core >>> specification. >>> >>> -- >>> Ticket URL: >>> roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 5 01:42:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D08B3A6825 for ; Mon, 5 Apr 2010 01:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.749 X-Spam-Level: X-Spam-Status: No, score=-7.749 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHnkUYnY+A88 for ; Mon, 5 Apr 2010 01:42:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BCA0A3A6817 for ; Mon, 5 Apr 2010 01:42:03 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAFA+uUuQ/uCWe2dsb2JhbACbSRUBAQsLIgYcmiCXUIUHBA X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="58978602" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2010 08:42:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o358g1Ub029119; Mon, 5 Apr 2010 08:42:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 10:42:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 10:41:54 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> In-Reply-To: <4BB90A23.5000301@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #29: DIS packet format Thread-Index: AcrUQUAtiWAUMc2ATNWL8uUWymUg7gAWPFSA References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 05 Apr 2010 08:42:00.0744 (UTC) FILETIME=[DBE0C280:01CAD49B] Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 08:42:06 -0000 All/ I agree with the RPL standard options, which by the way are TLVs of sort. Does not mean that we have to define a single option so far, but maybe allow for padding. Still, Phil's point stands. There are things that are needed most time and even options is overkill. In particular the instance ID, and probably a few flags like Phoebus points out. What about: " XXX DODAG Information Solicitation (DIS) =20 The DODAG Information Solicitation (DIS) message may be used to solicit a DODAG Information Object from a RPL node. Its use is analogous to that of a Router Solicitation; a node may use DIS to probe its neighborhood for nearby DODAGs. Section 6.2.4 describes how nodes respond to a DIS. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D|O|C|reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | DODAGID (If D flag set) | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DIS Base RPLInstanceID: 8-bit field set by the DODAG root that indicates which RPL Instance the DODAG is part of. D flag: Set if the DODAGID is present. O flag: Set to request a DODAG Configuration Object C flag: Set if the requester expects no inconsistency, just revalidation. DODAGID: 128-bit unsigned integer set by a DODAG root which uniquely identifies a DODAG. Possibly derived from the IPv6 address of the DODAG root. The field can be omitted when the node does not look for a DODAG root in particular. =20 The DODAG Information Solicitation MAY carry options. With this specification only the padding (Pad1 and PadN) option MAY be used in a DIS messsage. < TBD, list of OFs? > " Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Phoebus Chen > Sent: Sunday, April 04, 2010 11:53 PM > To: roll@ietf.org > Subject: Re: [Roll] [roll] #29: DIS packet format >=20 > JP and WG, >=20 > Maybe this should be a standard option instead of a TLV, but as I mentioned > in an earlier email, I think it's clearer to use flags or options in the DIS to > specify that a node is > a) requesting a DODAG Configuration Object (or some other suboptions in > the DIO), and > b) not wanting to reset the Trickle timer, rather than define that as the > functionality of a unicast DIS message (as opposed to a multicast DIS > message, RPLv7, Sec. 5.3.5., pg. 36). >=20 > Just putting this back on the table with the other DIS suboptions being > discussed, to help with the decision of a packet format. >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 > On 4/2/10 4:39 PM, JP Vasseur wrote: > > I think that the consensus was also to slightly change the DIS packet > > format to allow for future options to be carried in the form of TLV > > (as we do in many other protocols) , which is not possible with the > > current packet format. > > > > WG ? > > > > JP. > > > > On Apr 2, 2010, at 11:29 AM, Pascal Thubert (pthubert) wrote: > > > >> Hi: > >> > >> From theads and discussions, I'd think that the conclusion could be > >> to make sure we do not disallow options in the future, but for the > >> short term to only specify what we really need. > >> What we really need to probably the DODAG ID (UNSPECIFIED if none) > >> and the instance ID (0 by default). I think those 2 should be in the > >> common header and not in an option. > >> > >> Advice? > >> > >> Pascal > >> > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >>> Of roll issue tracker > >>> Sent: Monday, March 29, 2010 5:47 AM > >>> To: wintert@acm.org; jpv@cisco.com > >>> Cc: roll@ietf.org > >>> Subject: [Roll] [roll] #29: DIS packet format > >>> > >>> #29: DIS packet format > >>> -------------------------------- > >>> +--------------------------------------- > >>> --------------------------------+---- > >>> Reporter: jpv@... | Owner: wintert@... > >>> Type: task | Status: new > >>> Priority: major | Milestone: > >>> Component: rpl | Version: > >>> Severity: Active WG Document | Keywords: > >>> -------------------------------- > >>> +--------------------------------------- > >>> --------------------------------+---- > >>> Consensus on the ROLL ML to change the DIS packet format and make > >>> the body capable of carrying TLVs, with no TLV defined in the core > >>> specification. > >>> > >>> -- > >>> Ticket URL: > >>> roll > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 5 01:58:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93163A6888 for ; Mon, 5 Apr 2010 01:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-3.917, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sbcsJqCh6LB for ; Mon, 5 Apr 2010 01:58:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8C3863A67F8 for ; Mon, 5 Apr 2010 01:58:11 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBADJDuUuQ/uCWe2dsb2JhbACbSRUBAQsLIgYcmg2XUYUHBI4q X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="5187403" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2010 08:23:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o358w8C0000939; Mon, 5 Apr 2010 08:58:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 10:58:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 10:58:04 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIS information filter Thread-Index: AcrShjE+beotJu5SQZaEeXZLyb/LYwCFpIKA References: From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "ROLL WG" X-OriginalArrivalTime: 05 Apr 2010 08:58:08.0526 (UTC) FILETIME=[1CB892E0:01CAD49E] Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 08:58:13 -0000 Hi Phil: I'm in, agreement with everything you said below. But one thing where you lost me. I understood that you were advocating for simplicity and not using an option for something that's really basic/core, thus my post on another thread before I saw this where those parms make the DIS message itself. I tend to prefer the simplicity in this case. For me an option is good for:=20 - something that's used only when an optional behavior applies. For instance OF specific suboptions. - something that does not need to be repeated in all messages. Like OF parms. - something that might be repeated multiple times in a message. For instance I think that the target of a DAO should be an option so we can have multiple of them in one message - something that might be used in multiple types of messages. The target I mentioned above could be useful in DIO for stimulated repair, incoming request and P2P as already discussed in the ML. So, I agree with accepting options in DIS, I'm just unclear whether your proposal is an option or mostly the base DIS. Votes? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Friday, April 02, 2010 7:01 PM > To: ROLL WG > Subject: [Roll] DIS information filter >=20 > (Trying to restart the thread) >=20 > In -07, nodes always respond to DIS messages by resetting their Trickle > timers. A few people on the list have pointed out that this is problematic. If > an environment has multiple RPL instances, for example, when a node > solicits information it must do so from *all* instances, even if it knows the > one it wants to join. >=20 > The basic issue is that a node may wish to solicit DIOs from only a subset of > nodes; it's wasteful to force a lot of nodes to reset their trickle timers > unnecessarily. >=20 > I propose that we add a new suboption to RPL, which is only valid for DIS > messages. The Solicited Information Filter suboption specifies a set of > predicates; if a node satisfies the predicates, it MUST reset its timer in > response to the message. If it does not satisfy the predicates, it MUST NOT > reset its timer in response to the message. >=20 > The trick is to make this a simple, fixed-length suboption; forcing nodes to > parse all kinds of suboptions is problematic in terms of code size. Similarly, > we'd like the suboption to cover the compelling cases but not be so complete > that it wastes space on useless fields. So the question is: what information do > nodes want to filter on? >=20 > The one that immediately comes to mind is a DODAG Iteration: this would > imply the RPLInstanceID, Sequence, and DODAGID. >=20 > There have been a few mentions of Rank. I personally think it makes more > sense to handle this through trickle suppression (you generally want low- > Rank messages more than high-Rank ones), but this seems like a good point > of discussion. >=20 > So my current proposal is that the Solicited Information Suboption has the > following format: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 5 | Reserved | Sequence | = RPLInstanceID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | DODAGID | > + + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Furthermore, we should reserve values for Sequence, RPLInstanceID, and > DODAGID as wildcards ("any value matches"). This would indicate that such > values can't be used normally. Alternatively, the reserved region could have > bits stating which of the three fields to match on. >=20 > Thoughts? >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Apr 5 02:35:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76943A67B3 for ; Mon, 5 Apr 2010 02:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.735 X-Spam-Level: X-Spam-Status: No, score=-8.735 tagged_above=-999 required=5 tests=[AWL=1.865, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW+2Jz4O-peu for ; Mon, 5 Apr 2010 02:35:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B7D963A677D for ; Mon, 5 Apr 2010 02:35:10 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgECAGdLuUuQ/uCWe2dsb2JhbACbSRUBAQsLIgYcmi2XT4UHBA X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="58979509" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2010 09:35:07 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o359Z7F0005520; Mon, 5 Apr 2010 09:35:07 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 11:35:07 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 11:35:06 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 11:35:05 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Apr 2010 09:35:06.0637 (UTC) FILETIME=[46D173D0:01CAD4A3] Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 09:35:12 -0000 Hi, There is golden rule for deciding this, mostly common sense. The reason why I would argue for a sub-option in this case is that we may need other ones in the future. It might not be needed in some cases, and we may need more in other cases, a good reason for using options in my opinion. Thanks. JP. On Apr 5, 2010, at 10:58 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > I'm in, agreement with everything you said below. But one thing where > you lost me. > > I understood that you were advocating for simplicity and not using an > option for something that's really basic/core, thus my post on another > thread before I saw this where those parms make the DIS message > itself. > I tend to prefer the simplicity in this case. > > For me an option is good for: > - something that's used only when an optional behavior applies. For > instance OF specific suboptions. > - something that does not need to be repeated in all messages. Like OF > parms. > - something that might be repeated multiple times in a message. For > instance I think that the target of a DAO should be an option so we > can > have multiple of them in one message > - something that might be used in multiple types of messages. The > target > I mentioned above could be useful in DIO for stimulated repair, > incoming > request and P2P as already discussed in the ML. > > So, I agree with accepting options in DIS, I'm just unclear whether > your > proposal is an option or mostly the base DIS. > > Votes? > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Philip Levis >> Sent: Friday, April 02, 2010 7:01 PM >> To: ROLL WG >> Subject: [Roll] DIS information filter >> >> (Trying to restart the thread) >> >> In -07, nodes always respond to DIS messages by resetting their > Trickle >> timers. A few people on the list have pointed out that this is > problematic. If >> an environment has multiple RPL instances, for example, when a node >> solicits information it must do so from *all* instances, even if it > knows the >> one it wants to join. >> >> The basic issue is that a node may wish to solicit DIOs from only a > subset of >> nodes; it's wasteful to force a lot of nodes to reset their trickle > timers >> unnecessarily. >> >> I propose that we add a new suboption to RPL, which is only valid for > DIS >> messages. The Solicited Information Filter suboption specifies a set > of >> predicates; if a node satisfies the predicates, it MUST reset its > timer in >> response to the message. If it does not satisfy the predicates, it > MUST NOT >> reset its timer in response to the message. >> >> The trick is to make this a simple, fixed-length suboption; forcing > nodes to >> parse all kinds of suboptions is problematic in terms of code size. > Similarly, >> we'd like the suboption to cover the compelling cases but not be so > complete >> that it wastes space on useless fields. So the question is: what > information do >> nodes want to filter on? >> >> The one that immediately comes to mind is a DODAG Iteration: this > would >> imply the RPLInstanceID, Sequence, and DODAGID. >> >> There have been a few mentions of Rank. I personally think it makes > more >> sense to handle this through trickle suppression (you generally want > low- >> Rank messages more than high-Rank ones), but this seems like a good > point >> of discussion. >> >> So my current proposal is that the Solicited Information Suboption >> has > the >> following format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 5 | Reserved | Sequence | RPLInstanceID > | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | > | >> + > + >> | DODAGID > | >> + > + >> | > | >> + > + >> | > | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Furthermore, we should reserve values for Sequence, RPLInstanceID, >> and >> DODAGID as wildcards ("any value matches"). This would indicate that > such >> values can't be used normally. Alternatively, the reserved region > could have >> bits stating which of the three fields to match on. >> >> Thoughts? >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 5 02:43:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E123A67D3 for ; Mon, 5 Apr 2010 02:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.237 X-Spam-Level: X-Spam-Status: No, score=-8.237 tagged_above=-999 required=5 tests=[AWL=2.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH2zjxypo1jQ for ; Mon, 5 Apr 2010 02:43:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 83E0F3A677D for ; Mon, 5 Apr 2010 02:43:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="509273458" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2010 09:43:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o359hXTL003502; Mon, 5 Apr 2010 09:43:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 11:43: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 11:43:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIS information filter Thread-Index: AcrUo0cqRmVdBcBgSJCNcLnsUEQK/wAAIVjw References: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 05 Apr 2010 09:43:32.0733 (UTC) FILETIME=[747992D0:01CAD4A4] Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 09:43:36 -0000 JP: I agree with allowing options and eventually suboptions (since we migrated out of ND messages, the so-called suboptions are really options, we need to fix that) in all RPL messages. This does not mean that everything has to be options. Same goes for DIO, would you make everything in the base header an option? OTOH, in the current spec, the target in a DAO is not an option. This prevents from packing multiple targets in a single DAO, which is really sad in the stateful mode.=20 I agree with good sense as long as it is really common.=20 Pascal > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Monday, April 05, 2010 11:35 AM > To: Pascal Thubert (pthubert) > Cc: Philip Levis; ROLL WG > Subject: Re: [Roll] DIS information filter >=20 > Hi, >=20 > There is golden rule for deciding this, mostly common sense. The reason why > I would argue for a sub-option in this case is that we may need other ones in > the future. It might not be needed in some cases, and we may need more in > other cases, a good reason for using options in my opinion. >=20 > Thanks. >=20 > JP. >=20 > On Apr 5, 2010, at 10:58 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > I'm in, agreement with everything you said below. But one thing where > > you lost me. > > > > I understood that you were advocating for simplicity and not using an > > option for something that's really basic/core, thus my post on another > > thread before I saw this where those parms make the DIS message > > itself. > > I tend to prefer the simplicity in this case. > > > > For me an option is good for: > > - something that's used only when an optional behavior applies. For > > instance OF specific suboptions. > > - something that does not need to be repeated in all messages. Like OF > > parms. > > - something that might be repeated multiple times in a message. For > > instance I think that the target of a DAO should be an option so we > > can have multiple of them in one message > > - something that might be used in multiple types of messages. The > > target I mentioned above could be useful in DIO for stimulated repair, > > incoming request and P2P as already discussed in the ML. > > > > So, I agree with accepting options in DIS, I'm just unclear whether > > your proposal is an option or mostly the base DIS. > > > > Votes? > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of > >> Philip Levis > >> Sent: Friday, April 02, 2010 7:01 PM > >> To: ROLL WG > >> Subject: [Roll] DIS information filter > >> > >> (Trying to restart the thread) > >> > >> In -07, nodes always respond to DIS messages by resetting their > > Trickle > >> timers. A few people on the list have pointed out that this is > > problematic. If > >> an environment has multiple RPL instances, for example, when a node > >> solicits information it must do so from *all* instances, even if it > > knows the > >> one it wants to join. > >> > >> The basic issue is that a node may wish to solicit DIOs from only a > > subset of > >> nodes; it's wasteful to force a lot of nodes to reset their trickle > > timers > >> unnecessarily. > >> > >> I propose that we add a new suboption to RPL, which is only valid for > > DIS > >> messages. The Solicited Information Filter suboption specifies a set > > of > >> predicates; if a node satisfies the predicates, it MUST reset its > > timer in > >> response to the message. If it does not satisfy the predicates, it > > MUST NOT > >> reset its timer in response to the message. > >> > >> The trick is to make this a simple, fixed-length suboption; forcing > > nodes to > >> parse all kinds of suboptions is problematic in terms of code size. > > Similarly, > >> we'd like the suboption to cover the compelling cases but not be so > > complete > >> that it wastes space on useless fields. So the question is: what > > information do > >> nodes want to filter on? > >> > >> The one that immediately comes to mind is a DODAG Iteration: this > > would > >> imply the RPLInstanceID, Sequence, and DODAGID. > >> > >> There have been a few mentions of Rank. I personally think it makes > > more > >> sense to handle this through trickle suppression (you generally want > > low- > >> Rank messages more than high-Rank ones), but this seems like a good > > point > >> of discussion. > >> > >> So my current proposal is that the Solicited Information Suboption > >> has > > the > >> following format: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> > >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type =3D 5 | Reserved | Sequence | RPLInstanceID > > | > >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | > > | > >> + > > + > >> | DODAGID > > | > >> + > > + > >> | > > | > >> + > > + > >> | > > | > >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Furthermore, we should reserve values for Sequence, RPLInstanceID, > >> and DODAGID as wildcards ("any value matches"). This would indicate > >> that > > such > >> values can't be used normally. Alternatively, the reserved region > > could have > >> bits stating which of the three fields to match on. > >> > >> Thoughts? > >> > >> Phil > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 5 02:53:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045283A68A4 for ; Mon, 5 Apr 2010 02:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.965 X-Spam-Level: X-Spam-Status: No, score=-3.965 tagged_above=-999 required=5 tests=[AWL=-2.855, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymiCMYjLY6Hj for ; Mon, 5 Apr 2010 02:53:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F14613A676A for ; Mon, 5 Apr 2010 02:53:21 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="5188413" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2010 09:18:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o359rJfl007815; Mon, 5 Apr 2010 09:53:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 11:53:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 11:53:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923F4E@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIS information filter Thread-Index: AcrUo0cqRmVdBcBgSJCNcLnsUEQK/wAAIVjwAABrhwA= References: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 05 Apr 2010 09:53:19.0269 (UTC) FILETIME=[D213DD50:01CAD4A5] Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 09:53:24 -0000 Hi again JP: What about this to clearly indicate that all RPL messages have the same construct: " . ICMPv6 RPL Control Message This document defines the RPL Control Message, a new ICMPv6 message. A RPL Control Message is identified by a code, and composed of a base that depends on the code, and a series of options. A RPL Control Message has the scope of a link. The source address is a link local address. The destination address is either all routers multicast address (FF02::2) or a link local address. In accordance with [RFC4443], the RPL Control Message has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Base | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option(s)... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: RPL Control Message The RPL Control message is an ICMPv6 information message with a requested Type of 155. The Code field identifies the type of RPL Control Message. This document defines three codes for the following RPL Control Message types: o 0x01: DODAG Information Solicitation (Section 5.1) o 0x02: DODAG Information Object (Section 5.2) o 0x04: Destination Advertisement Object (Section 5.3) " Then: " 5.4. RPL Control Message Options A RPL message is composed of a main body that depends on the message, and that may be followed by options. All options but the Pad1 follow the same format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 9: RPL message option Generic Format Winter, et al. Expires September 9, 2010 [Page 28] Internet-Draft draft-ietf-roll-rpl-07 March 2010 Option Type: 8-bit identifier of the type of option. Option Length: 16-bit unsigned integer, representing the length in octets of the option, not including the option Type and Length fields. Option Data: A variable length field that contains data specific to the option. When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following Options, correctly handling any remaining options in the message. RPL message options may have alignment requirements. Following the convention in IPv6, options with alignment requirements are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n =3D 1, 2, 4, or 8). This document defines the following RPL Message options: Pad1 1-octet padding, for use in all RPL messages. Padn n-octets padding, for use in all RPL messages. Metric Container To report path characteristics, for use in DIO messages. Destination Prefix To indicate a internal or external prefix, for use in DIO messages. DODAG Configuration To pass DODAG parameters, for use in DIO messages. This section describes the format of DIO options and the five options this document defines: Pad 1, Pad N, DAG Metric Container, DAG Destination Prefix, and DAG Configuration. " Cheers, Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: Monday, April 05, 2010 11:43 AM > To: 'JP Vasseur' > Cc: Philip Levis; ROLL WG > Subject: RE: [Roll] DIS information filter >=20 > JP: >=20 > I agree with allowing options and eventually suboptions (since we migrated > out of ND messages, the so-called suboptions are really options, we need to > fix that) in all RPL messages. >=20 > This does not mean that everything has to be options. Same goes for DIO, > would you make everything in the base header an option? >=20 > OTOH, in the current spec, the target in a DAO is not an option. This prevents > from packing multiple targets in a single DAO, which is really sad in the > stateful mode. >=20 > I agree with good sense as long as it is really common. >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: JP Vasseur [mailto:jpv@cisco.com] > > Sent: Monday, April 05, 2010 11:35 AM > > To: Pascal Thubert (pthubert) > > Cc: Philip Levis; ROLL WG > > Subject: Re: [Roll] DIS information filter > > > > Hi, > > > > There is golden rule for deciding this, mostly common sense. The > > reason why I would argue for a sub-option in this case is that we may > > need other ones in the future. It might not be needed in some cases, > > and we may need more in other cases, a good reason for using options in > my opinion. > > > > Thanks. > > > > JP. > > > > On Apr 5, 2010, at 10:58 AM, Pascal Thubert (pthubert) wrote: > > > > > Hi Phil: > > > > > > I'm in, agreement with everything you said below. But one thing > > > where you lost me. > > > > > > I understood that you were advocating for simplicity and not using > > > an option for something that's really basic/core, thus my post on > > > another thread before I saw this where those parms make the DIS > > > message itself. > > > I tend to prefer the simplicity in this case. > > > > > > For me an option is good for: > > > - something that's used only when an optional behavior applies. For > > > instance OF specific suboptions. > > > - something that does not need to be repeated in all messages. Like > > > OF parms. > > > - something that might be repeated multiple times in a message. For > > > instance I think that the target of a DAO should be an option so we > > > can have multiple of them in one message > > > - something that might be used in multiple types of messages. The > > > target I mentioned above could be useful in DIO for stimulated > > > repair, incoming request and P2P as already discussed in the ML. > > > > > > So, I agree with accepting options in DIS, I'm just unclear whether > > > your proposal is an option or mostly the base DIS. > > > > > > Votes? > > > > > > Pascal > > > > > > > > >> -----Original Message----- > > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > >> Behalf > > > Of > > >> Philip Levis > > >> Sent: Friday, April 02, 2010 7:01 PM > > >> To: ROLL WG > > >> Subject: [Roll] DIS information filter > > >> > > >> (Trying to restart the thread) > > >> > > >> In -07, nodes always respond to DIS messages by resetting their > > > Trickle > > >> timers. A few people on the list have pointed out that this is > > > problematic. If > > >> an environment has multiple RPL instances, for example, when a node > > >> solicits information it must do so from *all* instances, even if it > > > knows the > > >> one it wants to join. > > >> > > >> The basic issue is that a node may wish to solicit DIOs from only a > > > subset of > > >> nodes; it's wasteful to force a lot of nodes to reset their trickle > > > timers > > >> unnecessarily. > > >> > > >> I propose that we add a new suboption to RPL, which is only valid > > >> for > > > DIS > > >> messages. The Solicited Information Filter suboption specifies a > > >> set > > > of > > >> predicates; if a node satisfies the predicates, it MUST reset its > > > timer in > > >> response to the message. If it does not satisfy the predicates, it > > > MUST NOT > > >> reset its timer in response to the message. > > >> > > >> The trick is to make this a simple, fixed-length suboption; forcing > > > nodes to > > >> parse all kinds of suboptions is problematic in terms of code size. > > > Similarly, > > >> we'd like the suboption to cover the compelling cases but not be so > > > complete > > >> that it wastes space on useless fields. So the question is: what > > > information do > > >> nodes want to filter on? > > >> > > >> The one that immediately comes to mind is a DODAG Iteration: this > > > would > > >> imply the RPLInstanceID, Sequence, and DODAGID. > > >> > > >> There have been a few mentions of Rank. I personally think it makes > > > more > > >> sense to handle this through trickle suppression (you generally > > >> want > > > low- > > >> Rank messages more than high-Rank ones), but this seems like a good > > > point > > >> of discussion. > > >> > > >> So my current proposal is that the Solicited Information Suboption > > >> has > > > the > > >> following format: > > >> > > >> 0 1 2 3 > > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > > >> 1 > > >> > > >> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> | Type =3D 5 | Reserved | Sequence | RPLInstanceID > > > | > > >> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> | > > > | > > >> + > > > + > > >> | DODAGID > > > | > > >> + > > > + > > >> | > > > | > > >> + > > > + > > >> | > > > | > > >> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> > > >> Furthermore, we should reserve values for Sequence, RPLInstanceID, > > >> and DODAGID as wildcards ("any value matches"). This would indicate > > >> that > > > such > > >> values can't be used normally. Alternatively, the reserved region > > > could have > > >> bits stating which of the three fields to match on. > > >> > > >> Thoughts? > > >> > > >> Phil > > >> _______________________________________________ > > >> 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 hrogge@googlemail.com Mon Apr 5 03:06:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A284C3A6870 for ; Mon, 5 Apr 2010 03:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFj3Xo3hQMsx for ; Mon, 5 Apr 2010 03:06:09 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id F0B893A68C3 for ; Mon, 5 Apr 2010 03:04:17 -0700 (PDT) Received: by ewy24 with SMTP id 24so1151123ewy.13 for ; Mon, 05 Apr 2010 03:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=Hoj8l7TL/YOoHFR5LIkqZdWGpTF4grgbWU2JdF1aciw=; b=LbWJGT8bdMIUWS5y8+iK2gc7YnQQ68kSLbEV4+vrzZskvK5ysQngdZODTCbk+sprD/ gFUupT8O06Iyvunrgjk/N0raBYWvF/9xpdCbB4fNrAQK3rB4bE6wcl5T6cF0a2N+lJz1 vB3pwEZlaSfQaKWWDXfRm6Qgt2hT9prMtUMbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=SkWClJyDLdGeMNYIY3bGJVss06WN8dA3Kyxqr8Xho6QDpnk455bQVpj64xlKYCvsXv 0Wn+ctV3H+DWLvYa0NWcIzNY2eK1ZP5siv+N+/r9U0Q4s5sg7STdaO63F2QslQ9Qx/3J h839cQvBx1TxSsta1zc6RYoyHBUGgIyGXtRJA= Received: by 10.213.43.68 with SMTP id v4mr2895507ebe.91.1270461851011; Mon, 05 Apr 2010 03:04:11 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 15sm6201796ewy.12.2010.04.05.03.04.09 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Apr 2010 03:04:09 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Mon, 5 Apr 2010 12:04:03 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo; KDE/4.4.2; x86_64; ; ) References: <6A2A459175DABE4BB11DE2026AA50A5D01923F4E@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F4E@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1520780.px6UcRAdBa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004051204.08322.hrogge@googlemail.com> Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 10:06:10 -0000 --nextPart1520780.px6UcRAdBa Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Montag 05 April 2010 11:53:12 schrieb Pascal Thubert (pthubert): > Hi again JP: >=20 > What about this to clearly indicate that all RPL messages have the same > construct: >=20 > " > . ICMPv6 RPL Control Message >=20 > This document defines the RPL Control Message, a new ICMPv6 message. > A RPL Control Message is identified by a code, and composed of a base > that depends on the code, and a series of options. >=20 > A RPL Control Message has the scope of a link. The source address is > a link local address. The destination address is either all routers > multicast address (FF02::2) or a link local address. Just as a comment, the IANA has reserved a linklocal multicast address for= =20 manet routers (see RFC 5498), maybe this address (ff02::6d) would be useful= in=20 the Ripple context too. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1520780.px6UcRAdBa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAku5tZgACgkQcenvcwAcHWcyJQCfQrbcOGBLRD0h/WfgUp7Xkq6L osoAn1fXB8J/ZvJmSt7AdY4KHWEJBsEP =Fwtn -----END PGP SIGNATURE----- --nextPart1520780.px6UcRAdBa-- From robert.cragie@gridmerge.com Mon Apr 5 04:05:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D098D3A67FE for ; Mon, 5 Apr 2010 04:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id del18uywlHrr for ; Mon, 5 Apr 2010 04:05:24 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 09E743A68DE for ; Mon, 5 Apr 2010 04:05:23 -0700 (PDT) Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.64]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1Nyk7L-0005fl-0E for roll@ietf.org; Mon, 05 Apr 2010 12:05:19 +0100 Message-ID: <4BB9C3E8.8010907@gridmerge.com> Date: Mon, 05 Apr 2010 12:05:12 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> In-Reply-To: <4BB77631.20503@acm.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030104020205020203080706" Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 11:05:25 -0000 This is a cryptographically signed message in MIME format. --------------ms030104020205020203080706 Content-Type: multipart/alternative; boundary="------------060008020300070702070909" This is a multi-part message in MIME format. --------------060008020300070702070909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable +1 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 03/04/2010 6:09 PM, Tim Winter wrote: > WG, > > From Anaheim and the list it seems that there is support to proceed on= RPL with > storing and non-storing modes of operation, and not to elaborate mixed = mode operation > at this time (while allowing room for future specification of mixed mod= e). > > The summary approach would be to signal the mode of operation through t= he DIO, that > all nodes MUST be capable to support a non-storing mode of operation, a= nd that nodes > who are incapable of acting as routers in a storing mode may participat= e in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a st= oring node > becomes saturated is still under consideration). > > Would you please confirm this approach to the list? Then we may procee= d to refine > RPL accordingly for the next revision, -08, and to take this into accou= nt when > working the other tickets. > > Thanks, > > -Tim > > > roll issue tracker wrote: > =20 >> #26: Establishing downward routes in RPL : storing / non-storing / mix= ed modes >> of operation >> --------------------------------+-------------------------------------= ------ >> Reporter: jpv@=E2=80=A6 | Owner: wintert@=E2=80= =A6 >> Type: task | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------+-------------------------------------= ------ >> In the RPL-07 proposal the DAO mechanism described in Section 6 atte= mpts >> to support >> operation with a mix of storing nodes and non-storing nodes- where s= toring >> nodes may >> be provisioned with enough memory that they are capable to provision= hop- >> by-hop >> downward routes learned from DAO messages, and non-storing nodes wou= ld >> rely on source >> routing for downward routes. The present proposal describes operati= on in >> a mixed >> mode operation, with both storing and non-storing nodes, where each = node >> may >> provision downward routing state as according to its capabilities an= d >> largely >> independent of its position in the LLN topology. >> >> It has been noted that operation in the case where all nodes (except= >> possibly the >> root) are non-storing nodes allows for certain optimizations, and th= at the >> case where >> all nodes (except possibly leaves) are storing leads to other >> optimizations. It has >> also been noted that in the mixed cases the ability to provide an op= timal >> solution >> may break down. In particular there are concerns about the complexi= ty and >> correctness of mixed-mode operation as proposed by RPL-07. >> >> With this in mind, should RPL allow for operation in a mixture of st= oring >> /non-storing >> nodes? Or should each RPL Instance be exclusively operating in eith= er >> storing or >> non-storing mode (with the provision that operation as a leaf is alw= ays an >> option)? >> (The non-mixed case may imply some control flag or equivalent given = in the >> DIO to >> signal the mode of operation). >> >> Tim Winter. >> >> =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 --------------060008020300070702070909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 03/04/2010 6:09 PM, Tim Winter wrote: 
WG,

=46rom Anaheim and the list it seems that there is support to proceed on =
RPL with
storing and non-storing modes of operation, and not to elaborate mixed mo=
de operation
at this time (while allowing room for future specification of mixed mode)=
=2E

The summary approach would be to signal the mode of operation through the=
 DIO, that
all nodes MUST be capable to support a non-storing mode of operation, and=
 that nodes
who are incapable of acting as routers in a storing mode may participate =
in the DODAG
as hosts (leaves).  (The suitable behavior when a routing table in a stor=
ing node
becomes saturated is still under consideration).

Would you please confirm this approach to the list?  Then we may proceed =
to refine
RPL accordingly for the next revision, -08, and to take this into account=
 when
working the other tickets.

Thanks,

-Tim


roll issue tracker wrote:
  
#26: Establishing downward routes in RPL : storing / n=
on-storing / mixed modes
of operation
--------------------------------+----------------------------------------=
---
 Reporter:  jpv@=E2=80=A6               |       Owner:  wintert@=E2=80=A6=
     =20
     Type:  task                |      Status:  new           =20
 Priority:  major               |   Milestone:                =20
Component:  rpl                 |     Version:                =20
 Severity:  Active WG Document  |    Keywords:                =20
--------------------------------+----------------------------------------=
---
 In the RPL-07 proposal the DAO mechanism described in Section 6 attempts=

 to support
 operation with a mix of storing nodes and non-storing nodes- where stori=
ng
 nodes may
 be provisioned with enough memory that they are capable to provision hop=
-
 by-hop
 downward routes learned from DAO messages, and non-storing nodes would
 rely on source
 routing for downward routes.  The present proposal describes operation i=
n
 a mixed
 mode operation, with both storing and non-storing nodes, where each node=

 may
 provision downward routing state as according to its capabilities and
 largely
 independent of its position in the LLN topology.

 It has been noted that operation in the case where all nodes (except
 possibly the
 root) are non-storing nodes allows for certain optimizations, and that t=
he
 case where
 all nodes (except possibly leaves) are storing leads to other
 optimizations.  It has
 also been noted that in the mixed cases the ability to provide an optima=
l
 solution
 may break down.  In particular there are concerns about the complexity a=
nd
 correctness of mixed-mode operation as proposed by RPL-07.

 With this in mind, should RPL allow for operation in a mixture of storin=
g
 /non-storing
 nodes?  Or should each RPL Instance be exclusively operating in either
 storing or
 non-storing mode (with the provision that operation as a leaf is always =
an
 option)?
 (The non-mixed case may imply some control flag or equivalent given in t=
he
 DIO to
 signal the mode of operation).

 Tim Winter.

    
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------060008020300070702070909-- --------------ms030104020205020203080706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0 MDUxMTA1MTJaMCMGCSqGSIb3DQEJBDEWBBTQ1wdurqjoJKBRq+c12ZTIvDE9AjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAI9eOyjqLi0H1xfTJbdjpoJTEpxMQTZO8h16o+Jxjx/AbqY4AkbMPO6rRbs/rAoWfMZj JBAhfSU/5gcNHSHz6GiUUO2Ho47qNKL6jo88WxOuSYAiM1sPML6LiClrvMKfJdmOI9Y2le1Z bbgDsRIGExelwaLP9CDXwUayFyi3OmslehYX+LVBBNDcjU4qCgMlyQrw3MRo1dUdQCpicBdI n1oDAeSoFuGf5XnT287eTr871U9B7FoerGHGLl6xy0/K202onk0xgcKcMLspZQkpjzJgDOYs RqzEOBCOVdvuSHuTIgfLMdkobHqJhPEV+Cpcowqzy4T/tDjruMHOw75JqzkAAAAAAAA= --------------ms030104020205020203080706-- From richard.kelsey@ember.com Mon Apr 5 05:18:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A533F3A67D1 for ; Mon, 5 Apr 2010 05:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha+jRalRwc9V for ; Mon, 5 Apr 2010 05:18:11 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 039B33A68DF for ; Mon, 5 Apr 2010 05:18:10 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 08:21:07 -0400 Date: Mon, 05 Apr 2010 08:13:53 -0400 Message-Id: <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> (message from Philip Levis on Fri, 2 Apr 2010 17:31:24 -0700) From: Richard Kelsey References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> X-OriginalArrivalTime: 05 Apr 2010 12:21:07.0874 (UTC) FILETIME=[782D9820:01CAD4BA] Cc: roll@ietf.org Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 12:18:12 -0000 > From: Philip Levis > Date: Fri, 2 Apr 2010 17:31:24 -0700 > > On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote: > > > The DODAGID scopes the DODAG sequence. Without the DODAGID, you'd > > have to coordinate sequence numbers between all roots within the > > same instance. > > Makes sense, but 16 bytes seems like a lot of state for such as simple > problem... On the other hand, the one-byte RPLInstanceID seems like very little state for a harder problem. It is likely that the current P2P effort is going to force us to revisit how RPLInstanceID and DODAGID are used. If a switch needs to create a new DODAG in order to find a route to a lamp, where does it get an unused RPLInstanceID from? If P2P does turn out to need RPLInstanceIDs on the fly, we will need to figure out how they are obtained. I have some ideas about this, and I know that Pascal has thought about it as well. -Richard Kelsey From Ted.Humpal@jci.com Mon Apr 5 05:36:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F103A6965; Mon, 5 Apr 2010 05:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-JAS0Bu9huB; Mon, 5 Apr 2010 05:36:31 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id 6019E3A68DF; Mon, 5 Apr 2010 05:36:31 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKS7nZSzMXheP2F3Qtyg0LGGLU44AgBbzm@postini.com; Mon, 05 Apr 2010 05:36:30 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010040507362893-614313 ; Mon, 5 Apr 2010 07:36:28 -0500 In-Reply-To: <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey MIME-Version: 1.0 X-KeepSent: 7E4046A6:6329A463-862576FC:00447DE1; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Ted.Humpal@jci.com Message-ID: Date: Mon, 5 Apr 2010 07:36:19 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/05/2010 07:36:22 AM, Serialize complete at 04/05/2010 07:36:22 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 07:36:28 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 07:36:35 AM, Serialize complete at 04/05/2010 07:36:35 AM Content-Type: text/html; charset="US-ASCII" Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 12:36:32 -0000
With all of the discussions for P2P, and the need for the creation of new DODAG IDs to support this - are we considering
adding additional management roles to the  DHCP like server or designating a new device type? This new role will manage the DODAG IDs - such
as assignments - duplicate ID detection and deletion or renewal?

Ted


From: Richard Kelsey <richard.kelsey@ember.com>
To: Philip Levis <pal@cs.stanford.edu>
Cc: roll@ietf.org
Date: 04/05/2010 07:18 AM
Subject: Re: [Roll] DODAGID




> From: Philip Levis <pal@cs.stanford.edu>
> Date: Fri, 2 Apr 2010 17:31:24 -0700
>
> On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote:
>
> >  The DODAGID scopes the DODAG sequence.  Without the DODAGID, you'd
> > have to coordinate sequence numbers between all roots within the
> > same instance.
>
> Makes sense, but 16 bytes seems like a lot of state for such as simple
> problem...

On the other hand, the one-byte RPLInstanceID seems like
very little state for a harder problem.

It is likely that the current P2P effort is going to force
us to revisit how RPLInstanceID and DODAGID are used.  If a
switch needs to create a new DODAG in order to find a route
to a lamp, where does it get an unused RPLInstanceID from?
If P2P does turn out to need RPLInstanceIDs on the fly, we
will need to figure out how they are obtained.  I have some
ideas about this, and I know that Pascal has thought about
it as well.

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

From jhui@archrock.com Mon Apr 5 07:43:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC3B3A68D9 for ; Mon, 5 Apr 2010 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3BcOuHSadB7 for ; Mon, 5 Apr 2010 07:43:27 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6537A3A6938 for ; Mon, 5 Apr 2010 07:43:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8668EAF910; Mon, 5 Apr 2010 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec9670-c8fNc; Mon, 5 Apr 2010 07:43:19 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 5D730AF838; Mon, 5 Apr 2010 07:43:19 -0700 (PDT) Message-Id: <05569F31-C596-4161-B863-A477DEDF09D3@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F0A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 07:43:18 -0700 References: <8696DBDB-4ADE-46BE-A87C-690C2E288F1D@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923F0A@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 14:43:28 -0000 Hi Pascal, On Apr 4, 2010, at 12:02 PM, Pascal Thubert (pthubert) wrote: > The DODAGID is expected to be an IPv6 address of the root. The prefix > option normally indicates a prefix that can be reached via the > DODAGID. > > Interestingly, there is a strong need to also indicateand maintain > availability of a prefix that would be deployed over the DODAG, when > the > subnet spans the DAG (6LoWPAN & Autoconf). > A simple bit in the option could indicate that. In either case, the > prefix ends up in the RAs, either for not-onlink SLAAC, or for the > purpose of RFC 4191. I agree it would be nice to re-use bits wherever possible. Adding a single bit would work fine for SLAAC as long as we don't need to worry about graceful renumbering. If we do, then we need to start worrying about valid and preferred lifetimes, multiple prefixes, etc. In many applications, I think having a single prefix is enough and graceful renumbering is not an issue. But I can see other cases where this may be an issue. The usual tradeoffs apply :) -- Jonathan Hui From jhui@archrock.com Mon Apr 5 07:50:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1EB28C125 for ; Mon, 5 Apr 2010 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqqD4glsEiYy for ; Mon, 5 Apr 2010 07:50:36 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8839728C121 for ; Mon, 5 Apr 2010 07:50:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EE6C7AF90F; Mon, 5 Apr 2010 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7DKBT3NRAFw; Mon, 5 Apr 2010 07:50:30 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 53122AF838; Mon, 5 Apr 2010 07:50:30 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 07:50:29 -0700 References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 14:50:37 -0000 Hi Richard, On Apr 5, 2010, at 5:13 AM, Richard Kelsey wrote: >> From: Philip Levis >> Date: Fri, 2 Apr 2010 17:31:24 -0700 >> >> On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote: >> >>> The DODAGID scopes the DODAG sequence. Without the DODAGID, you'd >>> have to coordinate sequence numbers between all roots within the >>> same instance. >> >> Makes sense, but 16 bytes seems like a lot of state for such as >> simple >> problem... > > On the other hand, the one-byte RPLInstanceID seems like > very little state for a harder problem. > > It is likely that the current P2P effort is going to force > us to revisit how RPLInstanceID and DODAGID are used. If a > switch needs to create a new DODAG in order to find a route > to a lamp, where does it get an unused RPLInstanceID from? > If P2P does turn out to need RPLInstanceIDs on the fly, we > will need to figure out how they are obtained. I have some > ideas about this, and I know that Pascal has thought about > it as well. Yes, this was going to be my reply to Phil as well. Every new namespace is something that needs to have some additional mechanisms to handle. The original intention with the DODAG ID being the IP address of the root is that it avoids creating a new namespace. Though in some cases, there are ways to automatically manage the namespace without explicit user management or a stateful central server, but requires ways to avoid selecting duplicates when possible, detect duplicates when they occur, and recover when duplicates are detected. In the case of DODAGID/InstanceID, one way for the root to detect duplicates is by processing received DIO messages and seeing if the Sequence values makes sense. As you suggest, I'm sure there are other things you could do. -- Jonathan Hui From jhui@archrock.com Mon Apr 5 07:51:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B5F28C11B for ; Mon, 5 Apr 2010 07:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-q8kRMiCPbI for ; Mon, 5 Apr 2010 07:51:27 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id CD9883A69DB for ; Mon, 5 Apr 2010 07:51:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7A52EAF998; Mon, 5 Apr 2010 07:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3pNGR21sgKQ; Mon, 5 Apr 2010 07:51:20 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 7F287AF838; Mon, 5 Apr 2010 07:51:20 -0700 (PDT) Message-Id: <91079E78-18BE-4C26-81BD-5A3FE9747317@archrock.com> From: Jonathan Hui To: Tim Winter In-Reply-To: <4BB77631.20503@acm.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 07:51:20 -0700 References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 14:51:27 -0000 +1 -- Jonathan Hui On Apr 3, 2010, at 10:09 AM, Tim Winter wrote: > WG, > > =46rom Anaheim and the list it seems that there is support to proceed =20= > on RPL with > storing and non-storing modes of operation, and not to elaborate =20 > mixed mode operation > at this time (while allowing room for future specification of mixed =20= > mode). > > The summary approach would be to signal the mode of operation =20 > through the DIO, that > all nodes MUST be capable to support a non-storing mode of =20 > operation, and that nodes > who are incapable of acting as routers in a storing mode may =20 > participate in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a =20= > storing node > becomes saturated is still under consideration). > > Would you please confirm this approach to the list? Then we may =20 > proceed to refine > RPL accordingly for the next revision, -08, and to take this into =20 > account when > working the other tickets. > > Thanks, > > -Tim > > > roll issue tracker wrote: >> #26: Establishing downward routes in RPL : storing / non-storing / =20= >> mixed modes >> of operation >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: task | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> In the RPL-07 proposal the DAO mechanism described in Section 6 =20 >> attempts >> to support >> operation with a mix of storing nodes and non-storing nodes- where =20= >> storing >> nodes may >> be provisioned with enough memory that they are capable to =20 >> provision hop- >> by-hop >> downward routes learned from DAO messages, and non-storing nodes =20 >> would >> rely on source >> routing for downward routes. The present proposal describes =20 >> operation in >> a mixed >> mode operation, with both storing and non-storing nodes, where each =20= >> node >> may >> provision downward routing state as according to its capabilities and >> largely >> independent of its position in the LLN topology. >> >> It has been noted that operation in the case where all nodes (except >> possibly the >> root) are non-storing nodes allows for certain optimizations, and =20 >> that the >> case where >> all nodes (except possibly leaves) are storing leads to other >> optimizations. It has >> also been noted that in the mixed cases the ability to provide an =20 >> optimal >> solution >> may break down. In particular there are concerns about the =20 >> complexity and >> correctness of mixed-mode operation as proposed by RPL-07. >> >> With this in mind, should RPL allow for operation in a mixture of =20 >> storing >> /non-storing >> nodes? Or should each RPL Instance be exclusively operating in =20 >> either >> storing or >> non-storing mode (with the provision that operation as a leaf is =20 >> always an >> option)? >> (The non-mixed case may imply some control flag or equivalent given =20= >> in the >> DIO to >> signal the mode of operation). >> >> Tim Winter. >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From tzeta.tsao@ekasystems.com Mon Apr 5 08:03:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCC33A69DF for ; Mon, 5 Apr 2010 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq5YbNNzT1ow for ; Mon, 5 Apr 2010 08:03:37 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 2484C3A69DB for ; Mon, 5 Apr 2010 08:03:37 -0700 (PDT) Received: (qmail 79463 invoked from network); 5 Apr 2010 15:03:33 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 05 Apr 2010 08:03:32 -0700 PDT X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: ulxCouYVM1mzKSuu4iXKztS1JJ6v15JRbsdj0dncdO2l2vu.kss9ZDKl2jRy0BuMGfwccKe6acUrXwMLRMfFyZh98o_vQVB6OghFKseev1_x7sF.qU4Jz4o2SXhEomLaPgnd0Yzp31Hw89JzGYvjoLnPGiSWWS4mMMQzivopOUTKoOKYbLkEgSm1RdXCp9MHPFk00iXcNqv665Xzb1oL2TS02G6.FxveH5wAeZ.vVATxUAH2dGLb7n_mh6rf7E2e2Pyk_PC4LU8eFCLr7kv8mxD4radAN8bsUnabI23_Nygn00C59clz6Wpv2xmSmFOk.VOtAc7Uy9Yf5mkkKe5u9wRqpNnKXBSuqBCjnE7TF6uw0.lhPIiQ88583LNWX_APaeWbWOfywHg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB9FBC4.2040505@ekasystems.com> Date: Mon, 05 Apr 2010 11:03:32 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: roll@ietf.org References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> In-Reply-To: <4BB77631.20503@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 15:03:38 -0000 +1 Tim Winter wrote: > WG, > > From Anaheim and the list it seems that there is support to proceed on RPL with > storing and non-storing modes of operation, and not to elaborate mixed mode operation > at this time (while allowing room for future specification of mixed mode). > > The summary approach would be to signal the mode of operation through the DIO, that > all nodes MUST be capable to support a non-storing mode of operation, and that nodes > who are incapable of acting as routers in a storing mode may participate in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a storing node > becomes saturated is still under consideration). > > Would you please confirm this approach to the list? Then we may proceed to refine > RPL accordingly for the next revision, -08, and to take this into account when > working the other tickets. > > Thanks, > > -Tim > > > roll issue tracker wrote: >> #26: Establishing downward routes in RPL : storing / non-storing / mixed modes >> of operation >> --------------------------------+------------------------------------------- >> Reporter: jpv@… | Owner: wintert@… >> Type: task | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------+------------------------------------------- >> In the RPL-07 proposal the DAO mechanism described in Section 6 attempts >> to support >> operation with a mix of storing nodes and non-storing nodes- where storing >> nodes may >> be provisioned with enough memory that they are capable to provision hop- >> by-hop >> downward routes learned from DAO messages, and non-storing nodes would >> rely on source >> routing for downward routes. The present proposal describes operation in >> a mixed >> mode operation, with both storing and non-storing nodes, where each node >> may >> provision downward routing state as according to its capabilities and >> largely >> independent of its position in the LLN topology. >> >> It has been noted that operation in the case where all nodes (except >> possibly the >> root) are non-storing nodes allows for certain optimizations, and that the >> case where >> all nodes (except possibly leaves) are storing leads to other >> optimizations. It has >> also been noted that in the mixed cases the ability to provide an optimal >> solution >> may break down. In particular there are concerns about the complexity and >> correctness of mixed-mode operation as proposed by RPL-07. >> >> With this in mind, should RPL allow for operation in a mixture of storing >> /non-storing >> nodes? Or should each RPL Instance be exclusively operating in either >> storing or >> non-storing mode (with the provision that operation as a leaf is always an >> option)? >> (The non-mixed case may imply some control flag or equivalent given in the >> DIO to >> signal the mode of operation). >> >> Tim Winter. >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Mon Apr 5 08:09:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED813A696D; Mon, 5 Apr 2010 08:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBudU1NRUI1G; Mon, 5 Apr 2010 08:09:52 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 982313A69F4; Mon, 5 Apr 2010 08:09:50 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKS7n9PELBYguhHxycAa/iSvZXAeiOAbqE@postini.com; Mon, 05 Apr 2010 08:09:49 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010040510100379-641011 ; Mon, 5 Apr 2010 10:10:03 -0500 In-Reply-To: <4BB77631.20503@acm.org> References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> To: Tim Winter MIME-Version: 1.0 X-KeepSent: 1C631134:A4DA40CE-862576FC:004EF590; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 5 Apr 2010 10:09:37 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/05/2010 10:09:45 AM, Serialize complete at 04/05/2010 10:09:45 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 10:10:03 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 10:10:07 AM, Serialize complete at 04/05/2010 10:10:07 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 15:09:58 -0000
Hi Tim,

Interspersed "storing" nod= es were added (I believe) in RPL-2 as a means to placate us P2P folks with some means to move a packet laterally across a DAG efficiently.  Now we're looking at dropping this concept with no solid replacement defined.  Going back to "non-storing' nodes moves us back to pre-RPL2 levels.  Adding state to all nodes likely will saturate state tables.<= /font>

I don't think we should drop intersp= ersed storing nodes until we have a solid P2P replacement strategy.

Jerry




From: Tim Winter <wintert@acm.org>
To: roll@ietf.org
Date: 04/03/2010 12:09 PM
Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation




WG,

>From Anaheim and the list it seems that there is support to proceed on RPL with
storing and non-storing modes of operation, and not to elaborate mixed mode operation
at this time (while allowing room for future specification of mixed mode).<= br>
The summary approach would be to signal the mode of operation through the DIO, that
all nodes MUST be capable to support a non-storing mode of operation, and that nodes
who are incapable of acting as routers in a storing mode may participate in the DODAG
as hosts (leaves).  (The suitable behavior when a routing table in a storing node
becomes saturated is still under consideration).

Would you please confirm this approach to the list?  Then we may proce= ed to refine
RPL accordingly for the next revision, -08, and to take this into account when
working the other tickets.

Thanks,

-Tim


roll issue tracker wrote:
> #26: Establishing downward routes in RPL : storing / non-storing / mixed modes
> of operation
> --------------------------------+-------------------------------------= ------
>  Reporter:  jpv@…           &= nbsp;   |       Owner:  wintert@…     &n= bsp;
>      Type:  task                |      Status:  new            
>  Priority:  major               |   Milestone:                
> Component:  rpl                 |     Version:                
>  Severity:  Active WG Document  |    Keywords:                
> --------------------------------+-------------------------------------= ------
>  In the RPL-07 proposal the DAO mechanism described in Section 6 attempts
>  to support
>  operation with a mix of storing nodes and non-storing nodes- where storing
>  nodes may
>  be provisioned with enough memory that they are capable to provi= sion hop-
>  by-hop
>  downward routes learned from DAO messages, and non-storing nodes would
>  rely on source
>  routing for downward routes.  The present proposal describes operation in
>  a mixed
>  mode operation, with both storing and non-storing nodes, where each node
>  may
>  provision downward routing state as according to its capabilities and
>  largely
>  independent of its position in the LLN topology.
>
>  It has been noted that operation in the case where all nodes (except
>  possibly the
>  root) are non-storing nodes allows for certain optimizations, and that the
>  case where
>  all nodes (except possibly leaves) are storing leads to other
>  optimizations.  It has
>  also been noted that in the mixed cases the ability to provide an optimal
>  solution
>  may break down.  In particular there are concerns about the complexity and
>  correctness of mixed-mode operation as proposed by RPL-07.
>
>  With this in mind, should RPL allow for operation in a mixture of storing
>  /non-storing
>  nodes?  Or should each RPL Instance be exclusively operating in either
>  storing or
>  non-storing mode (with the provision that operation as a leaf is always an
>  option)?
>  (The non-mixed case may imply some control flag or equivalent given in the
>  DIO to
>  signal the mode of operation).
>
>  Tim Winter.
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From jhui@archrock.com Mon Apr 5 08:21:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE5F3A69F3; Mon, 5 Apr 2010 08:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCPiRhyW6OY7; Mon, 5 Apr 2010 08:20:57 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3892228C122; Mon, 5 Apr 2010 08:20:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B7D5DAF95C; Mon, 5 Apr 2010 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7efNGGgIZ0oi; Mon, 5 Apr 2010 08:20:40 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id B5897AF835; Mon, 5 Apr 2010 08:20:40 -0700 (PDT) Message-Id: From: Jonathan Hui To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 08:20:40 -0700 References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 15:21:04 -0000 Hi Jerry, Within the RPL WG document, the intent to support mixed-mode has been =20= there since the beginning in rpl-00. The issue here is whether or not =20= we are going to address piecewise source routing and the necessary =20 mechanisms to build up distributed state for piecewise source routes =20 at this time. Separate is the issue of allowing anode to store its own source routes =20= for packets that it sources. This is different from piecewise source =20= routing where an intermediate node may need to remove an existing =20 source route header and replace it with a new one. I don't think =20 there is any objection for a node to store its own source route for =20 packets that it sources at this time. So do you really need piecewise source routing? Or is some form of =20 source routing good enough? -- Jonathan Hui On Apr 5, 2010, at 8:09 AM, Jerald.P.Martocci@jci.com wrote: > > Hi Tim, > > Interspersed "storing" nodes were added (I believe) in RPL-2 as a =20 > means to placate us P2P folks with some means to move a packet =20 > laterally across a DAG efficiently. Now we're looking at dropping =20 > this concept with no solid replacement defined. Going back to "non-=20= > storing' nodes moves us back to pre-RPL2 levels. Adding state to =20 > all nodes likely will saturate state tables. > > I don't think we should drop interspersed storing nodes until we =20 > have a solid P2P replacement strategy. > > Jerry > > > > > From: > Tim Winter > To: > roll@ietf.org > Date: > 04/03/2010 12:09 PM > Subject: > Re: [Roll] [roll] #26: Establishing downward routes in RPL : =20 > storing / non-storing / mixed modes of operation > > > > > WG, > > =46rom Anaheim and the list it seems that there is support to proceed =20= > on RPL with > storing and non-storing modes of operation, and not to elaborate =20 > mixed mode operation > at this time (while allowing room for future specification of mixed =20= > mode). > > The summary approach would be to signal the mode of operation =20 > through the DIO, that > all nodes MUST be capable to support a non-storing mode of =20 > operation, and that nodes > who are incapable of acting as routers in a storing mode may =20 > participate in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a =20= > storing node > becomes saturated is still under consideration). > > Would you please confirm this approach to the list? Then we may =20 > proceed to refine > RPL accordingly for the next revision, -08, and to take this into =20 > account when > working the other tickets. > > Thanks, > > -Tim > > > roll issue tracker wrote: > > #26: Establishing downward routes in RPL : storing / non-storing / =20= > mixed modes > > of operation > > --------------------------------=20 > +------------------------------------------- > > Reporter: jpv@=85 | Owner: wintert@=85 > > Type: task | Status: new > > Priority: major | Milestone: > > Component: rpl | Version: > > Severity: Active WG Document | Keywords: > > --------------------------------=20 > +------------------------------------------- > > In the RPL-07 proposal the DAO mechanism described in Section 6 =20 > attempts > > to support > > operation with a mix of storing nodes and non-storing nodes- =20 > where storing > > nodes may > > be provisioned with enough memory that they are capable to =20 > provision hop- > > by-hop > > downward routes learned from DAO messages, and non-storing nodes =20= > would > > rely on source > > routing for downward routes. The present proposal describes =20 > operation in > > a mixed > > mode operation, with both storing and non-storing nodes, where =20 > each node > > may > > provision downward routing state as according to its capabilities =20= > and > > largely > > independent of its position in the LLN topology. > > > > It has been noted that operation in the case where all nodes =20 > (except > > possibly the > > root) are non-storing nodes allows for certain optimizations, and =20= > that the > > case where > > all nodes (except possibly leaves) are storing leads to other > > optimizations. It has > > also been noted that in the mixed cases the ability to provide an =20= > optimal > > solution > > may break down. In particular there are concerns about the =20 > complexity and > > correctness of mixed-mode operation as proposed by RPL-07. > > > > With this in mind, should RPL allow for operation in a mixture of =20= > storing > > /non-storing > > nodes? Or should each RPL Instance be exclusively operating in =20 > either > > storing or > > non-storing mode (with the provision that operation as a leaf is =20= > always an > > option)? > > (The non-mixed case may imply some control flag or equivalent =20 > given in the > > DIO to > > signal the mode of operation). > > > > Tim Winter. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Mon Apr 5 08:44:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C773828C162; Mon, 5 Apr 2010 08:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zmpqw5dkY87; Mon, 5 Apr 2010 08:44:08 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id 9C9F128C160; Mon, 5 Apr 2010 08:44:06 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKS7oFQ811tRVyALx101YUFdXmntl/L+Ik@postini.com; Mon, 05 Apr 2010 08:44:05 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010040510440399-650680 ; Mon, 5 Apr 2010 10:44:03 -0500 In-Reply-To: References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> To: Jonathan Hui MIME-Version: 1.0 X-KeepSent: 4C6D669B:8E628DBB-862576FC:0055A1C2; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 5 Apr 2010 10:43:54 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/05/2010 10:43:58 AM, Serialize complete at 04/05/2010 10:43:58 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 10:44:03 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/05/2010 10:44:10 AM, Serialize complete at 04/05/2010 10:44:10 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 15:44:18 -0000

Jonathan,

Good point.  To me piecewise so= urce routing is an implementation decision.  While it may be more efficient, as was noted in Anaheim, it's way more complex.  

I'm satisfied for your alternate pro= posal that allows a node optionally to keep route info.  I didn't think that's what Tim was asking us to vote on.  I thought the vote was all or nothing.

To try and be clear, I would like to see 'non-storing' nodes except for the LBR which MUST keep downward paths to all nodes in the DAG.  Other nodes could then optionally keep state as needed other nodes of interest.

Jerry




From: Jonathan Hui <jhui@archrock.com&g= t;
To: Jerald.P.Martocci@jci.com
Cc: Tim Winter <wintert@acm.org>, roll@ietf.org, roll-bounces@ietf.org
Date: 04/05/2010 10:20 AM
Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation





Hi Jerry,

Within the RPL WG document, the intent to support mixed-mode has been  = ;
there since the beginning in rpl-00.  The issue here is whether or not  
we are going to address piecewise source routing and the necessary   mechanisms to build up distributed state for piecewise source routes  =
at this time.

Separate is the issue of allowing anode to store its own source routes  
for packets that it sources.  This is different from piecewise source  
routing where an intermediate node may need to remove an existing  
source route header and replace it with a new one.  I don't think  
there is any objection for a node to store its own source route for  <= br> packets that it sources at this time.

So do you really need piecewise source routing?  Or is some form of  
source routing good enough?

--
Jonathan Hui

On Apr 5, 2010, at 8:09 AM, Jerald.P.Martocci@jci.com wrote:

>
> Hi Tim,
>
> Interspersed "storing" nodes were added (I believe) in RPL-2 as a  
> means to placate us P2P folks with some means to move a packet  <= br> > laterally across a DAG efficiently.  Now we're looking at dropping  
> this concept with no solid replacement defined.  Going back to "non-
> storing' nodes moves us back to pre-RPL2 levels.  Adding state to  
> all nodes likely will saturate state tables.
>
> I don't think we should drop interspersed storing nodes until we  = ;
> have a solid P2P replacement strategy.
>
> Jerry
>
>
>
>
> From:
> Tim Winter <wintert@acm.org>
> To:
> roll@ietf.org
> Date:
> 04/03/2010 12:09 PM
> Subject:
> Re: [Roll] [roll] #26: Establishing downward routes in RPL :  
> storing / non-storing / mixed modes of operation
>
>
>
>
> WG,
>
> From Anaheim and the list it seems that there is support to proceed  
> on RPL with
> storing and non-storing modes of operation, and not to elaborate  = ;
> mixed mode operation
> at this time (while allowing room for future specification of mixed  
> mode).
>
> The summary approach would be to signal the mode of operation   > through the DIO, that
> all nodes MUST be capable to support a non-storing mode of  
> operation, and that nodes
> who are incapable of acting as routers in a storing mode may  
> participate in the DODAG
> as hosts (leaves).  (The suitable behavior when a routing table in a  
> storing node
> becomes saturated is still under consideration).
>
> Would you please confirm this approach to the list?  Then we may  
> proceed to refine
> RPL accordingly for the next revision, -08, and to take this into  
> account when
> working the other tickets.
>
> Thanks,
>
> -Tim
>
>
> roll issue tracker wrote:
> > #26: Establishing downward routes in RPL : storing / non-storing /  
> mixed modes
> > of operation
> > --------------------------------
> +-------------------------------------------
> >  Reporter:  jpv@…         &nb= sp;     |       Owner:  wintert@…
> >      Type:  task                |      Status:  new
> >  Priority:  major               |   Milestone:
> > Component:  rpl                 |     Version:
> >  Severity:  Active WG Document  |    Key= words:
> > --------------------------------
> +-------------------------------------------
> >  In the RPL-07 proposal the DAO mechanism described in Secti= on 6  
> attempts
> >  to support
> >  operation with a mix of storing nodes and non-storing nodes-  
> where storing
> >  nodes may
> >  be provisioned with enough memory that they are capable to  
> provision hop-
> >  by-hop
> >  downward routes learned from DAO messages, and non-storing nodes  
> would
> >  rely on source
> >  routing for downward routes.  The present proposal describes  
> operation in
> >  a mixed
> >  mode operation, with both storing and non-storing nodes, where  
> each node
> >  may
> >  provision downward routing state as according to its capabi= lities  
> and
> >  largely
> >  independent of its position in the LLN topology.
> >
> >  It has been noted that operation in the case where all nodes  
> (except
> >  possibly the
> >  root) are non-storing nodes allows for certain optimization= s, and  
> that the
> >  case where
> >  all nodes (except possibly leaves) are storing leads to other
> >  optimizations.  It has
> >  also been noted that in the mixed cases the ability to provide an  
> optimal
> >  solution
> >  may break down.  In particular there are concerns about the  
> complexity and
> >  correctness of mixed-mode operation as proposed by RPL-07.<= br> > >
> >  With this in mind, should RPL allow for operation in a mixture of  
> storing
> >  /non-storing
> >  nodes?  Or should each RPL Instance be exclusively operating in  
> either
> >  storing or
> >  non-storing mode (with the provision that operation as a leaf is  
> always an
> >  option)?
> >  (The non-mixed case may imply some control flag or equivale= nt  
> given in the
> >  DIO to
> >  signal the mode of operation).
> >
> >  Tim Winter.
> >
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/roll
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/roll

From pal@cs.stanford.edu Mon Apr 5 10:11:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84AC3A686C for ; Mon, 5 Apr 2010 10:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNrjpCU-62ry for ; Mon, 5 Apr 2010 10:11:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 513503A68A4 for ; Mon, 5 Apr 2010 10:11:50 -0700 (PDT) Received: from [172.27.75.96] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nypq0-0003Wf-CB; Mon, 05 Apr 2010 10:11:48 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> Date: Mon, 5 Apr 2010 10:11:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A78CB47-A1D8-4C8D-9DB4-66DBC189B3C1@cs.stanford.edu> References: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 17:11:58 -0000 On Apr 5, 2010, at 2:43 AM, Pascal Thubert (pthubert) wrote: > JP: >=20 > I agree with allowing options and eventually suboptions (since we > migrated out of ND messages, the so-called suboptions are really > options, we need to fix that) in all RPL messages. >=20 > This does not mean that everything has to be options. Same goes for = DIO, > would you make everything in the base header an option? >=20 > OTOH, in the current spec, the target in a DAO is not an option. This > prevents from packing multiple targets in a single DAO, which is = really > sad in the stateful mode.=20 >=20 > I agree with good sense as long as it is really common.=20 Sure -- but there is zero evidence that these filters or flags that are = in your proposal are very common fields that will almost-always be = present or really commonly used. Seems like it increases complexity for = a *possible* need. I think the possibility is great enough to call for = including the suboption, but not so great to require it in all messages. Phil= From pal@cs.stanford.edu Mon Apr 5 10:13:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD733A6897 for ; Mon, 5 Apr 2010 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIMs+zPipzEK for ; Mon, 5 Apr 2010 10:13:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id C5D093A67EF for ; Mon, 5 Apr 2010 10:13:55 -0700 (PDT) Received: from [172.27.75.96] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nyps2-0003ib-5K; Mon, 05 Apr 2010 10:13:54 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> Date: Mon, 5 Apr 2010 10:13:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 17:13:57 -0000 On Apr 5, 2010, at 1:41 AM, Pascal Thubert (pthubert) wrote: > All/ >=20 > I agree with the RPL standard options, which by the way are TLVs of > sort. > Does not mean that we have to define a single option so far, but maybe > allow for padding. > Still, Phil's point stands. There are things that are needed most time > and even options is overkill. > In particular the instance ID, and probably a few flags like Phoebus > points out. > What about: Pascal, Can you outline what you see as the benefits/drawbacks/tradeoffs in = comparison to my proposal? My two cents:=20 1) The C flag seems strange -- what does it mean? When would a DIS = indicate an inconsistency?=20 2) The approach requires *all* DIS messages to contain this information, = which seems wasteful. My intuition is that support for DIS information = filters ought to be a MAY, as it's an optimization that might be very = useful or might be irrelevant. If the former, implementations will = include it and later down the line it can become a SHOULD or MUST. If = the latter, no-one will use it and it can die out. 3) Why the O-flag? This is what unicast DIS messages are for. Phil= From trac@tools.ietf.org Mon Apr 5 10:14:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9EC3A69A4 for ; Mon, 5 Apr 2010 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.41 X-Spam-Level: X-Spam-Status: No, score=-101.41 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esc01BEKKRix for ; Mon, 5 Apr 2010 10:14:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C08153A686C for ; Mon, 5 Apr 2010 10:14:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NypsN-00046G-O7; Mon, 05 Apr 2010 10:14:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: jhui@archrock.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 05 Apr 2010 17:14:15 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://rsync.tools.ietf.org/wg/roll/trac/ticket/33 Message-ID: <055.1156abc194de723b97c62420ddb8fc0f@tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #33: Source Route Failure ticket X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:14:21 -0000 #33: Source Route Failure ticket -----------------------------------+---------------------------------------- Reporter: jpv@… | Owner: jhui@… Type: defect | Status: new Priority: major | Milestone: Component: building-routing-reqs | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- RPL-07 currently does not make any attempt to specify what actions a non- storing node should take when using source route information fails. Some options are: 1) Drop the packet and nothing else. 2) Drop the packet and send back an ICMPv6 error. 3) Drop the packet and send back a RPL error. 4) Backtrack by returning the packet towards the root and indicating where the route failed. On a separate dimension, it is important to note that the above options are not mutually exclusive and we have the following options: 1) Specify only a single action when source route failures occur. 2) Provide an option that can select which action to take on a per- instance, per-dag, or per-packet basis. -- Ticket URL: roll From pthubert@cisco.com Mon Apr 5 11:06:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F47A3A6A15 for ; Mon, 5 Apr 2010 11:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.233 X-Spam-Level: X-Spam-Status: No, score=-8.233 tagged_above=-999 required=5 tests=[AWL=2.366, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osbL2eztsRBH for ; Mon, 5 Apr 2010 11:06:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 363F23A6A16 for ; Mon, 5 Apr 2010 11:06:47 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGbDuUurR7Hu/2dsb2JhbACbS3GeIpgVhQcEjio X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="509585542" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2010 18:06:45 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o35I6id5012108; Mon, 5 Apr 2010 18:06:45 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 20:06:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 20:06:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> In-Reply-To: <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #29: DIS packet format Thread-Index: AcrU42P3m1i1nZXLSxCr4FCpL3vtPwABnRYA References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 05 Apr 2010 18:06:44.0072 (UTC) FILETIME=[BFEA4E80:01CAD4EA] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:06:49 -0000 Hi Phil: Both flags comes from Phoebus' mail. And I tend to agree with him in both cases. With the current draft, a DIS from a node forces the router that receives it to reset its trickle timer. Yet it makes sense for a node to poll its router to make sure it is lively, and that does not mean inconsistency. Thus the C flag to indicate that it's just a check, no worries. About the O flag, it seems that today we confuse the method (mcast vs. unicast) with the goal (get parameters or not). I do not think that such a semantical stretch will serve us in the long term. Better call a cat a cat, wouldn't you think? Let's see what others think about what should be in the base DIS and what should be in a new option. Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, April 05, 2010 7:14 PM > To: Pascal Thubert (pthubert) > Cc: phoebus@ieee.org; roll@ietf.org > Subject: Re: [Roll] [roll] #29: DIS packet format >=20 >=20 > On Apr 5, 2010, at 1:41 AM, Pascal Thubert (pthubert) wrote: >=20 > > All/ > > > > I agree with the RPL standard options, which by the way are TLVs of > > sort. > > Does not mean that we have to define a single option so far, but maybe > > allow for padding. > > Still, Phil's point stands. There are things that are needed most time > > and even options is overkill. > > In particular the instance ID, and probably a few flags like Phoebus > > points out. > > What about: >=20 > Pascal, >=20 > Can you outline what you see as the benefits/drawbacks/tradeoffs in > comparison to my proposal? >=20 > My two cents: >=20 > 1) The C flag seems strange -- what does it mean? When would a DIS indicate > an inconsistency? >=20 > 2) The approach requires *all* DIS messages to contain this information, > which seems wasteful. My intuition is that support for DIS information filters > ought to be a MAY, as it's an optimization that might be very useful or might > be irrelevant. If the former, implementations will include it and later down > the line it can become a SHOULD or MUST. If the latter, no-one will use it and > it can die out. >=20 > 3) Why the O-flag? This is what unicast DIS messages are for. >=20 > Phil From pthubert@cisco.com Mon Apr 5 11:22:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCED28B797; Mon, 5 Apr 2010 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7JkBDxitrxP; Mon, 5 Apr 2010 11:22:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 116703A659A; Mon, 5 Apr 2010 11:22:18 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksCAJ/HuUuQ/uCWe2dsb2JhbACBP5oMFQEBCwsiBhyeNpgYglSCMwQ X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208,217";a="5199240" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Apr 2010 17:46:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35IM3tS016769; Mon, 5 Apr 2010 18:22:03 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 20:22:02 +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_01CAD4EC.E357AD49" Date: Mon, 5 Apr 2010 20:21:57 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923FF1@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DODAGID Thread-Index: AcrUvLJxlmrHmW0kQrK8lThXBciGeAALqHnw References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com><9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu><87k4sm2j26.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: , "Richard Kelsey" X-OriginalArrivalTime: 05 Apr 2010 18:22:02.0863 (UTC) FILETIME=[E38EAFF0:01CAD4EC] Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:22:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD4EC.E357AD49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard and all: =20 One thing that was discussed in the corridor was the need to be able to autoconf an instance ID for P2P. The way to do that would be that the namespace would be local to the node that autoconfigures the instanceID. =20 For those local instanceID, what would then uniquely identify the instance would be the tuple (DODAGID, instanceID). A diect consequence is that there can be only one root to the DAG, but that's OK for P2P. =20 One will note that the instance ID must also be present in the packets for loop detection. This is not really a problem for P2P if the DODAGID is the address of one of the endpoints anyway. =20 Please find some proposed text: =20 " 3.1.1. Topology Identifiers =20 RPL uses four identifiers to track and control the topology: =20 o The first is a RPLInstanceID that is used to identify instances. A RPLInstanceID can be either local or global. =20 * A global RPLInstanceID is a network wide unique identifier that enables to group a number of DODAGs with a common Goal and Objective Function into a same instance. =20 * A local RPLInstanceID is associated to a DODAGID to identify a DODAG for use in P2P communication where the DODAGID is one of the endpoints of the communication. =20 A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different OFs and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance =20 ... =20 " Then a section on the instance ID " RPL Instance ID =20 A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms for allocating and provisioning global RPLInstanceID are out of scope for this document. There can be up to 128 global instance in the whole network, and up 64 local instances per DODAGID. =20 A global RPLinstanceID is encoded in a RPLinstanceID field as follows: =20 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLinstanceID in 0..127 +-+-+-+-+-+-+-+-+ | =20 Figure 3: RPL Instance ID field format for global instances =20 A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it must be unique for that DODAGID. In that case, the DODAGID MUST be a valid address of the root that is used as an endpoint of all communications within that instance. =20 A local RPLinstanceID is encoded in a RPLinstanceID field as follows: =20 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|D| ID | Local RPLInstanceID in 0..63 +-+-+-+-+-+-+-+-+ | =20 Figure 4: RPL Instance ID field format for local instances =20 The D flag in a Local RPLInstanceID is always set to 0 in RPL control messages. It is used in data packets to indicate whether the DODAGID is the source or the destination of the packet. If the D flag is set to 1 then the DODAGID MUST be the destination of the IPv6 packet.If the D flag is reset then the DODAGID MUST be the source of the IPv6 packet. =20 =20 " =20 Advice? =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ted.Humpal@jci.com Sent: Monday, April 05, 2010 2:36 PM To: Richard Kelsey Cc: roll-bounces@ietf.org; roll@ietf.org Subject: Re: [Roll] DODAGID =20 With all of the discussions for P2P, and the need for the creation of new DODAG IDs to support this - are we considering=20 adding additional management roles to the DHCP like server or designating a new device type? This new role will manage the DODAG IDs - such=20 as assignments - duplicate ID detection and deletion or renewal?=20 Ted=20 From:=20 Richard Kelsey =20 To:=20 Philip Levis =20 Cc:=20 roll@ietf.org=20 Date:=20 04/05/2010 07:18 AM=20 Subject:=20 Re: [Roll] DODAGID =20 ________________________________ > From: Philip Levis > Date: Fri, 2 Apr 2010 17:31:24 -0700 >=20 > On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote: >=20 > > The DODAGID scopes the DODAG sequence. Without the DODAGID, you'd > > have to coordinate sequence numbers between all roots within the > > same instance. >=20 > Makes sense, but 16 bytes seems like a lot of state for such as simple > problem... On the other hand, the one-byte RPLInstanceID seems like very little state for a harder problem. It is likely that the current P2P effort is going to force us to revisit how RPLInstanceID and DODAGID are used. If a switch needs to create a new DODAG in order to find a route to a lamp, where does it get an unused RPLInstanceID from? If P2P does turn out to need RPLInstanceIDs on the fly, we will need to figure out how they are obtained. I have some ideas about this, and I know that Pascal has thought about it as well. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAD4EC.E357AD49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard and all:

 

One thing that was discussed in the corridor was the need to be able = to autoconf an instance ID for P2P.

The way to do that would be that the namespace would be local to the = node that autoconfigures the instanceID.

 

For those local instanceID, what would then uniquely identify the = instance would be the tuple (DODAGID, instanceID). A diect consequence = is that there can be only one root to the DAG, but that’s OK for = P2P.

 

One will note that the instance ID must also be present in the = packets for loop detection. This is not really a problem for P2P if the = DODAGID is the address of one of the endpoints = anyway.

 

Please find some proposed text:

 

“

3.1.1.  Topology =
Identifiers
 
  =
 RPL uses four identifiers to track and control the =
topology:
 
   =
o  The first is a RPLInstanceID that is used to identify =
instances.
      A =
RPLInstanceID can be either local or =
global.
 
  &nbs=
p;   *  A global RPLInstanceID is a network wide unique =
identifier that
 =
        enables to group a =
number of DODAGs with a common Goal =
and
        =
 Objective Function into a same =
instance.
 
  &n=
bsp;   *  A local RPLInstanceID is associated to a =
DODAGID to identify =
a
         =
DODAG for use in P2P communication where the DODAGID is one =
of
         =
the endpoints of the =
communication.
 
 &nb=
sp;    A network may have multiple RPLInstanceIDs, each =
of which defines
      an =
independent set of DODAGs, which may be optimized for =
different
      OFs and/or =
applications.  The set of DODAGs identified by =
a
      RPLInstanceID is =
called a RPL =
Instance
 
…
 

“

Then a section on the instance ID

“

RPL Instance = ID

 

   A = global RPLInstanceID MUST be unique to the whole LLN.  = Mechanisms

   for = allocating and provisioning global RPLInstanceID are out = of

   scope = for this document.  There can be up to 128 global instance = in

  the = whole network, and up 64 local instances per = DODAGID.

 

   A = global RPLinstanceID is encoded in a RPLinstanceID field = as

   = follows:

 

        0 1 2 3 4 5 6 = 7

       = +-+-+-+-+-+-+-+-+

       |0|     = ID      |  Global RPLinstanceID in = 0..127

       = +-+-+-+-+-+-+-+-+

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

 

        Figure 3: RPL Instance = ID field format for global instances

 

   A = local RPLInstanceID is autoconfigured by the node that owns = the

   = DODAGID and it must be unique for that DODAGID.  In that case, = the

   = DODAGID MUST be a valid address of the root that is used as = an

   = endpoint of all communications within that = instance.

 

   A = local RPLinstanceID is encoded in a RPLinstanceID field as = follows:

 

        0 1 2 3 4 5 6 = 7

       = +-+-+-+-+-+-+-+-+

       |1|D|   = ID      |  Local RPLInstanceID in = 0..63

       = +-+-+-+-+-+-+-+-+         &n= bsp;    =             &= nbsp;           &n= bsp;     |

 

        Figure 4: RPL Instance = ID field format for local instances

 

   The D = flag in a Local RPLInstanceID is always set to 0 in RPL = control

   = messages.  It is used in data packets to indicate whether the = DODAGID

   is the = source or the destination of the packet.  If the D flag is = set

   to 1 = then the DODAGID MUST be the destination of the IPv6 = packet.If

   the D = flag is reset then the DODAGID MUST be the source of the = IPv6

   = packet.

 

 

”

 

Advice?

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Ted.Humpal@jci.com
Sent: Monday, April 05, 2010 2:36 = PM
To: Richard Kelsey
Cc: roll-bounces@ietf.org; = roll@ietf.org
Subject: Re: [Roll] = DODAGID

 


With all of = the discussions for P2P, and the need for the creation of new DODAG IDs = to support this - are we considering
adding = additional management roles to the  DHCP like server or designating = a new device type? This new role will manage the DODAG IDs - such =
as = assignments - duplicate ID detection and deletion or renewal? =

Ted =

= From:

Richard = Kelsey <richard.kelsey@ember.com> =

= To:

Philip Levis = <pal@cs.stanford.edu>

= Cc:

roll@ietf.org<= /span>

= Date:

04/05/2010 = 07:18 AM

= Subject:

Re: [Roll] = DODAGID

 




> From: Philip Levis <pal@cs.stanford.edu>
> Date: Fri, 2 Apr 2010 17:31:24 -0700
> =
> On Apr 2, 2010, at 10:06 AM, Jonathan Hui = wrote:
>
> >  The DODAGID scopes = the DODAG sequence.  Without the DODAGID, you'd
> = > have to coordinate sequence numbers between all roots within = the
> > same instance.
> =
> Makes sense, but 16 bytes seems like a lot of state = for such as simple
> problem...

On the = other hand, the one-byte RPLInstanceID seems like
very = little state for a harder problem.

It is likely that the = current P2P effort is going to force
us to revisit how = RPLInstanceID and DODAGID are used.  If a
switch needs = to create a new DODAG in order to find a route
to a lamp, = where does it get an unused RPLInstanceID from?
If P2P does = turn out to need RPLInstanceIDs on the fly, we
will need to = figure out how they are obtained.  I have some
ideas = about this, and I know that Pascal has thought about
it as = well.

              =                 -Richard = Kelsey
_______________________________________________Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CAD4EC.E357AD49-- From pthubert@cisco.com Mon Apr 5 11:30:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F374328C0FD for ; Mon, 5 Apr 2010 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[AWL=2.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANgh+b4nhhXV for ; Mon, 5 Apr 2010 11:30:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6AF313A6985 for ; Mon, 5 Apr 2010 11:30:26 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAbJuUurR7H+/2dsb2JhbACbS3GeL5gZhQcE X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="178086008" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2010 18:30:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35IULAv014178; Mon, 5 Apr 2010 18:30:23 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 20:30:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 20:30:16 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923FF2@XMB-AMS-107.cisco.com> In-Reply-To: <05569F31-C596-4161-B863-A477DEDF09D3@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DODAGID Thread-Index: AcrUzl1SRzXnI9ndTFqXXxMY/N0cPQAHr/xg References: <8696DBDB-4ADE-46BE-A87C-690C2E288F1D@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923F0A@XMB-AMS-107.cisco.com> <05569F31-C596-4161-B863-A477DEDF09D3@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 05 Apr 2010 18:30:22.0753 (UTC) FILETIME=[0D83D910:01CAD4EE] Cc: ROLL WG , Erik Nordmark Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:30:33 -0000 Hi Jonathan: Good point. Please note that the DAG Destination Prefix option is inspired from ND, and in particular it has a lifetime.=20 Also that there can be multiple such options in a DIO. So I think that it is possible to make a renumbering though the whole process is largely out of scope for RPL. Do I understand that you support the idea? Please find some proposed text that goes with it: " xxx Destination Prefix The Destination Prefix option format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | option Length |R|rsv|Prf| rsv = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: DAG Destination Prefix The Destination Prefix option is used in DIO to indicate that connectivity to the specified destination prefix is available from the DODAG root. A RA (R) flag indicates whether the DODAG is part of the subnet where the prefix is deployed and influences the way the prefix may be presented to the hosts by RPL routers in RA messages. This may be useful in cases where more than one LBR is operating within the LLN and offering connectivity to different administrative domains, e.g. a home network and a utility network. In such cases, upon observing the Destination Prefixes offered by a particular DODAG, a node MAY decide to join multiple DODAGs in support of a particular application. The option Length is coded as the length of the option in octets, excluding the Type and Length fields. Prf is the Route Preference as in [RFC4191]. The reserved fields MUST be set to zero on transmission and MUST be ignored on receipt. If the R flag is set, then the DODAG is part of the subnet where the prefix is deployed. The prefix may be advertised as not onlink in RA messages for the purpose address autoconfiguration. If the R flag is reset, then the prefix is exterior to the DODAG yet may be reached via the root. The prefix may be advertised in RA messages for communicating default router preferences and more-specific routes from routers to hosts as prescribed in [RFC4191] with the preference in the Prf field. The Prefix Lifetime is a 32-bit unsigned integer representing the length of time in seconds (relative to the time the packet is sent) that the Destination Prefix is valid for route determination. The lifetime is initially set by the node that owns the prefix and denotes the valid lifetime for that prefix (similar to AdvValidLifetime [RFC4861]). The value might be reduced by the originator and/or en-route nodes that will not provide connectivity for the whole valid lifetime. A value of all one bits (0xFFFFFFFF) represents infinity. A value of all zero bits (0x00000000) indicates a loss of reachability. The Prefix Length is an 8-bit unsigned integer that indicates the number of leading bits in the destination prefix. The Destination Prefix contains Prefix Length significant bits of the destination prefix. The remaining bits of the Destination Prefix, as required to complete the trailing octet, are set to 0. In the event that a DIO message may need to specify connectivity to more than one destination, the Destination Prefix option may be repeated. " What do you think? Pascal > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: Monday, April 05, 2010 4:43 PM > To: Pascal Thubert (pthubert) > Cc: JeongGil Ko (John); Philip Levis; ROLL WG > Subject: Re: [Roll] DODAGID >=20 >=20 > Hi Pascal, >=20 > On Apr 4, 2010, at 12:02 PM, Pascal Thubert (pthubert) wrote: >=20 > > The DODAGID is expected to be an IPv6 address of the root. The prefix > > option normally indicates a prefix that can be reached via the > > DODAGID. > > > > Interestingly, there is a strong need to also indicateand maintain > > availability of a prefix that would be deployed over the DODAG, when > > the subnet spans the DAG (6LoWPAN & Autoconf). > > A simple bit in the option could indicate that. In either case, the > > prefix ends up in the RAs, either for not-onlink SLAAC, or for the > > purpose of RFC 4191. >=20 > I agree it would be nice to re-use bits wherever possible. Adding a single bit > would work fine for SLAAC as long as we don't need to worry about graceful > renumbering. If we do, then we need to start worrying about valid and > preferred lifetimes, multiple prefixes, etc. In many applications, I think > having a single prefix is enough and graceful renumbering is not an issue. But > I can see other cases where this may be an issue. The usual tradeoffs apply :) >=20 > -- > Jonathan Hui From pthubert@cisco.com Mon Apr 5 11:31:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5502B28C11A for ; Mon, 5 Apr 2010 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.577 X-Spam-Level: X-Spam-Status: No, score=-8.577 tagged_above=-999 required=5 tests=[AWL=2.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72jwTvxm5OpQ for ; Mon, 5 Apr 2010 11:31:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A400B28C108 for ; Mon, 5 Apr 2010 11:31:48 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="314593149" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Apr 2010 18:31:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35IVkJZ015302; Mon, 5 Apr 2010 18:31:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 20:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 20:31:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923FF3@XMB-AMS-107.cisco.com> In-Reply-To: <201004051204.08322.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIS information filter Thread-Index: AcrUp2B6y6SYaV/ETfSun6u5CpJzrwARrsew References: <6A2A459175DABE4BB11DE2026AA50A5D01923F4E@XMB-AMS-107.cisco.com> <201004051204.08322.hrogge@googlemail.com> From: "Pascal Thubert (pthubert)" To: "Henning Rogge" , X-OriginalArrivalTime: 05 Apr 2010 18:31:45.0659 (UTC) FILETIME=[3EEE4CB0:01CAD4EE] Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:31:52 -0000 SGkgSGVubmluZzoNCg0KR29vZCB0byBoZWFyIGZyb20geW91IDopDQoNCkRvIHlvdSB0aGluayB3 ZSBjYW4gc2FmZWx5IHNoYXJlIHRoZSBNQU5FVCBtY2FzdCBhZGRyZXNzPyBPciBtYXliZSBzaG91 bGQgd2UgZGVmaW5lIGFsbC1ycGwtcm91dGVycz8NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0 bzpocm9nZ2VAZ29vZ2xlbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDUsIDIwMTAg MTI6MDQgUE0NCj4gVG86IHJvbGxAaWV0Zi5vcmcNCj4gQ2M6IFBhc2NhbCBUaHViZXJ0IChwdGh1 YmVydCk7IEpQIFZhc3NldXINCj4gU3ViamVjdDogUmU6IFtSb2xsXSBESVMgaW5mb3JtYXRpb24g ZmlsdGVyDQo+IA0KPiBBbSBNb250YWcgMDUgQXByaWwgMjAxMCAxMTo1MzoxMiBzY2hyaWViIFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCk6DQo+ID4gSGkgYWdhaW4gSlA6DQo+ID4NCj4gPiBXaGF0 IGFib3V0IHRoaXMgdG8gY2xlYXJseSBpbmRpY2F0ZSB0aGF0IGFsbCBSUEwgbWVzc2FnZXMgaGF2 ZSB0aGUNCj4gPiBzYW1lDQo+ID4gY29uc3RydWN0Og0KPiA+DQo+ID4gIg0KPiA+IC4gIElDTVB2 NiBSUEwgQ29udHJvbCBNZXNzYWdlDQo+ID4NCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMg dGhlIFJQTCBDb250cm9sIE1lc3NhZ2UsIGEgbmV3IElDTVB2NiBtZXNzYWdlLg0KPiA+ICAgIEEg UlBMIENvbnRyb2wgTWVzc2FnZSBpcyBpZGVudGlmaWVkIGJ5IGEgY29kZSwgYW5kIGNvbXBvc2Vk IG9mIGEgYmFzZQ0KPiA+ICAgIHRoYXQgZGVwZW5kcyBvbiB0aGUgY29kZSwgYW5kIGEgc2VyaWVz IG9mIG9wdGlvbnMuDQo+ID4NCj4gPiAgICBBIFJQTCBDb250cm9sIE1lc3NhZ2UgaGFzIHRoZSBz Y29wZSBvZiBhIGxpbmsuICBUaGUgc291cmNlIGFkZHJlc3MgaXMNCj4gPiAgICBhIGxpbmsgbG9j YWwgYWRkcmVzcy4gIFRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGVpdGhlciBhbGwgcm91dGVy cw0KPiA+ICAgIG11bHRpY2FzdCBhZGRyZXNzIChGRjAyOjoyKSBvciBhIGxpbmsgbG9jYWwgYWRk cmVzcy4NCj4gSnVzdCBhcyBhIGNvbW1lbnQsIHRoZSBJQU5BIGhhcyByZXNlcnZlZCBhIGxpbmts b2NhbCBtdWx0aWNhc3QgYWRkcmVzcyBmb3INCj4gbWFuZXQgcm91dGVycyAoc2VlIFJGQyA1NDk4 KSwgbWF5YmUgdGhpcyBhZGRyZXNzIChmZjAyOjo2ZCkgd291bGQgYmUgdXNlZnVsDQo+IGluIHRo ZSBSaXBwbGUgY29udGV4dCB0b28uDQo+IA0KPiBIZW5uaW5nIFJvZ2dlDQo+IA0KPiAtLQ0KPiAx KSBZb3UgY2FuJ3Qgd2luLg0KPiAyKSBZb3UgY2FuJ3QgYnJlYWsgZXZlbi4NCj4gMykgWW91IGNh bid0IGxlYXZlIHRoZSBnYW1lLg0KPiDigJQgVGhlIExhd3Mgb2YgVGhlcm1vZHluYW1pY3MsIHN1 bW1hcml6ZWQNCg== From mcr@sandelman.ca Mon Apr 5 11:37:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CEE28C108 for ; Mon, 5 Apr 2010 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lKEJHdytO53 for ; Mon, 5 Apr 2010 11:37:20 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8FA9D28C0FE for ; Mon, 5 Apr 2010 11:37:20 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 10BA934756; Mon, 5 Apr 2010 14:35:13 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 542AB4E7ED; Mon, 5 Apr 2010 14:37:17 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 05 Apr 2010 14:37:17 -0400 Message-ID: <3378.1270492637@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:37:21 -0000 >>>>> "Philip" == Philip Levis writes: >> The DODAGID scopes the DODAG sequence. Without the DODAGID, >> you'd have to coordinate sequence numbers between all roots >> within the same instance. Philip> Makes sense, but 16 bytes seems like a lot of state for such Philip> as simple problem... In my implementation, it's treated as a null-padded string. It may be descriptive. (Obviously, my implementation is happy to just see random unprintable characters). The DODAGID is the major thing I see one would provision into nodes/applications. -- ] 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 mcr@sandelman.ca Mon Apr 5 11:40:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F6E3A68ED; Mon, 5 Apr 2010 11:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdBj9hLwqkY0; Mon, 5 Apr 2010 11:40:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0EDA73A68D9; Mon, 5 Apr 2010 11:40:55 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 419F134387; Mon, 5 Apr 2010 14:38:48 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 772A54E7ED; Mon, 5 Apr 2010 14:40:52 -0400 (EDT) From: Michael Richardson To: Ted.Humpal@jci.com In-Reply-To: References: <4AD79907-4A5C-4A81-BC21-33E29C9CA3B0@archrock.com> <9DE9D678-89BB-4623-8F39-1C59479C8837@cs.stanford.edu> <87k4sm2j26.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 05 Apr 2010 14:40:52 -0400 Message-ID: <3664.1270492852@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] DODAGID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:40:56 -0000 >>>>> "Ted" == Ted Humpal writes: Ted> With all of the discussions for P2P, and the need for the Ted> creation of new DODAG IDs to support this - are we considering Ted> adding additional management roles to the DHCP like server or Ted> designating a new device type? This new role will manage the Ted> DODAG IDs - such as assignments - duplicate ID detection and Ted> deletion or renewal? Uhm... does (stateless, IPv6) DHCP happen first, or does RPL? I'd have thought that the bootstrap order was: 0) do layer-2 stuff, if any. 1) hear RA from nearby nodes, configure address, send ND. (*) 2) listen for DIO. 3) pick parent, send DAG 4) do DHCP to get additional information (*) maybe I'm wrong about the nodes doing RA. -- ] 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 mcr@sandelman.ca Mon Apr 5 11:43:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DD53A68D9 for ; Mon, 5 Apr 2010 11:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaqahfaqdPh0 for ; Mon, 5 Apr 2010 11:43:12 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 345E93A6853 for ; Mon, 5 Apr 2010 11:43:12 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 5BF163478E; Mon, 5 Apr 2010 14:41:05 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 9DC964E7ED; Mon, 5 Apr 2010 14:43:09 -0400 (EDT) From: Michael Richardson To: Jonathan Hui X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 05 Apr 2010 14:43:09 -0400 Message-ID: <3836.1270492989@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: [Roll] how is the DODAGID generated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 18:43:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> additional mechanisms to handle. The original intention Jonathan> with the DODAG ID being the IP address of the root is that Jonathan> it avoids creating a new namespace. okay, I didn't know that it was supposed to be that. Maybe I missed that in the text, I'll go re-read it. This now explains why it is 16 bytes. Which IP address of the root is it? (The root is likely to have more than one interface, and in any case, is it the link-local, or another address?) - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS7ovOoCLcPvd0N1lAQIVmQf8ComZWxK1W12t7B9MKy+ohRIO/ncJt0Bv YDbRL+Vhtw/uOwWNcT4VKMByCWyQw5nLuIilzA9ie1+eCMuiCcChfUj2+XbxGHt3 qse8SjYnBe57BVLxPtmzbdjq0fi9X9L9H8KMBG/aZ3nm6dwHx5xEtdauBg8L6J7t xZov3GuBuxYNdIfYdCUQoWjKJOXtqRQ9JHJvnApsfOsC9VmZXD6ALsaa/nxc4dD1 PIVLiq91jgQPzaDGzVHOjC+HIkZrveQQRC+rJG0BJSL0wf7Gcfe2+PZ/HKOIfAUP Lf6lOaSSv+DSLT0cFAa5FzrGlIHJQapk0Cf/p44OjdwSyMZL8aNf2w== =am4y -----END PGP SIGNATURE----- From hrogge@googlemail.com Mon Apr 5 12:35:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D603A6A69 for ; Mon, 5 Apr 2010 12:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35B79oqt1LJC for ; Mon, 5 Apr 2010 12:35:57 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 2D6C43A6A27 for ; Mon, 5 Apr 2010 12:35:57 -0700 (PDT) Received: by ewy24 with SMTP id 24so1308573ewy.13 for ; Mon, 05 Apr 2010 12:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=ngW0pK4mDnmrzrCYtTXDL4x3PpipOahueFbumzQebb0=; b=wW1xrwpMBxMhn/Mj/jqzZi7zG0OAVbixv13r2Y05CYX38CsLkXfCGFuqMtxBKWvck4 rJd8t8lU9pUI6gdAGQCxpl0ojoYF9F3Mle2UNUeTgvba3EIgYA0ALM/c0AJlBvxcljjJ t1KJzauw6FH1YAJ8ifmrU0IG5mIBR/eZorGlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=bPPYIUMVYz0OndCivpcA+PoZ0nNeTPC2+15HqG02Lh66vgo3a4y0MicQk/83rVXfIb VVz0UOC/yMPm55MHEDT53uOd7JvKWKl0My63bvmuhR5KnK4tj7BLN5n3Ei/1LlekboTk 4c0bl83jl7VVsFD6Pth7TGf3Duw+ElpU/tjN8= Received: by 10.213.58.13 with SMTP id e13mr1303243ebh.86.1270496151133; Mon, 05 Apr 2010 12:35:51 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 14sm6547233ewy.6.2010.04.05.12.35.49 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Apr 2010 12:35:49 -0700 (PDT) From: Henning Rogge To: "Pascal Thubert (pthubert)" Date: Mon, 5 Apr 2010 21:35:41 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo; KDE/4.4.2; x86_64; ; ) References: <201004051204.08322.hrogge@googlemail.com> <6A2A459175DABE4BB11DE2026AA50A5D01923FF3@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923FF3@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1288860.UmBzurEMVs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004052135.48818.hrogge@googlemail.com> Cc: roll@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Apr 2010 19:35:58 -0000 --nextPart1288860.UmBzurEMVs Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Montag 05 April 2010 20:31:42 schrieb Pascal Thubert (pthubert): > Hi Henning: >=20 > Good to hear from you :) >=20 > Do you think we can safely share the MANET mcast address? Or maybe should > we define all-rpl-routers? I don't see any problem using the address. In my oppinion Ripple is a MANET= =20 protocol, it has a different focus than stuff developed in the ietf manet=20 group, but that's not really important. The IANA allocation of the RFC I was talking about contains the multicast=20 group (linklocal manet routers) and a port for packetbb. I don't see any=20 reason why other similar protocols should not use the same IP but another=20 port. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1288860.UmBzurEMVs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAku6O5QACgkQcenvcwAcHWd2JwCeKKV6mR5/MNeT+MJC9Zg1wX62 R2cAn0k6LW0Wj3B2PzE/HTTUzYHiEzAr =o0EB -----END PGP SIGNATURE----- --nextPart1288860.UmBzurEMVs-- From pal@cs.stanford.edu Mon Apr 5 20:24:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD553A67CC for ; Mon, 5 Apr 2010 20:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4zJ3miYay7L for ; Mon, 5 Apr 2010 20:24:29 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5FCC13A67B6 for ; Mon, 5 Apr 2010 20:24:29 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NyzOt-0006zp-Bt; Mon, 05 Apr 2010 20:24:27 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> Date: Mon, 5 Apr 2010 20:24:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1077) X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 03:24:30 -0000 On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 > Both flags comes from Phoebus' mail. And I tend to agree with him in > both cases. >=20 > With the current draft, a DIS from a node forces the router that > receives it to reset its trickle timer. Yet it makes sense for a node = to > poll its router to make sure it is lively, and that does not mean > inconsistency. Thus the C flag to indicate that it's just a check, no > worries. Check of what? Is the intention that this is an alternative to ping? A = DIS does not indicate an inconsistency: a DIS indicates that a node = desires destination information from its neighbors. It can do so for all = kinds of reasons. Not resetting a trickle timer is dangerous, due to = trickle suppression. An immediate response will suppress other trickle = messages. What happens if the C flag is set but the message is = multicast?=20 >=20 > About the O flag, it seems that today we confuse the method (mcast vs. > unicast) with the goal (get parameters or not). I do not think that = such > a semantical stretch will serve us in the long term. Better call a cat = a > cat, wouldn't you think? Except that unicast vs. multicast relate to whether suppression is used. = This then ties into the use of Trickle timers. Fundamentally, a node = needs to respond differently to multicast and unicast. That being said, an O flag does seem useful. Otherwise a node must first = issue a multicast DIS and then a unicast DIS. But it would seem like = this is a better design tradeoff to consider, rather than simply = introducing a redundant mechanism. If DIS messages include the O flag, = should we then remove the MUST from unicast DIS processing?=20 If a node hears a DIS with the O flag set, does the presence or absence = of a configuration suboption affect suppression? Phil= From roger.alexander@ekasystems.com Tue Apr 6 05:01:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BC23A6897 for ; Tue, 6 Apr 2010 05:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT6Lybollwvq for ; Tue, 6 Apr 2010 05:01:30 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id DBD6F3A6808 for ; Tue, 6 Apr 2010 05:01:29 -0700 (PDT) Received: (qmail 26455 invoked from network); 6 Apr 2010 12:01:25 -0000 Received: from [192.168.1.6] (roger.alexander@71.191.169.123 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 06 Apr 2010 05:01:25 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: Hc2GPN4VM1kPZQeY7KczaD49OtXmk.nswfrjc_.XieNVSQk39hakTImin55idVshLdqXTPwy42Nl.CTfCKXDRHcaUYmRZZ5lk8M3Q2TCFsVMRfG_tA2DaRNRKs8WkVaVtUW_iCyCn.93p9PATTzkixZALOdBORlr669XG5UjEveZKsIgQOfeW1c_MmB3rMszIVPQMZK0jvFPK1ZGg3fOxEDxecWaR9clzS7d6k4Dj8lPNIDZn33vRlI8W8Uyn64zRCSMxvCGIRUemOCpYvS6IyRs83uSlO4.2yUT.53GwiR3ghftTveTMAAhggIaHvhKlexjYh1S.tznHWNt9MaVldnQ6vB4WFghMyq3MqszAhJFRlHKxbCL3JB.gs.3qazefovymieSWZyRPF7WVb09t7TN1nQwD66kYVhB7H8- X-Yahoo-Newman-Property: ymail-3 References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> Message-Id: From: Roger Alexander To: Tim Winter In-Reply-To: <4BB77631.20503@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 6 Apr 2010 08:01:24 -0400 Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 12:01:31 -0000 +1 Roger On Apr 3, 2010, at 1:09 PM, Tim Winter wrote: > WG, > > =46rom Anaheim and the list it seems that there is support to proceed =20= > on RPL with > storing and non-storing modes of operation, and not to elaborate =20 > mixed mode operation > at this time (while allowing room for future specification of mixed =20= > mode). > > The summary approach would be to signal the mode of operation =20 > through the DIO, that > all nodes MUST be capable to support a non-storing mode of =20 > operation, and that nodes > who are incapable of acting as routers in a storing mode may =20 > participate in the DODAG > as hosts (leaves). (The suitable behavior when a routing table in a =20= > storing node > becomes saturated is still under consideration). > > Would you please confirm this approach to the list? Then we may =20 > proceed to refine > RPL accordingly for the next revision, -08, and to take this into =20 > account when > working the other tickets. > > Thanks, > > -Tim > > > roll issue tracker wrote: >> #26: Establishing downward routes in RPL : storing / non-storing / =20= >> mixed modes >> of operation >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=E2=80=A6 | Owner: wintert@=E2=80=A6= >> Type: task | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> In the RPL-07 proposal the DAO mechanism described in Section 6 =20 >> attempts >> to support >> operation with a mix of storing nodes and non-storing nodes- where =20= >> storing >> nodes may >> be provisioned with enough memory that they are capable to =20 >> provision hop- >> by-hop >> downward routes learned from DAO messages, and non-storing nodes =20 >> would >> rely on source >> routing for downward routes. The present proposal describes =20 >> operation in >> a mixed >> mode operation, with both storing and non-storing nodes, where each =20= >> node >> may >> provision downward routing state as according to its capabilities and >> largely >> independent of its position in the LLN topology. >> >> It has been noted that operation in the case where all nodes (except >> possibly the >> root) are non-storing nodes allows for certain optimizations, and =20 >> that the >> case where >> all nodes (except possibly leaves) are storing leads to other >> optimizations. It has >> also been noted that in the mixed cases the ability to provide an =20 >> optimal >> solution >> may break down. In particular there are concerns about the =20 >> complexity and >> correctness of mixed-mode operation as proposed by RPL-07. >> >> With this in mind, should RPL allow for operation in a mixture of =20 >> storing >> /non-storing >> nodes? Or should each RPL Instance be exclusively operating in =20 >> either >> storing or >> non-storing mode (with the provision that operation as a leaf is =20 >> always an >> option)? >> (The non-mixed case may imply some control flag or equivalent given =20= >> in the >> DIO to >> signal the mode of operation). >> >> Tim Winter. >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Tue Apr 6 06:33:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504CF3A695B for ; Tue, 6 Apr 2010 06:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.835 X-Spam-Level: X-Spam-Status: No, score=-103.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71gPUOUCXQ0k for ; Tue, 6 Apr 2010 06:33:35 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 9DB813A6958 for ; Tue, 6 Apr 2010 06:33:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 86AC914DC41; Tue, 6 Apr 2010 15:33:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GoMAcuI8gIqY; Tue, 6 Apr 2010 15:33:00 +0200 (CEST) X-KTH-Auth: phoebus [2002:82ed:3247:b:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-59.s3.kth.se (unknown [IPv6:2002:82ed:3247:b:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id DD6F214D7F9; Tue, 6 Apr 2010 15:32:58 +0200 (CEST) Message-ID: <4BBB3809.3090102@ieee.org> Date: Tue, 06 Apr 2010 15:32:57 +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.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Philip Levis References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> In-Reply-To: <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2010 13:33:39 -0000 On 4/6/10 5:24 AM, Philip Levis wrote: > > On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> Both flags comes from Phoebus' mail. And I tend to agree with him >> in both cases. >> >> With the current draft, a DIS from a node forces the router that >> receives it to reset its trickle timer. Yet it makes sense for a >> node to poll its router to make sure it is lively, and that does >> not mean inconsistency. Thus the C flag to indicate that it's just >> a check, no worries. > > Check of what? Is the intention that this is an alternative to ping? > A DIS does not indicate an inconsistency: a DIS indicates that a node > desires destination information from its neighbors. It can do so for > all kinds of reasons. Not resetting a trickle timer is dangerous, due > to trickle suppression. An immediate response will suppress other > trickle messages. What happens if the C flag is set but the message > is multicast? > I think that part of the confusion is that most of the dialog surrounding resetting the Trickle timer assumes that we only reset the Trickle timer upon detecting an inconsistency. My understanding of how the Trickle timer is being used in this situation is that we are resetting the Trickle timer after hearing a multicast DIS to get more reliability of DIO message delivery, sort of as a replacement for an acknowledgment by having more frequent retransmissions for a short while. Which is really stretching the Trickle timer to do more than what it was originally designed to do (detect and resolve inconsistency), but I digress. We can rename the C flag to an R flag, for "reset Trickle timer", if that clears up the confusion. But in any case, I think that resetting the Trickle timer should not be tied to unicast or multicast. I see no reason to restrict all multicast DIS messages to always reset the Trickle timer, if you want to keep the mechanisms flexible. It's not entirely clear to me that forcing a Trickle timer reset is always cheaper, in terms of routing control message overhead, than having a node multicast a DIS again (no Trickle timer reset) if it does not feel it has heard enough responses. Remember, some deployments may choose to turn off the suppression mechanism in Trickle (we have the ability to set DIORedundancyConstant = 0xFF) so that it can hear all DIO advertisements. Another way to look at it is: Does RPL "break" if we allow unicast DIS messages to reset the Trickle timer, or multicast DIS messages to not reset the Trickle timer? Are we ready to make such a decision, now, that those two cases are always bad? BTW, I generally do want to rein in the ambiguity of how RPL behaves. If it turns out that there are very few situations where we would want to reset the Trickle timer after receiving a unicast DIS (or not reset the Trickle timer after receiving a multicast DIS) the specification can make recommendations on how to set the flags for those DIS messages. >> >> About the O flag, it seems that today we confuse the method (mcast >> vs. unicast) with the goal (get parameters or not). I do not think >> that such a semantical stretch will serve us in the long term. >> Better call a cat a cat, wouldn't you think? > > Except that unicast vs. multicast relate to whether suppression is > used. This then ties into the use of Trickle timers. Fundamentally, a > node needs to respond differently to multicast and unicast. > > That being said, an O flag does seem useful. Otherwise a node must > first issue a multicast DIS and then a unicast DIS. But it would seem > like this is a better design tradeoff to consider, rather than simply > introducing a redundant mechanism. If DIS messages include the O > flag, should we then remove the MUST from unicast DIS processing? > Hmm, I'm not sure that I agree that issuing a multicast DIS and then a unicast DIS is a better design tradeoff than adding a 1-bit flag to the DIS message. I think the idea here is to replace the text in Section 5.3.5 on how to handle unicast and multicast messages. Instead, that should be under a description of how to respond to a DIS message depending on what flags are set. > If a node hears a DIS with the O flag set, does the presence or > absence of a configuration suboption affect suppression? > > Phil -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pal@cs.stanford.edu Tue Apr 6 10:11:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4698A3A6803 for ; Tue, 6 Apr 2010 10:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2BMOcokEJCY for ; Tue, 6 Apr 2010 10:11:42 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 195C03A67D3 for ; Tue, 6 Apr 2010 10:11:42 -0700 (PDT) Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzCJP-0001tX-9g; Tue, 06 Apr 2010 10:11:39 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BBB3809.3090102@ieee.org> Date: Tue, 6 Apr 2010 10:11:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 17:11:45 -0000 On Apr 6, 2010, at 6:32 AM, Phoebus Chen wrote: > On 4/6/10 5:24 AM, Philip Levis wrote: >>=20 >> On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> Hi Phil: >>>=20 >>> Both flags comes from Phoebus' mail. And I tend to agree with him >>> in both cases. >>>=20 >>> With the current draft, a DIS from a node forces the router that >>> receives it to reset its trickle timer. Yet it makes sense for a >>> node to poll its router to make sure it is lively, and that does >>> not mean inconsistency. Thus the C flag to indicate that it's just >>> a check, no worries. >>=20 >> Check of what? Is the intention that this is an alternative to ping? >> A DIS does not indicate an inconsistency: a DIS indicates that a node >> desires destination information from its neighbors. It can do so for >> all kinds of reasons. Not resetting a trickle timer is dangerous, due >> to trickle suppression. An immediate response will suppress other >> trickle messages. What happens if the C flag is set but the message >> is multicast? >>=20 >=20 > I think that part of the confusion is that most of the dialog > surrounding resetting the Trickle timer assumes that we only reset the > Trickle timer upon detecting an inconsistency. My understanding of how > the Trickle timer is being used in this situation is > that we are resetting the Trickle timer after hearing a multicast DIS > to get more reliability of DIO message delivery, sort of as a > replacement for an acknowledgment by having more frequent > retransmissions for a short while. Which is really stretching the > Trickle timer to do more than what it was originally designed to do > (detect and resolve inconsistency), but I digress. If you do not reset the Trickle timer, what do you do? You can't = immediately respond: that's a broadcast storm. Take a look at the = results in the Trickle paper: one of the key properties of the = exponential timer is that it scales to high variations in density.=20 > We can rename the C flag to an R flag, for "reset Trickle timer", if > that clears up the confusion. But in any case, I think that resetting > the Trickle timer should not be tied to unicast or multicast. =20 It is absolutely critical that it be tied to it: unicast packets do not = cause a broadcast storm. If this means that the draft says that = multicast packets MUST have the flag set, that would be fine. > I see no > reason to restrict all multicast DIS messages to always reset the > Trickle timer, if you want to keep the mechanisms flexible. It's not > entirely clear to me that forcing a Trickle timer reset is always > cheaper, in terms of routing control message overhead, than having a > node multicast a DIS again (no Trickle timer reset) if it does not = feel > it has heard enough responses. The problem is too many responses.=20 > Remember, some deployments may choose to > turn off the suppression mechanism in Trickle (we have the ability to > set DIORedundancyConstant =3D 0xFF) so that it can hear all DIO > advertisements. Sure -- but the exponential timer will cause nodes to eventually reach a = communication rate that the link layer can support. >=20 > Another way to look at it is: Does RPL "break" if we allow unicast DIS = messages to reset the Trickle timer, or multicast DIS messages to not = reset the Trickle timer? Are we ready to make such a decision, now, = that those two cases are always bad? If a multicast message does not reset the trickle timer, but instead = elicits an immediate response, that will break RPL. It is OK for a unicast message to reset the Trickle timer. Phil From jpv@cisco.com Tue Apr 6 10:33:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BBC28C0DE for ; Tue, 6 Apr 2010 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.53 X-Spam-Level: X-Spam-Status: No, score=-9.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkGKtxAPXVvk for ; Tue, 6 Apr 2010 10:33:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B894028C116 for ; Tue, 6 Apr 2010 10:31:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALIMu0tAaHte/2dsb2JhbAAvmwxxoiGZA4UJBA X-IronPort-AV: E=Sophos;i="4.51,373,1267401600"; d="scan'208";a="111063643" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2010 17:31:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o36HVtKH013196; Tue, 6 Apr 2010 17:31:56 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 23:01:55 +0530 Received: from [192.168.51.198] ([10.61.101.138]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 23:01:55 +0530 Message-Id: <79EE5F97-5855-46FE-92DE-8D6FD022C391@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 12:15:05 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Apr 2010 17:31:55.0454 (UTC) FILETIME=[0D6A3DE0:01CAD5AF] Cc: ROLL WG Subject: Re: [Roll] DIS information filter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 17:33:04 -0000 Hi, On Apr 5, 2010, at 11:43 AM, Pascal Thubert (pthubert) wrote: > JP: > > I agree with allowing options and eventually suboptions (since we > migrated out of ND messages, the so-called suboptions are really > options, we need to fix that) in all RPL messages. > > This does not mean that everything has to be options. Same goes for > DIO, > would you make everything in the base header an option? Sure, I do agree. > > OTOH, in the current spec, the target in a DAO is not an option. This > prevents from packing multiple targets in a single DAO, which is > really > sad in the stateful mode. > > I agree with good sense as long as it is really common. Agree. JP. > > Pascal > > >> -----Original Message----- >> From: JP Vasseur [mailto:jpv@cisco.com] >> Sent: Monday, April 05, 2010 11:35 AM >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; ROLL WG >> Subject: Re: [Roll] DIS information filter >> >> Hi, >> >> There is golden rule for deciding this, mostly common sense. The > reason why >> I would argue for a sub-option in this case is that we may need other > ones in >> the future. It might not be needed in some cases, and we may need >> more > in >> other cases, a good reason for using options in my opinion. >> >> Thanks. >> >> JP. >> >> On Apr 5, 2010, at 10:58 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Phil: >>> >>> I'm in, agreement with everything you said below. But one thing > where >>> you lost me. >>> >>> I understood that you were advocating for simplicity and not using > an >>> option for something that's really basic/core, thus my post on > another >>> thread before I saw this where those parms make the DIS message >>> itself. >>> I tend to prefer the simplicity in this case. >>> >>> For me an option is good for: >>> - something that's used only when an optional behavior applies. For >>> instance OF specific suboptions. >>> - something that does not need to be repeated in all messages. Like > OF >>> parms. >>> - something that might be repeated multiple times in a message. For >>> instance I think that the target of a DAO should be an option so we >>> can have multiple of them in one message >>> - something that might be used in multiple types of messages. The >>> target I mentioned above could be useful in DIO for stimulated > repair, >>> incoming request and P2P as already discussed in the ML. >>> >>> So, I agree with accepting options in DIS, I'm just unclear whether >>> your proposal is an option or mostly the base DIS. >>> >>> Votes? >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf >>> Of >>>> Philip Levis >>>> Sent: Friday, April 02, 2010 7:01 PM >>>> To: ROLL WG >>>> Subject: [Roll] DIS information filter >>>> >>>> (Trying to restart the thread) >>>> >>>> In -07, nodes always respond to DIS messages by resetting their >>> Trickle >>>> timers. A few people on the list have pointed out that this is >>> problematic. If >>>> an environment has multiple RPL instances, for example, when a node >>>> solicits information it must do so from *all* instances, even if it >>> knows the >>>> one it wants to join. >>>> >>>> The basic issue is that a node may wish to solicit DIOs from only a >>> subset of >>>> nodes; it's wasteful to force a lot of nodes to reset their trickle >>> timers >>>> unnecessarily. >>>> >>>> I propose that we add a new suboption to RPL, which is only valid > for >>> DIS >>>> messages. The Solicited Information Filter suboption specifies a > set >>> of >>>> predicates; if a node satisfies the predicates, it MUST reset its >>> timer in >>>> response to the message. If it does not satisfy the predicates, it >>> MUST NOT >>>> reset its timer in response to the message. >>>> >>>> The trick is to make this a simple, fixed-length suboption; forcing >>> nodes to >>>> parse all kinds of suboptions is problematic in terms of code size. >>> Similarly, >>>> we'd like the suboption to cover the compelling cases but not be so >>> complete >>>> that it wastes space on useless fields. So the question is: what >>> information do >>>> nodes want to filter on? >>>> >>>> The one that immediately comes to mind is a DODAG Iteration: this >>> would >>>> imply the RPLInstanceID, Sequence, and DODAGID. >>>> >>>> There have been a few mentions of Rank. I personally think it makes >>> more >>>> sense to handle this through trickle suppression (you generally > want >>> low- >>>> Rank messages more than high-Rank ones), but this seems like a good >>> point >>>> of discussion. >>>> >>>> So my current proposal is that the Solicited Information Suboption >>>> has >>> the >>>> following format: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 >>>> >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type = 5 | Reserved | Sequence | > RPLInstanceID >>> | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | >>> | >>>> + >>> + >>>> | DODAGID >>> | >>>> + >>> + >>>> | >>> | >>>> + >>> + >>>> | >>> | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Furthermore, we should reserve values for Sequence, RPLInstanceID, >>>> and DODAGID as wildcards ("any value matches"). This would indicate >>>> that >>> such >>>> values can't be used normally. Alternatively, the reserved region >>> could have >>>> bits stating which of the three fields to match on. >>>> >>>> Thoughts? >>>> >>>> Phil >>>> _______________________________________________ >>>> 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 yoav@yitran.com Tue Apr 6 13:05:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C8B3A696C for ; Tue, 6 Apr 2010 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cngFl+w+HcK for ; Tue, 6 Apr 2010 13:05:23 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 0DFC93A68ED for ; Tue, 6 Apr 2010 13:05:17 -0700 (PDT) Received: from source ([209.85.220.215]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKS7uT+vjauRFs7jqHLd7WLHPSK7/1k5dc@postini.com; Tue, 06 Apr 2010 13:05:16 PDT Received: by mail-fx0-f215.google.com with SMTP id 7so301279fxm.18 for ; Tue, 06 Apr 2010 13:05:14 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> In-Reply-To: <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrVrEAZ9Va7HerWQBOKlt/WtTJWhQAE0FNA Date: Tue, 6 Apr 2010 23:05:12 +0300 Received: by 10.239.193.6 with SMTP id g6mr56168hbi.212.1270584314574; Tue, 06 Apr 2010 13:05:14 -0700 (PDT) Message-ID: <001c01cad5c4$77c8b8f0$675a2ad0$@com> To: Philip Levis , phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 20:05:24 -0000 Question: I understand that responding immediately causes broadcast storms. But our initial concern was that resetting the trickle timer by all devices hearing a multicast DIS in a dense network, may also cause congestion by DIO responses (assuming no suppression is used). I was wondering whether a quick exponentially decaying reduction or reduction with probability of the timer do instead of a full timer reset (maybe multiplication or probability factors can be set on the DIS message)? For unicast DIS, the factors can indicate 100% timer reset. This can allow the DIS transmitter to make a flexible protocol that allows for multiple "waves" of DIS messages to be sent by the same node, where the probability or the reduction factor starts off small, and is increased gradually if the DIS transmitter requires more DIO responses. This protocol would also converge much faster if we can come up with a way of not sending DIOs that were already sent in previous "waves" (but let's focus on one problem solving at a time :) ) Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Tuesday, April 06, 2010 8:12 PM To: phoebus@ieee.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #29: DIS packet format On Apr 6, 2010, at 6:32 AM, Phoebus Chen wrote: > On 4/6/10 5:24 AM, Philip Levis wrote: >> >> On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Phil: >>> >>> Both flags comes from Phoebus' mail. And I tend to agree with him >>> in both cases. >>> >>> With the current draft, a DIS from a node forces the router that >>> receives it to reset its trickle timer. Yet it makes sense for a >>> node to poll its router to make sure it is lively, and that does >>> not mean inconsistency. Thus the C flag to indicate that it's just >>> a check, no worries. >> >> Check of what? Is the intention that this is an alternative to ping? >> A DIS does not indicate an inconsistency: a DIS indicates that a node >> desires destination information from its neighbors. It can do so for >> all kinds of reasons. Not resetting a trickle timer is dangerous, due >> to trickle suppression. An immediate response will suppress other >> trickle messages. What happens if the C flag is set but the message >> is multicast? >> > > I think that part of the confusion is that most of the dialog > surrounding resetting the Trickle timer assumes that we only reset the > Trickle timer upon detecting an inconsistency. My understanding of how > the Trickle timer is being used in this situation is > that we are resetting the Trickle timer after hearing a multicast DIS > to get more reliability of DIO message delivery, sort of as a > replacement for an acknowledgment by having more frequent > retransmissions for a short while. Which is really stretching the > Trickle timer to do more than what it was originally designed to do > (detect and resolve inconsistency), but I digress. If you do not reset the Trickle timer, what do you do? You can't immediately respond: that's a broadcast storm. Take a look at the results in the Trickle paper: one of the key properties of the exponential timer is that it scales to high variations in density. > We can rename the C flag to an R flag, for "reset Trickle timer", if > that clears up the confusion. But in any case, I think that resetting > the Trickle timer should not be tied to unicast or multicast. It is absolutely critical that it be tied to it: unicast packets do not cause a broadcast storm. If this means that the draft says that multicast packets MUST have the flag set, that would be fine. > I see no > reason to restrict all multicast DIS messages to always reset the > Trickle timer, if you want to keep the mechanisms flexible. It's not > entirely clear to me that forcing a Trickle timer reset is always > cheaper, in terms of routing control message overhead, than having a > node multicast a DIS again (no Trickle timer reset) if it does not feel > it has heard enough responses. The problem is too many responses. > Remember, some deployments may choose to > turn off the suppression mechanism in Trickle (we have the ability to > set DIORedundancyConstant = 0xFF) so that it can hear all DIO > advertisements. Sure -- but the exponential timer will cause nodes to eventually reach a communication rate that the link layer can support. > > Another way to look at it is: Does RPL "break" if we allow unicast DIS messages to reset the Trickle timer, or multicast DIS messages to not reset the Trickle timer? Are we ready to make such a decision, now, that those two cases are always bad? If a multicast message does not reset the trickle timer, but instead elicits an immediate response, that will break RPL. It is OK for a unicast message to reset the Trickle timer. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Tue Apr 6 13:54:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800D93A688D for ; Tue, 6 Apr 2010 13:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.824 X-Spam-Level: X-Spam-Status: No, score=-104.824 tagged_above=-999 required=5 tests=[AWL=1.425, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvDZhJgqYFRv for ; Tue, 6 Apr 2010 13:54:05 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 71F543A691F for ; Tue, 6 Apr 2010 13:53:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 4E2E814C022; Tue, 6 Apr 2010 22:53:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lHBnFGLmbIEg; Tue, 6 Apr 2010 22:53:17 +0200 (CEST) X-KTH-Auth: phoebus [213.100.62.72] X-KTH-mail-from: phoebus@ieee.org Received: from c213-100-62-72.swipnet.se (c213-100-62-72.swipnet.se [213.100.62.72]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 81CB414C113; Tue, 6 Apr 2010 22:53:14 +0200 (CEST) Message-ID: <4BBB9F3A.9080603@ieee.org> Date: Tue, 06 Apr 2010 22:53:14 +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.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Philip Levis References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> In-Reply-To: <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2010 20:54:06 -0000 On 4/6/10 7:11 PM, Philip Levis wrote: > > On Apr 6, 2010, at 6:32 AM, Phoebus Chen wrote: > >> On 4/6/10 5:24 AM, Philip Levis wrote: >>> >>> On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Phil: >>>> >>>> Both flags comes from Phoebus' mail. And I tend to agree with >>>> him in both cases. >>>> >>>> With the current draft, a DIS from a node forces the router >>>> that receives it to reset its trickle timer. Yet it makes sense >>>> for a node to poll its router to make sure it is lively, and >>>> that does not mean inconsistency. Thus the C flag to indicate >>>> that it's just a check, no worries. >>> >>> Check of what? Is the intention that this is an alternative to >>> ping? A DIS does not indicate an inconsistency: a DIS indicates >>> that a node desires destination information from its neighbors. >>> It can do so for all kinds of reasons. Not resetting a trickle >>> timer is dangerous, due to trickle suppression. An immediate >>> response will suppress other trickle messages. What happens if >>> the C flag is set but the message is multicast? >>> >> >> I think that part of the confusion is that most of the dialog >> surrounding resetting the Trickle timer assumes that we only reset >> the Trickle timer upon detecting an inconsistency. My understanding >> of how the Trickle timer is being used in this situation is that we >> are resetting the Trickle timer after hearing a multicast DIS to >> get more reliability of DIO message delivery, sort of as a >> replacement for an acknowledgment by having more frequent >> retransmissions for a short while. Which is really stretching the >> Trickle timer to do more than what it was originally designed to >> do (detect and resolve inconsistency), but I digress. > > If you do not reset the Trickle timer, what do you do? You can't > immediately respond: that's a broadcast storm. Take a look at the > results in the Trickle paper: one of the key properties of the > exponential timer is that it scales to high variations in density. > Yes, you will get a 1-hop broadcast storm. Which could be bad if the network were really dense. > >> We can rename the C flag to an R flag, for "reset Trickle timer", >> if that clears up the confusion. But in any case, I think that >> resetting the Trickle timer should not be tied to unicast or >> multicast. > > It is absolutely critical that it be tied to it: unicast packets do > not cause a broadcast storm. If this means that the draft says that > multicast packets MUST have the flag set, that would be fine. > > >> I see no reason to restrict all multicast DIS messages to always >> reset the Trickle timer, if you want to keep the mechanisms >> flexible. It's not entirely clear to me that forcing a Trickle >> timer reset is always cheaper, in terms of routing control message >> overhead, than having a node multicast a DIS again (no Trickle >> timer reset) if it does not feel it has heard enough responses. > > The problem is too many responses. > > >> Remember, some deployments may choose to turn off the suppression >> mechanism in Trickle (we have the ability to set >> DIORedundancyConstant = 0xFF) so that it can hear all DIO >> advertisements. > > Sure -- but the exponential timer will cause nodes to eventually > reach a communication rate that the link layer can support. > Without suppression, you would have as much of a broadcast storm as a one time immediate response. Minus the effects of the T/2 randomization for the sending times in Trickle. If you're concerned about congestion from sending at the same time (as opposed to concern about the number of messages), remember that the MAC layer should probably be handling this: for example, that's what CSMA with exponential backoff is suppose to handle. >> >> Another way to look at it is: Does RPL "break" if we allow unicast >> DIS messages to reset the Trickle timer, or multicast DIS messages >> to not reset the Trickle timer? Are we ready to make such a >> decision, now, that those two cases are always bad? > > If a multicast message does not reset the trickle timer, but instead > elicits an immediate response, that will break RPL. > > It is OK for a unicast message to reset the Trickle timer. > > Phil > I wouldn't say that RPL "breaks" if we elicit an immediate response. It's just highly inefficient in very dense networks. There might be networks which are not dense too. Using Trickle seems to bring it's own set of questions of how to do suppression properly - I currently don't have a clear grasp of all of Trickle's implications on how RPL behaves (and I have looked at the Trickle paper, but it's for a different scenario than RPL). Allowing a multicast message to elicit an immediate response would leave another option for sparse networks, if strange behavior arises from using Trickle. But in any case, maybe this discussion is straying off the main point... using flags in the DIS message to signal a trickle timer reset does not limit us from saying "multicast packets MUST have the flag set" later on, if further discussion and studies really point us in that direction as you say it should. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From phoebus@ieee.org Tue Apr 6 13:59:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B803A6A14 for ; Tue, 6 Apr 2010 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.950, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmJYBo+Ee4q7 for ; Tue, 6 Apr 2010 13:59:49 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 9119D3A696C for ; Tue, 6 Apr 2010 13:59:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0D47814C113; Tue, 6 Apr 2010 22:59:16 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Dw4KI-ssndau; Tue, 6 Apr 2010 22:59:14 +0200 (CEST) X-KTH-Auth: phoebus [213.100.62.72] X-KTH-mail-from: phoebus@ieee.org Received: from c213-100-62-72.swipnet.se (c213-100-62-72.swipnet.se [213.100.62.72]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 2CE3914C022; Tue, 6 Apr 2010 22:59:13 +0200 (CEST) Message-ID: <4BBBA0A1.8050201@ieee.org> Date: Tue, 06 Apr 2010 22:59:13 +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.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yoav Ben-Yehezkel References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> <001c01cad5c4$77c8b8f0$675a2ad0$@com> In-Reply-To: <001c01cad5c4$77c8b8f0$675a2ad0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2010 20:59:50 -0000 On 4/6/10 10:05 PM, Yoav Ben-Yehezkel wrote: > Question: > > I understand that responding immediately causes broadcast storms. But our > initial concern was that resetting the trickle timer by all devices > hearing a multicast DIS in a dense network, may also cause congestion by > DIO responses (assuming no suppression is used). > > I was wondering whether a quick exponentially decaying reduction or > reduction with probability of the timer do instead of a full timer reset > (maybe multiplication or probability factors can be set on the DIS > message)? For unicast DIS, the factors can indicate 100% timer reset. > > This can allow the DIS transmitter to make a flexible protocol that allows > for multiple "waves" of DIS messages to be sent by the same node, where > the probability or the reduction factor starts off small, and is increased > gradually if the DIS transmitter requires more DIO responses. This > protocol would also converge much faster if we can come up with a way of > not sending DIOs that were already sent in previous "waves" (but let's > focus on one problem solving at a time :) ) That's an interesting proposal. Could be an interesting research problem. But I'm quite nervous about introducing a really new mechanism into the standard here... I have trouble understanding the implications of using Trickle in RPL. I think I'll have even more trouble understanding the implications of this in RPL ;). > > Thanks, > Yoav > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Tuesday, April 06, 2010 8:12 PM > To: phoebus@ieee.org > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #29: DIS packet format > > > On Apr 6, 2010, at 6:32 AM, Phoebus Chen wrote: > >> On 4/6/10 5:24 AM, Philip Levis wrote: >>> >>> On Apr 5, 2010, at 11:06 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Phil: >>>> >>>> Both flags comes from Phoebus' mail. And I tend to agree with him >>>> in both cases. >>>> >>>> With the current draft, a DIS from a node forces the router that >>>> receives it to reset its trickle timer. Yet it makes sense for a >>>> node to poll its router to make sure it is lively, and that does >>>> not mean inconsistency. Thus the C flag to indicate that it's just >>>> a check, no worries. >>> >>> Check of what? Is the intention that this is an alternative to ping? >>> A DIS does not indicate an inconsistency: a DIS indicates that a node >>> desires destination information from its neighbors. It can do so for >>> all kinds of reasons. Not resetting a trickle timer is dangerous, due >>> to trickle suppression. An immediate response will suppress other >>> trickle messages. What happens if the C flag is set but the message >>> is multicast? >>> >> >> I think that part of the confusion is that most of the dialog >> surrounding resetting the Trickle timer assumes that we only reset the >> Trickle timer upon detecting an inconsistency. My understanding of how >> the Trickle timer is being used in this situation is >> that we are resetting the Trickle timer after hearing a multicast DIS >> to get more reliability of DIO message delivery, sort of as a >> replacement for an acknowledgment by having more frequent >> retransmissions for a short while. Which is really stretching the >> Trickle timer to do more than what it was originally designed to do >> (detect and resolve inconsistency), but I digress. > > If you do not reset the Trickle timer, what do you do? You can't > immediately respond: that's a broadcast storm. Take a look at the results > in the Trickle paper: one of the key properties of the exponential timer > is that it scales to high variations in density. > > >> We can rename the C flag to an R flag, for "reset Trickle timer", if >> that clears up the confusion. But in any case, I think that resetting >> the Trickle timer should not be tied to unicast or multicast. > > It is absolutely critical that it be tied to it: unicast packets do not > cause a broadcast storm. If this means that the draft says that multicast > packets MUST have the flag set, that would be fine. > > >> I see no >> reason to restrict all multicast DIS messages to always reset the >> Trickle timer, if you want to keep the mechanisms flexible. It's not >> entirely clear to me that forcing a Trickle timer reset is always >> cheaper, in terms of routing control message overhead, than having a >> node multicast a DIS again (no Trickle timer reset) if it does not feel >> it has heard enough responses. > > The problem is too many responses. > > >> Remember, some deployments may choose to >> turn off the suppression mechanism in Trickle (we have the ability to >> set DIORedundancyConstant = 0xFF) so that it can hear all DIO >> advertisements. > > Sure -- but the exponential timer will cause nodes to eventually reach a > communication rate that the link layer can support. > >> >> Another way to look at it is: Does RPL "break" if we allow unicast DIS > messages to reset the Trickle timer, or multicast DIS messages to not > reset the Trickle timer? Are we ready to make such a decision, now, that > those two cases are always bad? > > If a multicast message does not reset the trickle timer, but instead > elicits an immediate response, that will break RPL. > > It is OK for a unicast message to reset the Trickle timer. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pal@cs.stanford.edu Tue Apr 6 14:18:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251783A69A4 for ; Tue, 6 Apr 2010 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3GkUX6I0L0M for ; Tue, 6 Apr 2010 14:17:59 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 026953A6A38 for ; Tue, 6 Apr 2010 14:17:58 -0700 (PDT) Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzG9k-0008IC-Mq; Tue, 06 Apr 2010 14:17:56 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <001c01cad5c4$77c8b8f0$675a2ad0$@com> Date: Tue, 6 Apr 2010 14:17:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> <001c01cad5c4$77c8b8f0$675a2ad0$@com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 21:18:00 -0000 On Apr 6, 2010, at 1:05 PM, Yoav Ben-Yehezkel wrote: > Question: >=20 > I understand that responding immediately causes broadcast storms. But = our > initial concern was that resetting the trickle timer by all devices > hearing a multicast DIS in a dense network, may also cause congestion = by > DIO responses (assuming no suppression is used). This seems like a big assumption. > I was wondering whether a quick exponentially decaying reduction or > reduction with probability of the timer do instead of a full timer = reset > (maybe multiplication or probability factors can be set on the DIS > message)? For unicast DIS, the factors can indicate 100% timer reset. That's an interesting question: seems like the exact kind of thing that = simulations, validated by experiments on real networks, can evaluate. > This can allow the DIS transmitter to make a flexible protocol that = allows > for multiple "waves" of DIS messages to be sent by the same node, = where > the probability or the reduction factor starts off small, and is = increased > gradually if the DIS transmitter requires more DIO responses. This > protocol would also converge much faster if we can come up with a way = of > not sending DIOs that were already sent in previous "waves" (but let's > focus on one problem solving at a time :) ) >=20 =20 This sounds like a very interesting idea. But does it matter? My concern is that Trickle has been demonstrated to work well in = multiple protocol implementations with years of experience behind them. = This doesn't mean that Trickle is perfect: Joakim has pointed out how = there can be some unbalanced edge cases. But the goal here (RPL WG) = isn't to come up with new, interesting ideas, but rather to standardize = current, well-established practice. With my academic hat on, I think think this is a fascinating direction = for investigation and research. With my engineering hat on, I am very = skeptical. Phil From yoav@yitran.com Tue Apr 6 15:24:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4063A68A4 for ; Tue, 6 Apr 2010 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DkMnkeiihR for ; Tue, 6 Apr 2010 15:24:40 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 70B1228C142 for ; Tue, 6 Apr 2010 15:21:10 -0700 (PDT) Received: from source ([72.14.220.153]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKS7uz0yIiA62jETm+BDDFrfucps3VqeV6@postini.com; Tue, 06 Apr 2010 15:21:11 PDT Received: by fg-out-1718.google.com with SMTP id d23so193623fga.16 for ; Tue, 06 Apr 2010 15:21:07 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> <001c01cad5c4$77c8b8f0$675a2ad0$@com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrVzqKDlMIKgLJxRROTaFy/AvPz1gABOD4g Date: Wed, 7 Apr 2010 01:21:05 +0300 Received: by 10.239.187.129 with SMTP id l1mr702366hbh.86.1270592466875; Tue, 06 Apr 2010 15:21:06 -0700 (PDT) Message-ID: <168d73a61dcec2047687f031edd1e3d7@mail.gmail.com> To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2010 22:24:41 -0000 Thanks for the response. See my comments in body of text. -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Wednesday, April 07, 2010 12:18 AM To: Yoav Ben-Yehezkel Cc: phoebus@ieee.org; roll@ietf.org Subject: Re: [Roll] [roll] #29: DIS packet format On Apr 6, 2010, at 1:05 PM, Yoav Ben-Yehezkel wrote: > Question: > > I understand that responding immediately causes broadcast storms. But our > initial concern was that resetting the trickle timer by all devices > hearing a multicast DIS in a dense network, may also cause congestion by > DIO responses (assuming no suppression is used). This seems like a big assumption. <> Maybe - but the question is whether RPL has to work under this worst case assumption? I don't know the answer. Was hoping to get the input from the WG. <> > I was wondering whether a quick exponentially decaying reduction or > reduction with probability of the timer do instead of a full timer reset > (maybe multiplication or probability factors can be set on the DIS > message)? For unicast DIS, the factors can indicate 100% timer reset. That's an interesting question: seems like the exact kind of thing that simulations, validated by experiments on real networks, can evaluate. <> I agree. Are there WG members with a ready simulation that can quickly check this? <> > This can allow the DIS transmitter to make a flexible protocol that allows > for multiple "waves" of DIS messages to be sent by the same node, where > the probability or the reduction factor starts off small, and is increased > gradually if the DIS transmitter requires more DIO responses. This > protocol would also converge much faster if we can come up with a way of > not sending DIOs that were already sent in previous "waves" (but let's > focus on one problem solving at a time :) ) > This sounds like a very interesting idea. But does it matter? My concern is that Trickle has been demonstrated to work well in multiple protocol implementations with years of experience behind them. This doesn't mean that Trickle is perfect: Joakim has pointed out how there can be some unbalanced edge cases. But the goal here (RPL WG) isn't to come up with new, interesting ideas, but rather to standardize current, well-established practice. <> I agree and I wasn't insinuating that this will be part of RPL specification, I was just pointing out that this field of multiplication or probability factor could leave lots of flexibility and enhancements should someone try this direction for future research or even proprietary use. I really see one proprietary place where it matters from our experience in low speed PLC networks. We see asymmetry of more than 20db difference on opposite links caused by Receiver noises and Transmitter loads, so unlike the wireless media - for us the assumption that a opposite link exists when receiving a DIO cannot be implicit in many cases. Loosing the link with a parent from the parent set without the parent loosing the link with the child is common and doing lots of pings is a waste. So having a DIS/DIO session occasionally would really help to quickly find alternate parents+update rank, and filtering DIO responses would also help in these cases. Does use of this kind of algorithm can remain proprietary as long as the behavior of the transmitter transmitting the DIS and receiver once receiving the DIS packet follows the critical MUST path of RPL? <> With my academic hat on, I think think this is a fascinating direction for investigation and research. With my engineering hat on, I am very skeptical. <> :) With my academic hat on & :( with my engineering hat on. Phil From abr@sdesigns.dk Wed Apr 7 02:08:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249F03A6874 for ; Wed, 7 Apr 2010 02:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.56 X-Spam-Level: * X-Spam-Status: No, score=1.56 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MANGLED_HOME=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g4XELbzXpUj for ; Wed, 7 Apr 2010 02:08:44 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 178713A67D4 for ; Wed, 7 Apr 2010 02:08:43 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 11:08:40 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FD2@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-brandt-roll-rpl-applicability-home-building-00 Thread-Index: AcrWIYR0V0VXACAqQ3WxpsXyqwydNAAC1BVwAAE0WQA= From: "Anders Brandt" To: Subject: [Roll] FW: New Version Notification for draft-brandt-roll-rpl-applicability-home-building-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 09:08:45 -0000 Gentlemen, An applicability statement "The use of RPL in Building and Home Environments" has been submitted to the I-D database. It will form the basis for the P2P and route repair discussion in RPL. https://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-hom e-building/ Cheers, Anders -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, April 07, 2010 09:11 To: Anders Brandt Cc: Emmanuel.Baccelli@inria.fr; robert.cragie@gridmerge.com Subject: New Version Notification for draft-brandt-roll-rpl-applicability-home-building-00=20 A new version of I-D, draft-brandt-roll-rpl-applicability-home-building-00.txt has been successfully submitted by Anders Brandt and posted to the IETF repository. Filename: draft-brandt-roll-rpl-applicability-home-building Revision: 00 Title: Applicability Statement: The use of RPL in Building and Home Environments Creation_date: 2010-04-06 WG ID: Independent Submission Number_of_pages: 6 Abstract: The purpose of this document is to to provide guidance in the use of RPL to provide the features required in building or home environments, two application spaces which share a substantial number of requirements. Note that this document refers to a specific revision of the RPL draft, and thus, a new revision of the RPL draft will likely necessitate a new revision of this document. =20 The IETF Secretariat. From abr@sdesigns.dk Wed Apr 7 04:04:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACB33A68CD for ; Wed, 7 Apr 2010 04:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cONxzsxUgADA for ; Wed, 7 Apr 2010 04:04:12 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id DF7653A68C7 for ; Wed, 7 Apr 2010 04:04:11 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD642.0BBEFB0E" Date: Wed, 7 Apr 2010 13:04:08 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FD8@zensys17.zensys.local> In-Reply-To: <4BB38ECC.5050604@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrQ/L7d7XMPQnUGTmim4N9GUPk5IgFRHGMA References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu><9317.1269879175@marajade.sandelman.ca><01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net><20100.1269887835@marajade.sandelman.ca><00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net><7375.1269904161@marajade.sandelman.ca><01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net><17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> From: "Anders Brandt" To: "Kris Pister" Cc: roll Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 11:04:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD642.0BBEFB0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kris Pister wrote: =20 >For those using TSCH (802.15.4E), there's built-in replay protection because all nodes in the network share a common sense of time.=20 >Absolute Slot Number is a monotonic representation of time, and acts like a nonce in the MIC calculation, so replaying a packet in a >different time slot doesn't work. =20 Just a reminder: (also emphasized in Anaheim): Some PHY/MAC layers provide adequate security, others do not. Therefore it was agreed that the security framework must describe what is required but not mandate that the IP layer implements this security. i.e. if L2 security is good, do not replicate it on L3. =20 >This is a nice example, in that it's akin to the sort of weird RF behavior that occurs naturally. Nodes far apart in the network suddenly >hear each other quite well for some period of time, and then just as mysteriously don't hear each other anymore.=20 >RPL had better be able to deal with this, or we're in deep trouble. =20 +1 - Anders ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Kris Pister Sent: Wednesday, March 31, 2010 20:05 To: Michael Richardson Cc: 'roll' Subject: Re: [Roll] Mixed mode operation =09 =09 Michael Richardson wrote:=20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =09 =09 =20 "Don" =3D=3D Don Sturek writes: =20 Don> It would make sense to recommend to vendors they implement a Don> route entry management solution and to even provide a best Don> practices. =09 Don> On the point below on hacker exploitation, mesh routing relies Don> on distributed routing. I think all router devices need to be Don> authenticated before being allowed to participate. For any =09 Authentication may not solve anything if it does not include non-spoofable replay protection. My experience with L2-"security" is that it does not provide this. =20 For those using TSCH (802.15.4E), there's built-in replay protection because all nodes in the network share a common sense of time. Absolute Slot Number is a monotonic representation of time, and acts like a nonce in the MIC calculation, so replaying a packet in a different time slot doesn't work. =09 Consider that one can record and replay packets. An attacker can record packets in one part of the network and replay=20 them back in another part of the network. Think of someone with a tape recorder recording your voice in your house, and then playing it back in your office, to make someone believe you are in the office. This works even if you speak in code. =20 =09 This is not an active mitm attack, because no packets are actually removed or intercepted.=20 =09 This is a VERY HARD problem to solve, because really, if the attacker just installed a high-gain antenna in one part of the building, a coax cable, and another antenna in another part of the building, it's really the same thing! The difference is perhaps that the totally passive system will relay packets usefully.=20 =20 This is a nice example, in that it's akin to the sort of weird RF behavior that occurs naturally. Nodes far apart in the network suddenly hear each other quite well for some period of time, and then just as mysteriously don't hear each other anymore. RPL had better be able to deal with this, or we're in deep trouble. =09 ksjp =09 So, again my situation is: =09 mcr> The situation I want to think about is what happens when there mcr> are n+1 entries needed, and only n available. Not 2n, or 10n. =09 If I make a particular node think it's adjacent now to n+1 nodes, which routing entry is flushed out? =09 - --=20 ] 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 =20 then sign the petition.=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys =09 =09 iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ =09 fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t =09 lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3 =09 aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd =09 tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA=3D=3D =3D0QxQ -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAD642.0BBEFB0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Kris Pister wrote:
 
>For those=20 using TSCH (802.15.4E), there's built-in replay protection because all = nodes in=20 the network share a common sense of time. 
>Absolute Slot=20 Number is a monotonic representation of time, and acts like a nonce in = the MIC=20 calculation, so replaying a packet in a
>different time=20 slot doesn't work.
 
Just=20 a reminder: (also emphasized in Anaheim):
Some PHY/MAC layers=20 provide adequate security, others do = not.
Therefore it was agreed that = the security=20 framework must describe what is required but not mandate that = the IP layer=20 implements this security.
i.e. if L2 security is good, do not replicate = it on=20 L3.
 
>This is a nice=20 example, in that it's akin to the sort of weird RF behavior that occurs=20 naturally.  Nodes far apart in the network suddenly
>hear each=20 other quite well for some period of time, and then just as mysteriously = don't=20 hear each other anymore. 
>RPL had better=20 be able to deal with this, or we're in deep trouble.
 
+1

- = Anders

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Kris = Pister
Sent:=20 Wednesday, March 31, 2010 20:05
To: Michael = Richardson
Cc:=20 'roll'
Subject: Re: [Roll] Mixed mode = operation

Michael Richardson wrote:=20 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


  
"Don" =3D=3D Don =
Sturek <d.sturek@att.net> writes:
            =
Don> It would make sense to recommend to = vendors they implement a Don> route entry management solution and to even provide a best Don> practices. Don> On the point below on hacker exploitation, mesh routing = relies Don> on distributed routing. I think all router devices need to = be Don> authenticated before being allowed to participate. For any Authentication may not solve anything if it does not include non-spoofable replay protection. My experience with L2-"security" is that it does not provide this.
For those using TSCH (802.15.4E), there's built-in = replay=20 protection because all nodes in the network share a common sense of=20 time.  Absolute Slot Number is a monotonic representation of = time, and=20 acts like a nonce in the MIC calculation, so replaying a packet in a = different=20 time slot doesn't work.
Consider that one can record and replay =
packets.
An attacker can record packets in one part of the network and replay=20
them back in another part of the network.    Think of someone with a
tape recorder recording your voice in your house, and then playing it
back in your office, to make someone believe you are in the office.
This works even if you speak in code. =20

This is not an active mitm attack, because no packets are actually
removed or intercepted.=20

This is a VERY HARD problem to solve, because really, if the attacker
just installed a high-gain antenna in one part of the building, a coax
cable, and another antenna in another part of the building, it's really
the same thing!  The difference is perhaps that the totally passive
system will relay packets usefully.=20
This is a nice example, in that it's akin to the = sort of=20 weird RF behavior that occurs naturally.  Nodes far apart in the = network=20 suddenly hear each other quite well for some period of time, and then = just as=20 mysteriously don't hear each other anymore.  RPL had better be = able to=20 deal with this, or we're in deep trouble.

ksjp
So, again my situation is:

mcr> The situation I want to think about is what happens when there
mcr> are n+1 entries needed, and only n available.  Not 2n, or 10n.

If I make a particular node think it's adjacent now to n+1 nodes, which
routing entry is flushed out?

- --=20
]       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.o=
n.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.yout=
ube.com/watch?v=3Dkzx1ycLXQSE>
	               then sign the petition.=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ
fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t
lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3
aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd
tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP
Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA=3D=3D
=3D0QxQ
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
------_=_NextPart_001_01CAD642.0BBEFB0E-- From abr@sdesigns.dk Wed Apr 7 04:14:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9293A68E7 for ; Wed, 7 Apr 2010 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1WpRd9quodh for ; Wed, 7 Apr 2010 04:14:33 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id A94FF3A68F1 for ; Wed, 7 Apr 2010 04:14:32 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 13:14:29 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrREM19bqkOxVY3S6CkAvp10DeQNAAUTalQATgQ5hA= References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu><1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" , "Mukul Goyal" , "Owen Kirby" Cc: roll Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 11:14:35 -0000 Pascal wrote: > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Thursday, April 01, 2010 08:35 > To: Mukul Goyal; Owen Kirby > Cc: roll > Subject: Re: [Roll] Mixed mode operation >=20 > Hi Owen and Mukul: >=20 > It seems that for every problem we should spell out the=20 > stateless and the stateful models. >=20 > The NACK is a response to the stateful mode problem of the=20 > saturation of the routing table in a parent that is an=20 > intermediate router somewhere in the network. The NACK does=20 > not address the saturation of the root. > The problem cannot be addressed by simple planning because it=20 > has to do with the parent selection algorithm. Upon a NACK, a=20 > node would select an alternate parent as that is not=20 > saturated for its excess DAO. If the network is appropriately=20 > planned and dimensioned, such a parent should exist. This=20 Home users do no planning and dimensioning. They plug in stuff and push buttons. We better have a strategy for unappropriate network topologies. (Sorry. Couldn't help commenting on this one!) > pushes the saturation problem back up to the root, where it=20 > can be handled more easily. >=20 > At this point, the question is whether the root itself is=20 > saturated or not. This problem is common to stateful and=20 > source route. And the answer is, again, network planning. As=20 > a network evolves and grows, if a root is getting close to=20 > capacity, the user needs to deploy an additional root. We=20 > could do better than that in some future, by pushing nodes=20 > from one DODAG to the next to improve the load balancing=20 > between roots. Like I said, I think that can be done. But=20 > Phil and JP indicated their reluctance to additional=20 > mechanisms, and certainly this has a lesser degree of criticality.=20 >=20 > Finally, the NACK is just another ACK, with a failure Return=20 > code. What the issue is about is having an ACK. I take it=20 > that Owen agrees with us that it is useful for stateful? >=20 > Note that the ACK that is proposed in issue #27 is not=20 > end-to-end but hop-by-hop. The biggest reason is to make the=20 > DAO more reliable. Once we have it, then we can derive=20 > benefits like the NACK. >=20 > Whether there is a need for end-to-end ack for source route=20 > mode is TBD. RF is inherently unreliable. Unless I receive an end-to-end ack I must assume that my message was lost. Relying on a message telling me that delivery failed at repeater #4 is wishfull thinking. That message may be lost as well. Thus the answer is yes. > I see what Owen is proposing. What do others think? >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Mukul Goyal > > Sent: Wednesday, March 31, 2010 10:29 PM > > To: Owen Kirby > > Cc: roll > > Subject: Re: [Roll] Mixed mode operation > >=20 > > Hi Owen > >=20 > > I guess one could argue that in a non-storing LLN the DAG=20 > root is the > only > > storing node. So if it can not store a DAO, the DAO can not=20 > be stored > at all. > > But still it is important for a node to know that its DAO can not be > stored. It > > could use this information to decide whether to jump to (or join) > another > > DAG. So, clearly a positive DAO ACK makes sense. > >=20 > > Now, in case of a storing LLN, a parent does not need to=20 > "route" a DAO > ACK > > back. So, negative DAO ACKs would work fine. The benefit of negative > DAO > > ACK is less message generation. > >=20 > > Thanks > > Mukul > >=20 > > ----- Original Message ----- > > From: "Mukul Goyal" > > To: "Owen Kirby" > > Cc: "roll" > > Sent: Wednesday, March 31, 2010 2:51:40 PM GMT -06:00 US/Canada > Central > > Subject: Re: [Roll] Mixed mode operation > >=20 > > Hi Owen > >=20 > > This makes sense to me. > >=20 > > Thanks > > Mukul > >=20 > > ----- Original Message ----- > > From: "Owen Kirby" > > To: "Mukul Goyal" > > Cc: "Pascal Thubert (pthubert)" , "roll" > > > Sent: Wednesday, March 31, 2010 2:40:09 PM GMT -06:00 US/Canada > Central > > Subject: Re: [Roll] Mixed mode operation > >=20 > > Mukul, Pascal, > >=20 > > Please correct me if I'm wrong, but are we really sure a *negative* > ack is > > what we need in this case? > >=20 > > It seems to me that if the root needs to send a negative ack because > the > > routing tables are full, then the root could be in a state=20 > where it's > unable to > > route the NACK to the node that sent the DAO in the first place. In > which > > case, the node never gets a NACK and will assume that the reverse > route is > > being stored on the root. > >=20 > > To illustrate how this might happen on a non-caching network: > >=20 > > A -> B -> C -> ... -> Root > >=20 > > 1) C sends a DAO, and fills up the routing table on the DAG=20 > root so it > can't > > accept any more DAOs. > > 2) B sends a DAO to the root. The root can route a NACK back because > it > > knows how to route to C, and the parent set in B's DAO contains C. > > 3) A sends a DAO to the root, but the root doesn't have a route to B > and thus > > can't find a route back to A. > >=20 > > It seems to me that a positive ack would be more appropriate in this > case. > > This would also prevent inconsistencies if the DAO or NACK gets lost > due to > > interference. > >=20 > > Thanks, > > Owen > >=20 > > Mukul Goyal wrote: > > > Pascal, > > > > > > > > >> If a parent can reject a DAO with a negative ack, then the child > can > > >> > > > select an alternate parent for that DAO and the light=20 > will come up. > > > This is the bare minimum we can do. We already have an=20 > issue on this=20 > > > and I'm asking support on the proposal. > > > > > > > > > I totally support the negative DAO ack. I think it is critical. > > > > > > Thanks > > > Mukul > > > > > > ----- Original Message ----- > > > From: "Pascal Thubert (pthubert)" > > > To: "Philip Levis" > > > Cc: "roll" > > > Sent: Wednesday, March 31, 2010 4:28:09 AM GMT -06:00 US/Canada=20 > > > Central > > > Subject: Re: [Roll] Mixed mode operation > > > > > > Hi Phil: > > > > > > I do not think that we can live without enough capacity, trying to > fix > > > that is a nightmare. I just wish that a network with=20 > enough capacity=20 > > > works, and that is not obvious today. On the contrary, I'm afraid > that > > > if we do nothing, a well dimensioned network will randomly expose=20 > > > routing table capacity issues that will be difficult to justify. > > > > > > We seem to agree that the problem is mostly a deployment problem, > add > > > a root, right? That's certainly fine with the usual mesh problem > when > > > the weak link is the bandwidth at the root. That's=20 > probably failing=20 > > > short when the capacity problem is the routing table in a=20 > node hops=20 > > > away from the root. > > > > > > With the current spec, all the nodes around could select a same > parent > > > and overload it while alternates exist with plenty of room. This > might > > > push the capacity problem hops away from the root. If a candidate=20 > > > parent can hint that it is loaded and not willing to accept much > more, > > > then the parent selection in the children can load balance with > other > > > parents. So the problem is again pushed back to the root and we're > safe > > again. > > > > > > If a parent can reject a DAO with a negative ack, then=20 > the child can=20 > > > select an alternate parent for that DAO and the light=20 > will come up. > > > This is the bare minimum we can do. We already have an=20 > issue on this=20 > > > and I'm asking support on the proposal. > > > > > > Pascal > > > > > > > > > > > >> -----Original Message----- > > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > > >> Sent: Tuesday, March 30, 2010 7:03 PM > > >> To: Pascal Thubert (pthubert) > > >> Cc: Michael Richardson; roll > > >> Subject: Re: [Roll] Mixed mode operation > > >> > > >> On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: > > >> > > >> > > >>> Hi: > > >>> > > >>> As Phil said the anti-replay came up in Anaheim. This=20 > piece is to > be > > >>> covered in the security analysis. So I think we should only > consider > > >>> the saturation of routing tables in this thread. > > >>> > > >>> Also I do not believe in churn in routing tables to address > capacity > > >>> overload. We've seen in ND that a cache that's not dimensioned=20 > > >>> appropriately (too small) just causes permanent look ups that=20 > > >>> multiply the traffic in the network, loss and latency. > > >>> > > >>> In classical mesh networking, what you do when the network gets > > >>> > > > fully > > > > > >>> busy is that you add another root. Capacity management=20 > becomes a=20 > > >>> deployment issue. Usually what we address there is the=20 > bandwidth=20 > > >>> capacity on the root radio space. In this thread, the=20 > problem is a > > >>> > > > bit > > > > > >>> different and the routing table overload might occur one or more > > >>> > > > hops > > > > > >>> away from the root. Still, the solution to increase=20 > capacity needs > > >>> > > > is > > > > > >>> probably divide and conquer, and nothing will replace a proper=20 > > >>> capacity planning overall. > > >>> > > >>> RPL enables DAGs that are made of multiple DODAGs. RPL=20 > enables the=20 > > >>> radio roots to be connected to a backbone, with a=20 > super-root there > > >>> > > > if > > > > > >>> you want a single DODAG. RPL dynamically adapts to the=20 > addition or > > >>> > > > the > > > > > >>> removal of a root in an instance so adapting the=20 > capacity to new=20 > > >>> requirements has only a local impact on the network. It also > adapts > > >>> dynamically to the addition of a parent in the DODAG to=20 > share the > > >>> > > > load > > > > > >> close to the root. > > >> > > >>> So we can do divide and conquer dynamically. > > >>> > > >>> If there are enough parents and still one parent is overloaded=20 > > >>> somewhere, then we might have an issue with the parent=20 > selection. > At > > >>> the moment, a parent cannot indicate the capacity of=20 > its routing=20 > > >>> table, so a node might attach to parent that has no room for it. > > >>> > > > Also, > > > > > >>> one of the reasons for a DAO ack is for a parent to reject a DAO > for > > >>> lack of capacity. > > >>> > > >>> If there are enough roots and still one DODAG is overloaded > > >>> > > > somewhere, > > > > > >>> then we might have an issue with the DODAG selection. We need is > to > > >>> push nodes on the ridge between DADOGs to jump onto the other > > DODAG > > >>> > > >> in > > >> > > >>> order to balance the load between DODAGs. To do that, we need a=20 > > >>> pushback mechanism from the nodes where the capacity is=20 > reached to > > >>> > > > the > > > > > >>> nodes on the ridge that can jump elsewhere. > > >>> > > >>> I'm not saying that this is easy, but I think it can be done. > > >>> > > >> I really think this is outside the protocol=20 > specification and is a > > >> > > > non-issue. Does > > > > > >> any other routing protocol specify what happens when there is > > >> > > > insufficient > > > > > >> space in a routing table? It's an=20 > implementation-specific decision. > > >> At > > >> > > > the very > > > > > >> least, it should be outside the core specification. > > >> > > >> It's an operational/administrative issue: if the=20 > network's routing > > >> > > > tables are > > > > > >> overloaded, add another root. Rank and incrementing=20 > DODAG sequence=20 > > >> numbers are a perfectly reasonable way to achieve this. We don't > need > > >> additional complexity. > > >> > > >> Phil > > >> > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > >=20 > > _______________________________________________ > > 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 >=20 From pal@cs.stanford.edu Wed Apr 7 09:14:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76203A695A for ; Wed, 7 Apr 2010 09:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zP95U6cSQhQ for ; Wed, 7 Apr 2010 09:14:01 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 637383A6AA5 for ; Wed, 7 Apr 2010 09:12:40 -0700 (PDT) Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzXrp-0003G9-DZ; Wed, 07 Apr 2010 09:12:37 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> Date: Wed, 7 Apr 2010 08:35:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A80A97B-880F-4FB9-876E-468FB8DFEBA0@cs.stanford.edu> References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu><1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 Cc: roll Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 16:14:04 -0000 On Apr 7, 2010, at 4:14 AM, Anders Brandt wrote: > Pascal wrote: >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 >> Behalf Of Pascal Thubert (pthubert) >> Sent: Thursday, April 01, 2010 08:35 >> To: Mukul Goyal; Owen Kirby >> Cc: roll >> Subject: Re: [Roll] Mixed mode operation >>=20 >> Hi Owen and Mukul: >>=20 >> It seems that for every problem we should spell out the=20 >> stateless and the stateful models. >>=20 >> The NACK is a response to the stateful mode problem of the=20 >> saturation of the routing table in a parent that is an=20 >> intermediate router somewhere in the network. The NACK does=20 >> not address the saturation of the root. >> The problem cannot be addressed by simple planning because it=20 >> has to do with the parent selection algorithm. Upon a NACK, a=20 >> node would select an alternate parent as that is not=20 >> saturated for its excess DAO. If the network is appropriately=20 >> planned and dimensioned, such a parent should exist. This=20 >=20 > Home users do no planning and dimensioning. > They plug in stuff and push buttons. > We better have a strategy for unappropriate network topologies. >=20 > (Sorry. Couldn't help commenting on this one!) Agreed. But we also need to acknowledge that at some point things have = to give. Vendors will sell devices that have the range and resources to = work in expected configurations. E.g., we can't expect RPL to work in a = typical home automation setting if the radio range is 1 inch or if the = nodes have 1 byte of RAM. Nor can we expect RPL to work well when there = are 1 billion nodes in a cubic meter. Of course, the more robust and = flexible (in the sense of network topologies, not software options and = knobs), RPL is, the broader the set of expected configurations under a = set of resources will be. The unconstrained task is impossible: a network of tiny microcontrollers = that always works with low latency in all possible configurations, = densities, and environments. Phil From Jerald.P.Martocci@jci.com Wed Apr 7 09:58:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3502A3A69A5; Wed, 7 Apr 2010 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyubvcb89m9b; Wed, 7 Apr 2010 09:58:50 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id F1C1D3A6860; Wed, 7 Apr 2010 09:58:49 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKS7y5xvZo+ZUlX5BYIz6ZQDPYtyL9VApm@postini.com; Wed, 07 Apr 2010 09:58:47 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010040711583515-242575 ; Wed, 7 Apr 2010 11:58:35 -0500 In-Reply-To: <5A80A97B-880F-4FB9-876E-468FB8DFEBA0@cs.stanford.edu> References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu><1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> <5A80A97B-880F-4FB9-876E-468FB8DFEBA0@cs.stanford.edu> To: Philip Levis MIME-Version: 1.0 X-KeepSent: 09C877B9:8F868038-862576FE:0059CD79; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 7 Apr 2010 11:58:39 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/07/2010 11:58:43 AM, Serialize complete at 04/07/2010 11:58:43 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2010 11:58:35 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2010 11:58:39 AM, Serialize complete at 04/07/2010 11:58:39 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1" Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 16:58:56 -0000

Hi Phil,

Agreed,  However, I think we (R= OLL WG) must provide a solution that works at least as well as the wireless sensor implementations we already market; and at the same labor and product cost point.  Otherwise, our customers question our use of the technolo= gy.  Unfortunately, (at least in the commercial market) there is currently little sway we get from our customers simply because the solution is IP based.  My customers are only interested in controlling the environment in their buildings.  

I know the commercial building requi= rement draft (and I believe Ander's Home Requirement Draft) clearly quantifies these requirements.  Here are some snippets of the draft that we should be designing the router protocol toward:
.  
  • It must be possible to fully commiss= ion network devices without requiring any additional commissioning device (e.g., laptop). From the ROLL perspective, zero-configuration means that a node can obtain an address and join the network on its own, without human interv= ention.
  • HVAC room applications typically have sensors/actuators and controllers spaced about 50 ft apart.  Lighting is also very unifo= rmly installed with ballasts installed approximately every 10 feet.
  • The routing protocol must be able to support networks with at least 2000 nodes where 1000 nodes would act as routers and the other 1000 nodes would be hosts.  
  • The software size requirements for r= outing devices (e.g., room controllers) should be implementable in 8-bit devices with no more than 256KB of flash memory.  The software size requirement for non-routing devices (e.g., sleeping sensors and actuators) should be implementable in 8-bit devices with no more than 128KB of memory.  
  • A node transmitting a ‘request= with expected reply’ to another node must send the message to the destinat= ion and receive the response in not more than 120ms.  This response time should be achievable with 5 or less hops in each direction.  When I drafted these requirements, I simply documented the empirical performance as measured on our existing products.  If RPL implementations meet these capacity and performance measures my customers will be satisfied; if not, I'm not sure RPL will be successful in the commercial market.


    Jerry




    From: Philip Levis <pal@cs.stanford.edu= >
    To: Anders Brandt <abr@sdesigns.dk>= ;
    Cc: roll <roll@ietf.org>
    Date: 04/07/2010 11:14 AM
    Subject: Re: [Roll] Mixed mode operation





    On Apr 7, 2010, at 4:14 AM, Anders Brandt wrote:

    > Pascal wrote:
    >
    >> -----Original Message-----
    >> From: roll-bounces@ietf.org [    mailto:roll-bounces@ietf.org= ] On
    >> Behalf Of Pascal Thubert (pthubert)
    >> Sent: Thursday, April 01, 2010 08:35
    >> To: Mukul Goyal; Owen Kirby
    >> Cc: roll
    >> Subject: Re: [Roll] Mixed mode operation
    >>
    >> Hi Owen and Mukul:
    >>
    >> It seems that for every problem we should spell out the
    >> stateless and the stateful models.
    >>
    >> The NACK is a response to the stateful mode problem of the
    >> saturation of the routing table in a parent that is an
    >> intermediate router somewhere in the network. The NACK does
    >> not address the saturation of the root.
    >> The problem cannot be addressed by simple planning because it
    >> has to do with the parent selection algorithm. Upon a NACK, a
    >> node would select an alternate parent as that is not
    >> saturated for its excess DAO. If the network is appropriately
    >> planned and dimensioned, such a parent should exist. This
    >
    > Home users do no planning and dimensioning.
    > They plug in stuff and push buttons.
    > We better have a strategy for unappropriate network topologies.
    >
    > (Sorry. Couldn't help commenting on this one!)

    Agreed. But we also need to acknowledge that at some point things have to give. Vendors will sell devices that have the range and resources to work in expected configurations. E.g., we can't expect RPL to work in a typical home automation setting if the radio range is 1 inch or if the nodes have 1 byte of RAM. Nor can we expect RPL to work well when there are 1 billion nodes in a cubic meter. Of course, the more robust and flexib= le (in the sense of network topologies, not software options and knobs), RPL is, the broader the set of expected configurations under a set of resources will be.

    The unconstrained task is impossible: a network of tiny microcontrollers that always works with low latency in all possible configurations, densitie= s, and environments.

    Phil


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

    From pal@cs.stanford.edu Wed Apr 7 10:36:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22DC3A6ABD for ; Wed, 7 Apr 2010 10:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbSh-jBPJCkN for ; Wed, 7 Apr 2010 10:36:08 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0EC4D3A6A8E for ; Wed, 7 Apr 2010 10:36:07 -0700 (PDT) Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzZAZ-0003SL-TC; Wed, 07 Apr 2010 10:36:04 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-6-296787490 From: Philip Levis In-Reply-To: Date: Wed, 7 Apr 2010 10:36:03 -0700 Message-Id: <786E9949-2E55-4503-966E-8F0B5A4A699D@cs.stanford.edu> References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu><1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> <5A80A97B-880F-4FB9-876E-468FB8DFEBA0@cs.stanford.edu> To: Jerald.P.Martocci@jci.com X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 104fcb84af92cc131bf6e023e43ddbb4 Cc: roll WG Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 17:36:09 -0000 --Apple-Mail-6-296787490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 7, 2010, at 9:58 AM, Jerald.P.Martocci@jci.com wrote: >=20 >=20 > Hi Phil,=20 >=20 > Agreed, However, I think we (ROLL WG) must provide a solution that = works at least as well as the wireless sensor implementations we already = market; and at the same labor and product cost point. Otherwise, our = customers question our use of the technology. Unfortunately, (at least = in the commercial market) there is currently little sway we get from our = customers simply because the solution is IP based. My customers are = only interested in controlling the environment in their buildings. =20 >=20 > I know the commercial building requirement draft (and I believe = Ander's Home Requirement Draft) clearly quantifies these requirements. = Here are some snippets of the draft that we should be designing the = router protocol toward:=20 > . =20 > It must be possible to fully commission network devices without = requiring any additional commissioning device (e.g., laptop). =46rom the = ROLL perspective, zero-configuration means that a node can obtain an = address and join the network on its own, without human intervention. > HVAC room applications typically have sensors/actuators and = controllers spaced about 50 ft apart. Lighting is also very uniformly = installed with ballasts installed approximately every 10 feet. > The routing protocol must be able to support networks with at least = 2000 nodes where 1000 nodes would act as routers and the other 1000 = nodes would be hosts. =20 > The software size requirements for routing devices (e.g., room = controllers) should be implementable in 8-bit devices with no more than = 256KB of flash memory. The software size requirement for non-routing = devices (e.g., sleeping sensors and actuators) should be implementable = in 8-bit devices with no more than 128KB of memory. =20 > A node transmitting a =91request with expected reply=92 to another = node must send the message to the destination and receive the response = in not more than 120ms. This response time should be achievable with 5 = or less hops in each direction. =20 > When I drafted these requirements, I simply documented the empirical = performance as measured on our existing products. If RPL = implementations meet these capacity and performance measures my = customers will be satisfied; if not, I'm not sure RPL will be successful = in the commercial market.=20 Jerry, This is fantastic. Nice, precise requirements. Phil= --Apple-Mail-6-296787490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Jerald.P.Martocci@jci.com = wrote:


    Hi Phil,

    Agreed,  However, I think = we (ROLL WG) must provide a solution that works at least as well as the wireless sensor implementations we already market; and at the same labor and = product cost point.  Otherwise, our customers question our use of the = technology.  Unfortunately, (at least in the commercial market) there is = currently little sway we get from our customers simply because the solution is IP based.  My customers are only interested in controlling the = environment in their buildings.  

    I know the commercial building = requirement draft (and I believe Ander's Home Requirement Draft) clearly quantifies these requirements.  Here are some snippets of the draft that we = should be designing the router protocol toward:
    .  
    • It must be possible to fully = commission network devices without requiring any additional commissioning device = (e.g., laptop). =46rom the ROLL perspective, zero-configuration means that a = node can obtain an address and join the network on its own, without human = intervention.
    • HVAC room applications = typically have sensors/actuators and controllers spaced about 50 ft apart.  Lighting is also very = uniformly installed with ballasts installed approximately every 10 feet.
    • The routing protocol must = be able to support networks with at least 2000 nodes where 1000 nodes would act as routers and the other 1000 nodes would be hosts.  
    • The software size = requirements for routing devices (e.g., room controllers) should be implementable in 8-bit = devices with no more than 256KB of flash memory.  The software size = requirement for non-routing devices (e.g., sleeping sensors and actuators) should be implementable in 8-bit devices with no more than 128KB of memory. =  
    • A node transmitting a = =91request with expected reply=92 to another node must send the message to the = destination and receive the response in not more than 120ms.  This response = time should be achievable with 5 or less hops in each direction. =  
    When I drafted these requirements, I simply documented the empirical = performance as measured on our existing products.  If RPL implementations meet these capacity and performance measures my customers will be satisfied; if not, I'm not sure RPL will be successful in the commercial = market.

    Jerry,

    This is = fantastic. Nice, precise = requirements.

    Phil
    = --Apple-Mail-6-296787490-- From robert.cragie@gridmerge.com Wed Apr 7 12:50:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC773A6850 for ; Wed, 7 Apr 2010 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx4pMRpfpQeV for ; Wed, 7 Apr 2010 12:50:46 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 244E33A67FA for ; Wed, 7 Apr 2010 12:50:36 -0700 (PDT) Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NzbGh-0002J9-H5 for roll@ietf.org; Wed, 07 Apr 2010 20:50:32 +0100 Message-ID: <4BBCE201.2020206@gridmerge.com> Date: Wed, 07 Apr 2010 20:50:25 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> <56FAF6DE-2204-48FE-8E29-3533BEC7BE4A@cs.stanford.edu> In-Reply-To: <56FAF6DE-2204-48FE-8E29-3533BEC7BE4A@cs.stanford.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010309020800020300000209" Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:50:49 -0000 This is a cryptographically signed message in MIME format. --------------ms010309020800020300000209 Content-Type: multipart/alternative; boundary="------------060208050404030601000700" This is a multi-part message in MIME format. --------------060208050404030601000700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Apologies in advance for the long e-mail. I'm trying to follow this=20 thread and draw some conclusions. _DIO/DAO parent_ I find the terms DIO parent and DAO parent confusing. There can only be=20 one parent type and that is a node with a lower rank than you. This is=20 why I tend to subscribe to Pascal's view that these are really two=20 separate DAGs. If there is some convenient way of amalgamating them then = all well and good but I sometimes wonder if it wouldn't be easier to=20 call them all DAGs and consider the downward route an additional=20 'twig-like' DAG to a single node. In this way, a common objective=20 function for reaching a node makes far more sense. In fact, I wonder what the need for a separate DAO message is at all.=20 The main distinction between a DIO and a DAO is that a DAO sent up the=20 DAG as opposed to multicast, i.e. directed; however the DAO is not=20 /routed /through the DAG and has concept of rank and parents too for=20 propagation. So really it does not seem much different to a DIO. It just = has some rough guidance from another DAG as to where to direct it. So we = could consider three DIO's: 1. DIO to all, multicast 2. DIO to target, multicast 3. DIO to target, directed (1) is what is currently DIO, (2) is what we need for P2P, (3) is what=20 is currently DAO. OK, maybe we just call (3) a DAO still but let's clean = up how it propagates. Note we may be wanting to add Richard's, parent tables to the DIO as=20 well as replacing the DAO RRstack for the non-storing P2P solution. _Link costs and DAG formation_ Regarding link costs and their place in DAG formation, Mukul stated in=20 an earlier e-mail: /So when B receives a multicast DIO from A, B may know: 1) unidirectional cost A->B only or 2) unidirectional cost B->A only or 3) both or 4) none / I would say B always has some semblance of the link cost from A->B by=20 virtue of having received a packet from A. At the very least, it knows A = is able to communicate to B because, well, it received it. It could then = use further metrics such as LQL to further judge the link cost. So I=20 would revise this to: So when B receives a multicast DIO from A, B: 1. will have some notion of unidirectional cost A->B by virtue of receiving it 2. may know unidirectional cost B->A only 3. may know both Consider the simple DAG below. Apologies for the drawn-out scenario and=20 please correct anything which seems wrong. For rank I am using simple=20 cardinal number ordinality: A / \ B C / \ / \ D E F 1. A transmits DIO 2. B hears DIO 1. B knows there is a route from A->B by virtue of receiving it 2. /*B does not necessarily know there is a route from B->A as it may not have the unidirectional link cost from B->A*/ 3. /*If the objective of forming the DODAG is to be able to route to A then B needs some metric for link cost from B->A*/= 4. B must compute its rank based on the objective function, the DIO from A and possibly other stored state 5. B computes its rank as A+1 and marks A as parent 6. Some time later, B transmits DIO 1. D hears DIO 1. D knows there is a route from B->D by virtue of receiving it 2. */D does not necessarily know there is a route from D->B as it may not have the unidirectional link cost from D->B/* 3. */If the objective of forming the DODAG is to be able to route to A then D needs some metric for link cost from D->B/* 4. D must compute its rank based on the objective function, the DIO from B and possibly other stored state 5. D computes its rank as B+1 (=3D A+2) and marks B as a parent 6. Some time later, D transmits DIO 2. E hears DIO 1. E knows there is a route from B->E by virtue of receiving it 2. */E does not necessarily know there is a route from E->B as it may not have the unidirectional link cost from E->B/* 3. */If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->B/* 4. E must compute its rank based on the objective function, the DIO from B and possibly other stored state 5. E computes its rank as B+1 (=3D A+2) and marks B as a parent 6. Some time later, E transmits DIO 3. C hears DIO 1. C knows there is a route from A->C by virtue of receiving it 2. /*C does not necessarily know there is a route from C->A as it may not have the unidirectional link cost from C->A*/ 3. /*If the objective of forming the DODAG is to be able to route from C->A then C needs some metric for link cost from C->A*/ 4. C must compute its rank based on the objective function, the DIO from A and possibly other stored state 5. C computes its rank as A+1 6. Some time later, C transmits DIO 1. E hears DIO (assume E has already heard DIO from B) 1. E knows there is a route from C->E by virtue of receiving it 2. */E does not necessarily know there is a route from E->C as it may not have the unidirectional link cost from E->C/* 3. */If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->C/* 4. E must compute its rank based on the objective function, the DIO from C and possibly other stored state 5. E computes its rank as C+1 (=3D A+2). As it is th= e same as previously calculated rank, it marks C as another potential parent 6. Some time later, E continues to transmit DIO as it was already transmitting it 2. F hears DIO 1. F knows there is a route from C->F by virtue of receiving it 2. /*F does not necessarily know there is a route from F->C as it may not have the unidirectional link cost from F->C*/ 3. /*If the objective of forming the DODAG is to be able to route to A then F needs some metric for link cost from F->C*/ 4. F must compute its rank based on the objective function, the DIO from C and possibly other stored state 5. F computes its rank as C+1 (=3D A+2) and marks C as a parent 6. Some time later, F transmits DIO Consider a path along that DAG, (A - B - D): 1. Using DIOs doesn't naturally form the route from D to A (A <- B <- D) unless outgoing costs (i.e. B's perception of B->A, D's perception of D->B) is known 2. Using a DIO does naturally form the route from A to D (A -> B -> D) on the assumption that reception of data is a reasonable confirmation that a link exists 1. However as DIO originator, A needs to know that D heard its DIO via B therefore still needs a return path back to A via B. So it's catch 22. The bottom line is that I cannot see how DAG formation can function=20 properly without the outgoing cost being known. The question is - how do = we know it? Three possible solutions for A <- B: 1. B receives data from A with A's perception of B->A based on incoming cost 2. B has a perception of B->A outgoing cost based on other metrics e.g. failed L2 acks 3. B assumes that A is reachable by virtue of having received from it (1) is probably the best, (2) is workable but still requires a viable=20 link from A -> B and (3) is guessing. To achieve (1), there is probably=20 some need for additional status messages to propagate this information. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 01/04/2010 3:31 AM, Philip Levis wrote: > > On Mar 31, 2010, at 5:43 PM, Mukul Goyal wrote: > >>>>> I'm not sure I understand the concern. Is it that if this isn't=20 >>>>> stated explicitly, then an implementation might put a neighbor in=20 >>>>> the parent set for which it cannot compute DAGRank from the OF?=20 >>>>> How would it ever compute its own DAGRank? Can you explain the=20 >>>>> failure condition? >>>> >>>> Consider the situation where node A receives a DIO from node B and=20 >>>> knows the cost of link B->A (either it already knew this cost or=20 >>>> DIO carries this cost or it assumes a value for this cost) but not=20 >>>> that of link A->B. Then, node A may be able to compute its DAG rank = >>>> via node B and thus possibly select node B as a DIO parent. But,=20 >>>> even if B becomes a DIO parent, A should not consider B as a=20 >>>> candidate for DAO parenthood because A does not know the cost of=20 >>>> link A->B. >>> >>> [Phil] So a node A MUST NOT select node B as a parent if the OF=20 >>> cannot compute the DAGRank of the resulting route? >>> >>> Node A may have sufficient information to calculate its DAG rank via = >>> B but still may not have the information to calculate B's=20 >>> suitability as a DAO parent (e.g. if OF just considers the upwards=20 >>> costs in calculating the DAG rank and such costs are known to A but=20 >>> requires knowledge of downwards costs for a parent's selection as=20 >>> DAO parent and these downwards costs (from B to A) are not known to A= ). >> >> [Phil] >> I'm sorry -- your sentence is kind of long and convoluted, and I=20 >> can't understand it. >> >> I am sorry too: for the length and convolution of my sentence. :) >> And for the fact that you can't understand it (if you say so). :) >> >> Hey, I am kidding. Dont get mad at me. >> >> [Phil] Does it say yes my sentence is correct or no it is not correct?= >> >> It says that your sentence is not correct. This is because your=20 >> sentence assumes that the DAGrank calculation requires knowledge of=20 >> all sorts of costs that the node may need to choose its DAG or DAO=20 >> parents. This assumption is not true. A DAGrank is simply a loop=20 >> avoidance mechanism that may not be a very good indicator of actual=20 >> routing costs in either direction. I know you would disagree with me=20 >> (based on my understanding of your point of view from your previous=20 >> posts). > > Ah -- I think this is why we can't seem to agree: we're coming from=20 > different assumptions. There was a change in -07; Richard noted that=20 > having Rank *not* reflect a metric is problematic, as it constrains=20 > parent selection. I.e., if Rank does not directly reflect a metric,=20 > it's possible that a node can't pick a better (lower metric) parent=20 > because it has a higher Rank. This led to the inclusion of=20 > MinHopRankIncrease, elevating Rank to 16-bits, and the introduction of = > DAGRank, such that Rank could still reflect a good fidelity metric but = > DAGRank can provide good loop avoidance and topology constraints. > > The operating assumption is that since Rank constrains the set of=20 > parents a node can select, then separating it from metrics is problemat= ic. > > The OF computes the Rank (this has always been the case): it should=20 > have all of the needed information. Or is there something in the draft = > that says it won't? > > Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 --------------060208050404030601000700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apologies in advance for the long e-mail. I'm trying to follow this thread and draw some conclusions.

    DIO/DAO parent

    I find the terms DIO parent and DAO parent confusing. There can only be one parent type and that is a node with a lower rank than you. This is why I tend to subscribe to Pascal's view that these are really two separate DAGs. If there is some convenient way of amalgamating them then all well and good but I sometimes wonder if it wouldn't be easier to call them all DAGs and consider the downward route an additional 'twig-like' DAG to a single node. In this way, a common objective function for reaching a node makes far more sense.

    In fact, I wonder what the need for a separate DAO message is at all. The main distinction between a DIO and a DAO is that a DAO sent up the DAG as opposed to multicast, i.e. directed; however the DAO is not rou= ted through the DAG and has concept of rank and parents too for propagation. So really it does not seem much different to a DIO. It just has some rough guidance from another DAG as to where to direct it. So we could consider three DIO's:
    1. DIO to all, multicast
    2. DIO to target, multicast
    3. DIO to target, directed
    (1) is what is currently DIO, (2) is what we need for P2P, (3) is what is currently DAO. OK, maybe we just call (3) a DAO still but let's clean up how it propagates.

    Note we may be wanting to add Richard's, parent tables to the DIO as well as replacing the DAO RRstack for the non-storing P2P solution.

    Link costs and DAG formation

    Regarding link costs and their place in DAG formation, Mukul stated in an earlier e-mail:

    So when B receives a multicast DIO from A, B may know:

    1) unidirectional cost A->B only or
    2) unidirectional cost B->A only or
    3) both or
    4) none

    I would say B always has some semblance of the link cost from A->B by virtue of having received a packet from A. At the very least, it knows A is able to communicate to B because, well, it received it. It could then use further metrics such as LQL to further judge the link cost. So I would revise this to:

    So when B receives a multicast DIO from A, B:
    1. will have some notion of unidirectional cost A->B by virtue of receiving it
    2. may know unidirectional cost B->A only
    3. may know both
    Consider the simple DAG below. Apologies for the drawn-out scenario and please correct anything which seems wrong. For rank I am using simple cardinal number ordinality:

        A
       / \
      B   C
     / \ / \
    D   E   F

    1. A transmits DIO
    2. B hears DIO
      1. B knows there is a route from A->B by virtue of receiving it
      2. B does not necessarily know there is a route from B->A as it may not have the unidirectional link cost from B->A
        3. =
      3. If the objective of forming the DODAG is to be able to route to A then B needs some metric for link cost from B->A
      4. B must compute its rank based on the objective function, the DIO from A and possibly other stored state
      5. B computes its rank as A+1 and marks A as parent
      6. Some time later, B transmits DIO
        1. D hears DIO
          1. D knows there is a route from B->D by virtue of receiving it
          2. D does not necessarily know there is a route from D->B as it may not have the unidirectional link cost from D->B<= /b>
          3. If the objective of forming the DODAG is to be able to route to A then D needs some metric for link cost from D->B=
          4. D must compute its rank based on the objective function, the DIO from B and possibly other stored state
          5. D computes its rank as B+1 (=3D A+2) and marks B as a parent<= /li>
          6. Some time later, D transmits DIO
        2. E hears DIO
          1. E knows there is a route from B->E by virtue of receiving it
          2. E does not necessarily know there is a route from E->B as it may not have the unidirectional link cost from E->B<= /b>
          3. If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->B
          4. E must compute its rank based on the objective function, the DIO from B and possibly other stored state
          5. E computes its rank as B+1 (=3D A+2) and marks B as a parent<= br>
          6. Some time later, E transmits DIO
    3. C hears DIO
      1. C knows there is a route from A->C by virtue of receiving it
      2. C does not necessarily know there is a route from C->A as it may not have the unidirectional link cost from C->A
        3. =
      3. If the objective of forming the DODAG is to be able to route from C->A then C needs some metric for link cost from C->A
      4. C must compute its rank based on the objective function, the DIO from A and possibly other stored state
      5. C computes its rank as A+1
      6. Some time later, C transmits DIO
        1. E hears DIO (assume E has already heard DIO from B)
          1. E knows there is a route from C->E by virtue of receiving it
          2. E does not necessarily know there is a route from E->C as it may not have the unidirectional link cost from E->C<= /b>
          3. If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->C
          4. E must compute its rank based on the objective function, the DIO from C and possibly other stored state
          5. E computes its rank as C+1 (=3D A+2). As it is the same as previously calculated rank, it marks C as another potential parent
          6. Some time later, E continues to transmit DIO as it was already transmitting it
        2. F hears DIO
          1. F knows there is a route from C->F by virtue of receiving it
          2. F does not necessarily know there is a route from F->C as it may not have the unidirectional link cost from F->C<= /i>
          3. If the objective of forming the DODAG is to be able to route to A then F needs some metric for link cost from F->C
          4. F must compute its rank based on the objective function, the DIO from C and possibly other stored state
          5. F computes its rank as C+1 (=3D A+2) and marks C as a parent<= /li>
          6. Some time later, F transmits DIO
    Consider a path along that DAG, (A - B - D):
    1. Using DIOs doesn't naturally form the route from D to A (A <- B <- D) unless outgoing costs (i.e. B's perception of B->A, D's perception of D->B) is known
    2. Using a DIO does naturally form the route from A to D (A -> B -> D) on the assumption that reception of data is a reasonable confirmation that a link exists
      1. However as DIO originator, A needs to know that D heard its DIO via B therefore still needs a return path back to A via B. So it's catch 22.
    The bottom line is that I cannot see how DAG formation can function properly without the outgoing cost being known. The question is - how do we know it? Three possible solutions for A <- B:
    1. B receives data from A with A's perception of B->A based on incoming cost
    2. B has a perception of B->A outgoing cost based on other metrics e.g. failed L2 acks
    3. B assumes that A is reachable by virtue of having received from it<= /li>
    (1) is probably the best, (2) is workable but still requires a viable link from A -> B and (3) is guessing. To achieve (1), there is probably some need for additional status messages to propagate this information.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888
    http://www.gridmerge.com


    On 01/04/2010 3:31 AM, Philip Levis wrote:

    On Mar 31, 2010, at 5:43 PM, Mukul Goyal wrote:

    I'm not sure I understand the concern. Is it that if this isn't stated explicitly, then an implementation might put a neighbor in the parent set for which it cannot compute DAGRank from the OF? How would it ever compute its own DAGRank? Can you explain the failure condition?

    Consider the situation where node A receives a DIO from node B and knows the cost of link B->A (either it already knew this cost or DIO carries this cost or it assumes a value for this cost) but not that of link A->B. Then, node A may be able to compute its DAG rank via node B and thus possibly select node B as a DIO parent. But, even if B becomes a DIO parent, A should not consider B as a candidate for DAO parenthood because A does not know the cost of link A->B.    

    [Phil] So a node A MUST NOT select node B as a parent if the OF cannot compute the DAGRank of the resulting route?<= br>

    Node A may have sufficient information to calculate its DAG rank via B but still may not have the information to calculate B's suitability as a DAO parent (e.g. if OF just considers the upwards costs in calculating the DAG rank and such costs are known to A but requires knowledge of downwards costs for a parent's selection as DAO parent and these downwards costs (from B to A) are not known to A).

    [Phil]
    I'm sorry -- your sentence is kind of long and convoluted, and I can't understand it.

    I am sorry too: for the length and convolution of my sentence. :)
    And for the fact that you can't understand it (if you say so). :)

    Hey, I am kidding. Dont get mad at me.

    [Phil] Does it say yes my sentence is correct or no it is not correct?
    It says that your sentence is not correct. This is because your sentence assumes that the DAGrank calculation requires knowledge of all sorts of costs that the node may need to choose its DAG or DAO parents. This assumption is not true. A DAGrank is simply a loop avoidance mechanism that may not be a very good indicator of actual routing costs in either direction. I know you would disagree with me (based on my understanding of your point of view from your previous posts).

    Ah -- I think this is why we can't seem to agree: we're coming from different assumptions. There was a change in -07; Richard noted that having Rank *not* reflect a metric is problematic, as it constrains parent selection. I.e., if Rank does not directly reflect a metric, it's possible that a node can't pick a better (lower metric) parent because it has a higher Rank. This led to the inclusion of MinHopRankIncrease, elevating Rank to 16-bits, and the introduction of DAGRank, such that Rank could still reflect a good fidelity metric but DAGRank can provide good loop avoidance and topology constraints.

    The operating assumption is that since Rank constrains the set of parents a node can select, then separating it from metrics is problematic.

    The OF computes the Rank (this has always been the case): it should have all of the needed information. Or is there something in the draft that says it won't?

    Phil
    
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
    --------------060208050404030601000700-- --------------ms010309020800020300000209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0 MDcxOTUwMjVaMCMGCSqGSIb3DQEJBDEWBBR/d4Nxebny0aSJivVsL53tk5BSGjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAEB+CfvvTGjvyua0eUIKZAAw0bLDnEw+edoqPNFAHzZvl3rv/mejcnX8VNjtfDJQ4nU7 0HmtgvD8qtj68qMWoUHfz2/EPIVdnC88zH+oENbt6J3oOEwNafyXYMO7QxpOoIa+a93McMWF gsOgIyfYZP2c/yKetIG6/dfApmf/gED59rg/BT5jOEqnq+q3xOQVDTK/OE/w8l1FVmp9kHus o0LD8we2s++cBEuLpIJkEOO1d2n/Av0QVB0g7JnQurlUP9TWhHAtLEuvZPrzYvNyFC8kBQIg KEclyCiIFX8yKTjJkmXrrHnaby/gjiwEql9cZieF4c6brgr4CEvIokQ5HwQAAAAAAAA= --------------ms010309020800020300000209-- From jeonggil.ko@gmail.com Wed Apr 7 13:05:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25093A67C2 for ; Wed, 7 Apr 2010 13:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XkFydpjxTZe for ; Wed, 7 Apr 2010 13:05:33 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id 920243A67A4 for ; Wed, 7 Apr 2010 13:05:33 -0700 (PDT) Received: by pzk29 with SMTP id 29so1345268pzk.29 for ; Wed, 07 Apr 2010 13:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=3sqtAANSoaghM2+MgYiaJ3jIIN9e0iWSXc+B5eUrW1Q=; b=nZjrGfdli8kIJB/jrNAVSSsyLsErcSBSNFsI+Scr8i2UhkSa8idh3V9UioWo6CaFad LANE4UbaRzztMgGKiHCvZmx4sau8qMe443/54dW4fM9Yyxmjlin8qiIZ4BN4o5wTKhfo lnC4Y1wCgaXnSzz3MNRJu8CSnSNJ3YboNmevg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=YSAZYtZyi0UVwgr9I5FfnUIq/IrV/o10PQi+/cS7XDMbS8/6DkA+RfHHbQJOUfKCSE /2G6TFtGInUXvrnwWKyw3ZLiigOjG4rQYJlvRLXJ4H7sGGL6EA3GSOYjHU80zo9BG830 DbagjNU89qT2dWL2dKizcWr2Eu8YWrkZv4/64= Received: by 10.143.154.37 with SMTP id g37mr3886138wfo.35.1270670727952; Wed, 07 Apr 2010 13:05:27 -0700 (PDT) Received: from dnab4046cc.stanford.edu (DNab4046cc.Stanford.EDU [171.64.70.204]) by mx.google.com with ESMTPS id cm22sm1176123ibb.23.2010.04.07.13.05.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 13:05:27 -0700 (PDT) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 13:05:22 -0700 Message-Id: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Roll] Proposal for Source Routing Header Format and Source Routing Operations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 20:05:34 -0000 Hi! Great to see all this discussions on downwards route establishment! To = add one more to the conversations here is a proposal for source routing = headers. In non-storing mode (where only the root has individual path = information) the root will be attaching a source routing header to the = data packet that a source node wants to send to a specific destination. = We can always make the header super fancy but in my opinion I think we = only need two fields in this header and here it is! Feel free to break = the stuff and mangle with it so that it looks great in the specs later = on. FYI, this is the format that I am using in my implementations so it = does work :) 1. Source Routing Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEntry (8 bits) | = | +-+-+-+-+-+-+-+-+ = + | Source Route Entry (128*NEntry bits) = | + = + | = | Figure 1. Proposed Source Routing Header Format; each line is 32 = bits:) - NEntry: Indicates the number of 128 bit addresses that the source = route entry field is carrying. - Source Route Entry: List of 128 bit address that consist the route to = the destination. Here, the address of the node that is one hop away from = the *destination* comes first.=20 2. Source Routing Packet Operations When source routing is initiated at a storing node (e.g., root of the = DODAG), the header is attached on the data packet for the entire route = (i.e., from next hop node to the destination). This header is positioned = in front of the user payload. When the next hop node receives a packet = that is not destined to itself AND the network is NOT provisioned to be = in 'storing mode' then it checks NEntry to find what the next hop is in = the source route entry. Since the 'Source Route Entry' is ordered in = 'farthest -> closest' (in terms of hops) order, a node can figure out = what the next hop address is with only the NEntry value (since it = already knows how big an ipv6 address is). After collecting the next hop = node's address, the node erases this address element from the entry and = decreases NEntry by one. This assures that we avoid the overhead of = carrying the entire source route throughout the data path.=20 The approach itself should be very simple and trivial for everyone to = follow. So we can start from here and build on! Thanks. -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From pister@eecs.berkeley.edu Wed Apr 7 13:45:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F356728C0F8 for ; Wed, 7 Apr 2010 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH5MNVToJ8Ci for ; Wed, 7 Apr 2010 13:45:55 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 1B2863A67A4 for ; Wed, 7 Apr 2010 13:45:55 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o37KjkkD008949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Apr 2010 13:45:48 -0700 (PDT) Message-ID: <4BBCEEFA.6090307@eecs.berkeley.edu> Date: Wed, 07 Apr 2010 13:45:46 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jonathan Hui References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> <91079E78-18BE-4C26-81BD-5A3FE9747317@archrock.com> In-Reply-To: <91079E78-18BE-4C26-81BD-5A3FE9747317@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 20:45:56 -0000 +1 > > On Apr 3, 2010, at 10:09 AM, Tim Winter wrote: > >> WG, >> >> From Anaheim and the list it seems that there is support to proceed >> on RPL with >> storing and non-storing modes of operation, and not to elaborate >> mixed mode operation >> at this time (while allowing room for future specification of mixed >> mode). >> >> The summary approach would be to signal the mode of operation through >> the DIO, that >> all nodes MUST be capable to support a non-storing mode of operation, >> and that nodes >> who are incapable of acting as routers in a storing mode may >> participate in the DODAG >> as hosts (leaves). (The suitable behavior when a routing table in a >> storing node >> becomes saturated is still under consideration). >> >> Would you please confirm this approach to the list? Then we may >> proceed to refine >> RPL accordingly for the next revision, -08, and to take this into >> account when >> working the other tickets. >> >> Thanks, >> >> -Tim >> >> >> roll issue tracker wrote: >>> #26: Establishing downward routes in RPL : storing / non-storing / >>> mixed modes >>> of operation >>> --------------------------------+------------------------------------------- >>> >>> Reporter: jpv@… | Owner: wintert@… >>> Type: task | Status: new >>> Priority: major | Milestone: >>> Component: rpl | Version: >>> Severity: Active WG Document | Keywords: >>> --------------------------------+------------------------------------------- >>> >>> In the RPL-07 proposal the DAO mechanism described in Section 6 >>> attempts >>> to support >>> operation with a mix of storing nodes and non-storing nodes- where >>> storing >>> nodes may >>> be provisioned with enough memory that they are capable to provision >>> hop- >>> by-hop >>> downward routes learned from DAO messages, and non-storing nodes would >>> rely on source >>> routing for downward routes. The present proposal describes >>> operation in >>> a mixed >>> mode operation, with both storing and non-storing nodes, where each >>> node >>> may >>> provision downward routing state as according to its capabilities and >>> largely >>> independent of its position in the LLN topology. >>> >>> It has been noted that operation in the case where all nodes (except >>> possibly the >>> root) are non-storing nodes allows for certain optimizations, and >>> that the >>> case where >>> all nodes (except possibly leaves) are storing leads to other >>> optimizations. It has >>> also been noted that in the mixed cases the ability to provide an >>> optimal >>> solution >>> may break down. In particular there are concerns about the >>> complexity and >>> correctness of mixed-mode operation as proposed by RPL-07. >>> >>> With this in mind, should RPL allow for operation in a mixture of >>> storing >>> /non-storing >>> nodes? Or should each RPL Instance be exclusively operating in either >>> storing or >>> non-storing mode (with the provision that operation as a leaf is >>> always an >>> option)? >>> (The non-mixed case may imply some control flag or equivalent given >>> in the >>> DIO to >>> signal the mode of operation). >>> >>> Tim Winter. >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Wed Apr 7 13:55:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A423A67FA for ; Wed, 7 Apr 2010 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR3rhGGz8s-W for ; Wed, 7 Apr 2010 13:55:53 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 4CE433A67F5 for ; Wed, 7 Apr 2010 13:55:53 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o37KtiR1009214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Apr 2010 13:55:45 -0700 (PDT) Message-ID: <4BBCF150.4010701@eecs.berkeley.edu> Date: Wed, 07 Apr 2010 13:55:44 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Philip Levis References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> In-Reply-To: <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> Content-Type: multipart/alternative; boundary="------------020703000901020702000801" Cc: 'roll' Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 20:55:54 -0000 This is a multi-part message in MIME format. --------------020703000901020702000801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip Levis wrote: > > On Mar 31, 2010, at 11:05 AM, Kris Pister wrote: > >> Michael Richardson wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>>>>>>> "Don" == Don Sturek writes: >>>>>>>> >>> Don> It would make sense to recommend to vendors they implement a >>> Don> route entry management solution and to even provide a best >>> Don> practices. >>> >>> Don> On the point below on hacker exploitation, mesh routing relies >>> Don> on distributed routing. I think all router devices need to be >>> Don> authenticated before being allowed to participate. For any >>> >>> Authentication may not solve anything if it does not include >>> non-spoofable replay protection. My experience with L2-"security" is >>> that it does not provide this. >>> >> For those using TSCH (802.15.4E), there's built-in replay protection >> because all nodes in the network share a common sense of time. >> Absolute Slot Number is a monotonic representation of time, and acts >> like a nonce in the MIC calculation, so replaying a packet in a >> different time slot doesn't work. > > Unfortunately we can't assume 802.15.4E. :( > >>> Consider that one can record and replay packets. >>> An attacker can record packets in one part of the network and replay >>> them back in another part of the network. Think of someone with a >>> tape recorder recording your voice in your house, and then playing it >>> back in your office, to make someone believe you are in the office. >>> This works even if you speak in code. >>> >>> This is not an active mitm attack, because no packets are actually >>> removed or intercepted. >>> >>> This is a VERY HARD problem to solve, because really, if the attacker >>> just installed a high-gain antenna in one part of the building, a coax >>> cable, and another antenna in another part of the building, it's really >>> the same thing! The difference is perhaps that the totally passive >>> system will relay packets usefully. >>> >> This is a nice example, in that it's akin to the sort of weird RF >> behavior that occurs naturally. Nodes far apart in the network >> suddenly hear each other quite well for some period of time, and then >> just as mysteriously don't hear each other anymore. RPL had better >> be able to deal with this, or we're in deep trouble. > > It does not seem an undue burden to me for a node to send a > request/response that demonstrates another node's real presence before > making that node its preferred parent. Or are there simpler mechanisms? What do you mean by "real presence"? In Michael's example, if I have a co-ax worm-hole, does that count as real presence? Or are you saying that I should re-verify security credentials before making someone my parent? I don't understand your question. ksjp > > Phil --------------020703000901020702000801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    Philip Levis wrote:

    On Mar 31, 2010, at 11:05 AM, Kris Pister wrote:

    Michael Richardson wrote: 
    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


  
    "Don" == Don Sturek <d.sturek@att.net> writes:
            
        Don> It would make sense to recommend to vendors they implement a
    Don> route entry management solution and to even provide a best
    Don> practices.

    Don> On the point below on hacker exploitation, mesh routing relies
    Don> on distributed routing.  I think all router devices need to be
    Don> authenticated before being allowed to participate.  For any

Authentication may not solve anything if it does not include
non-spoofable replay protection.  My experience with L2-"security" is
that it does not provide this.
    For those using TSCH (802.15.4E), there's built-in replay protection because all nodes in the network share a common sense of time.  Absolute Slot Number is a monotonic representation of time, and acts like a nonce in the MIC calculation, so replaying a packet in a different time slot doesn't work.

    Unfortunately we can't assume 802.15.4E. :(

    Consider that one can record and replay packets.
An attacker can record packets in one part of the network and replay 
them back in another part of the network.    Think of someone with a
tape recorder recording your voice in your house, and then playing it
back in your office, to make someone believe you are in the office.
This works even if you speak in code.  

This is not an active mitm attack, because no packets are actually
removed or intercepted. 

This is a VERY HARD problem to solve, because really, if the attacker
just installed a high-gain antenna in one part of the building, a coax
cable, and another antenna in another part of the building, it's really
the same thing!  The difference is perhaps that the totally passive
system will relay packets usefully.
    This is a nice example, in that it's akin to the sort of weird RF behavior that occurs naturally.  Nodes far apart in the network suddenly hear each other quite well for some period of time, and then just as mysteriously don't hear each other anymore.  RPL had better be able to deal with this, or we're in deep trouble.

    It does not seem an undue burden to me for a node to send a request/response that demonstrates another node's real presence before making that node its preferred parent. Or are there simpler mechanisms?
    What do you mean by "real presence"?  In Michael's example, if I have a co-ax worm-hole, does that count as real presence?
    Or are you saying that I should re-verify security credentials before making someone my parent?
    I don't understand your question.

    ksjp

    Phil
    --------------020703000901020702000801-- From pal@cs.stanford.edu Wed Apr 7 14:07:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712313A67F5 for ; Wed, 7 Apr 2010 14:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cub5PG1jdQN for ; Wed, 7 Apr 2010 14:07:32 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AFAE63A67EF for ; Wed, 7 Apr 2010 14:07:32 -0700 (PDT) Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzcTB-0004vP-Tr; Wed, 07 Apr 2010 14:07:30 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BBCF150.4010701@eecs.berkeley.edu> Date: Wed, 7 Apr 2010 14:07:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1077) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: 'roll' Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 21:07:33 -0000 On Apr 7, 2010, at 1:55 PM, Kris Pister wrote: >>>=20 >>=20 >> It does not seem an undue burden to me for a node to send a = request/response that demonstrates another node's real presence before = making that node its preferred parent. Or are there simpler mechanisms? > What do you mean by "real presence"? In Michael's example, if I have = a co-ax worm-hole, does that count as real presence? Yes -- basically, whether the network address whose DIOs you hear can = actually generate messages to you and process messages you send. > Or are you saying that I should re-verify security credentials before = making someone my parent? Yes. One simple way to verify that the source network address of the = received packets can actually respond and process messages is to ask it = to do so. Or is this just not very important? Phil From pister@eecs.berkeley.edu Wed Apr 7 15:14:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959E53A696C for ; Wed, 7 Apr 2010 15:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2euysJdTYk9 for ; Wed, 7 Apr 2010 15:14:24 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 419943A67EF for ; Wed, 7 Apr 2010 15:14:16 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o37ME7K9011800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Apr 2010 15:14:08 -0700 (PDT) Message-ID: <4BBD03AF.9050803@eecs.berkeley.edu> Date: Wed, 07 Apr 2010 15:14:07 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Philip Levis References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> In-Reply-To: <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> Content-Type: multipart/alternative; boundary="------------000409060802040205050502" Cc: 'roll' Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2010 22:14:26 -0000 This is a multi-part message in MIME format. --------------000409060802040205050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip Levis wrote: > On Apr 7, 2010, at 1:55 PM, Kris Pister wrote: > > >>> It does not seem an undue burden to me for a node to send a request/response that demonstrates another node's real presence before making that node its preferred parent. Or are there simpler mechanisms? >>> >> What do you mean by "real presence"? In Michael's example, if I have a co-ax worm-hole, does that count as real presence? >> > > Yes -- basically, whether the network address whose DIOs you hear can actually generate messages to you and process messages you send. > > Good. Agreed. > >> Or are you saying that I should re-verify security credentials before making someone my parent? >> > > Yes. One simple way to verify that the source network address of the received packets can actually respond and process messages is to ask it to do so. Or is this just not very important? > There are two issues here: one is related to symmetry of the communication link, and the other is related to replay protection. We know from physics that the symmetry of an RF link in a linear medium is guaranteed. We know from practice that physics lies a lot. :) Others have indicated that PLC links can be asymmetric. For 15.4 radios, my experience is that the vast majority of links are within a dB or two of being symmetric...as long as you have the same hardware on both sides. If one node has a PA and the other doesn't, forget it. Occasionally, even with identical hardware, you still get unusual behavior, which can cause trouble for bonding with a chosen parent. If you have a link-layer ACK, this problem goes away. In wireless HART, potential parents who don't want to respond to petulant children are blacklisted by the emotionally-scarred child. My guess is that you're more concerned with replay though (yes?). If C hears a DIO from P, then there is a lot of context in that message. The mechanisms that we're proposing to use to protect DIOs will contain a nonce. If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce. Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes? Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation? I guess if I were really paranoid I could make up a random address to put in the DIS. So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy. ksjp --------------000409060802040205050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    Philip Levis wrote: 
    On Apr 7, 2010, at 1:55 PM, Kris Pister wrote:

  
    It does not seem an undue burden to me for a node to send a request/response that demonstrates another node's real presence before making that node its preferred parent. Or are there simpler mechanisms?
      
    What do you mean by "real presence"?  In Michael's example, if I have a co-ax worm-hole, does that count as real presence?
    
    
Yes -- basically, whether the network address whose DIOs you hear can actually generate messages to you and process messages you send.
    Good.  Agreed.
      
    Or are you saying that I should re-verify security credentials before making someone my parent?
    
    
Yes. One simple way to verify that the source network address of the received packets can actually respond and process messages is to ask it to do so. Or is this just not very important?
    There are two issues here: one is related to symmetry of the communication link, and the other is related to replay protection.  We know from physics that the symmetry of an RF link in a linear medium is guaranteed.  We know from practice that physics lies a lot. :)   Others have indicated that PLC links can be asymmetric.  For 15.4 radios, my experience is that the vast majority of links are within a dB or two of being symmetric...as long as you have the same hardware on both sides.  If one node has a PA and the other doesn't, forget it.  Occasionally, even with identical hardware, you still get unusual behavior, which can cause trouble for bonding with a chosen parent.  If you have a link-layer ACK, this problem goes away.  In wireless HART, potential parents who don't want to respond to petulant children are blacklisted by the emotionally-scarred child.

    My guess is that you're more concerned with replay though (yes?).  If C hears a DIO from P, then there is a lot of context in that message.  The mechanisms that we're proposing to use to protect DIOs will contain a nonce. 
    If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce.  Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes?  Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation?  I guess if I were really paranoid I could make up a random address to put in the DIS.
    So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy.

    ksjp
    --------------000409060802040205050502-- From richard.kelsey@ember.com Wed Apr 7 19:01:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A68A3A688D for ; Wed, 7 Apr 2010 19:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsNp82GoPEWE for ; Wed, 7 Apr 2010 19:01:00 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BB85A3A6782 for ; Wed, 7 Apr 2010 19:00:59 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 22:03:56 -0400 Date: Wed, 07 Apr 2010 22:00:27 -0400 Message-Id: <87zl1ehfes.fsf@kelsey-ws.hq.ember.com> To: "Anders Brandt" In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> (abr@sdesigns.dk) From: Richard Kelsey References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu><1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FD9@zensys17.zensys.local> X-OriginalArrivalTime: 08 Apr 2010 02:03:56.0345 (UTC) FILETIME=[BEE7F290:01CAD6BF] Cc: roll@ietf.org Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 02:01:00 -0000 > Date: Wed, 7 Apr 2010 13:14:29 +0200 > From: "Anders Brandt" > > Pascal wrote: > > > Note that the ACK that is proposed in issue #27 is not > > end-to-end but hop-by-hop. The biggest reason is to make the > > DAO more reliable. Once we have it, then we can derive > > benefits like the NACK. > > > > Whether there is a need for end-to-end ack for source route > > mode is TBD. > > RF is inherently unreliable. Unless I receive an end-to-end ack > I must assume that my message was lost. > Relying on a message telling me that delivery failed at repeater > #4 is wishfull thinking. That message may be lost as well. > Thus the answer is yes. I agree with Anders on this. There needs to be at least the option of an end-to-end ack for source route mode. This ack could be implicit, in that receiving a source routed message can tell you that the sender has a source route to you. -Richard Kelsey From pal@cs.stanford.edu Wed Apr 7 19:46:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0319F3A67F7 for ; Wed, 7 Apr 2010 19:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFlQ4k5dlhG4 for ; Wed, 7 Apr 2010 19:46:20 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2B9FC3A67C1 for ; Wed, 7 Apr 2010 19:46:20 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nzhl3-0006mG-0J; Wed, 07 Apr 2010 19:46:17 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BBD03AF.9050803@eecs.berkeley.edu> Date: Wed, 7 Apr 2010 18:21:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1077) X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: 'roll' Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 02:46:21 -0000 On Apr 7, 2010, at 3:14 PM, Kris Pister wrote: >=20 > My guess is that you're more concerned with replay though (yes?). Yes. =20 > If C hears a DIO from P, then there is a lot of context in that = message. The mechanisms that we're proposing to use to protect DIOs = will contain a nonce. =20 > If C is worried about the authenticity and timeliness of the DIO, then = C can send a unicast DIS after hearing the DIO and make sure that the = response has an incremented nonce.=20 I don't think this is sufficient. I am an attacker. I hear and record = DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1. > Assuming that the MIC is calculated over the headers (which include = both P and C addresses) then we should be OK, yes?=20 Only if the DIO is sent as a unicast (uniquely tied to the DIS). > Or are you suggesting the need for a random number/challenge in the = DIS that is also a part of the MIC calculation?=20 Yes, something like that. Could be something such that multicast DIOs = have an incrementing sequence number, responds to unicast DISes are = unicast and use the nonce in the DIS. Otherwise it becomes tricky, there = are DoS attacks (node C sends a DIS with a nonce, I immediately send a = DIS with another nonce, which nonce will P use). > I guess if I were really paranoid I could make up a random address to = put in the DIS. > So I think that we have the (proposed) *mechanisms* that we need to do = what you want, and it will be up to implementers to decide on policy. I'm just worried about the basic case of an adversary replaying DIOs. Phil= From yoav@yitran.com Thu Apr 8 00:43:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231953A6774 for ; Thu, 8 Apr 2010 00:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NjQlHSZaQje for ; Thu, 8 Apr 2010 00:43:51 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 80CC63A6805 for ; Thu, 8 Apr 2010 00:43:50 -0700 (PDT) Received: from source ([72.14.220.156]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKS72JM4jj0hC/KCTZo2i68Xf309LIV3eq@postini.com; Thu, 08 Apr 2010 00:43:48 PDT Received: by fg-out-1718.google.com with SMTP id e12so1701889fga.6 for ; Thu, 08 Apr 2010 00:43:46 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrWxa4FTFs+0mCHQ6qKT1KhvF+C7gAJTHmQ Date: Thu, 8 Apr 2010 10:43:44 +0300 Received: by 10.239.169.145 with SMTP id o17mr949280hbe.147.1270712625512; Thu, 08 Apr 2010 00:43:45 -0700 (PDT) Message-ID: <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> To: Philip Levis , Kris Pister Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Mixed mode operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 07:43:52 -0000 Just a thought ... If a secured DIO will contain the trickle timer limit, the receiver of replayed DIOs can easily follow a specific node to see if it's a replaying attacker or not by sending out a DIS and expecting to see a reduced trickle timer limit on the DIO. Recording specific reduced trickle timers seems more difficult than regular DIOs. Another option is to specify the actual time difference between DIO transmissions (with some allowed margin). The response to DIS would most probably be much shorter than the time on the recorded message. BTW - The DIS for credential re-check be trickle-timered as well, right? Otherwise, how do we approach the potential DIS storm problem with a credentials re-check, in case a replayed DIO will cause many other nodes to send DIS to recheck credentials with the replaying node. Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Thursday, April 08, 2010 4:21 AM To: Kris Pister Cc: 'roll' Subject: Re: [Roll] Mixed mode operation On Apr 7, 2010, at 3:14 PM, Kris Pister wrote: > > My guess is that you're more concerned with replay though (yes?). Yes. > If C hears a DIO from P, then there is a lot of context in that message. The mechanisms that we're proposing to use to protect DIOs will contain a nonce. > If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce. I don't think this is sufficient. I am an attacker. I hear and record DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1. > Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes? Only if the DIO is sent as a unicast (uniquely tied to the DIS). > Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation? Yes, something like that. Could be something such that multicast DIOs have an incrementing sequence number, responds to unicast DISes are unicast and use the nonce in the DIS. Otherwise it becomes tricky, there are DoS attacks (node C sends a DIS with a nonce, I immediately send a DIS with another nonce, which nonce will P use). > I guess if I were really paranoid I could make up a random address to put in the DIS. > So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy. I'm just worried about the basic case of an adversary replaying DIOs. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Thu Apr 8 00:55:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBC728C0D9 for ; Thu, 8 Apr 2010 00:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-oWIEdzoRhB for ; Thu, 8 Apr 2010 00:55:36 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id B57703A69FE for ; Thu, 8 Apr 2010 00:54:59 -0700 (PDT) Received: from source ([72.14.220.158]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKS72L0Db1sN2Bs2KBWsJ4sEdzM3lGEQB6@postini.com; Thu, 08 Apr 2010 00:54:57 PDT Received: by fg-out-1718.google.com with SMTP id l26so695306fgb.12 for ; Thu, 08 Apr 2010 00:54:56 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> <56FAF6DE-2204-48FE-8E29-3533BEC7BE4A@cs.stanford.edu> <4BBCE201.2020206@gridmerge.com> In-Reply-To: <4BBCE201.2020206@gridmerge.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrWi6bBr50mbWhpTSS8yZzwvB0lqgAZPmdg Date: Thu, 8 Apr 2010 10:54:54 +0300 Received: by 10.239.162.10 with SMTP id j10mr981312hbd.41.1270713295521; Thu, 08 Apr 2010 00:54:55 -0700 (PDT) Message-ID: <005201cad6f0$c6b18be0$5414a3a0$@com> To: robert.cragie@gridmerge.com, roll Content-Type: multipart/alternative; boundary=001485f5b1b89747ee0483b4fe97 Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 07:55:38 -0000 --001485f5b1b89747ee0483b4fe97 Content-Type: text/plain; charset=ISO-8859-1 +1 *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of *Robert Cragie *Sent:* Wednesday, April 07, 2010 10:50 PM *To:* roll@ietf.org *Subject:* Re: [Roll] proposal for DAOs in non-caching DODAGs Apologies in advance for the long e-mail. I'm trying to follow this thread and draw some conclusions. *DIO/DAO parent* I find the terms DIO parent and DAO parent confusing. There can only be one parent type and that is a node with a lower rank than you. This is why I tend to subscribe to Pascal's view that these are really two separate DAGs. If there is some convenient way of amalgamating them then all well and good but I sometimes wonder if it wouldn't be easier to call them all DAGs and consider the downward route an additional 'twig-like' DAG to a single node. In this way, a common objective function for reaching a node makes far more sense. In fact, I wonder what the need for a separate DAO message is at all. The main distinction between a DIO and a DAO is that a DAO sent up the DAG as opposed to multicast, i.e. directed; however the DAO is not *routed *through the DAG and has concept of rank and parents too for propagation. So really it does not seem much different to a DIO. It just has some rough guidance from another DAG as to where to direct it. So we could consider three DIO's: 1. DIO to all, multicast 2. DIO to target, multicast 3. DIO to target, directed (1) is what is currently DIO, (2) is what we need for P2P, (3) is what is currently DAO. OK, maybe we just call (3) a DAO still but let's clean up how it propagates. Note we may be wanting to add Richard's, parent tables to the DIO as well as replacing the DAO RRstack for the non-storing P2P solution. *Link costs and DAG formation* Regarding link costs and their place in DAG formation, Mukul stated in an earlier e-mail: *So when B receives a multicast DIO from A, B may know: 1) unidirectional cost A->B only or 2) unidirectional cost B->A only or 3) both or 4) none * I would say B always has some semblance of the link cost from A->B by virtue of having received a packet from A. At the very least, it knows A is able to communicate to B because, well, it received it. It could then use further metrics such as LQL to further judge the link cost. So I would revise this to: So when B receives a multicast DIO from A, B: 1. will have some notion of unidirectional cost A->B by virtue of receiving it 2. may know unidirectional cost B->A only 3. may know both Consider the simple DAG below. Apologies for the drawn-out scenario and please correct anything which seems wrong. For rank I am using simple cardinal number ordinality: A / \ B C / \ / \ D E F 1. A transmits DIO 2. B hears DIO 1. B knows there is a route from A->B by virtue of receiving it 2. *B does not necessarily know there is a route from B->A as it may not have the unidirectional link cost from B->A* 3. *If the objective of forming the DODAG is to be able to route to A then B needs some metric for link cost from B->A* 4. B must compute its rank based on the objective function, the DIO from A and possibly other stored state 5. B computes its rank as A+1 and marks A as parent 6. Some time later, B transmits DIO 1. D hears DIO 1. D knows there is a route from B->D by virtue of receiving it 2. *D does not necessarily know there is a route from D->B as it may not have the unidirectional link cost from D->B* 3. *If the objective of forming the DODAG is to be able to route to A then D needs some metric for link cost from D->B* 4. D must compute its rank based on the objective function, the DIO from B and possibly other stored state 5. D computes its rank as B+1 (= A+2) and marks B as a parent 6. Some time later, D transmits DIO 2. E hears DIO 1. E knows there is a route from B->E by virtue of receiving it 2. *E does not necessarily know there is a route from E->B as it may not have the unidirectional link cost from E->B* 3. *If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->B* 4. E must compute its rank based on the objective function, the DIO from B and possibly other stored state 5. E computes its rank as B+1 (= A+2) and marks B as a parent 6. Some time later, E transmits DIO 3. C hears DIO 1. C knows there is a route from A->C by virtue of receiving it 2. *C does not necessarily know there is a route from C->A as it may not have the unidirectional link cost from C->A* 3. *If the objective of forming the DODAG is to be able to route from C->A then C needs some metric for link cost from C->A* 4. C must compute its rank based on the objective function, the DIO from A and possibly other stored state 5. C computes its rank as A+1 6. Some time later, C transmits DIO 1. E hears DIO (assume E has already heard DIO from B) 1. E knows there is a route from C->E by virtue of receiving it 2. *E does not necessarily know there is a route from E->C as it may not have the unidirectional link cost from E->C* 3. *If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->C* 4. E must compute its rank based on the objective function, the DIO from C and possibly other stored state 5. E computes its rank as C+1 (= A+2). As it is the same as previously calculated rank, it marks C as another potential parent 6. Some time later, E continues to transmit DIO as it was already transmitting it 2. F hears DIO 1. F knows there is a route from C->F by virtue of receiving it 2. *F does not necessarily know there is a route from F->C as it may not have the unidirectional link cost from F->C* 3. *If the objective of forming the DODAG is to be able to route to A then F needs some metric for link cost from F->C* 4. F must compute its rank based on the objective function, the DIO from C and possibly other stored state 5. F computes its rank as C+1 (= A+2) and marks C as a parent 6. Some time later, F transmits DIO Consider a path along that DAG, (A - B - D): 1. Using DIOs doesn't naturally form the route from D to A (A <- B <- D) unless outgoing costs (i.e. B's perception of B->A, D's perception of D->B) is known 2. Using a DIO does naturally form the route from A to D (A -> B -> D) on the assumption that reception of data is a reasonable confirmation that a link exists 1. However as DIO originator, A needs to know that D heard its DIO via B therefore still needs a return path back to A via B. So it's catch 22. The bottom line is that I cannot see how DAG formation can function properly without the outgoing cost being known. The question is - how do we know it? Three possible solutions for A <- B: 1. B receives data from A with A's perception of B->A based on incoming cost 2. B has a perception of B->A outgoing cost based on other metrics e.g. failed L2 acks 3. B assumes that A is reachable by virtue of having received from it (1) is probably the best, (2) is workable but still requires a viable link from A -> B and (3) is guessing. To achieve (1), there is probably some need for additional status messages to propagate this information. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 01/04/2010 3:31 AM, Philip Levis wrote: On Mar 31, 2010, at 5:43 PM, Mukul Goyal wrote: I'm not sure I understand the concern. Is it that if this isn't stated explicitly, then an implementation might put a neighbor in the parent set for which it cannot compute DAGRank from the OF? How would it ever compute its own DAGRank? Can you explain the failure condition? Consider the situation where node A receives a DIO from node B and knows the cost of link B->A (either it already knew this cost or DIO carries this cost or it assumes a value for this cost) but not that of link A->B. Then, node A may be able to compute its DAG rank via node B and thus possibly select node B as a DIO parent. But, even if B becomes a DIO parent, A should not consider B as a candidate for DAO parenthood because A does not know the cost of link A->B. [Phil] So a node A MUST NOT select node B as a parent if the OF cannot compute the DAGRank of the resulting route? Node A may have sufficient information to calculate its DAG rank via B but still may not have the information to calculate B's suitability as a DAO parent (e.g. if OF just considers the upwards costs in calculating the DAG rank and such costs are known to A but requires knowledge of downwards costs for a parent's selection as DAO parent and these downwards costs (from B to A) are not known to A). [Phil] I'm sorry -- your sentence is kind of long and convoluted, and I can't understand it. I am sorry too: for the length and convolution of my sentence. :) And for the fact that you can't understand it (if you say so). :) Hey, I am kidding. Dont get mad at me. [Phil] Does it say yes my sentence is correct or no it is not correct? It says that your sentence is not correct. This is because your sentence assumes that the DAGrank calculation requires knowledge of all sorts of costs that the node may need to choose its DAG or DAO parents. This assumption is not true. A DAGrank is simply a loop avoidance mechanism that may not be a very good indicator of actual routing costs in either direction. I know you would disagree with me (based on my understanding of your point of view from your previous posts). Ah -- I think this is why we can't seem to agree: we're coming from different assumptions. There was a change in -07; Richard noted that having Rank *not* reflect a metric is problematic, as it constrains parent selection. I.e., if Rank does not directly reflect a metric, it's possible that a node can't pick a better (lower metric) parent because it has a higher Rank. This led to the inclusion of MinHopRankIncrease, elevating Rank to 16-bits, and the introduction of DAGRank, such that Rank could still reflect a good fidelity metric but DAGRank can provide good loop avoidance and topology constraints. The operating assumption is that since Rank constrains the set of parents a node can select, then separating it from metrics is problematic. The OF computes the Rank (this has always been the case): it should have all of the needed information. Or is there something in the draft that says it won't? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --001485f5b1b89747ee0483b4fe97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    +1

    =A0

    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]= On Behalf Of Robert Cragie
    Sent: Wednesday, April 07, 2010 10:50 PM
    To: roll@ietf.org
    Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs

    =A0

    Apologies in advance for the long e-mail. I'm tr= ying to follow this thread and draw some conclusions.

    DIO/DAO parent

    I find the terms DIO parent and DAO parent confusing. There can only be one parent type and that is a node with a lower rank than you. This is why I te= nd to subscribe to Pascal's view that these are really two separate DAGs. = If there is some convenient way of amalgamating them then all well and good but I sometimes wonder if it wouldn't be easier to call them all DAGs and con= sider the downward route an additional 'twig-like' DAG to a single node. = In this way, a common objective function for reaching a node makes far more sense.

    In fact, I wonder what the need for a separate DAO message is at all. The m= ain distinction between a DIO and a DAO is that a DAO sent up the DAG as oppose= d to multicast, i.e. directed; however the DAO is not routed through the = DAG and has concept of rank and parents too for propagation. So really it does = not seem much different to a DIO. It just has some rough guidance from another = DAG as to where to direct it. So we could consider three DIO's:

    1. DIO to all, multicast
    2. DIO to target, multicast
    3. DIO to target, directed

    (1) is what is currently DIO, (2) is what we need fo= r P2P, (3) is what is currently DAO. OK, maybe we just call (3) a DAO still but le= t's clean up how it propagates.

    Note we may be wanting to add Richard's, parent tables to the DIO as we= ll as replacing the DAO RRstack for the non-storing P2P solution.

    Link costs and DAG formation

    Regarding link costs and their place in DAG formation, Mukul stated in an earlier e-mail:

    So when B receives a multicast DIO from A, B may know:

    1) unidirectional cost A->B only or
    2) unidirectional cost B->A only or
    3) both or
    4) none

    I would say B always has some semblance of the link cost from A->B by vi= rtue of having received a packet from A. At the very least, it knows A is able t= o communicate to B because, well, it received it. It could then use further metrics such as LQL to further judge the link cost. So I would revise this = to:

    So when B receives a multicast DIO from A, B:

    1. will have some notion of unidirectional cost A->B by virtue of receiving it
    2. may know unidirectional cost B->A only
    3. may know both

    Consider the simple D= AG below. Apologies for the drawn-out scenario and please correct anything which seem= s wrong. For rank I am using simple cardinal number ordinality:

    =A0=A0=A0 A
    =A0=A0 / \
    =A0 B=A0=A0 C
    =A0/ \ / \
    D=A0=A0 E=A0=A0 F

    1. A transmits DIO
    2. B hears DIO
      1. B knows there is a route from A->B b= y virtue of receiving it
      2. B does not necessarily know there= is a route from B->A as it may not have the unidirectional link cost = from B->A
      3. If the objective of forming the D= ODAG is to be able to route to A then B needs some metric for link cost fr= om B->A
      4. B must compute its rank based on the objective function, the DIO from A and possibly other stored state
      5. B computes its rank as A+1 and marks A = as parent
      6. Some time later, B transmits DIO
        1. D hears DIO
          1. D knows there is a route from B->D= by virtue of receiving it
          2. D does not necessarily know the= re is a route from D->B as it may not have the unidirectional link = cost from D->B
          3. If the objective of forming the DODAG is to be able to route to A then D needs some metric for link cost from D->B
          4. D must compute its rank based on the objective function, the DIO from B and possibly other stored state<= /li>
          5. D computes its rank as B+1 (=3D A+2) = and marks B as a parent
          6. Some time later, D transmits DIO
        2. E hears DIO
          1. E knows there is a route from B->E= by virtue of receiving it
          2. E does not necessarily know the= re is a route from E->B as it may not have the unidirectional link = cost from E->B
          3. If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->B
          4. E must compute its rank based on the objective function, the DIO from B and possibly other stored state<= /li>
          5. E computes its rank as B+1 (=3D A+2) = and marks B as a parent
          6. Some time later, E transmits DIO
    3. C hears DIO
      1. C knows there is a route from A->C b= y virtue of receiving it
      2. C does not necessarily know there= is a route from C->A as it may not have the unidirectional link cost = from C->A
      3. If the objective of forming the D= ODAG is to be able to route from C->A then C needs some metric for link cost from C->A
      4. C must compute its rank based on the objective function, the DIO from A and possibly other stored state
      5. C computes its rank as A+1
      6. Some time later, C transmits DIO
        1. E hears DIO (assume E has already hear= d DIO from B)
          1. E knows there is a route from C->E= by virtue of receiving it
          2. E does not necessarily know the= re is a route from E->C as it may not have the unidirectional link = cost from E->C
          3. If the objective of forming the DODAG is to be able to route to A then E needs some metric for link cost from E->C
          4. E must compute its rank based on the objective function, the DIO from C and possibly other stored state<= /li>
          5. E computes its rank as C+1 (=3D A+2).= As it is the same as previously calculated rank, it marks C as another potential parent
          6. Some time later, E continues to trans= mit DIO as it was already transmitting it
        2. F hears DIO
          1. F knows there is a route from C->F= by virtue of receiving it
          2. F does not necessarily know the= re is a route from F->C as it may not have the unidirectional link = cost from F->C
          3. If the objective of forming the DODAG is to be able to route to A then F needs some metric for link cost from F->C
          4. F must compute its rank based on the objective function, the DIO from C and possibly other stored state<= /li>
          5. F computes its rank as C+1 (=3D A+2) = and marks C as a parent
          6. Some time later, F transmits DIO

    Consider a path along that DAG, (A - B - D):

    1. Using DIOs doesn't naturally form the rou= te from D to A (A <- B <- D<= /tt>) unless outgoing costs (i.e. B's perception of B->A, D's per= ception of D->B) is known
    2. Using a DIO does naturally form the route fro= m A to D (A -> B -> D) on the assumption that reception of data is a reasonable confirmation tha= t a link exists
      1. However as DIO originator, A needs to k= now that D heard its DIO via B therefore still needs a return path back t= o A via B. So it's catch 22.

    The bottom line is that I cannot see how DAG formati= on can function properly without the outgoing cost being known. The question is - = how do we know it? Three possible solutions for A <- B:

    1. B receives data from A with A's perceptio= n of B->A based on incoming cost
    2. B has a perception of B->A outgoing cost b= ased on other metrics e.g. failed L2 acks
    3. B assumes that A is reachable by virtue of ha= ving received from it

    (1) is probably the b= est, (2) is workable but still requires a viable link from A -> B and (3) is guessing. To achieve (1), there is probably some need for additional status messages to propagate this information.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888
    http://www.gridmerge.com


    On 01/04/2010 3:31 AM, Philip Levis wrote:

    =A0

    On Mar 31, 2010, at 5:43 PM, Mukul Goyal wrote:



    I'm not sure I understand the concern. Is it tha= t if this isn't stated explicitly, then an implementation might put a neighbor in= the parent set for which it cannot compute DAGRank from the OF? How would it ev= er compute its own DAGRank? Can you explain the failure condition?

    =A0

    Consider the situation where node A receives a DIO f= rom node B and knows the cost of link B->A (either it already knew this cost or D= IO carries this cost or it assumes a value for this cost) but not that of link A->B. Then, node A may be able to compute its DAG rank via node B and th= us possibly select node B as a DIO parent. But, even if B becomes a DIO parent= , A should not consider B as a candidate for DAO parenthood because A does not = know the cost of link A->B. =A0=A0=A0

    =A0

    [Phil] So a node A MUST NOT select node B as a paren= t if the OF cannot compute the DAGRank of the resulting route?

    =A0

    Node A may have sufficient information to calculate = its DAG rank via B but still may not have the information to calculate B's suit= ability as a DAO parent (e.g. if OF just considers the upwards costs in calculating= the DAG rank and such costs are known to A but requires knowledge of downwards costs for a parent's selection as DAO parent and these downwards costs = (from B to A) are not known to A).


    [Phil]
    I'm sorry -- your sentence is kind of long and convoluted, and I can= 9;t understand it.

    I am sorry too: for the length and convolution of my sentence. :)
    And for the fact that you can't understand it (if you say so). :)

    Hey, I am kidding. Dont get mad at me.

    [Phil] Does it say yes my sentence is correct or no it is not correct?

    It says that your sentence is not correct. This is because your sentence assumes that the DAGrank calculation requires knowledge of all sorts of cos= ts that the node may need to choose its DAG or DAO parents. This assumption is= not true. A DAGrank is simply a loop avoidance mechanism that may not be a very good indicator of actual routing costs in either direction. I know you woul= d disagree with me (based on my understanding of your point of view from your previous posts).

    =A0

    Ah -- I think this is why we can't seem to agree= : we're coming from different assumptions. There was a change in -07; Richard noted that having Rank *not* reflect a metric is problematic, as it constrains pa= rent selection. I.e., if Rank does not directly reflect a metric, it's possi= ble that a node can't pick a better (lower metric) parent because it has a highe= r Rank. This led to the inclusion of MinHopRankIncrease, elevating Rank to 16-bits,= and the introduction of DAGRank, such that Rank could still reflect a good fide= lity metric but DAGRank can provide good loop avoidance and topology constraints= .

    =A0

    The operating assumption is that since Rank constrai= ns the set of parents a node can select, then separating it from metrics is problematic.

    =A0

    The OF computes the Rank (this has always been the c= ase): it should have all of the needed information. Or is there something in the dra= ft that says it won't?

    =A0

    Phil

    =A0
    =A0
    __________________________________________=
_____
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll
    =A0
    --001485f5b1b89747ee0483b4fe97-- From mdurvy@cisco.com Thu Apr 8 01:17:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6093A69B3 for ; Thu, 8 Apr 2010 01:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vabq-Xx8z7gM for ; Thu, 8 Apr 2010 01:17:21 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8C4B43A6A0C for ; Thu, 8 Apr 2010 01:16:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-AV: E=Sophos;i="4.52,169,1270425600"; d="p7s'?scan'208";a="179914169" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2010 08:16:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o388GOYB026727; Thu, 8 Apr 2010 08:16:25 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 10:16:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Apr 2010 10:16:23 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_091C_01CAD704.8A162AB0"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSO Interop event - Feed-back welcome Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvg References: From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 08 Apr 2010 08:16:24.0074 (UTC) FILETIME=[C730C6A0:01CAD6F3] Cc: ROLL WG Subject: Re: [Roll] IPSO Interop event - Feed-back welcome X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 08:17:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_091C_01CAD704.8A162AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, Following the discussion on the mailing list I just wanted to clarify a few things so that we can find the best way to interact in the future. - We were proposed a slot to announce this first interop event during the ROLL WG meeting, future events may be advertised only on an IPSO web-site if this is preferred by the WG. - IPSO is not defining standards. It is organizing interop events to ensure that different implementations of the same standard do work together. The current status is that you have to pay a membership fee to participate in these events (and indeed these events take work, prior preparation, and money to organize). - We understand (at least) some people are still interested in interop event feedback. This will be given on individual, voluntary, basis by the participants of the interop event. Best, Mathilde -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com] Sent: vendredi, 26. mars 2010 03:55 To: Mathilde Durvy (mdurvy) Cc: ROLL WG Subject: IPSO Interop event - Feed-back welcome Hi, Just re-enforcing my comments during the ROLL WG meeting ... any feed- back from the IPSO interop about any issues that you may have found would be extremely useful to continue to improve our spec. Feel free to also share good news. Thanks. JP. ------=_NextPart_000_091C_01CAD704.8A162AB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDQwODA4MTYyM1owIwYJKoZI hvcNAQkEMRYEFLBvSviR1sxFF0d6ypIbAK4lm1uEMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGATXe3 /XFMYIapzVdP2fsH/5/DZsN3MBfN/OG5sNkJQGaFMd/8BcqYih/+j8dIsG9EigxvtkPzjaBez8+T 2FoF1dkYK2X3R8xlsfPwJl8QdXTlRld0ykztB0zHCRXWoQxaP+kHozgV7gJGNs2SbT2lwFjMYg8o /zQRcV/YI+sDfp8AAAAAAAA= ------=_NextPart_000_091C_01CAD704.8A162AB0-- From alexandru.petrescu@gmail.com Thu Apr 8 01:26:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1893A6A0D for ; Thu, 8 Apr 2010 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb79rMvFsqdh for ; Thu, 8 Apr 2010 01:26:57 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 61AD93A69F5 for ; Thu, 8 Apr 2010 01:26:17 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E86E2D48187 for ; Thu, 8 Apr 2010 10:26:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id F0945D48021 for ; Thu, 8 Apr 2010 10:26:08 +0200 (CEST) Message-ID: <4BBD9319.3000808@gmail.com> Date: Thu, 08 Apr 2010 10:26:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100407-1, 07/04/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] IPSO Interop event - Feed-back welcome X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 08:26:57 -0000 Le 08/04/2010 10:16, Mathilde Durvy (mdurvy) a écrit : [...] > - We understand (at least) some people are still interested in > interop event feedback. This will be given on individual, voluntary, > basis by the participants of the interop event. Who should I ask? I need to know which implementations were present and who interoperated with whom. Thanks, Alex > > Best, Mathilde > > > -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com] > Sent: vendredi, 26. mars 2010 03:55 To: Mathilde Durvy (mdurvy) Cc: > ROLL WG Subject: IPSO Interop event - Feed-back welcome > > Hi, > > Just re-enforcing my comments during the ROLL WG meeting ... any > feed- back from the IPSO interop about any issues that you may have > found would be extremely useful to continue to improve our spec. Feel > free to also share good news. > > Thanks. > > JP. > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Thu Apr 8 02:05:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50043A6A18 for ; Thu, 8 Apr 2010 02:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig8cp0OeUn0P for ; Thu, 8 Apr 2010 02:05:20 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0F6DD3A69EA for ; Thu, 8 Apr 2010 02:04:58 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 11:04:55 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FF2@zensys17.zensys.local> In-Reply-To: <01ae01cad126$7cb77240$762656c0$@alexander@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrRHXFi1IM+tvTSQQOogOInR2O18AACEh4QAXUyT/A= References: <677908518.2401541270072502887.JavaMail.root@mail02.pantherlink.uwm.edu><643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> <01ae01cad126$7cb77240$762656c0$@alexander@ekasystems.com> From: "Anders Brandt" To: "Roger Alexander" , "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:05:21 -0000 =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Roger Alexander > Sent: Thursday, April 01, 2010 01:04 > To: 'Mukul Goyal'; 'Richard Kelsey' > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > Hi Mukul, >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf=20 > > Of Mukul Goyal > > Sent: Wednesday, March 31, 2010 5:59 PM > > To: Richard Kelsey > > Cc: roll@ietf.org > > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >=20 > > Richard > >=20 > > >For me there is one big difference, which is that using two > > instances does not require any changes to the RPL draft. =20 > We need to=20 > > support multiple instances in any case, so using two instances for=20 > > separate up/down routes does not add any new complications. > >=20 > > I am not sure about the comparative overhead of 2 RPL=20 > instances versus > > 1 instance. Are you sure this is not going to be an issue=20 > for extreme-=20 > > RAM limited devices that can afford to join 1 DAG but not 2? > >=20 > > I guess this is probably not going to be an issue since,=20 > even if the=20 > > metrics are significantly asymmetrical, a node can simply=20 > choose all=20 > > its DAO parents as DAG parents but not actually use them for upward=20 > > communication. > >=20 > > I guess we need more opinions. >=20 > As indicated in my earlier response to Jonathan, it is=20 > possible to consider two instances for separate upward and=20 > downward routing but unless the intent is to allow for more=20 > diverse objective functions, it may be possible with separate=20 > directional metrics to use a single instance and so avoid=20 > additional potential state and operational overhead. + 1 >=20 > >=20 > > Thanks > > Mukul > >=20 > >=20 > > > I think the two instance solution would make sense if we=20 > stick with=20 > > > the current constraint in rpl-07 that DAO parents must be=20 > a subset=20 > > > of the DAG parents (i.e. all DAO parents are also DAG parents). > >=20 > > Yes. I am having trouble seeing how DAOs would work if DAO parents=20 > > were not also DAG parents. > >=20 > > > Then all we need is a way to specify whether or not an=20 > instance is=20 > > > building upward routes, downward routes, or both. > >=20 > > I think a better way to put it would be to specify how=20 > asymmetric link=20 > > metrics are to be combined (downward value only, upward value only,=20 > > max of the two, min of the two, average, ...). I will ask=20 > JP to open=20 > > a ticket. > >=20 > > > The only other minor issue > > > is whether we need to think through any cases where coordination=20 > > > between the upwards and downwards instances is useful. =20 > For example,=20 > > > what needs to happen when packet delivery fails on the downward=20 > > > route? Does the error/backtracking happen on the same=20 > instance or a=20 > > > different instance? Do we need to specify such behavior=20 > in the core=20 > > > spec? > >=20 > > Again, I do not see how this is different from other collections of=20 > > instances. What happens when a packet delivery fails on a=20 > low-latency=20 > > instance? Does the error get forwarded on that instance or=20 > some other=20 > > instance? > >=20 > > -Richard Kelsey=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Thu Apr 8 02:15:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBF13A6832 for ; Thu, 8 Apr 2010 02:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.835 X-Spam-Level: X-Spam-Status: No, score=-8.835 tagged_above=-999 required=5 tests=[AWL=1.764, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87OPKxStnYZW for ; Thu, 8 Apr 2010 02:15:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E260E3A67CF for ; Thu, 8 Apr 2010 02:15:43 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHM7vUurR7H+/2dsb2JhbACbLXGfW5kihQkEjjo X-IronPort-AV: E=Sophos;i="4.52,169,1270425600"; d="scan'208";a="179937568" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2010 09:15:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o389Fb5f008898; Thu, 8 Apr 2010 09:15:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 11:15:16 +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, 8 Apr 2010 11:15:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> In-Reply-To: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposal for Source Routing Header Format and Source RoutingOperations Thread-Index: AcrWjbRWtbbeEP0rQX2EjTMIG5kzGAAbSz7Q References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" , "ROLL WG" X-OriginalArrivalTime: 08 Apr 2010 09:15:16.0674 (UTC) FILETIME=[00C8C220:01CAD6FC] Subject: Re: [Roll] Proposal for Source Routing Header Format and Source RoutingOperations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:15:48 -0000 Hi John: IPv6 already has a number of routing headers, in particular RH0, though it is being deprecated for general use in the Internet. And there are reasons why the fields in RH0/1 are there and we need to make sure we lose none of that. In particular a RH is recoverable, and it is easy to spot the consumed entries. On top of this our new problems are: - make sure the RH stays within the RPL network (since it is used downwards that should be doable) - control the size (that probably means compress) Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JeongGil Ko (John) > Sent: Wednesday, April 07, 2010 10:05 PM > To: ROLL WG > Subject: [Roll] Proposal for Source Routing Header Format and Source > RoutingOperations >=20 > Hi! >=20 > Great to see all this discussions on downwards route establishment! To add > one more to the conversations here is a proposal for source routing headers. > In non-storing mode (where only the root has individual path information) > the root will be attaching a source routing header to the data packet that a > source node wants to send to a specific destination. We can always make the > header super fancy but in my opinion I think we only need two fields in this > header and here it is! Feel free to break the stuff and mangle with it so that it > looks great in the specs later on. FYI, this is the format that I am using in my > implementations so it does work :) >=20 > 1. Source Routing Header Format >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEntry (8 bits) | | > +-+-+-+-+-+-+-+-+ + > | Source Route Entry (128*NEntry bits) | > + + > | | >=20 > Figure 1. Proposed Source Routing Header Format; each line is 32 bits:) >=20 > - NEntry: Indicates the number of 128 bit addresses that the source route > entry field is carrying. >=20 > - Source Route Entry: List of 128 bit address that consist the route to the > destination. Here, the address of the node that is one hop away from the > *destination* comes first. >=20 > 2. Source Routing Packet Operations >=20 > When source routing is initiated at a storing node (e.g., root of the DODAG), > the header is attached on the data packet for the entire route (i.e., from > next hop node to the destination). This header is positioned in front of the > user payload. When the next hop node receives a packet that is not destined > to itself AND the network is NOT provisioned to be in 'storing mode' then it > checks NEntry to find what the next hop is in the source route entry. Since > the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms of hops) > order, a node can figure out what the next hop address is with only the > NEntry value (since it already knows how big an ipv6 address is). After > collecting the next hop node's address, the node erases this address > element from the entry and decreases NEntry by one. This assures that we > avoid the overhead of carrying the entire source route throughout the data > path. >=20 > The approach itself should be very simple and trivial for everyone to follow. > So we can start from here and build on! >=20 > Thanks. >=20 > -John >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Thu Apr 8 02:32:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CABA3A6A3B for ; Thu, 8 Apr 2010 02:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6P-dwT782Vg for ; Thu, 8 Apr 2010 02:32:09 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id C17C93A6A42 for ; Thu, 8 Apr 2010 02:31:12 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 11:31:09 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FF5@zensys17.zensys.local> In-Reply-To: <87r5n034nw.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQ5UQgpQnoBJccT8SfrUHe0WAKUQGGMRFQ References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com><8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> <87r5n034nw.fsf@kelsey-ws.hq.ember.com> From: "Anders Brandt" To: "Richard Kelsey" , "Jonathan Hui" Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:32:10 -0000 =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: Wednesday, March 31, 2010 17:14 > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > > From: Jonathan Hui > > Date: Tue, 30 Mar 2010 19:08:42 -0700 > >=20 > > I like the proposal in general, though it does need to be=20 > fleshed out=20 > > a bit more. >=20 > I have not gone over the draft to see exactly what changes=20 > would be required. If there is enough support for going=20 > forward, I will do so. This is all assuming that we stop=20 > supporting mixed mode, which will require its own set of=20 > changes to the text. >=20 > > Specifically, this works well in the non-storing case if all nodes=20 > > source DAOs to the root so that the root can properly=20 > construct paths=20 > > back to any individual node that is sending DAOs. But is there any=20 > > desire to allow some nodes not to source DAOs if they don't=20 > need to? =20 > > If so, we should specify that a node MUST source DAOs as=20 > long as they=20 > > are forwarding DAOs for descendants. >=20 > The current draft requires that all nodes send DAOs: >=20 > 13. A node that receives a newly incremented DTSN from a=20 > DAO Parent > MUST schedule a DAO transmission. >=20 > If we wanted to relax this, then yes, forwarding a DAO would=20 > require that the forwarder also send their own DIO. >=20 > > Separately, it might be nice to include a record-route=20 > mechanism (not=20 > > the same as reverse route stack DAOs) so that nodes that=20 > only want to=20 > > quickly establish routes can do so without having to=20 > possibly wait for=20 > > all ancestors to source their own DAOs as well. I've found that=20 > > record-route works really well in short request-response=20 > transactions,=20 > > especially in cases where you don't want to continuously maintain=20 > > downward routing state. >=20 > Yes. Would record route go in the RPL draft? I associate it=20 > what source route, which apparently cannot be in the RPL draft. Hm. Since source routing is the lowest common denominator for RPL I sure expect source routing is going to be in the RPL draft. >=20 > -Richard Kelsey >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Daniel.Popa@itron.com Thu Apr 8 02:40:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF10E3A6A28 for ; Thu, 8 Apr 2010 02:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tGh-05F7SjR for ; Thu, 8 Apr 2010 02:40:21 -0700 (PDT) Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id DE52E3A68CC for ; Thu, 8 Apr 2010 02:40:17 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 05:40:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations Thread-Index: AcrWjbRWtbbeEP0rQX2EjTMIG5kzGAAbSz7QAACR7MA= References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> From: "Popa, Daniel" To: "ROLL WG" Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:40:23 -0000 Hi Pascal, John, Since source routing explicitly gives forwarding instruction to each intermediate node, it can make sense to use only (MAC address based) L2 forwarding instead of (IPv6 address based) L3 forwarding.=20 This brings two advantages:=20 - avoid processing each transit packets up to L3.=20 - use MAC addresses that - in ROLL environment - have inherently shorter length than an IPv6 address.=20 Cheers, Daniel =20 =20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: jeudi 8 avril 2010 11:15 To: JeongGil Ko (John); ROLL WG Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations Hi John: IPv6 already has a number of routing headers, in particular RH0, though it is being deprecated for general use in the Internet. And there are reasons why the fields in RH0/1 are there and we need to make sure we lose none of that. In particular a RH is recoverable, and it is easy to spot the consumed entries. On top of this our new problems are: - make sure the RH stays within the RPL network (since it is used downwards that should be doable) - control the size (that probably means compress) Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JeongGil Ko (John) > Sent: Wednesday, April 07, 2010 10:05 PM > To: ROLL WG > Subject: [Roll] Proposal for Source Routing Header Format and Source > RoutingOperations >=20 > Hi! >=20 > Great to see all this discussions on downwards route establishment! To add > one more to the conversations here is a proposal for source routing headers. > In non-storing mode (where only the root has individual path information) > the root will be attaching a source routing header to the data packet that a > source node wants to send to a specific destination. We can always make the > header super fancy but in my opinion I think we only need two fields in this > header and here it is! Feel free to break the stuff and mangle with it so that it > looks great in the specs later on. FYI, this is the format that I am using in my > implementations so it does work :) >=20 > 1. Source Routing Header Format >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEntry (8 bits) | | > +-+-+-+-+-+-+-+-+ + > | Source Route Entry (128*NEntry bits) | > + + > | | >=20 > Figure 1. Proposed Source Routing Header Format; each line is 32 bits:) >=20 > - NEntry: Indicates the number of 128 bit addresses that the source route > entry field is carrying. >=20 > - Source Route Entry: List of 128 bit address that consist the route to the > destination. Here, the address of the node that is one hop away from the > *destination* comes first. >=20 > 2. Source Routing Packet Operations >=20 > When source routing is initiated at a storing node (e.g., root of the DODAG), > the header is attached on the data packet for the entire route (i.e., from > next hop node to the destination). This header is positioned in front of the > user payload. When the next hop node receives a packet that is not destined > to itself AND the network is NOT provisioned to be in 'storing mode' then it > checks NEntry to find what the next hop is in the source route entry. Since > the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms of hops) > order, a node can figure out what the next hop address is with only the > NEntry value (since it already knows how big an ipv6 address is). After > collecting the next hop node's address, the node erases this address > element from the entry and decreases NEntry by one. This assures that we > avoid the overhead of carrying the entire source route throughout the data > path. >=20 > The approach itself should be very simple and trivial for everyone to follow. > So we can start from here and build on! >=20 > Thanks. >=20 > -John >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko >=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 pthubert@cisco.com Thu Apr 8 02:50:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B946628C0F8 for ; Thu, 8 Apr 2010 02:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.238 X-Spam-Level: X-Spam-Status: No, score=-8.238 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GydRmnUd3i0j for ; Thu, 8 Apr 2010 02:50:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AB7043A6826 for ; Thu, 8 Apr 2010 02:50:41 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpDvUurR7Hu/2dsb2JhbACbL3GfZ5kjhQkEjjs X-IronPort-AV: E=Sophos;i="4.52,169,1270425600"; d="scan'208";a="179953009" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2010 09:50:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o389oUJ5001083; Thu, 8 Apr 2010 09:50:36 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 11:50:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 11:50:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BD364@XMB-AMS-107.cisco.com> In-Reply-To: <168d73a61dcec2047687f031edd1e3d7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #29: DIS packet format Thread-Index: AcrVzqKDlMIKgLJxRROTaFy/AvPz1gABOD4gAEqM/DA= References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D01923DCB@XMB-AMS-107.cisco.com><988B6221-1673-437E-B0B7-DD04FEC3DF5C@cisco.com> <4BB90A23.5000301@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D01923F38@XMB-AMS-107.cisco.com> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org><2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu><001c01cad5c4$77c8b8f0$675a2ad0$@com> <168d73a61dcec2047687f031edd1e3d7@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "Philip Levis" , X-OriginalArrivalTime: 08 Apr 2010 09:50:31.0922 (UTC) FILETIME=[ED91FD20:01CAD700] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:50:43 -0000 Hi Phil and Yoav: Do you think we can conclude on this? At the moment I do not know what to do for 08. - about placing the instance and the DODAGID in the base DIS (similar to other messages) or invent an option for that - about Phoebus' flags. For the O-flag: The flag makes explicit the request for an option, arguing that the presence of that option should not be inferred from the fact that a packet is unicast or mcast. Is there an objection to this flag? For the C-flag: It is Fair & Square to me that the DIO is fired after a random timer to eliminate hidden terminal, avoid sync effect, etc... And that excess of DIO response must be trickled out. And it is also very probable that the source of the DIS will see more DIOs than any of the routers playing trickle so it should get more than enough DIOs if trickle really filters some out. And if that's not enough, then the node can reissue a DIS, and the randomness in trickle will make it so that other routers reply. So I agree that this aspect of trickle plays there perfectly. =20 What troubles me is that past the wave of answers to the DIS, the routers will have to redo the exponential backoff game of multiplying by 2 till the max is reached. If there's no inconsistency to fix in the first place, then the routers should right away restore the previous value of their trickle timer, wouldn't you think? If so, then please go ahead and propose text for those flags that's clearer than the original proposal. Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Yoav Ben-Yehezkel > Sent: Wednesday, April 07, 2010 12:21 AM > To: Philip Levis > Cc: roll@ietf.org; phoebus@ieee.org > Subject: Re: [Roll] [roll] #29: DIS packet format >=20 > Thanks for the response. > See my comments in body of text. >=20 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Wednesday, April 07, 2010 12:18 AM > To: Yoav Ben-Yehezkel > Cc: phoebus@ieee.org; roll@ietf.org > Subject: Re: [Roll] [roll] #29: DIS packet format >=20 >=20 > On Apr 6, 2010, at 1:05 PM, Yoav Ben-Yehezkel wrote: >=20 > > Question: > > > > I understand that responding immediately causes broadcast storms. But > our > > initial concern was that resetting the trickle timer by all devices > > hearing a multicast DIS in a dense network, may also cause congestion > > by DIO responses (assuming no suppression is used). >=20 > This seems like a big assumption. >=20 > <> Maybe - but the question is whether RPL has to work under this > worst case assumption? I don't know the answer. Was hoping to get the > input from the WG. <> >=20 > > I was wondering whether a quick exponentially decaying reduction or > > reduction with probability of the timer do instead of a full timer > > reset (maybe multiplication or probability factors can be set on the > > DIS message)? For unicast DIS, the factors can indicate 100% timer reset. >=20 > That's an interesting question: seems like the exact kind of thing that > simulations, validated by experiments on real networks, can evaluate. > <> I agree. Are there WG members with a ready simulation that can > quickly check this? <> >=20 > > This can allow the DIS transmitter to make a flexible protocol that > allows > > for multiple "waves" of DIS messages to be sent by the same node, > > where the probability or the reduction factor starts off small, and is > increased > > gradually if the DIS transmitter requires more DIO responses. This > > protocol would also converge much faster if we can come up with a way > > of not sending DIOs that were already sent in previous "waves" (but > > let's focus on one problem solving at a time :) ) > > >=20 > This sounds like a very interesting idea. But does it matter? >=20 > My concern is that Trickle has been demonstrated to work well in multiple > protocol implementations with years of experience behind them. This > doesn't mean that Trickle is perfect: Joakim has pointed out how there can > be some unbalanced edge cases. But the goal here (RPL WG) isn't to come up > with new, interesting ideas, but rather to standardize current, well- > established practice. >=20 > <> I agree and I wasn't insinuating that this will be part of RPL > specification, I was just pointing out that this field of multiplication or > probability factor could leave lots of flexibility and enhancements should > someone try this direction for future research or even proprietary use. >=20 > I really see one proprietary place where it matters from our experience in > low speed PLC networks. >=20 > We see asymmetry of more than 20db difference on opposite links caused > by Receiver noises and Transmitter loads, so unlike the wireless media - for > us the assumption that a opposite link exists when receiving a DIO cannot be > implicit in many cases. Loosing the link with a parent from the parent set > without the parent loosing the link with the child is common and doing lots of > pings is a waste. So having a DIS/DIO session occasionally would really help to > quickly find alternate parents+update rank, and filtering DIO responses > would also help in these cases. > Does use of this kind of algorithm can remain proprietary as long as the > behavior of the transmitter transmitting the DIS and receiver once receiving > the DIS packet follows the critical MUST path of RPL? <> >=20 > With my academic hat on, I think think this is a fascinating direction for > investigation and research. With my engineering hat on, I am very skeptical. >=20 > <> :) With my academic hat on & :( with my engineering hat on. >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Apr 8 02:58:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F723A6826 for ; Thu, 8 Apr 2010 02:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71d7auPWvta2 for ; Thu, 8 Apr 2010 02:58:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C29CB3A683E for ; Thu, 8 Apr 2010 02:58:07 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEpFvUurR7H+/2dsb2JhbACbL3GfTZkihQkE X-IronPort-AV: E=Sophos;i="4.52,169,1270425600"; d="scan'208";a="112163480" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2010 09:58:04 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o389w1Sj007055; Thu, 8 Apr 2010 09:58:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 11:58:00 +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, 8 Apr 2010 11:57:56 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations Thread-Index: AcrWjbRWtbbeEP0rQX2EjTMIG5kzGAAbSz7QAACR7MAAAPUKYA== References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Popa, Daniel" , "ROLL WG" X-OriginalArrivalTime: 08 Apr 2010 09:58:00.0722 (UTC) FILETIME=[F9136F20:01CAD701] Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 09:58:23 -0000 Hi Daniel: Routers might have multiple interfaces of multiple MAC types. Internet 0 even has a MAC-less format. So the result of you proposal, which looks like a great idea in a pure 802.15.4 world with short addresses, becomes a nightmare to define in a fully generic fashion. OTOH, a locally significant opaque tag in which the parent could hide a short address of the child - if it cares to do it that way - looks like a way more acceptable approach So it seems to me that you can get what you want as long as we can make the tag big enough for short addresses. When the tag is too small to contain what the parent really needs, then the parent will have to store a state with the full information in memory, and then place an index of some sort in the tag. What do you think? Pascal > -----Original Message----- > From: Popa, Daniel [mailto:Daniel.Popa@itron.com] > Sent: Thursday, April 08, 2010 11:40 AM > To: ROLL WG > Cc: Pascal Thubert (pthubert); JeongGil Ko (John) > Subject: RE: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations >=20 > Hi Pascal, John, >=20 > Since source routing explicitly gives forwarding instruction to each > intermediate node, it can make sense to use only (MAC address based) L2 > forwarding instead of (IPv6 address based) L3 forwarding. >=20 > This brings two advantages: > - avoid processing each transit packets up to L3. > - use MAC addresses that - in ROLL environment - have inherently shorter > length than an IPv6 address. >=20 > Cheers, > Daniel >=20 >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: jeudi 8 avril 2010 11:15 > To: JeongGil Ko (John); ROLL WG > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations >=20 > Hi John: >=20 > IPv6 already has a number of routing headers, in particular RH0, though it is > being deprecated for general use in the Internet. > And there are reasons why the fields in RH0/1 are there and we need to > make sure we lose none of that. In particular a RH is recoverable, and it is > easy to spot the consumed entries. >=20 > On top of this our new problems are: > - make sure the RH stays within the RPL network (since it is used downwards > that should be doable) > - control the size (that probably means compress) >=20 > Cheers, >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > JeongGil Ko (John) > > Sent: Wednesday, April 07, 2010 10:05 PM > > To: ROLL WG > > Subject: [Roll] Proposal for Source Routing Header Format and Source > > RoutingOperations > > > > Hi! > > > > Great to see all this discussions on downwards route establishment! To > add > > one more to the conversations here is a proposal for source routing > headers. > > In non-storing mode (where only the root has individual path > information) > > the root will be attaching a source routing header to the data packet > that a > > source node wants to send to a specific destination. We can always > make the > > header super fancy but in my opinion I think we only need two fields > in this > > header and here it is! Feel free to break the stuff and mangle with it > so that it > > looks great in the specs later on. FYI, this is the format that I am > using in my > > implementations so it does work :) > > > > 1. Source Routing Header Format > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | NEntry (8 bits) | > | > > +-+-+-+-+-+-+-+-+ > + > > | Source Route Entry (128*NEntry bits) > | > > + > + > > | > | > > > > Figure 1. Proposed Source Routing Header Format; each line is 32 > bits:) > > > > - NEntry: Indicates the number of 128 bit addresses that the source > route > > entry field is carrying. > > > > - Source Route Entry: List of 128 bit address that consist the route > to the > > destination. Here, the address of the node that is one hop away from > the > > *destination* comes first. > > > > 2. Source Routing Packet Operations > > > > When source routing is initiated at a storing node (e.g., root of the > DODAG), > > the header is attached on the data packet for the entire route (i.e., > from > > next hop node to the destination). This header is positioned in front > of the > > user payload. When the next hop node receives a packet that is not > destined > > to itself AND the network is NOT provisioned to be in 'storing mode' > then it > > checks NEntry to find what the next hop is in the source route entry. > Since > > the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms > of hops) > > order, a node can figure out what the next hop address is with only > the > > NEntry value (since it already knows how big an ipv6 address is). > After > > collecting the next hop node's address, the node erases this address > > element from the entry and decreases NEntry by one. This assures that > we > > avoid the overhead of carrying the entire source route throughout the > data > > path. > > > > The approach itself should be very simple and trivial for everyone to > follow. > > So we can start from here and build on! > > > > Thanks. > > > > -John > > > > ------ > > JeongGil Ko (John) > > Ph.D. Student > > Department of Computer Science > > Johns Hopkins University > > http://www.cs.jhu.edu/~jgko > > > > _______________________________________________ > > 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 Daniel.Popa@itron.com Thu Apr 8 03:47:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CF93A69A3 for ; Thu, 8 Apr 2010 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s107irDa6A3u for ; Thu, 8 Apr 2010 03:47:32 -0700 (PDT) Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 999F928C138 for ; Thu, 8 Apr 2010 03:47:01 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 06:46:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations Thread-Index: AcrWjbRWtbbeEP0rQX2EjTMIG5kzGAAbSz7QAACR7MAAAPUKYAAAtoIA References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> From: "Popa, Daniel" To: "Pascal Thubert (pthubert)" , "ROLL WG" Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Apr 2010 10:47:41 -0000 Hi Pascal:=20 Some further thoughts between you lines.=20 Daniel=20 -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: jeudi 8 avril 2010 11:58 To: Popa, Daniel; ROLL WG Cc: JeongGil Ko (John) Subject: RE: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations Hi Daniel: Routers might have multiple interfaces of multiple MAC types. Internet 0 even has a MAC-less format. So the result of you proposal, which looks like a great idea in a pure 802.15.4 world with short addresses, becomes a nightmare to define in a fully generic fashion. -- DP: Indeed, I was thinking at 802.15.4 interfaces. The idea was that the routing protocol might have several instances of source routing scheme, for specific interfaces, and so it can use for 802.15.4 interface(s) the short MAC addresses instead of the IPv6 addresses. -- OTOH, a locally significant opaque tag in which the parent could hide a short address of the child - if it cares to do it that way - looks like a way more acceptable approach -- DP: You read my mind! :) A generic tagging mechanisms can efficiently hide multiple addressing and forwarding schemes, from various layers. The generic tag can then have different meanings for different interfaces. What do you think ? -- So it seems to me that you can get what you want as long as we can make the tag big enough for short addresses. When the tag is too small to contain what the parent really needs, then the parent will have to store a state with the full information in memory, and then place an index of some sort in the tag. --- DP: It seems to me that there is always a trade-off between the depth of the tree (i.e., number of intermediate hops between source and destination) and the efficiency of source routing protocol, irrespective of using tagging or IPv6 address. I would have a preference for defining a maximum size of the tag big enough to accommodate short addresses (but I think these will not be a problem if the maximum size of the tag is chosen as a function of IPv6 address length). --- > -----Original Message----- > From: Popa, Daniel [mailto:Daniel.Popa@itron.com] > Sent: Thursday, April 08, 2010 11:40 AM > To: ROLL WG > Cc: Pascal Thubert (pthubert); JeongGil Ko (John) > Subject: RE: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations >=20 > Hi Pascal, John, >=20 > Since source routing explicitly gives forwarding instruction to each > intermediate node, it can make sense to use only (MAC address based) L2 > forwarding instead of (IPv6 address based) L3 forwarding. >=20 > This brings two advantages: > - avoid processing each transit packets up to L3. > - use MAC addresses that - in ROLL environment - have inherently shorter > length than an IPv6 address. >=20 > Cheers, > Daniel >=20 >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: jeudi 8 avril 2010 11:15 > To: JeongGil Ko (John); ROLL WG > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations >=20 > Hi John: >=20 > IPv6 already has a number of routing headers, in particular RH0, though it is > being deprecated for general use in the Internet. > And there are reasons why the fields in RH0/1 are there and we need to > make sure we lose none of that. In particular a RH is recoverable, and it is > easy to spot the consumed entries. >=20 > On top of this our new problems are: > - make sure the RH stays within the RPL network (since it is used downwards > that should be doable) > - control the size (that probably means compress) >=20 > Cheers, >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > JeongGil Ko (John) > > Sent: Wednesday, April 07, 2010 10:05 PM > > To: ROLL WG > > Subject: [Roll] Proposal for Source Routing Header Format and Source > > RoutingOperations > > > > Hi! > > > > Great to see all this discussions on downwards route establishment! To > add > > one more to the conversations here is a proposal for source routing > headers. > > In non-storing mode (where only the root has individual path > information) > > the root will be attaching a source routing header to the data packet > that a > > source node wants to send to a specific destination. We can always > make the > > header super fancy but in my opinion I think we only need two fields > in this > > header and here it is! Feel free to break the stuff and mangle with it > so that it > > looks great in the specs later on. FYI, this is the format that I am > using in my > > implementations so it does work :) > > > > 1. Source Routing Header Format > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | NEntry (8 bits) | > | > > +-+-+-+-+-+-+-+-+ > + > > | Source Route Entry (128*NEntry bits) > | > > + > + > > | > | > > > > Figure 1. Proposed Source Routing Header Format; each line is 32 > bits:) > > > > - NEntry: Indicates the number of 128 bit addresses that the source > route > > entry field is carrying. > > > > - Source Route Entry: List of 128 bit address that consist the route > to the > > destination. Here, the address of the node that is one hop away from > the > > *destination* comes first. > > > > 2. Source Routing Packet Operations > > > > When source routing is initiated at a storing node (e.g., root of the > DODAG), > > the header is attached on the data packet for the entire route (i.e., > from > > next hop node to the destination). This header is positioned in front > of the > > user payload. When the next hop node receives a packet that is not > destined > > to itself AND the network is NOT provisioned to be in 'storing mode' > then it > > checks NEntry to find what the next hop is in the source route entry. > Since > > the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms > of hops) > > order, a node can figure out what the next hop address is with only > the > > NEntry value (since it already knows how big an ipv6 address is). > After > > collecting the next hop node's address, the node erases this address > > element from the entry and decreases NEntry by one. This assures that > we > > avoid the overhead of carrying the entire source route throughout the > data > > path. > > > > The approach itself should be very simple and trivial for everyone to > follow. > > So we can start from here and build on! > > > > Thanks. > > > > -John > > > > ------ > > JeongGil Ko (John) > > Ph.D. Student > > Department of Computer Science > > Johns Hopkins University > > http://www.cs.jhu.edu/~jgko > > > > _______________________________________________ > > 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 robert.cragie@gridmerge.com Thu Apr 8 04:26:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC043A6A3E for ; Thu, 8 Apr 2010 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBQ2mjWckaRB for ; Thu, 8 Apr 2010 04:26:20 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 4B6863A6A36 for ; Thu, 8 Apr 2010 04:26:20 -0700 (PDT) Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1NzpsF-0006Ag-3Q; Thu, 08 Apr 2010 12:26:15 +0100 Message-ID: <4BBDBD50.8030704@gridmerge.com> Date: Thu, 08 Apr 2010 12:26:08 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mukul Goyal , ROLL WG References: <1933727418.5688951270724843292.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1933727418.5688951270724843292.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080405080009020603020200" Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 11:26:22 -0000 This is a cryptographically signed message in MIME format. --------------ms080405080009020603020200 Content-Type: multipart/alternative; boundary="------------080209010403070109030401" This is a multi-part message in MIME format. --------------080209010403070109030401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mukul On 08/04/2010 12:07 PM, Mukul Goyal wrote: > Hi Robert > > =20 >> So when B receives a multicast DIO from A, B may know: >> =20 > =20 >> 1) unidirectional cost A->B only or >> 2) unidirectional cost B->A only or >> 3) both or >> 4) none >> =20 > Whether B knows A->B or B->A or both or none, really depends on the def= inition of L3 cost. Here are some examples: > > If the cost is ETX, it seems that B does not know A->B. It may know B->= A on the basis of past history of sending packets to A. > =20 But B knows there is a viable link A->B at that epoch by virtue of=20 receiving the packet at the very least. It would seem pointless to=20 ignore this as part of the link cost assessment, surely? > If the cost is LQI, B knows A->B. It probably does not know B->A unless= it received some past feedback from A. > > =20 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com --------------080209010403070109030401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
    Hi Mukul

On 08/04/2010 12:07 PM, Mukul Goyal wrote:

    Hi Robert

  
    So when B receives a multicast DIO from A, B may know:=
=20
    
      
    1) unidirectional cost A->B only or=20
2) unidirectional cost B->A only or=20
3) both or=20
4) none=20
    
    Whether B knows A->B or B->A or both or none, really depends on the=
 definition of L3 cost. Here are some examples:

If the cost is ETX, it seems that B does not know A->B. It may know B-=
>A on the basis of past history of sending packets to A.
    <RCC>But B knows there is a viable link A->B at that epoch by virtue of receiving the packet at the very least. It would seem pointless to ignore this as part of the link cost assessment, surely?</RCC>
    If the cost is LQI, B knows A->B. It probably does not know B->A un=
less it received some past feedback from A.
    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888
    http://www.gridmerge.com


    



--------------080209010403070109030401--

--------------ms080405080009020603020200
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgxMTI2MDhaMCMGCSqGSIb3DQEJBDEWBBSxbCvEzfJDtlbw/r0qaJjY7Op8qjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAJ2DbBpoTKRNihDswVrbBqHTx0753iwK13GdKs2oQCZBrBXjCR6vO0uEy7Qv/pR+VmG5
3pXqIt7wxyKHRTcYY/bq8MnD26b7LUmRMo9G90Rwn0liReeGIi4+pT62Inp7YwQXxdj0bKJI
pIDsVtSbXjY1awQZvTiUASbg4Ss9spUJgypeyF3qdBoVHxk70C/W2EUMlskR+0dfuWuBwOMO
UUm8KRc27t+9j/Lg+cr6M2yHBzg5C9Dj9yE4i0gHIQogzXkoKudSDjG19jfzWmj+hJrSARtp
Td0lgRm9gqnYaRF61w9wdZrLIvfEz79KQOHgnAqGcrwJuJM6Kg1w2lLHucIAAAAAAAA=
--------------ms080405080009020603020200--

From robert.cragie@gridmerge.com  Thu Apr  8 04:53:20 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1680C3A6A41 for ; Thu,  8 Apr 2010 04:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.823
X-Spam-Level: 
X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.775,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io7AokL9o-kj for ; Thu,  8 Apr 2010 04:53:17 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id E05113A68E7 for ; Thu,  8 Apr 2010 04:53:13 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1NzqIH-0003b5-86 for roll@ietf.org; Thu, 08 Apr 2010 12:53:10 +0100
Message-ID: <4BBDC39F.3040601@gridmerge.com>
Date: Thu, 08 Apr 2010 12:53:03 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000908020102030604060607"
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 11:53:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms000908020102030604060607
Content-Type: multipart/alternative;
 boundary="------------000603000808010401050606"

This is a multi-part message in MIME format.
--------------000603000808010401050606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot =

of overhead for certain underlying link layers, e.g. 802.15.4. I think=20
it is generally cleaner to do the compression at a layer which may=20
require it only, e.g. define it in the 6lowpan HC. This is then free to=20
some extent to specify how the compression is done. Although I doubt=20
this would go down well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing=20
to nodes which operate the scheme. This is probably acceptable=20
practically but doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry=20
the full source route all the way to at least the penultimate node and=20
use an index to show the current position in the route for potential=20
backtrace and error reporting back along the same route (assuming link=20
symmetry). This is how RH0 works.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types. Internet =
0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define in a=

> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could hide a=

> short address of the child - if it cares to do it that way - looks like=

> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can make=

> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to stor=
e
> a state with the full information in memory, and then place an index of=

> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>   =20
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
>>     =20
> L2
>   =20
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>>   - avoid processing each transit packets up to L3.
>>   - use MAC addresses that - in ROLL environment - have inherently
>>     =20
> shorter
>   =20
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>     =20
> Of
>   =20
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
>>     =20
> though it is
>   =20
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need to=

>> make sure we lose none of that. In particular a RH is recoverable, and=

>>     =20
> it is
>   =20
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
>>     =20
> downwards
>   =20
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>     =20
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>>       =20
>> Of
>>     =20
>>> JeongGil Ko (John)
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>> To: ROLL WG
>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>> RoutingOperations
>>>
>>> Hi!
>>>
>>> Great to see all this discussions on downwards route establishment!
>>>       =20
> To
>   =20
>> add
>>     =20
>>> one more to the conversations here is a proposal for source routing
>>>       =20
>> headers.
>>     =20
>>> In non-storing mode (where only the root has individual path
>>>       =20
>> information)
>>     =20
>>> the root will be attaching a source routing header to the data
>>>       =20
> packet
>   =20
>> that a
>>     =20
>>> source node wants to send to a specific destination. We can always
>>>       =20
>> make the
>>     =20
>>> header super fancy but in my opinion I think we only need two fields
>>>       =20
>> in this
>>     =20
>>> header and here it is! Feel free to break the stuff and mangle with
>>>       =20
> it
>   =20
>> so that it
>>     =20
>>> looks great in the specs later on. FYI, this is the format that I am
>>>       =20
>> using in my
>>     =20
>>> implementations so it does work :)
>>>
>>> 1. Source Routing Header Format
>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |   NEntry (8 bits)   |
>>>       =20
>> |
>>     =20
>>> +-+-+-+-+-+-+-+-+
>>>       =20
>> +
>>     =20
>>> |                       Source Route Entry (128*NEntry bits)
>>>       =20
>> |
>>     =20
>>> +
>>>       =20
>> +
>>     =20
>>> |
>>>       =20
>> |
>>     =20
>>>        Figure 1. Proposed Source Routing Header Format; each line is
>>>       =20
> 32
>   =20
>> bits:)
>>     =20
>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>>       =20
>> route
>>     =20
>>> entry field is carrying.
>>>
>>> - Source Route Entry: List of 128 bit address that consist the route
>>>       =20
>> to the
>>     =20
>>> destination. Here, the address of the node that is one hop away from
>>>       =20
>> the
>>     =20
>>> *destination* comes first.
>>>
>>> 2. Source Routing Packet Operations
>>>
>>> When source routing is initiated at a storing node (e.g., root of
>>>       =20
> the
>   =20
>> DODAG),
>>     =20
>>> the header is attached on the data packet for the entire route
>>>       =20
> (i.e.,
>   =20
>> from
>>     =20
>>> next hop node to the destination). This header is positioned in
>>>       =20
> front
>   =20
>> of the
>>     =20
>>> user payload. When the next hop node receives a packet that is not
>>>       =20
>> destined
>>     =20
>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>>>       =20
>> then it
>>     =20
>>> checks NEntry to find what the next hop is in the source route
>>>       =20
> entry.
>   =20
>> Since
>>     =20
>>> the 'Source Route Entry' is ordered in 'farthest ->  closest' (in
>>>       =20
> terms
>   =20
>> of hops)
>>     =20
>>> order, a node can figure out what the next hop address is with only
>>>       =20
>> the
>>     =20
>>> NEntry value (since it already knows how big an ipv6 address is).
>>>       =20
>> After
>>     =20
>>> collecting the next hop node's address, the node erases this address
>>> element from the entry and decreases NEntry by one. This assures
>>>       =20
> that
>   =20
>> we
>>     =20
>>> avoid the overhead of carrying the entire source route throughout
>>>       =20
> the
>   =20
>> data
>>     =20
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
>>>       =20
> to
>   =20
>> follow.
>>     =20
>>> So we can start from here and build on!
>>>
>>> Thanks.
>>>
>>> -John
>>>
>>> ------
>>> JeongGil Ko (John)
>>> Ph.D. Student
>>> Department of Computer Science
>>> Johns Hopkins University
>>> http://www.cs.jhu.edu/~jgko
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>       =20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>     =20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>   =20

--------------000603000808010401050606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


Hi Pascal,
    

    
Source routing should of course use the IPv6 addresses which means a
lot of overhead for certain underlying link layers, e.g. 802.15.4. I
think it is generally cleaner to do the compression at a layer which
may require it only, e.g. define it in the 6lowpan HC. This is then
free to some extent to specify how the compression is done. Although I
doubt this would go down well in the 6lowpan WG...
    

    
The tag scheme would work but it specifically scopes the source routing
to nodes which operate the scheme. This is probably acceptable
practically but doesn't 'smell right' somehow.
    

    
With regard to the original proposal: it is probably necessary to carry
the full source route all the way to at least the penultimate node and
use an index to show the current position in the route for potential
backtrace and error reporting back along the same route (assuming link
symmetry). This is how RH0 works.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:

    
  
    Hi Daniel:

Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.

OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach

So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.

What do you think?

Pascal


  
    
  
    
    
    -----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)
    
    
  
    
  
    L2
  
    
  
    
    
    forwarding instead of (IPv6 address based) L3 forwardi=
ng.

This brings two advantages:
 - avoid processing each transit packets up to L3.
 - use MAC addresses that - in ROLL environment - have inherently
    
    
  
    
  
    shorter
  
    
  
    
    
    length than an IPv6 address.

Cheers,
Daniel



-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
    
    
  
    
  
    Of
  
    
  
    
    
    Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

IPv6 already has a number of routing headers, in particular RH0,
    
    
  
    
  
    though it is
  
    
  
    
    
    being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
    
    
  
    
  
    it is
  
    
  
    
    
    easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
    
    
  
    
  
    downwards
  
    
  
    
    
    that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal


    
    
    
    
      
    -----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
      
    
    
    
    
    Of
    
    
    
    
      
    JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

Great to see all this discussions on downwards route establishment!
      
    
    
    
  
    
  
    To
  
    
  
    
    
    add
    
    
    
    
      
    one more to the conversations here is a proposal for=
 source routing
      
    
    
    
    
    headers.
    
    
    
    
      
    In non-storing mode (where only the root has individ=
ual path
      
    
    
    
    
    information)
    
    
    
    
      
    the root will be attaching a source routing header t=
o the data
      
    
    
    
  
    
  
    packet
  
    
  
    
    
    that a
    
    
    
    
      
    source node wants to send to a specific destination.=
 We can always
      
    
    
    
    
    make the
    
    
    
    
      
    header super fancy but in my opinion I think we only=
 need two fields
      
    
    
    
    
    in this
    
    
    
    
      
    header and here it is! Feel free to break the stuff =
and mangle with
      
    
    
    
  
    
  
    it
  
    
  
    
    
    so that it
    
    
    
    
      
    looks great in the specs later on. FYI, this is the =
format that I am
      
    
    
    
    
    using in my
    
    
    
    
      
    implementations so it does work :)

1. Source Routing Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |
      
    
    
    
    
    |
    
    
    
    
      
    +-+-+-+-+-+-+-+-+
      
    
    
    
    
    +
    
    
    
    
      
    |                       Source Route Entry (128*NEnt=
ry bits)
      
    
    
    
    
    |
    
    
    
    
      
    +
      
    
    
    
    
    +
    
    
    
    
      
    |
      
    
    
    
    
    |
    
    
    
    
      
          Figure 1. Proposed Source Routing Header Format; each line is
      
    
    
    
  
    
  
    32
  
    
  
    
    
    bits:)
    
    
    
    
      
    - NEntry: Indicates the number of 128 bit addresses that the source
      
    
    
    
    
    route
    
    
    
    
      
    entry field is carrying.

- Source Route Entry: List of 128 bit address that consist the route
      
    
    
    
    
    to the
    
    
    
    
      
    destination. Here, the address of the node that is o=
ne hop away from
      
    
    
    
    
    the
    
    
    
    
      
    *destination* comes first.

2. Source Routing Packet Operations

When source routing is initiated at a storing node (e.g., root of
      
    
    
    
  
    
  
    the
  
    
  
    
    
    DODAG),
    
    
    
    
      
    the header is attached on the data packet for the en=
tire route
      
    
    
    
  
    
  
    (i.e.,
  
    
  
    
    
    from
    
    
    
    
      
    next hop node to the destination). This header is po=
sitioned in
      
    
    
    
  
    
  
    front
  
    
  
    
    
    of the
    
    
    
    
      
    user payload. When the next hop node receives a pack=
et that is not
      
    
    
    
    
    destined
    
    
    
    
      
    to itself AND the network is NOT provisioned to be i=
n 'storing mode'
      
    
    
    
    
    then it
    
    
    
    
      
    checks NEntry to find what the next hop is in the so=
urce route
      
    
    
    
  
    
  
    entry.
  
    
  
    
    
    Since
    
    
    
    
      
    the 'Source Route Entry' is ordered in 'farthest -&g=
t; closest' (in
      
    
    
    
  
    
  
    terms
  
    
  
    
    
    of hops)
    
    
    
    
      
    order, a node can figure out what the next hop addre=
ss is with only
      
    
    
    
    
    the
    
    
    
    
      
    NEntry value (since it already knows how big an ipv6=
 address is).
      
    
    
    
    
    After
    
    
    
    
      
    collecting the next hop node's address, the node era=
ses this address
element from the entry and decreases NEntry by one. This assures
      
    
    
    
  
    
  
    that
  
    
  
    
    
    we
    
    
    
    
      
    avoid the overhead of carrying the entire source rou=
te throughout
      
    
    
    
  
    
  
    the
  
    
  
    
    
    data
    
    
    
    
      
    path.

The approach itself should be very simple and trivial for everyone
      
    
    
    
  
    
  
    to
  
    
  
    
    
    follow.
    
    
    
    
      
    So we can start from here and build on!

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
h=
ttp://www.cs.jhu.edu/~jgko

_______________________________________________
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

  
    

    



--------------000603000808010401050606--

--------------ms000908020102030604060607
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgxMTUzMDNaMCMGCSqGSIb3DQEJBDEWBBRjDtH+8HlWVtQHkDPg/IqDE5wqwDBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAEpd1UPnO8ZPaoZbmcjPSRZNhlussDK0Kh4L74oL1dkvDNhj/kGuT+rS7DkE7odfCyvC
IiOSb0Z7KG0nTZ4HiWXxARyqsW/IkUf6+vy+9GT1g6vu+fwSTVo9OJhXGhDU2fJx68iuCqar
ecGoqclEcM2ipOAmqXf1xe5AG9wlyjVzFvIgLTmwlKt3OUMjkmVa0e+sLovZ8mxspReykJae
yQn2fXzGMWDikoVE+6VKdOrGfH1aHgVtw4RHvCHRQVNRRQO8ScGlocDJvei/l00bnZ9nQpo6
hqXrCBj7TU64nA2TFvsZskGxnXphhaPpEQF5epTgFP04f3QpOQ3ymoilBb4AAAAAAAA=
--------------ms000908020102030604060607--

From daniel.gavelle@jennic.com  Thu Apr  8 06:11:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80B53A6A6B for ; Thu,  8 Apr 2010 06:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoLOPOG96pq1 for ; Thu,  8 Apr 2010 06:11:36 -0700 (PDT)
Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id C984C3A6A6E for ; Thu,  8 Apr 2010 06:11:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 942649BE503; Thu,  8 Apr 2010 14:11:30 +0100 (BST)
Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VYnxM4eZnuh; Thu,  8 Apr 2010 14:11:30 +0100 (BST)
Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 759249BE4FF; Thu,  8 Apr 2010 14:11:30 +0100 (BST)
Message-ID: <4BBDD602.7040707@jennic.com>
Date: Thu, 08 Apr 2010 14:11:30 +0100
From: Daniel Gavelle 
Organization: Jennic Ltd.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: robert.cragie@gridmerge.com
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <4BBDC39F.3040601@gridmerge.com>
In-Reply-To: <4BBDC39F.3040601@gridmerge.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: daniel.gavelle@jennic.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 13:11:39 -0000

Rob,

I agree that the source routing for the data frames should be done as 
part of the 6LowPAN HC.  This already has a stateful IPV6 address 
compression based on contexts.  It should be possible to compress the 
addresses down to two bytes per address if IPv6 addresses are derived 
from the 16 bit short address are being used in the LowPAN.

We don't want to hold up the current HC draft that is going through last 
call but the work could be done as a new RFC / amendment.  Source 
routing compression may need a fix for the problem of HC compression 
extending beyond the first fragment.

Doing the work in the 6LowPAN group means that the compression can 
easily be used for any source routing protocol, not just ROLL.  It could 
be done as a compression for the existing R0 routing header.  Maybe this 
thread needs moving to the 6LowPAN reflector.

Daniel.


Robert Cragie wrote:
> Hi Pascal,
> 
> Source routing should of course use the IPv6 addresses which means a lot 
> of overhead for certain underlying link layers, e.g. 802.15.4. I think 
> it is generally cleaner to do the compression at a layer which may 
> require it only, e.g. define it in the 6lowpan HC. This is then free to 
> some extent to specify how the compression is done. Although I doubt 
> this would go down well in the 6lowpan WG...
> 
> The tag scheme would work but it specifically scopes the source routing 
> to nodes which operate the scheme. This is probably acceptable 
> practically but doesn't 'smell right' somehow.
> 
> With regard to the original proposal: it is probably necessary to carry 
> the full source route all the way to at least the penultimate node and 
> use an index to show the current position in the route for potential 
> backtrace and error reporting back along the same route (assuming link 
> symmetry). This is how RH0 works.
> 
> Robert
> 
> Robert Cragie (Pacific Gas & Electric)
> 
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com 
> 
> 
> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. Internet 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a pure
>> 802.15.4 world with short addresses, becomes a nightmare to define in a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could hide a
>> short address of the child - if it cares to do it that way - looks like
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can make
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to store
>> a state with the full information in memory, and then place an index of
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>   
>>> -----Original Message-----
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>> To: ROLL WG
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi Pascal, John,
>>>
>>> Since source routing explicitly gives forwarding instruction to each
>>> intermediate node, it can make sense to use only (MAC address based)
>>>     
>> L2
>>   
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>> This brings two advantages:
>>>  - avoid processing each transit packets up to L3.
>>>  - use MAC addresses that - in ROLL environment - have inherently
>>>     
>> shorter
>>   
>>> length than an IPv6 address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>>     
>> Of
>>   
>>> Pascal Thubert (pthubert)
>>> Sent: jeudi 8 avril 2010 11:15
>>> To: JeongGil Ko (John); ROLL WG
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi John:
>>>
>>> IPv6 already has a number of routing headers, in particular RH0,
>>>     
>> though it is
>>   
>>> being deprecated for general use in the Internet.
>>> And there are reasons why the fields in RH0/1 are there and we need to
>>> make sure we lose none of that. In particular a RH is recoverable, and
>>>     
>> it is
>>   
>>> easy to spot the consumed entries.
>>>
>>> On top of this our new problems are:
>>> - make sure the RH stays within the RPL network (since it is used
>>>     
>> downwards
>>   
>>> that should be doable)
>>> - control the size (that probably means compress)
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>     
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>>>       
>>> Of
>>>     
>>>> JeongGil Ko (John)
>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>> To: ROLL WG
>>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>>> RoutingOperations
>>>>
>>>> Hi!
>>>>
>>>> Great to see all this discussions on downwards route establishment!
>>>>       
>> To
>>   
>>> add
>>>     
>>>> one more to the conversations here is a proposal for source routing
>>>>       
>>> headers.
>>>     
>>>> In non-storing mode (where only the root has individual path
>>>>       
>>> information)
>>>     
>>>> the root will be attaching a source routing header to the data
>>>>       
>> packet
>>   
>>> that a
>>>     
>>>> source node wants to send to a specific destination. We can always
>>>>       
>>> make the
>>>     
>>>> header super fancy but in my opinion I think we only need two fields
>>>>       
>>> in this
>>>     
>>>> header and here it is! Feel free to break the stuff and mangle with
>>>>       
>> it
>>   
>>> so that it
>>>     
>>>> looks great in the specs later on. FYI, this is the format that I am
>>>>       
>>> using in my
>>>     
>>>> implementations so it does work :)
>>>>
>>>> 1. Source Routing Header Format
>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> |   NEntry (8 bits)   |
>>>>       
>>> |
>>>     
>>>> +-+-+-+-+-+-+-+-+
>>>>       
>>> +
>>>     
>>>> |                       Source Route Entry (128*NEntry bits)
>>>>       
>>> |
>>>     
>>>> +
>>>>       
>>> +
>>>     
>>>> |
>>>>       
>>> |
>>>     
>>>>       Figure 1. Proposed Source Routing Header Format; each line is
>>>>       
>> 32
>>   
>>> bits:)
>>>     
>>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>>>       
>>> route
>>>     
>>>> entry field is carrying.
>>>>
>>>> - Source Route Entry: List of 128 bit address that consist the route
>>>>       
>>> to the
>>>     
>>>> destination. Here, the address of the node that is one hop away from
>>>>       
>>> the
>>>     
>>>> *destination* comes first.
>>>>
>>>> 2. Source Routing Packet Operations
>>>>
>>>> When source routing is initiated at a storing node (e.g., root of
>>>>       
>> the
>>   
>>> DODAG),
>>>     
>>>> the header is attached on the data packet for the entire route
>>>>       
>> (i.e.,
>>   
>>> from
>>>     
>>>> next hop node to the destination). This header is positioned in
>>>>       
>> front
>>   
>>> of the
>>>     
>>>> user payload. When the next hop node receives a packet that is not
>>>>       
>>> destined
>>>     
>>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>>>>       
>>> then it
>>>     
>>>> checks NEntry to find what the next hop is in the source route
>>>>       
>> entry.
>>   
>>> Since
>>>     
>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>>>       
>> terms
>>   
>>> of hops)
>>>     
>>>> order, a node can figure out what the next hop address is with only
>>>>       
>>> the
>>>     
>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>>       
>>> After
>>>     
>>>> collecting the next hop node's address, the node erases this address
>>>> element from the entry and decreases NEntry by one. This assures
>>>>       
>> that
>>   
>>> we
>>>     
>>>> avoid the overhead of carrying the entire source route throughout
>>>>       
>> the
>>   
>>> data
>>>     
>>>> path.
>>>>
>>>> The approach itself should be very simple and trivial for everyone
>>>>       
>> to
>>   
>>> follow.
>>>     
>>>> So we can start from here and build on!
>>>>
>>>> Thanks.
>>>>
>>>> -John
>>>>
>>>> ------
>>>> JeongGil Ko (John)
>>>> Ph.D. Student
>>>> Department of Computer Science
>>>> Johns Hopkins University
>>>> http://www.cs.jhu.edu/~jgko
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>       
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>     
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>   
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

From Daniel.Popa@itron.com  Thu Apr  8 06:33:17 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB6B28C103 for ; Thu,  8 Apr 2010 06:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUp8cnwlOt0X for ; Thu,  8 Apr 2010 06:33:06 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id F26573A6A33 for ; Thu,  8 Apr 2010 06:32:52 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD71F.FB5378BC"
Date: Thu, 8 Apr 2010 09:32:48 -0400
Message-ID: 
In-Reply-To: <4BBDC39F.3040601@gridmerge.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
Thread-Index: AcrXEhnLcuTR8T62SmKrgX/AZpTB/wABtSJQ
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <4BBDC39F.3040601@gridmerge.com>
From: "Popa, Daniel" 
To: , 
Subject: Re: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 13:33:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD71F.FB5378BC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Robert, Daniel,=20

=20

I believe that a tagging mechanism can efficiently accommodate our needs
by designing a generic tagging scheme with different scopes for source
routing (e.g., one of them can be source routing using 6lowPAN HC,
another using uncompressed L2 addressing, another can use uncompressed
L3 addressing, and so on ). This helps with link layers that do not
need/use 6lowPAN HC (because they can transport large MTU) but for which
using source address with IPv6 addressing might generate lot of
overhead. =20

=20

OTOH, we can have a generic tagging mechanism for routing with a scope
different from source routing.=20

=20

Concerning the error reporting along the route for the source routing
scheme where the next-hop addresses are specified: We do not need to
carry the full source route all the way to the penultimate node.=20

We can do it easier irrespective of link symmetry/asymmetry:  Even if
each node among the path towards the destination removes its own address
from the packet header, the node where the link (towards next-hop) is
broken still has enough information to send back to the source (i.e.,
root ): The tuple (source_address, final_destination_address,
intermediate_hop_address). This information should be enough for the
source of that message to identify the "broken link".

=20

What do you think ?=20

=20

Cheers,=20

Daniel =20

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: jeudi 8 avril 2010 13:53
To: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

=20

Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot
of overhead for certain underlying link layers, e.g. 802.15.4. I think
it is generally cleaner to do the compression at a layer which may
require it only, e.g. define it in the 6lowpan HC. This is then free to
some extent to specify how the compression is done. Although I doubt
this would go down well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing
to nodes which operate the scheme. This is probably acceptable
practically but doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry
the full source route all the way to at least the penultimate node and
use an index to show the current position in the route for potential
backtrace and error reporting back along the same route (assuming link
symmetry). This is how RH0 works.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:=20

Hi Daniel:
=20
Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.
=20
OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach
=20
So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.
=20
What do you think?
=20
Pascal
=20
=20
 =20

	-----Original Message-----
	From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
	Sent: Thursday, April 08, 2010 11:40 AM
	To: ROLL WG
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and
	SourceRoutingOperations
	=20
	Hi Pascal, John,
	=20
	Since source routing explicitly gives forwarding instruction to
each
	intermediate node, it can make sense to use only (MAC address
based)
	   =20

L2
 =20

	forwarding instead of (IPv6 address based) L3 forwarding.
	=20
	This brings two advantages:
	 - avoid processing each transit packets up to L3.
	 - use MAC addresses that - in ROLL environment - have
inherently
	   =20

shorter
 =20

	length than an IPv6 address.
	=20
	Cheers,
	Daniel
	=20
	=20
	=20
	-----Original Message-----
	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf
	   =20

Of
 =20

	Pascal Thubert (pthubert)
	Sent: jeudi 8 avril 2010 11:15
	To: JeongGil Ko (John); ROLL WG
	Subject: Re: [Roll] Proposal for Source Routing Header Format
and
	SourceRoutingOperations
	=20
	Hi John:
	=20
	IPv6 already has a number of routing headers, in particular RH0,
	   =20

though it is
 =20

	being deprecated for general use in the Internet.
	And there are reasons why the fields in RH0/1 are there and we
need to
	make sure we lose none of that. In particular a RH is
recoverable, and
	   =20

it is
 =20

	easy to spot the consumed entries.
	=20
	On top of this our new problems are:
	- make sure the RH stays within the RPL network (since it is
used
	   =20

downwards
 =20

	that should be doable)
	- control the size (that probably means compress)
	=20
	Cheers,
	=20
	Pascal
	=20
	=20
	   =20

		-----Original Message-----
		From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf
		     =20

	Of
	   =20

		JeongGil Ko (John)
		Sent: Wednesday, April 07, 2010 10:05 PM
		To: ROLL WG
		Subject: [Roll] Proposal for Source Routing Header
Format and Source
		RoutingOperations
		=20
		Hi!
		=20
		Great to see all this discussions on downwards route
establishment!
		     =20

To
 =20

	add
	   =20

		one more to the conversations here is a proposal for
source routing
		     =20

	headers.
	   =20

		In non-storing mode (where only the root has individual
path
		     =20

	information)
	   =20

		the root will be attaching a source routing header to
the data
		     =20

packet
 =20

	that a
	   =20

		source node wants to send to a specific destination. We
can always
		     =20

	make the
	   =20

		header super fancy but in my opinion I think we only
need two fields
		     =20

	in this
	   =20

		header and here it is! Feel free to break the stuff and
mangle with
		     =20

it
 =20

	so that it
	   =20

		looks great in the specs later on. FYI, this is the
format that I am
		     =20

	using in my
	   =20

		implementations so it does work :)
		=20
		1. Source Routing Header Format
		=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		|   NEntry (8 bits)   |
		     =20

	|
	   =20

		+-+-+-+-+-+-+-+-+
		     =20

	+
	   =20

		|                       Source Route Entry (128*NEntry
bits)
		     =20

	|
	   =20

		+
		     =20

	+
	   =20

		|
		     =20

	|
	   =20

		=20
		      Figure 1. Proposed Source Routing Header Format;
each line is
		     =20

32
 =20

	bits:)
	   =20

		=20
		- NEntry: Indicates the number of 128 bit addresses that
the source
		     =20

	route
	   =20

		entry field is carrying.
		=20
		- Source Route Entry: List of 128 bit address that
consist the route
		     =20

	to the
	   =20

		destination. Here, the address of the node that is one
hop away from
		     =20

	the
	   =20

		*destination* comes first.
		=20
		2. Source Routing Packet Operations
		=20
		When source routing is initiated at a storing node
(e.g., root of
		     =20

the
 =20

	DODAG),
	   =20

		the header is attached on the data packet for the entire
route
		     =20

(i.e.,
 =20

	from
	   =20

		next hop node to the destination). This header is
positioned in
		     =20

front
 =20

	of the
	   =20

		user payload. When the next hop node receives a packet
that is not
		     =20

	destined
	   =20

		to itself AND the network is NOT provisioned to be in
'storing mode'
		     =20

	then it
	   =20

		checks NEntry to find what the next hop is in the source
route
		     =20

entry.
 =20

	Since
	   =20

		the 'Source Route Entry' is ordered in 'farthest ->
closest' (in
		     =20

terms
 =20

	of hops)
	   =20

		order, a node can figure out what the next hop address
is with only
		     =20

	the
	   =20

		NEntry value (since it already knows how big an ipv6
address is).
		     =20

	After
	   =20

		collecting the next hop node's address, the node erases
this address
		element from the entry and decreases NEntry by one. This
assures
		     =20

that
 =20

	we
	   =20

		avoid the overhead of carrying the entire source route
throughout
		     =20

the
 =20

	data
	   =20

		path.
		=20
		The approach itself should be very simple and trivial
for everyone
		     =20

to
 =20

	follow.
	   =20

		So we can start from here and build on!
		=20
		Thanks.
		=20
		-John
		=20
		------
		JeongGil Ko (John)
		Ph.D. Student
		Department of Computer Science
		Johns Hopkins University
		http://www.cs.jhu.edu/~jgko
		=20
		_______________________________________________
		Roll mailing list
		Roll@ietf.org
		https://www.ietf.org/mailman/listinfo/roll
		     =20

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

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

------_=_NextPart_001_01CAD71F.FB5378BC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi Robert, Daniel, 
    


     
    


    I believe that a tagging mechanism can efficiently =
accommodate our
needs by designing a generic tagging scheme with different scopes for =
source
routing (e.g., one of them can be source routing using 6lowPAN HC, =
another
using uncompressed L2 addressing, another can use uncompressed L3 =
addressing,
and so on ). This helps with link layers that do not need/use 6lowPAN HC =
(because
they can transport large MTU) but for which using source address with =
IPv6
addressing might generate lot of overhead.  
    


     
    


    OTOH, we can have a generic tagging mechanism for routing =
with a
scope different from source routing. 
    


     
    


    Concerning the error reporting along the route for the =
source
routing scheme where the next-hop addresses are specified: We do not =
need to
carry the full source route all the way to the penultimate node. =

    


    We can do it easier irrespective of link =
symmetry/asymmetry:  Even
if each node among the path towards the destination removes its own =
address
from the packet header, the node where the link (towards next-hop) is =
broken still
has enough information to send back to the source (i.e., root ): The =
tuple (source_address,
final_destination_address, intermediate_hop_address). This information =
should
be enough for the source of that message to identify the “broken =
link”.
    


     
    


    What do you think ? 
    


     
    


    Cheers, 
    


    Daniel  
    


     
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
    
Sent: jeudi 8 avril 2010 13:53
    
To: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    Hi Pascal,
    

    
Source routing should of course use the IPv6 addresses which means a lot =
of
overhead for certain underlying link layers, e.g. 802.15.4. I think it =
is
generally cleaner to do the compression at a layer which may require it =
only,
e.g. define it in the 6lowpan HC. This is then free to some extent to =
specify
how the compression is done. Although I doubt this would go down well in =
the
6lowpan WG...
    

    
The tag scheme would work but it specifically scopes the source routing =
to
nodes which operate the scheme. This is probably acceptable practically =
but
doesn't 'smell right' somehow.
    

    
With regard to the original proposal: it is probably necessary to carry =
the
full source route all the way to at least the penultimate node and use =
an index
to show the current position in the route for potential backtrace and =
error
reporting back along the same route (assuming link symmetry). This is =
how RH0
works.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi Daniel:
     
    Routers =
might have multiple interfaces of multiple MAC types. Internet =
0
    even has a MAC-less =
format.
    So the result of you proposal, which looks =
like a great idea in a pure
    802.15.4 world with =
short addresses, becomes a nightmare to define in =
a
    fully generic =
fashion.
     
    OTOH, a =
locally significant opaque tag in which the parent could hide =
a
    short address of the child - if it cares to do it =
that way - looks like
    a way more acceptable =
approach
     
    So it seems to =
me that you can get what you want as long as we can =
make
    the tag big enough for short addresses. When =
the tag is too small to
    contain what the parent =
really needs, then the parent will have to store
    a =
state with the full information in memory, and then place an index =
of
    some sort in the =
tag.
     
    What do you =
think?
     
    Pascal=

     
     
     =
 
    


    -----Original =
Message-----
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    Sent: Thursday, April 08, 2010 11:40 =
AM
    To: ROLL WG
    Cc: Pascal =
Thubert (pthubert); JeongGil Ko (John)
    Subject: RE: =
[Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Hi Pascal, =
John,
     
    Since source =
routing explicitly gives forwarding instruction to =
each
    intermediate node, it can make sense to use =
only (MAC address based)
        =

    


    L2
      
    


    forwarding instead =
of (IPv6 address based) L3 =
forwarding.
     
    This brings =
two advantages:
     - avoid processing each transit =
packets up to L3.
     - use MAC addresses that - in =
ROLL environment - have =
inherently
        =

    


    shorter
      
    


    length =
than an IPv6 =
address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
        =

    


    Of
      
    


    Pascal =
Thubert (pthubert)
    Sent: jeudi 8 avril 2010 =
11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format =
and
    SourceRoutingOperations
     
    Hi =
John:
     
    IPv6 already has =
a number of routing headers, in particular =
RH0,
        =

    


    though it is
      
    


    being =
deprecated for general use in the Internet.
    And =
there are reasons why the fields in RH0/1 are there and we need =
to
    make sure we lose none of that. In particular a =
RH is recoverable, and
        =

    


    it is
      
    


    easy to =
spot the consumed =
entries.
     
    On top of this =
our new problems are:
    - make sure the RH stays =
within the RPL network (since it is =
used
        =

    


    downwards
      
    


    that =
should be doable)
    - control the size (that probably =
means =
compress)
     
    Cheers,
     
    Pascal
     
     
        =

    


    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
          =

    


    Of
        
    


    JeongGil =
Ko (John)
    Sent: Wednesday, April 07, 2010 10:05 =
PM
    To: ROLL WG
    Subject: [Roll] =
Proposal for Source Routing Header Format and =
Source
    RoutingOperations
    &=
nbsp;
    Hi!
     
    Great to see all this discussions on downwards route =
establishment!
          =

    


    


    To
      
    


    add
    <=
pre>    


    one more =
to the conversations here is a proposal for source =
routing
          =

    


    headers.
        
    


    In =
non-storing mode (where only the root has individual =
path
          =

    


    information)
        =

    


    the root =
will be attaching a source routing header to the =
data
          =

    


    


    packet
      
    


    that =
a
        
    


    source =
node wants to send to a specific destination. We can =
always
          =

    


    make the
        
    


    header =
super fancy but in my opinion I think we only need two =
fields
          =

    


    in this
        
    


    header =
and here it is! Feel free to break the stuff and mangle =
with
          =

    


    


    it
      
    


    so that =
it
        
    


    looks =
great in the specs later on. FYI, this is the format that I =
am
          =

    


    using in my
        =

    


    implementations so =
it does work :)
     
    1. =
Source Routing Header =
Format
     
    +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |&n=
bsp;  NEntry (8 bits)   =
|
        =
  
    


    |
        
    


    +-+-+-+-+-+-+-+-+
          =

    


    +
        
    


    |   &n=
bsp;           &nb=
sp;       Source Route Entry (128*NEntry =
bits)
          =

    


    |
        
    


    +
          
    


    +
        
    


    |
          
    


    |
        
    


     
          Figure 1. Proposed Source Routing =
Header Format; each line =
is
          =

    


    


    32
      
    


    bits:)
        
    


     
    - NEntry: Indicates the number of 128 bit addresses that the =
source
          =

    


    route
        
    


    entry =
field is carrying.
     
    - =
Source Route Entry: List of 128 bit address that consist the =
route
          =

    


    to the
        
    


    destination. Here, =
the address of the node that is one hop away =
from
          =

    


    the
        
    


    *destination* comes =
first.
     
    2. Source =
Routing Packet =
Operations
     
    When source =
routing is initiated at a storing node (e.g., root =
of
          =

    


    


    the
      
    


    DODAG),
        
    


    the =
header is attached on the data packet for the entire =
route
          =

    


    


    (i.e.,
      
    


    from
    =

        
    


    next hop =
node to the destination). This header is positioned =
in
          =

    


    


    front
      
    


    of =
the
        
    


    user =
payload. When the next hop node receives a packet that is =
not
          =

    


    destined
        
    


    to =
itself AND the network is NOT provisioned to be in 'storing =
mode'
          =

    


    then it
        
    


    checks =
NEntry to find what the next hop is in the source =
route
          =

    


    


    entry.
      
    


    Since
        
    


    the =
'Source Route Entry' is ordered in 'farthest -> closest' =
(in
          =

    


    


    terms
      
    


    of =
hops)
        
    


    order, a =
node can figure out what the next hop address is with =
only
          =

    


    the
        
    


    NEntry =
value (since it already knows how big an ipv6 address =
is).
          =

    


    After
        
    


    collecting the next =
hop node's address, the node erases this =
address
    element from the entry and decreases NEntry =
by one. This assures
          =

    


    


    that
      
    


    we
        


    avoid =
the overhead of carrying the entire source route =
throughout
          =

    


    


    the
      
    


    data
    =

        
    


    path.
     
    The approach itself should be very =
simple and trivial for =
everyone
          =

    


    


    to
      
    


    follow.
        
    


    So we =
can start from here and build =
on!
     
    Thanks.
     
    -John
    &nbs=
p;
    ------
    JeongGil Ko =
(John)
    Ph.D. =
Student
    Department of Computer =
Science
    Johns Hopkins =
University
    http://www.cs.jhu.edu/~jgko=

     
    ____________________________=
___________________
    Roll mailing =
list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
        &n=
bsp; 
    


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

    


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





------_=_NextPart_001_01CAD71F.FB5378BC--

From d.sturek@att.net  Thu Apr  8 06:35:32 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C471E3A688A for ; Thu,  8 Apr 2010 06:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.485
X-Spam-Level: 
X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bDm3RckQpOI for ; Thu,  8 Apr 2010 06:35:31 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 998B33A6893 for ; Thu,  8 Apr 2010 06:35:30 -0700 (PDT)
Received: (qmail 75527 invoked from network); 8 Apr 2010 13:35:25 -0000
Received: from adsl-69-108-49-215.dsl.sndg02.pacbell.net (d.sturek@69.108.49.215 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 08 Apr 2010 06:35:24 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: Uap8ia8VM1mAB9t7ScKziY_u0LOKmZ0NhlnpCuDkaO1Zoz.GOJ.1FgfgqrHAjsxja0TVTXpr6x1PpcteA8FTI8r9vsGvFIpbCGxqM8LiHl1zTyVvMzeiQYGCIk9_PPhVVmLJghyZzbXDRVKQ99yTYaxzMQ5SUkWNVdGleh3gCO0Wzb9AqDObZPKhZ_rLEF.HdxwdYLFzpAwh1o5UVMCcA809MuxL_BRrRRYMLP.AYQsZzxbzblVeOUzkoycK2Q8yxFZ3FTeLK4UxK5F9sRw63SEpZQOeAngJPzWL2bY23U5TcoILcTY-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: , 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com>
In-Reply-To: <4BBDD602.7040707@jennic.com>
Date: Thu, 8 Apr 2010 06:35:19 -0700
Message-ID: <008801cad720$555a0a50$000e1ef0$@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: AcrXHQflni4d0TGuT2615tUYJ7vTOAAAxEKQ
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 13:35:32 -0000

I can't see why 6LowPAN (and specifically the HC draft) would concern itself
with source routing.

Surely source routing is a concern of ROLL (and not 6LowPAN).

I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Rob,

I agree that the source routing for the data frames should be done as 
part of the 6LowPAN HC.  This already has a stateful IPV6 address 
compression based on contexts.  It should be possible to compress the 
addresses down to two bytes per address if IPv6 addresses are derived 
from the 16 bit short address are being used in the LowPAN.

We don't want to hold up the current HC draft that is going through last 
call but the work could be done as a new RFC / amendment.  Source 
routing compression may need a fix for the problem of HC compression 
extending beyond the first fragment.

Doing the work in the 6LowPAN group means that the compression can 
easily be used for any source routing protocol, not just ROLL.  It could 
be done as a compression for the existing R0 routing header.  Maybe this 
thread needs moving to the 6LowPAN reflector.

Daniel.


Robert Cragie wrote:
> Hi Pascal,
> 
> Source routing should of course use the IPv6 addresses which means a lot 
> of overhead for certain underlying link layers, e.g. 802.15.4. I think 
> it is generally cleaner to do the compression at a layer which may 
> require it only, e.g. define it in the 6lowpan HC. This is then free to 
> some extent to specify how the compression is done. Although I doubt 
> this would go down well in the 6lowpan WG...
> 
> The tag scheme would work but it specifically scopes the source routing 
> to nodes which operate the scheme. This is probably acceptable 
> practically but doesn't 'smell right' somehow.
> 
> With regard to the original proposal: it is probably necessary to carry 
> the full source route all the way to at least the penultimate node and 
> use an index to show the current position in the route for potential 
> backtrace and error reporting back along the same route (assuming link 
> symmetry). This is how RH0 works.
> 
> Robert
> 
> Robert Cragie (Pacific Gas & Electric)
> 
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com 
> 
> 
> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. Internet 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a pure
>> 802.15.4 world with short addresses, becomes a nightmare to define in a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could hide a
>> short address of the child - if it cares to do it that way - looks like
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can make
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to store
>> a state with the full information in memory, and then place an index of
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>   
>>> -----Original Message-----
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>> To: ROLL WG
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi Pascal, John,
>>>
>>> Since source routing explicitly gives forwarding instruction to each
>>> intermediate node, it can make sense to use only (MAC address based)
>>>     
>> L2
>>   
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>> This brings two advantages:
>>>  - avoid processing each transit packets up to L3.
>>>  - use MAC addresses that - in ROLL environment - have inherently
>>>     
>> shorter
>>   
>>> length than an IPv6 address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>>     
>> Of
>>   
>>> Pascal Thubert (pthubert)
>>> Sent: jeudi 8 avril 2010 11:15
>>> To: JeongGil Ko (John); ROLL WG
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi John:
>>>
>>> IPv6 already has a number of routing headers, in particular RH0,
>>>     
>> though it is
>>   
>>> being deprecated for general use in the Internet.
>>> And there are reasons why the fields in RH0/1 are there and we need to
>>> make sure we lose none of that. In particular a RH is recoverable, and
>>>     
>> it is
>>   
>>> easy to spot the consumed entries.
>>>
>>> On top of this our new problems are:
>>> - make sure the RH stays within the RPL network (since it is used
>>>     
>> downwards
>>   
>>> that should be doable)
>>> - control the size (that probably means compress)
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>     
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>>>       
>>> Of
>>>     
>>>> JeongGil Ko (John)
>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>> To: ROLL WG
>>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>>> RoutingOperations
>>>>
>>>> Hi!
>>>>
>>>> Great to see all this discussions on downwards route establishment!
>>>>       
>> To
>>   
>>> add
>>>     
>>>> one more to the conversations here is a proposal for source routing
>>>>       
>>> headers.
>>>     
>>>> In non-storing mode (where only the root has individual path
>>>>       
>>> information)
>>>     
>>>> the root will be attaching a source routing header to the data
>>>>       
>> packet
>>   
>>> that a
>>>     
>>>> source node wants to send to a specific destination. We can always
>>>>       
>>> make the
>>>     
>>>> header super fancy but in my opinion I think we only need two fields
>>>>       
>>> in this
>>>     
>>>> header and here it is! Feel free to break the stuff and mangle with
>>>>       
>> it
>>   
>>> so that it
>>>     
>>>> looks great in the specs later on. FYI, this is the format that I am
>>>>       
>>> using in my
>>>     
>>>> implementations so it does work :)
>>>>
>>>> 1. Source Routing Header Format
>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> |   NEntry (8 bits)   |
>>>>       
>>> |
>>>     
>>>> +-+-+-+-+-+-+-+-+
>>>>       
>>> +
>>>     
>>>> |                       Source Route Entry (128*NEntry bits)
>>>>       
>>> |
>>>     
>>>> +
>>>>       
>>> +
>>>     
>>>> |
>>>>       
>>> |
>>>     
>>>>       Figure 1. Proposed Source Routing Header Format; each line is
>>>>       
>> 32
>>   
>>> bits:)
>>>     
>>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>>>       
>>> route
>>>     
>>>> entry field is carrying.
>>>>
>>>> - Source Route Entry: List of 128 bit address that consist the route
>>>>       
>>> to the
>>>     
>>>> destination. Here, the address of the node that is one hop away from
>>>>       
>>> the
>>>     
>>>> *destination* comes first.
>>>>
>>>> 2. Source Routing Packet Operations
>>>>
>>>> When source routing is initiated at a storing node (e.g., root of
>>>>       
>> the
>>   
>>> DODAG),
>>>     
>>>> the header is attached on the data packet for the entire route
>>>>       
>> (i.e.,
>>   
>>> from
>>>     
>>>> next hop node to the destination). This header is positioned in
>>>>       
>> front
>>   
>>> of the
>>>     
>>>> user payload. When the next hop node receives a packet that is not
>>>>       
>>> destined
>>>     
>>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>>>>       
>>> then it
>>>     
>>>> checks NEntry to find what the next hop is in the source route
>>>>       
>> entry.
>>   
>>> Since
>>>     
>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>>>       
>> terms
>>   
>>> of hops)
>>>     
>>>> order, a node can figure out what the next hop address is with only
>>>>       
>>> the
>>>     
>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>>       
>>> After
>>>     
>>>> collecting the next hop node's address, the node erases this address
>>>> element from the entry and decreases NEntry by one. This assures
>>>>       
>> that
>>   
>>> we
>>>     
>>>> avoid the overhead of carrying the entire source route throughout
>>>>       
>> the
>>   
>>> data
>>>     
>>>> path.
>>>>
>>>> The approach itself should be very simple and trivial for everyone
>>>>       
>> to
>>   
>>> follow.
>>>     
>>>> So we can start from here and build on!
>>>>
>>>> Thanks.
>>>>
>>>> -John
>>>>
>>>> ------
>>>> JeongGil Ko (John)
>>>> Ph.D. Student
>>>> Department of Computer Science
>>>> Johns Hopkins University
>>>> http://www.cs.jhu.edu/~jgko
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>       
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>     
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>   
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


From d.sturek@att.net  Thu Apr  8 06:40:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0CB3A67EF for ; Thu,  8 Apr 2010 06:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.165
X-Spam-Level: 
X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZlss05OdOIx for ; Thu,  8 Apr 2010 06:40:31 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id CF6393A63EB for ; Thu,  8 Apr 2010 06:40:30 -0700 (PDT)
Received: (qmail 77846 invoked from network); 8 Apr 2010 13:40:28 -0000
Received: from adsl-69-108-49-215.dsl.sndg02.pacbell.net (d.sturek@69.108.49.215 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 08 Apr 2010 06:40:27 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: r1OTTpAVM1kpPP7aiaW.0ooiZhziAO0gHB0icjYDcVqxUrsAQz4TUL.Vr8mng0.7T66KmYFomHNy89RaY5LjA9qOMtGkLtc1R_BPpq5WauQUGGMIzhM3a_i55cI19rnBYlD_zROVjgpoYVpKhrHLuLhkE86mrb6WTPbvslRCZqUjS5HRiOn3fIJBAgv76IZPfmNH3XbZj.UQnRfIb3Gam8bqmCKI3F1C1E3BmO7_bSzXhE_1G0wECNFLORBDz6KJIEpP0Y_Wi27NNfBqmGt1SyGgaa69UnCQopH4yiU06OcQrrgpvAw-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Popa, Daniel'" , "'ROLL WG'" 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com> 
In-Reply-To: 
Date: Thu, 8 Apr 2010 06:40:22 -0700
Message-ID: <008901cad721$09cb9530$1d62bf90$@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: AcrWjbRWtbbeEP0rQX2EjTMIG5kzGAAbSz7QAACR7MAACN60QA==
Content-Language: en-us
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 13:40:37 -0000

Hi Daniel,

I think the scope of ROLL covers multiple MAC/PHYs.  I don't see how the
proposal below works with multiple MAC/PHYs.

Also, what forwarding are you talking about?  In the MAC/PHYs that I am
familiar with, forwarding is done by a higher layer above the MAC.  

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Popa, Daniel
Sent: Thursday, April 08, 2010 2:40 AM
To: ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based) L2
forwarding instead of (IPv6 address based) L3 forwarding. 

This brings two advantages: 
 - avoid processing each transit packets up to L3. 
 - use MAC addresses that - in ROLL environment - have inherently
shorter length than an IPv6 address. 

Cheers,
Daniel   

 

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

IPv6 already has a number of routing headers, in particular RH0, though
it is being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
it is easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
downwards that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
> 
> Hi!
> 
> Great to see all this discussions on downwards route establishment! To
add
> one more to the conversations here is a proposal for source routing
headers.
> In non-storing mode (where only the root has individual path
information)
> the root will be attaching a source routing header to the data packet
that a
> source node wants to send to a specific destination. We can always
make the
> header super fancy but in my opinion I think we only need two fields
in this
> header and here it is! Feel free to break the stuff and mangle with it
so that it
> looks great in the specs later on. FYI, this is the format that I am
using in my
> implementations so it does work :)
> 
> 1. Source Routing Header Format
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
|
> +-+-+-+-+-+-+-+-+
+
> |                       Source Route Entry (128*NEntry bits)
|
> +
+
> |
|
> 
>       Figure 1. Proposed Source Routing Header Format; each line is 32
bits:)
> 
> - NEntry: Indicates the number of 128 bit addresses that the source
route
> entry field is carrying.
> 
> - Source Route Entry: List of 128 bit address that consist the route
to the
> destination. Here, the address of the node that is one hop away from
the
> *destination* comes first.
> 
> 2. Source Routing Packet Operations
> 
> When source routing is initiated at a storing node (e.g., root of the
DODAG),
> the header is attached on the data packet for the entire route (i.e.,
from
> next hop node to the destination). This header is positioned in front
of the
> user payload. When the next hop node receives a packet that is not
destined
> to itself AND the network is NOT provisioned to be in 'storing mode'
then it
> checks NEntry to find what the next hop is in the source route entry.
Since
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms
of hops)
> order, a node can figure out what the next hop address is with only
the
> NEntry value (since it already knows how big an ipv6 address is).
After
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures that
we
> avoid the overhead of carrying the entire source route throughout the
data
> path.
> 
> The approach itself should be very simple and trivial for everyone to
follow.
> So we can start from here and build on!
> 
> Thanks.
> 
> -John
> 
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


From mdurvy@cisco.com  Thu Apr  8 06:46:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA6528C0E3 for ; Thu,  8 Apr 2010 06:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.669
X-Spam-Level: 
X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taMGR-iACA1Z for ; Thu,  8 Apr 2010 06:46:26 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 30EF23A6A39 for ; Thu,  8 Apr 2010 06:46:26 -0700 (PDT)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: smime.p7s : 4235
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAPZ6vUurR7H+/2dsb2JhbACbMXGgHJklhQkE
X-IronPort-AV: E=Sophos;i="4.52,170,1270425600";  d="p7s'?scan'208";a="218698006"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2010 13:46:22 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38DjhwB011981; Thu, 8 Apr 2010 13:46:22 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 8 Apr 2010 15:45:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 8 Apr 2010 15:45:42 +0200
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0A31_01CAD732.8BE5F2C0"; protocol="application/x-pkcs7-signature"
Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FF1A@XMB-AMS-103.cisco.com>
In-Reply-To: <4BBD9319.3000808@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrW9Vs/5rLUP/hiR4SIR8aloEKUBgAK+jCw
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <4BBD9319.3000808@gmail.com>
From: "Mathilde Durvy (mdurvy)" 
To: "Alexandru Petrescu" , 
X-OriginalArrivalTime: 08 Apr 2010 13:45:44.0353 (UTC) FILETIME=[C93C1110:01CAD721]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 13:46:27 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0A31_01CAD732.8BE5F2C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Alex,

What I meant in that the companies that participated in the interop =
event
will give their own feedback on the ROLL mailing list.=20

Best,
Mathilde

PS: The list of participating companies was included in the presentation =
I
gave during the Anaheim ROLL meeting.=20

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Alexandru Petrescu
Sent: jeudi, 8. avril 2010 10:26
To: roll@ietf.org
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome

Le 08/04/2010 10:16, Mathilde Durvy (mdurvy) a =E9crit :
[...]
> - We understand (at least) some people are still interested in interop =

> event feedback. This will be given on individual, voluntary, basis by=20
> the participants of the interop event.

Who should I ask?

I need to know which implementations were present and who interoperated =
with
whom.

Thanks,

Alex

>
> Best, Mathilde
>
>
> -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com]
> Sent: vendredi, 26. mars 2010 03:55 To: Mathilde Durvy (mdurvy) Cc:
> ROLL WG Subject: IPSO Interop event - Feed-back welcome
>
> Hi,
>
> Just re-enforcing my comments during the ROLL WG meeting ... any
> feed- back from the IPSO interop about any issues that you may have=20
> found would be extremely useful to continue to improve our spec. Feel=20
> free to also share good news.
>
> Thanks.
>
> JP.
>
>
>
> _______________________________________________ Roll mailing list=20
> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll

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

------=_NextPart_000_0A31_01CAD732.8BE5F2C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD
VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl
cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw
MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy
dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp
aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa
c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID
AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh
bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB
AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT
zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b
Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x
jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB
FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa
dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe
MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx
IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH
TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N
VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5
1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN
E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/
BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu
BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU
EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln
bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS
ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz
M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG
49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDQwODEzNDU0MlowIwYJKoZI
hvcNAQkEMRYEFEPRZG8k/oYdIoaaumHsL9TiDKTXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu
IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w
ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAgrlR
yMNP3Yf645BD4dNYP/dxdNUyYPB/6rbKUuV8T/8+C0SMfG8lIINZ3cgKObb2moX0r61sx3DNs4gF
GRKJZKM64Y3YN7c2VYtGN81wJCcB9YRILnH+iP/uQOITd79s55FRFnH1MmH13eOuRUvdeEt7LUFq
SZyT3rttKQ2hhXsAAAAAAAA=

------=_NextPart_000_0A31_01CAD732.8BE5F2C0--

From d.sturek@att.net  Thu Apr  8 07:00:06 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6143A68DE for ; Thu,  8 Apr 2010 07:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.814
X-Spam-Level: 
X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46kqz9nie2DV for ; Thu,  8 Apr 2010 06:59:55 -0700 (PDT)
Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id 13BE83A67F9 for ; Thu,  8 Apr 2010 06:59:55 -0700 (PDT)
Received: (qmail 15327 invoked from network); 8 Apr 2010 13:59:49 -0000
Received: from adsl-69-108-49-215.dsl.sndg02.pacbell.net (d.sturek@69.108.49.215 with login) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 08 Apr 2010 06:59:48 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: 8g_PWmYVM1nZ8ZeHmf8J8gL6F.QpYYAC_oNdu_h1.VdWJvKDsuN2pTDYBI3Q8AnAQUUNd2QtSkboLrai0W9Uid170l2uHk_7OO1zA48GbbKzPzuGoU_Crpj0V_Kk0wYgQXlgQmC4GCGy4CGrLEf3aUE6MQNTCu_aYVFzryRpx0MxtEZirIF.lIHK4BUm4IBzNbfoPwsZtqW029Ytzqti2P0At5IlbHG4kFMTM5y811T09Aw1l1pArVtyAGtO5uQ1mwv1XhTZAuJ5cG_.7FEgIInGHbPwtd.WPONe_3FpcbFJD.ISK57JS.8ciPjC31BmbXX6q8ktlHNHF.7.Vu_xynI-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Popa, Daniel'" , , 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> 
In-Reply-To: 
Date: Thu, 8 Apr 2010 06:59:43 -0700
Message-ID: <00b401cad723$bdc238d0$3946aa70$@sturek@att.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01CAD6E9.116360D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXEhnLcuTR8T62SmKrgX/AZpTB/wABtSJQAAKhlzA=
Content-Language: en-us
Subject: Re: [Roll] Proposal for Source Routing Header	Formatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 14:00:06 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00B5_01CAD6E9.116360D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I cannot imagine the proposal below working in a practical network
deployment (different scopes for source routing).  

 

I think we should address just one scope, at L3, and get that to work.


Don

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Popa, Daniel
Sent: Thursday, April 08, 2010 6:33 AM
To: robert.cragie@gridmerge.com; roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

 

Hi Robert, Daniel, 

 

I believe that a tagging mechanism can efficiently accommodate our needs by
designing a generic tagging scheme with different scopes for source routing
(e.g., one of them can be source routing using 6lowPAN HC, another using
uncompressed L2 addressing, another can use uncompressed L3 addressing, and
so on ). This helps with link layers that do not need/use 6lowPAN HC
(because they can transport large MTU) but for which using source address
with IPv6 addressing might generate lot of overhead.  

 

OTOH, we can have a generic tagging mechanism for routing with a scope
different from source routing. 

 

Concerning the error reporting along the route for the source routing scheme
where the next-hop addresses are specified: We do not need to carry the full
source route all the way to the penultimate node. 

We can do it easier irrespective of link symmetry/asymmetry:  Even if each
node among the path towards the destination removes its own address from the
packet header, the node where the link (towards next-hop) is broken still
has enough information to send back to the source (i.e., root ): The tuple
(source_address, final_destination_address, intermediate_hop_address). This
information should be enough for the source of that message to identify the
"broken link".

 

What do you think ? 

 

Cheers, 

Daniel  

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: jeudi 8 avril 2010 13:53
To: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

 

Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot of
overhead for certain underlying link layers, e.g. 802.15.4. I think it is
generally cleaner to do the compression at a layer which may require it
only, e.g. define it in the 6lowpan HC. This is then free to some extent to
specify how the compression is done. Although I doubt this would go down
well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing to
nodes which operate the scheme. This is probably acceptable practically but
doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry the
full source route all the way to at least the penultimate node and use an
index to show the current position in the route for potential backtrace and
error reporting back along the same route (assuming link symmetry). This is
how RH0 works.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: 

Hi Daniel:
 
Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.
 
OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach
 
So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.
 
What do you think?
 
Pascal
 
 
  

-----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,
 
Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)
    

L2
  

forwarding instead of (IPv6 address based) L3 forwarding.
 
This brings two advantages:
 - avoid processing each transit packets up to L3.
 - use MAC addresses that - in ROLL environment - have inherently
    

shorter
  

length than an IPv6 address.
 
Cheers,
Daniel
 
 
 
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
    

Of
  

Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi John:
 
IPv6 already has a number of routing headers, in particular RH0,
    

though it is
  

being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
    

it is
  

easy to spot the consumed entries.
 
On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
    

downwards
  

that should be doable)
- control the size (that probably means compress)
 
Cheers,
 
Pascal
 
 
    

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
      

Of
    

JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations
 
Hi!
 
Great to see all this discussions on downwards route establishment!
      

To
  

add
    

one more to the conversations here is a proposal for source routing
      

headers.
    

In non-storing mode (where only the root has individual path
      

information)
    

the root will be attaching a source routing header to the data
      

packet
  

that a
    

source node wants to send to a specific destination. We can always
      

make the
    

header super fancy but in my opinion I think we only need two fields
      

in this
    

header and here it is! Feel free to break the stuff and mangle with
      

it
  

so that it
    

looks great in the specs later on. FYI, this is the format that I am
      

using in my
    

implementations so it does work :)
 
1. Source Routing Header Format
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |
      

|
    

+-+-+-+-+-+-+-+-+
      

+
    

|                       Source Route Entry (128*NEntry bits)
      

|
    

+
      

+
    

|
      

|
    

 
      Figure 1. Proposed Source Routing Header Format; each line is
      

32
  

bits:)
    

 
- NEntry: Indicates the number of 128 bit addresses that the source
      

route
    

entry field is carrying.
 
- Source Route Entry: List of 128 bit address that consist the route
      

to the
    

destination. Here, the address of the node that is one hop away from
      

the
    

*destination* comes first.
 
2. Source Routing Packet Operations
 
When source routing is initiated at a storing node (e.g., root of
      

the
  

DODAG),
    

the header is attached on the data packet for the entire route
      

(i.e.,
  

from
    

next hop node to the destination). This header is positioned in
      

front
  

of the
    

user payload. When the next hop node receives a packet that is not
      

destined
    

to itself AND the network is NOT provisioned to be in 'storing mode'
      

then it
    

checks NEntry to find what the next hop is in the source route
      

entry.
  

Since
    

the 'Source Route Entry' is ordered in 'farthest -> closest' (in
      

terms
  

of hops)
    

order, a node can figure out what the next hop address is with only
      

the
    

NEntry value (since it already knows how big an ipv6 address is).
      

After
    

collecting the next hop node's address, the node erases this address
element from the entry and decreases NEntry by one. This assures
      

that
  

we
    

avoid the overhead of carrying the entire source route throughout
      

the
  

data
    

path.
 
The approach itself should be very simple and trivial for everyone
      

to
  

follow.
    

So we can start from here and build on!
 
Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko
 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
      

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

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

------=_NextPart_000_00B5_01CAD6E9.116360D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    I cannot imagine the proposal below working in a =
practical
network deployment (different scopes for source routing).  =

    


     
    


    I think we should address just one scope, at L3, and get =
that to
work.
    



    
Don
    


     
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: Thursday, April 08, 2010 6:33 AM
    
To: robert.cragie@gridmerge.com; roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    Hi Robert, Daniel, 
    


     
    


    I believe that a tagging mechanism can efficiently =
accommodate
our needs by designing a generic tagging scheme with different scopes =
for
source routing (e.g., one of them can be source routing using 6lowPAN =
HC,
another using uncompressed L2 addressing, another can use uncompressed =
L3
addressing, and so on ). This helps with link layers that do not =
need/use
6lowPAN HC (because they can transport large MTU) but for which using =
source
address with IPv6 addressing might generate lot of overhead. =
 
    


     
    


    OTOH, we can have a generic tagging mechanism for routing =
with a
scope different from source routing. 
    


     
    


    Concerning the error reporting along the route for the =
source
routing scheme where the next-hop addresses are specified: We do not =
need to
carry the full source route all the way to the penultimate node. =

    


    We can do it easier irrespective of link =
symmetry/asymmetry:
 Even if each node among the path towards the destination removes =
its own
address from the packet header, the node where the link (towards =
next-hop) is
broken still has enough information to send back to the source (i.e., =
root ):
The tuple (source_address, final_destination_address,
intermediate_hop_address). This information should be enough for the =
source of
that message to identify the “broken =
link”.
    


     
    


    What do you think ? 
    


     
    


    Cheers, 
    


    Daniel  
    


     
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
    
Sent: jeudi 8 avril 2010 13:53
    
To: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    Hi Pascal,
    

    
Source routing should of course use the IPv6 addresses which means a lot =
of
overhead for certain underlying link layers, e.g. 802.15.4. I think it =
is
generally cleaner to do the compression at a layer which may require it =
only,
e.g. define it in the 6lowpan HC. This is then free to some extent to =
specify
how the compression is done. Although I doubt this would go down well in =
the
6lowpan WG...
    

    
The tag scheme would work but it specifically scopes the source routing =
to
nodes which operate the scheme. This is probably acceptable practically =
but
doesn't 'smell right' somehow.
    

    
With regard to the original proposal: it is probably necessary to carry =
the
full source route all the way to at least the penultimate node and use =
an index
to show the current position in the route for potential backtrace and =
error
reporting back along the same route (assuming link symmetry). This is =
how RH0
works.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi Daniel:
     
    Routers =
might have multiple interfaces of multiple MAC types. Internet =
0
    even has a MAC-less =
format.
    So the result of you proposal, which looks =
like a great idea in a pure
    802.15.4 world with =
short addresses, becomes a nightmare to define in =
a
    fully generic =
fashion.
     
    OTOH, a =
locally significant opaque tag in which the parent could hide =
a
    short address of the child - if it cares to do it =
that way - looks like
    a way more acceptable =
approach
     
    So it seems to =
me that you can get what you want as long as we can =
make
    the tag big enough for short addresses. When =
the tag is too small to
    contain what the parent =
really needs, then the parent will have to store
    a =
state with the full information in memory, and then place an index =
of
    some sort in the =
tag.
     
    What do you =
think?
     
    Pascal=

     
     
     =
 
    


    -----Original =
Message-----
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    Sent: Thursday, April 08, 2010 11:40 =
AM
    To: ROLL WG
    Cc: Pascal =
Thubert (pthubert); JeongGil Ko (John)
    Subject: RE: =
[Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Hi Pascal, =
John,
     
    Since source =
routing explicitly gives forwarding instruction to =
each
    intermediate node, it can make sense to use =
only (MAC address based)
        =

    


    L2
      
    


    forwarding instead =
of (IPv6 address based) L3 =
forwarding.
     
    This brings =
two advantages:
     - avoid processing each transit =
packets up to L3.
     - use MAC addresses that - in =
ROLL environment - have =
inherently
        =

    


    shorter
      
    


    length =
than an IPv6 =
address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
        =

    


    Of
      
    


    Pascal =
Thubert (pthubert)
    Sent: jeudi 8 avril 2010 =
11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format =
and
    SourceRoutingOperations
     
    Hi =
John:
     
    IPv6 already has =
a number of routing headers, in particular =
RH0,
        =

    


    though it is
      
    


    being =
deprecated for general use in the Internet.
    And =
there are reasons why the fields in RH0/1 are there and we need =
to
    make sure we lose none of that. In particular a =
RH is recoverable, and
        =

    


    it is
      
    


    easy to =
spot the consumed =
entries.
     
    On top of this =
our new problems are:
    - make sure the RH stays =
within the RPL network (since it is =
used
        =

    


    downwards
      
    


    that =
should be doable)
    - control the size (that probably =
means =
compress)
     
    Cheers,
     
    Pascal
     
     
        =

    


    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
          =

    


    Of
        
    


    JeongGil =
Ko (John)
    Sent: Wednesday, April 07, 2010 10:05 =
PM
    To: ROLL WG
    Subject: [Roll] =
Proposal for Source Routing Header Format and =
Source
    RoutingOperations
    &=
nbsp;
    Hi!
     
    Great to see all this discussions on downwards route =
establishment!
          =

    


    


    To
      
    


    add
    <=
pre>    


    one more =
to the conversations here is a proposal for source =
routing
          =

    


    headers.
        
    


    In =
non-storing mode (where only the root has individual =
path
          =

    


    information)
        =

    


    the root =
will be attaching a source routing header to the =
data
          =

    


    


    packet
      
    


    that =
a
        
    


    source =
node wants to send to a specific destination. We can =
always
          =

    


    make the
        
    


    header =
super fancy but in my opinion I think we only need two =
fields
          =

    


    in this
        
    


    header =
and here it is! Feel free to break the stuff and mangle =
with
          =

    


    


    it
      
    


    so that =
it
        
    


    looks =
great in the specs later on. FYI, this is the format that I =
am
          =

    


    using in my
        =

    


    implementations so =
it does work :)
     
    1. =
Source Routing Header =
Format
     
    +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |&n=
bsp;  NEntry (8 bits)   =
|
        =
  
    


    |
        
    


    +-+-+-+-+-+-+-+-+
          =

    


    +
        
    


    |   &n=
bsp;           &nb=
sp;       Source Route Entry (128*NEntry =
bits)
          =

    


    |
        
    


    +
          
    


    +
        
    


    |
          
    


    |
        
    


     
          Figure 1. Proposed Source Routing =
Header Format; each line =
is
          =

    


    


    32
      
    


    bits:)
        
    


     
    - NEntry: Indicates the number of 128 bit addresses that the =
source
          =

    


    route
        
    


    entry =
field is carrying.
     
    - =
Source Route Entry: List of 128 bit address that consist the =
route
          =

    


    to the
        
    


    destination. Here, =
the address of the node that is one hop away =
from
          =

    


    the
        
    


    *destination* comes =
first.
     
    2. Source =
Routing Packet =
Operations
     
    When source =
routing is initiated at a storing node (e.g., root =
of
          =

    


    


    the
      
    


    DODAG),
        
    


    the =
header is attached on the data packet for the entire =
route
          =

    


    


    (i.e.,
      
    


    from
    =

        
    


    next hop =
node to the destination). This header is positioned =
in
          =

    


    


    front
      
    


    of =
the
        
    


    user =
payload. When the next hop node receives a packet that is =
not
          =

    


    destined
        
    


    to =
itself AND the network is NOT provisioned to be in 'storing =
mode'
          =

    


    then it
        
    


    checks =
NEntry to find what the next hop is in the source =
route
          =

    


    


    entry.
      
    


    Since
        
    


    the =
'Source Route Entry' is ordered in 'farthest -> closest' =
(in
          =

    


    


    terms
      
    


    of =
hops)
        
    


    order, a =
node can figure out what the next hop address is with =
only
          =

    


    the
        
    


    NEntry =
value (since it already knows how big an ipv6 address =
is).
          =

    


    After
        
    


    collecting the next =
hop node's address, the node erases this =
address
    element from the entry and decreases NEntry =
by one. This assures
          =

    


    


    that
      
    


    we
        


    avoid =
the overhead of carrying the entire source route =
throughout
          =

    


    


    the
      
    


    data
    =

        
    


    path.
     
    The approach itself should be very =
simple and trivial for =
everyone
          =

    


    


    to
      
    


    follow.
        
    


    So we =
can start from here and build =
on!
     
    Thanks.
     
    -John
    &nbs=
p;
    ------
    JeongGil Ko =
(John)
    Ph.D. =
Student
    Department of Computer =
Science
    Johns Hopkins =
University
    http://www.cs.jhu.edu/~jgko=

     
    ____________________________=
___________________
    Roll mailing =
list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
        &n=
bsp; 
    


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

    


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





------=_NextPart_000_00B5_01CAD6E9.116360D0--


From daniel.gavelle@jennic.com  Thu Apr  8 07:25:15 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985A93A6837 for ; Thu,  8 Apr 2010 07:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCo9X8an1p-P for ; Thu,  8 Apr 2010 07:25:13 -0700 (PDT)
Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 282AB3A67A7 for ; Thu,  8 Apr 2010 07:25:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 0ABC29BE503 for ; Thu,  8 Apr 2010 15:25:08 +0100 (BST)
Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQqpkXfD1vCw for ; Thu,  8 Apr 2010 15:25:07 +0100 (BST)
Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id E9B3F9BE4FF for ; Thu,  8 Apr 2010 15:25:07 +0100 (BST)
Message-ID: <4BBDE743.7060301@jennic.com>
Date: Thu, 08 Apr 2010 15:25:07 +0100
From: Daniel Gavelle 
Organization: Jennic Ltd.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: 'ROLL WG' 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 <008901cad721$09cb9530$1d62bf90$@sturek@att.net>
In-Reply-To: <008901cad721$09cb9530$1d62bf90$@sturek@att.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Roll] Proposal for Source Routing Header Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: daniel.gavelle@jennic.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 14:25:15 -0000

There is already support for source routing in IPv6, using the routing 
R0 extension header. Roll can use this in the same way as any other IPv6 
routing algorithm.

If MAC/PHYs can't use this because they haven't got the spare bandwidth 
to carry the full 128 bit address in line, they need to use compression. 
If compression is needed, it would also be needed for the source and 
destination addresses as well as the intermediate hops.  6LowPAN header 
compression can be used by any MAC/PHY, even if fragmentation is not 
required.

The R0 routing extension header is stable and has some nice features. 
For example, the addresses swap places within the header and so the IPv6 
check sum does not need to be calculated or the IPv6 packet re-written 
beyond the extension header.  I don't think we need to create a new IPv6 
source routing extension header just for Roll.

Daniel.


Don Sturek wrote:
> Hi Daniel,
> 
> I think the scope of ROLL covers multiple MAC/PHYs.  I don't see how the
> proposal below works with multiple MAC/PHYs.
> 
> Also, what forwarding are you talking about?  In the MAC/PHYs that I am
> familiar with, forwarding is done by a higher layer above the MAC.  
> 
> Don
> 
> 
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Popa, Daniel
> Sent: Thursday, April 08, 2010 2:40 AM
> To: ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
> 
> Hi Pascal, John,
> 
> Since source routing explicitly gives forwarding instruction to each
> intermediate node, it can make sense to use only (MAC address based) L2
> forwarding instead of (IPv6 address based) L3 forwarding. 
> 
> This brings two advantages: 
>  - avoid processing each transit packets up to L3. 
>  - use MAC addresses that - in ROLL environment - have inherently
> shorter length than an IPv6 address. 
> 
> Cheers,
> Daniel   
> 
>  
> 
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: jeudi 8 avril 2010 11:15
> To: JeongGil Ko (John); ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
> 
> Hi John:
> 
> IPv6 already has a number of routing headers, in particular RH0, though
> it is being deprecated for general use in the Internet.
> And there are reasons why the fields in RH0/1 are there and we need to
> make sure we lose none of that. In particular a RH is recoverable, and
> it is easy to spot the consumed entries.
> 
> On top of this our new problems are:
> - make sure the RH stays within the RPL network (since it is used
> downwards that should be doable)
> - control the size (that probably means compress)
> 
> Cheers,
> 
> Pascal
> 
> 
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> JeongGil Ko (John)
>> Sent: Wednesday, April 07, 2010 10:05 PM
>> To: ROLL WG
>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>> RoutingOperations
>>
>> Hi!
>>
>> Great to see all this discussions on downwards route establishment! To
> add
>> one more to the conversations here is a proposal for source routing
> headers.
>> In non-storing mode (where only the root has individual path
> information)
>> the root will be attaching a source routing header to the data packet
> that a
>> source node wants to send to a specific destination. We can always
> make the
>> header super fancy but in my opinion I think we only need two fields
> in this
>> header and here it is! Feel free to break the stuff and mangle with it
> so that it
>> looks great in the specs later on. FYI, this is the format that I am
> using in my
>> implementations so it does work :)
>>
>> 1. Source Routing Header Format
>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   NEntry (8 bits)   |
> |
>> +-+-+-+-+-+-+-+-+
> +
>> |                       Source Route Entry (128*NEntry bits)
> |
>> +
> +
>> |
> |
>>       Figure 1. Proposed Source Routing Header Format; each line is 32
> bits:)
>> - NEntry: Indicates the number of 128 bit addresses that the source
> route
>> entry field is carrying.
>>
>> - Source Route Entry: List of 128 bit address that consist the route
> to the
>> destination. Here, the address of the node that is one hop away from
> the
>> *destination* comes first.
>>
>> 2. Source Routing Packet Operations
>>
>> When source routing is initiated at a storing node (e.g., root of the
> DODAG),
>> the header is attached on the data packet for the entire route (i.e.,
> from
>> next hop node to the destination). This header is positioned in front
> of the
>> user payload. When the next hop node receives a packet that is not
> destined
>> to itself AND the network is NOT provisioned to be in 'storing mode'
> then it
>> checks NEntry to find what the next hop is in the source route entry.
> Since
>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms
> of hops)
>> order, a node can figure out what the next hop address is with only
> the
>> NEntry value (since it already knows how big an ipv6 address is).
> After
>> collecting the next hop node's address, the node erases this address
>> element from the entry and decreases NEntry by one. This assures that
> we
>> avoid the overhead of carrying the entire source route throughout the
> data
>> path.
>>
>> The approach itself should be very simple and trivial for everyone to
> follow.
>> So we can start from here and build on!
>>
>> Thanks.
>>
>> -John
>>
>> ------
>> JeongGil Ko (John)
>> Ph.D. Student
>> Department of Computer Science
>> Johns Hopkins University
>> http://www.cs.jhu.edu/~jgko
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

From robert.cragie@gridmerge.com  Thu Apr  8 07:52:05 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B680A3A69FB for ; Thu,  8 Apr 2010 07:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level: 
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=0.620,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcWh0tqEz8Bn for ; Thu,  8 Apr 2010 07:52:03 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 289DA3A68DE for ; Thu,  8 Apr 2010 07:51:53 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1Nzt58-00032B-NT; Thu, 08 Apr 2010 15:51:47 +0100
Message-ID: <4BBDED7C.40009@gridmerge.com>
Date: Thu, 08 Apr 2010 15:51:40 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: d.sturek@att.net
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net>
In-Reply-To: <008801cad720$555a0a50$000e1ef0$@sturek@att.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000101090209030703050201"
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 14:52:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms000101090209030703050201
Content-Type: multipart/alternative;
 boundary="------------030505010608060303080804"

This is a multi-part message in MIME format.
--------------030505010608060303080804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing,=20
it is concerning itself with efficient header compression, which would=20
include IPv6 extension headers such as RH0=20
. Whatever ends up getting=20
used for source routing needs to be some sort of IPv6 extension header.=20
Source routing for IPv6 would naturally contain IPv6 addresses. The=20
question is whether we want to invent some new extension header=20
specifically for ROLL which uses something other (i.e. smaller) than=20
IPv6 addresses, e.g. the tag scheme mentioned.

I agree, ROLL must accommodate source routing one way or another.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 08/04/2010 2:35 PM, Don Sturek wrote:
> I can't see why 6LowPAN (and specifically the HC draft) would concern i=
tself
> with source routing.
>
> Surely source routing is a concern of ROLL (and not 6LowPAN).
>
> I don't see how ROLL completes its charter or addresses its requirement=
s
> without adding source routing.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=

> Daniel Gavelle
> Sent: Thursday, April 08, 2010 6:12 AM
> To: robert.cragie@gridmerge.com
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Rob,
>
> I agree that the source routing for the data frames should be done as
> part of the 6LowPAN HC.  This already has a stateful IPV6 address
> compression based on contexts.  It should be possible to compress the
> addresses down to two bytes per address if IPv6 addresses are derived
> from the 16 bit short address are being used in the LowPAN.
>
> We don't want to hold up the current HC draft that is going through las=
t
> call but the work could be done as a new RFC / amendment.  Source
> routing compression may need a fix for the problem of HC compression
> extending beyond the first fragment.
>
> Doing the work in the 6LowPAN group means that the compression can
> easily be used for any source routing protocol, not just ROLL.  It coul=
d
> be done as a compression for the existing R0 routing header.  Maybe thi=
s
> thread needs moving to the 6LowPAN reflector.
>
> Daniel.
>
>
> Robert Cragie wrote:
>   =20
>> Hi Pascal,
>>
>> Source routing should of course use the IPv6 addresses which means a l=
ot
>> of overhead for certain underlying link layers, e.g. 802.15.4. I think=

>> it is generally cleaner to do the compression at a layer which may
>> require it only, e.g. define it in the 6lowpan HC. This is then free t=
o
>> some extent to specify how the compression is done. Although I doubt
>> this would go down well in the 6lowpan WG...
>>
>> The tag scheme would work but it specifically scopes the source routin=
g
>> to nodes which operate the scheme. This is probably acceptable
>> practically but doesn't 'smell right' somehow.
>>
>> With regard to the original proposal: it is probably necessary to carr=
y
>> the full source route all the way to at least the penultimate node and=

>> use an index to show the current position in the route for potential
>> backtrace and error reporting back along the same route (assuming link=

>> symmetry). This is how RH0 works.
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas&  Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>>     =20
>>> Hi Daniel:
>>>
>>> Routers might have multiple interfaces of multiple MAC types. Interne=
t 0
>>> even has a MAC-less format.
>>> So the result of you proposal, which looks like a great idea in a pur=
e
>>> 802.15.4 world with short addresses, becomes a nightmare to define in=
 a
>>> fully generic fashion.
>>>
>>> OTOH, a locally significant opaque tag in which the parent could hide=
 a
>>> short address of the child - if it cares to do it that way - looks li=
ke
>>> a way more acceptable approach
>>>
>>> So it seems to me that you can get what you want as long as we can ma=
ke
>>> the tag big enough for short addresses. When the tag is too small to
>>> contain what the parent really needs, then the parent will have to st=
ore
>>> a state with the full information in memory, and then place an index =
of
>>> some sort in the tag.
>>>
>>> What do you think?
>>>
>>> Pascal
>>>
>>>
>>>
>>>       =20
>>>> -----Original Message-----
>>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>>> Sent: Thursday, April 08, 2010 11:40 AM
>>>> To: ROLL WG
>>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi Pascal, John,
>>>>
>>>> Since source routing explicitly gives forwarding instruction to each=

>>>> intermediate node, it can make sense to use only (MAC address based)=

>>>>
>>>>         =20
>>> L2
>>>
>>>       =20
>>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>>
>>>> This brings two advantages:
>>>>   - avoid processing each transit packets up to L3.
>>>>   - use MAC addresses that - in ROLL environment - have inherently
>>>>
>>>>         =20
>>> shorter
>>>
>>>       =20
>>>> length than an IPv6 address.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=

>>>>
>>>>         =20
>>> Of
>>>
>>>       =20
>>>> Pascal Thubert (pthubert)
>>>> Sent: jeudi 8 avril 2010 11:15
>>>> To: JeongGil Ko (John); ROLL WG
>>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi John:
>>>>
>>>> IPv6 already has a number of routing headers, in particular RH0,
>>>>
>>>>         =20
>>> though it is
>>>
>>>       =20
>>>> being deprecated for general use in the Internet.
>>>> And there are reasons why the fields in RH0/1 are there and we need =
to
>>>> make sure we lose none of that. In particular a RH is recoverable, a=
nd
>>>>
>>>>         =20
>>> it is
>>>
>>>       =20
>>>> easy to spot the consumed entries.
>>>>
>>>> On top of this our new problems are:
>>>> - make sure the RH stays within the RPL network (since it is used
>>>>
>>>>         =20
>>> downwards
>>>
>>>       =20
>>>> that should be doable)
>>>> - control the size (that probably means compress)
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>
>>>>
>>>>         =20
>>>>> -----Original Message-----
>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behal=
f
>>>>>
>>>>>           =20
>>>> Of
>>>>
>>>>         =20
>>>>> JeongGil Ko (John)
>>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>>> To: ROLL WG
>>>>> Subject: [Roll] Proposal for Source Routing Header Format and Sourc=
e
>>>>> RoutingOperations
>>>>>
>>>>> Hi!
>>>>>
>>>>> Great to see all this discussions on downwards route establishment!=

>>>>>
>>>>>           =20
>>> To
>>>
>>>       =20
>>>> add
>>>>
>>>>         =20
>>>>> one more to the conversations here is a proposal for source routing=

>>>>>
>>>>>           =20
>>>> headers.
>>>>
>>>>         =20
>>>>> In non-storing mode (where only the root has individual path
>>>>>
>>>>>           =20
>>>> information)
>>>>
>>>>         =20
>>>>> the root will be attaching a source routing header to the data
>>>>>
>>>>>           =20
>>> packet
>>>
>>>       =20
>>>> that a
>>>>
>>>>         =20
>>>>> source node wants to send to a specific destination. We can always
>>>>>
>>>>>           =20
>>>> make the
>>>>
>>>>         =20
>>>>> header super fancy but in my opinion I think we only need two field=
s
>>>>>
>>>>>           =20
>>>> in this
>>>>
>>>>         =20
>>>>> header and here it is! Feel free to break the stuff and mangle with=

>>>>>
>>>>>           =20
>>> it
>>>
>>>       =20
>>>> so that it
>>>>
>>>>         =20
>>>>> looks great in the specs later on. FYI, this is the format that I a=
m
>>>>>
>>>>>           =20
>>>> using in my
>>>>
>>>>         =20
>>>>> implementations so it does work :)
>>>>>
>>>>> 1. Source Routing Header Format
>>>>>
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> |   NEntry (8 bits)   |
>>>>>
>>>>>           =20
>>>> |
>>>>
>>>>         =20
>>>>> +-+-+-+-+-+-+-+-+
>>>>>
>>>>>           =20
>>>> +
>>>>
>>>>         =20
>>>>> |                       Source Route Entry (128*NEntry bits)
>>>>>
>>>>>           =20
>>>> |
>>>>
>>>>         =20
>>>>> +
>>>>>
>>>>>           =20
>>>> +
>>>>
>>>>         =20
>>>>> |
>>>>>
>>>>>           =20
>>>> |
>>>>
>>>>         =20
>>>>>        Figure 1. Proposed Source Routing Header Format; each line i=
s
>>>>>
>>>>>           =20
>>> 32
>>>
>>>       =20
>>>> bits:)
>>>>
>>>>         =20
>>>>> - NEntry: Indicates the number of 128 bit addresses that the source=

>>>>>
>>>>>           =20
>>>> route
>>>>
>>>>         =20
>>>>> entry field is carrying.
>>>>>
>>>>> - Source Route Entry: List of 128 bit address that consist the rout=
e
>>>>>
>>>>>           =20
>>>> to the
>>>>
>>>>         =20
>>>>> destination. Here, the address of the node that is one hop away fro=
m
>>>>>
>>>>>           =20
>>>> the
>>>>
>>>>         =20
>>>>> *destination* comes first.
>>>>>
>>>>> 2. Source Routing Packet Operations
>>>>>
>>>>> When source routing is initiated at a storing node (e.g., root of
>>>>>
>>>>>           =20
>>> the
>>>
>>>       =20
>>>> DODAG),
>>>>
>>>>         =20
>>>>> the header is attached on the data packet for the entire route
>>>>>
>>>>>           =20
>>> (i.e.,
>>>
>>>       =20
>>>> from
>>>>
>>>>         =20
>>>>> next hop node to the destination). This header is positioned in
>>>>>
>>>>>           =20
>>> front
>>>
>>>       =20
>>>> of the
>>>>
>>>>         =20
>>>>> user payload. When the next hop node receives a packet that is not
>>>>>
>>>>>           =20
>>>> destined
>>>>
>>>>         =20
>>>>> to itself AND the network is NOT provisioned to be in 'storing mode=
'
>>>>>
>>>>>           =20
>>>> then it
>>>>
>>>>         =20
>>>>> checks NEntry to find what the next hop is in the source route
>>>>>
>>>>>           =20
>>> entry.
>>>
>>>       =20
>>>> Since
>>>>
>>>>         =20
>>>>> the 'Source Route Entry' is ordered in 'farthest ->  closest' (in
>>>>>
>>>>>           =20
>>> terms
>>>
>>>       =20
>>>> of hops)
>>>>
>>>>         =20
>>>>> order, a node can figure out what the next hop address is with only=

>>>>>
>>>>>           =20
>>>> the
>>>>
>>>>         =20
>>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>>>
>>>>>           =20
>>>> After
>>>>
>>>>         =20
>>>>> collecting the next hop node's address, the node erases this addres=
s
>>>>> element from the entry and decreases NEntry by one. This assures
>>>>>
>>>>>           =20
>>> that
>>>
>>>       =20
>>>> we
>>>>
>>>>         =20
>>>>> avoid the overhead of carrying the entire source route throughout
>>>>>
>>>>>           =20
>>> the
>>>
>>>       =20
>>>> data
>>>>
>>>>         =20
>>>>> path.
>>>>>
>>>>> The approach itself should be very simple and trivial for everyone
>>>>>
>>>>>           =20
>>> to
>>>
>>>       =20
>>>> follow.
>>>>
>>>>         =20
>>>>> So we can start from here and build on!
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -John
>>>>>
>>>>> ------
>>>>> JeongGil Ko (John)
>>>>> Ph.D. Student
>>>>> Department of Computer Science
>>>>> Johns Hopkins University
>>>>> http://www.cs.jhu.edu/~jgko
>>>>>
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>
>>>>>           =20
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>
>>>>         =20
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>>       =20
>> ----------------------------------------------------------------------=
--
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>     =20
>   =20

--------------030505010608060303080804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  
  


Hi Don,
    

    
It's not so much that 6lowpan is concerning itself with source routing,
it is concerning itself with efficient header compression, which would
include IPv6 extension headers such as RH0. Whatever
ends up getting used for source routing needs to be some sort of IPv6
extension header. Source routing for IPv6 would naturally contain IPv6
addresses. The question is whether we want to invent some new extension
header specifically for ROLL which uses something other (i.e. smaller)
than IPv6 addresses, e.g. the tag scheme mentioned.
    

    
I agree, ROLL must accommodate source routing one way or another.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 08/04/2010 2:35 PM, Don Sturek wrote:

    
  
    I can't see why 6LowPAN (and specifically the HC draft) =
would concern itself
with source routing.

Surely source routing is a concern of ROLL (and not 6LowPAN).

I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: robert.cragie@gridmerge.com
Cc: r=
oll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Rob,

I agree that the source routing for the data frames should be done as=20
part of the 6LowPAN HC.  This already has a stateful IPV6 address=20
compression based on contexts.  It should be possible to compress the=20
addresses down to two bytes per address if IPv6 addresses are derived=20
from the 16 bit short address are being used in the LowPAN.

We don't want to hold up the current HC draft that is going through last =

call but the work could be done as a new RFC / amendment.  Source=20
routing compression may need a fix for the problem of HC compression=20
extending beyond the first fragment.

Doing the work in the 6LowPAN group means that the compression can=20
easily be used for any source routing protocol, not just ROLL.  It could =

be done as a compression for the existing R0 routing header.  Maybe this =

thread needs moving to the 6LowPAN reflector.

Daniel.


Robert Cragie wrote:
  
    
  
    
    
    Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot =

of overhead for certain underlying link layers, e.g. 802.15.4. I think=20
it is generally cleaner to do the compression at a layer which may=20
require it only, e.g. define it in the 6lowpan HC. This is then free to=20
some extent to specify how the compression is done. Although I doubt=20
this would go down well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing=20
to nodes which operate the scheme. This is probably acceptable=20
practically but doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry=20
the full source route all the way to at least the penultimate node and=20
use an index to show the current position in the route for potential=20
backtrace and error reporting back along the same route (assuming link=20
symmetry). This is how RH0 works.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http=
://www.gridmerge.com <http://www.gridmerge.com/>


On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
    
    
    
    
      
    Hi Daniel:

Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.

OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach

So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.

What do you think?

Pascal


 =20
      
    
      
    
        
    -----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)
   =20
        
    
      
    
      
    L2
 =20
      
    
      
    
        
    forwarding instead of (IPv6 address based) L3 forw=
arding.

This brings two advantages:
 - avoid processing each transit packets up to L3.
 - use MAC addresses that - in ROLL environment - have inherently
   =20
        
    
      
    
      
    shorter
 =20
      
    
      
    
        
    length than an IPv6 address.

Cheers,
Daniel



-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
   =20
        
    
      
    
      
    Of
 =20
      
    
      
    
        
    Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

IPv6 already has a number of routing headers, in particular RH0,
   =20
        
    
      
    
      
    though it is
 =20
      
    
      
    
        
    being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
   =20
        
    
      
    
      
    it is
 =20
      
    
      
    
        
    easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
   =20
        
    
      
    
      
    downwards
 =20
      
    
      
    
        
    that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal


   =20
        
    
        
    
          
    -----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
     =20
          
    
        
    
        
    Of
   =20
        
    
        
    
          
    JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

Great to see all this discussions on downwards route establishment!
     =20
          
    
        
    
      
    
      
    To
 =20
      
    
      
    
        
    add
   =20
        
    
        
    
          
    one more to the conversations here is a proposal=
 for source routing
     =20
          
    
        
    
        
    headers.
   =20
        
    
        
    
          
    In non-storing mode (where only the root has ind=
ividual path
     =20
          
    
        
    
        
    information)
   =20
        
    
        
    
          
    the root will be attaching a source routing head=
er to the data
     =20
          
    
        
    
      
    
      
    packet
 =20
      
    
      
    
        
    that a
   =20
        
    
        
    
          
    source node wants to send to a specific destinat=
ion. We can always
     =20
          
    
        
    
        
    make the
   =20
        
    
        
    
          
    header super fancy but in my opinion I think we =
only need two fields
     =20
          
    
        
    
        
    in this
   =20
        
    
        
    
          
    header and here it is! Feel free to break the st=
uff and mangle with
     =20
          
    
        
    
      
    
      
    it
 =20
      
    
      
    
        
    so that it
   =20
        
    
        
    
          
    looks great in the specs later on. FYI, this is =
the format that I am
     =20
          
    
        
    
        
    using in my
   =20
        
    
        
    
          
    implementations so it does work :)

1. Source Routing Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |
     =20
          
    
        
    
        
    |
   =20
        
    
        
    
          
    +-+-+-+-+-+-+-+-+
     =20
          
    
        
    
        
    +
   =20
        
    
        
    
          
    |                       Source Route Entry (128*=
NEntry bits)
     =20
          
    
        
    
        
    |
   =20
        
    
        
    
          
    +
     =20
          
    
        
    
        
    +
   =20
        
    
        
    
          
    |
     =20
          
    
        
    
        
    |
   =20
        
    
        
    
          
          Figure 1. Proposed Source Routing Header F=
ormat; each line is
     =20
          
    
        
    
      
    
      
    32
 =20
      
    
      
    
        
    bits:)
   =20
        
    
        
    
          
    - NEntry: Indicates the number of 128 bit addres=
ses that the source
     =20
          
    
        
    
        
    route
   =20
        
    
        
    
          
    entry field is carrying.

- Source Route Entry: List of 128 bit address that consist the route
     =20
          
    
        
    
        
    to the
   =20
        
    
        
    
          
    destination. Here, the address of the node that =
is one hop away from
     =20
          
    
        
    
        
    the
   =20
        
    
        
    
          
    *destination* comes first.

2. Source Routing Packet Operations

When source routing is initiated at a storing node (e.g., root of
     =20
          
    
        
    
      
    
      
    the
 =20
      
    
      
    
        
    DODAG),
   =20
        
    
        
    
          
    the header is attached on the data packet for th=
e entire route
     =20
          
    
        
    
      
    
      
    (i.e.,
 =20
      
    
      
    
        
    from
   =20
        
    
        
    
          
    next hop node to the destination). This header i=
s positioned in
     =20
          
    
        
    
      
    
      
    front
 =20
      
    
      
    
        
    of the
   =20
        
    
        
    
          
    user payload. When the next hop node receives a =
packet that is not
     =20
          
    
        
    
        
    destined
   =20
        
    
        
    
          
    to itself AND the network is NOT provisioned to =
be in 'storing mode'
     =20
          
    
        
    
        
    then it
   =20
        
    
        
    
          
    checks NEntry to find what the next hop is in th=
e source route
     =20
          
    
        
    
      
    
      
    entry.
 =20
      
    
      
    
        
    Since
   =20
        
    
        
    
          
    the 'Source Route Entry' is ordered in 'farthest=
 -> closest' (in
     =20
          
    
        
    
      
    
      
    terms
 =20
      
    
      
    
        
    of hops)
   =20
        
    
        
    
          
    order, a node can figure out what the next hop a=
ddress is with only
     =20
          
    
        
    
        
    the
   =20
        
    
        
    
          
    NEntry value (since it already knows how big an =
ipv6 address is).
     =20
          
    
        
    
        
    After
   =20
        
    
        
    
          
    collecting the next hop node's address, the node=
 erases this address
element from the entry and decreases NEntry by one. This assures
     =20
          
    
        
    
      
    
      
    that
 =20
      
    
      
    
        
    we
   =20
        
    
        
    
          
    avoid the overhead of carrying the entire source=
 route throughout
     =20
          
    
        
    
      
    
      
    the
 =20
      
    
      
    
        
    data
   =20
        
    
        
    
          
    path.

The approach itself should be very simple and trivial for everyone
     =20
          
    
        
    
      
    
      
    to
 =20
      
    
      
    
        
    follow.
   =20
        
    
        
    
          
    So we can start from here and build on!

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
h=
ttp://www.cs.jhu.edu/~jgko

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

 =20
      
    
    
    
    
    ------------------------------------------------------------------------

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

    



--------------030505010608060303080804--

--------------ms000101090209030703050201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgxNDUxNDBaMCMGCSqGSIb3DQEJBDEWBBTVqK3pB5WwLrkkWe4cH8j44jo8SjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBADZmEJJFiO1d7+Wi4c00JViIrExWJ/l2uUdVKntcSYCZAHynru2S5RmwNH7VqKBoFMXC
eljZfhAGhaFD7klzT/gaSqrAr9Lt5Tjz/ItZp5qm40bkyHiYABEiCPYt0fi0QfKDxSCWpXAe
nySoeB0+c690ToodiZOLHTW06H/P7jGp0KhAHi2AjqasCksgD+xoCfwVNHFyslI1AQiDB+jQ
hCUTq3B63aBTT2oW6YYDJjaiPQlAaz1+1acZIby3DmIuIQFycZGZgw3R7bviHoql/EiBSMLc
0MPbzKj6rnSOZPEL5lLMfEH/GniECUhbRrDfAl6pcRql4fgaZJIr+sBBRoMAAAAAAAA=
--------------ms000101090209030703050201--

From jhui@archrock.com  Thu Apr  8 07:58:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099CD3A67B4 for ; Thu,  8 Apr 2010 07:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eEkOKZ4Rkt3 for ; Thu,  8 Apr 2010 07:58:05 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C3C713A67A6 for ; Thu,  8 Apr 2010 07:58:05 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 92656AF98D; Thu,  8 Apr 2010 07:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEHbnwS9MtlD; Thu,  8 Apr 2010 07:57:58 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id B4816AF838; Thu,  8 Apr 2010 07:57:58 -0700 (PDT)
Message-Id: <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
From: Jonathan Hui 
To: Pascal Thubert (pthubert) 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 8 Apr 2010 07:57:57 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>  <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG , "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 14:58:07 -0000

To make the source route header compact, I favor the tag/label  
approach over some other compaction mechanism that operates directly  
on a list of IPv6 addresses.  Tags/labels can be made general enough  
such that they can be derived in different ways.  Because the tags/ 
labels have scope local to each node, the mechanism is pretty general  
already.  For those that are already managing unique 802.15.4 short  
addresses across a network, I can see that it is attractive to utilize  
the short address directly and reduce state on devices.  In other  
cases, it may be best for the node to dynamically assign tags/labels  
for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more  
flexible than an approach to compacting a list of IPv6 addresses.  And  
note that the idea of using tags/labels is nothing new.  Of course we  
will adapt the basic mechanism a bit (label distribution, headers  
formats, etc), but the core ideas have been deployed in traditional IP  
networks for quite some time.

I reiterated a lot of what was already stated before by others, but  
that is what I think.

--
Jonathan Hui

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:

> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types.  
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define  
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could  
> hide a
> short address of the child - if it cares to do it that way - looks  
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can  
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to  
> store
> a state with the full information in memory, and then place an index  
> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
> L2
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
> shorter
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
> though it is
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need  
>> to
>> make sure we lose none of that. In particular a RH is recoverable,  
>> and
> it is
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
> downwards
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>> JeongGil Ko (John)
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>> To: ROLL WG
>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>> RoutingOperations
>>>
>>> Hi!
>>>
>>> Great to see all this discussions on downwards route establishment!
> To
>> add
>>> one more to the conversations here is a proposal for source routing
>> headers.
>>> In non-storing mode (where only the root has individual path
>> information)
>>> the root will be attaching a source routing header to the data
> packet
>> that a
>>> source node wants to send to a specific destination. We can always
>> make the
>>> header super fancy but in my opinion I think we only need two fields
>> in this
>>> header and here it is! Feel free to break the stuff and mangle with
> it
>> so that it
>>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>> implementations so it does work :)
>>>
>>> 1. Source Routing Header Format
>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |   NEntry (8 bits)   |
>> |
>>> +-+-+-+-+-+-+-+-+
>> +
>>> |                       Source Route Entry (128*NEntry bits)
>> |
>>> +
>> +
>>> |
>> |
>>>
>>>      Figure 1. Proposed Source Routing Header Format; each line is
> 32
>> bits:)
>>>
>>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>> entry field is carrying.
>>>
>>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>> destination. Here, the address of the node that is one hop away from
>> the
>>> *destination* comes first.
>>>
>>> 2. Source Routing Packet Operations
>>>
>>> When source routing is initiated at a storing node (e.g., root of
> the
>> DODAG),
>>> the header is attached on the data packet for the entire route
> (i.e.,
>> from
>>> next hop node to the destination). This header is positioned in
> front
>> of the
>>> user payload. When the next hop node receives a packet that is not
>> destined
>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>> checks NEntry to find what the next hop is in the source route
> entry.
>> Since
>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> terms
>> of hops)
>>> order, a node can figure out what the next hop address is with only
>> the
>>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>> collecting the next hop node's address, the node erases this address
>>> element from the entry and decreases NEntry by one. This assures
> that
>> we
>>> avoid the overhead of carrying the entire source route throughout
> the
>> data
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
> to
>> follow.
>>> So we can start from here and build on!
>>>
>>> Thanks.
>>>
>>> -John
>>>
>>> ------
>>> JeongGil Ko (John)
>>> Ph.D. Student
>>> Department of Computer Science
>>> Johns Hopkins University
>>> http://www.cs.jhu.edu/~jgko
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From d.sturek@att.net  Thu Apr  8 07:59:34 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527D53A67B4 for ; Thu,  8 Apr 2010 07:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.148
X-Spam-Level: 
X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vfZ4cPz7WpY for ; Thu,  8 Apr 2010 07:59:32 -0700 (PDT)
Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 157943A67A6 for ; Thu,  8 Apr 2010 07:59:32 -0700 (PDT)
Received: (qmail 90492 invoked from network); 8 Apr 2010 14:59:26 -0000
Received: from Studio (d.sturek@69.108.49.215 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 08 Apr 2010 07:59:25 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: pKoFdLkVM1mubBDCHPU5DBhGUFb_dNUpDhRstrw6jXvRpvVI1gN_xdW370jGdesYCHyoEjaUJ6dAySWfB1u1OV2OsBLfo_yc8PDLzyhQRGXAZMIsB.8rGNmnLmxNeqPC_7eza0wNJoK2fxWB9ESoDg9B42veUxAWM3blBcF8GAR3rSO2b3nk.i3Rp6HWDneAqaVsudeuMtJVNc.g2tf3RJF.SeTJ_tDyQDlFlsE1WOxiS.SoGvoFPsB0bY6OzNtvtkOa_vOkT54BQQMu4TfsXSU-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net> <4BBDED7C.40009@gridmerge.com>
In-Reply-To: <4BBDED7C.40009@gridmerge.com>
Date: Thu, 8 Apr 2010 07:59:24 -0700
Message-ID: <011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01CAD6F1.682E07F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXKw+sJlGj62/PRTGySm9pTNo/EQAALyhg
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 14:59:34 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0120_01CAD6F1.682E07F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I think the issue is this:

1)       ROLL cannot meet its charter without source routing

2)       Claiming the feature is now to be addressed in 6LowPAN seems a bit
wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  How are
those addressed?

 

Don

 

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] 
Sent: Thursday, April 08, 2010 7:52 AM
To: d.sturek@att.net
Cc: daniel.gavelle@jennic.com; roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

 

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing, it
is concerning itself with efficient header compression, which would include
IPv6 extension headers such as RH0
 . Whatever ends up getting used
for source routing needs to be some sort of IPv6 extension header. Source
routing for IPv6 would naturally contain IPv6 addresses. The question is
whether we want to invent some new extension header specifically for ROLL
which uses something other (i.e. smaller) than IPv6 addresses, e.g. the tag
scheme mentioned.

I agree, ROLL must accommodate source routing one way or another.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 08/04/2010 2:35 PM, Don Sturek wrote: 

I can't see why 6LowPAN (and specifically the HC draft) would concern itself
with source routing.
 
Surely source routing is a concern of ROLL (and not 6LowPAN).
 
I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.
 
Don
 
 
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Rob,
 
I agree that the source routing for the data frames should be done as 
part of the 6LowPAN HC.  This already has a stateful IPV6 address 
compression based on contexts.  It should be possible to compress the 
addresses down to two bytes per address if IPv6 addresses are derived 
from the 16 bit short address are being used in the LowPAN.
 
We don't want to hold up the current HC draft that is going through last 
call but the work could be done as a new RFC / amendment.  Source 
routing compression may need a fix for the problem of HC compression 
extending beyond the first fragment.
 
Doing the work in the 6LowPAN group means that the compression can 
easily be used for any source routing protocol, not just ROLL.  It could 
be done as a compression for the existing R0 routing header.  Maybe this 
thread needs moving to the 6LowPAN reflector.
 
Daniel.
 
 
Robert Cragie wrote:
  

Hi Pascal,
 
Source routing should of course use the IPv6 addresses which means a lot 
of overhead for certain underlying link layers, e.g. 802.15.4. I think 
it is generally cleaner to do the compression at a layer which may 
require it only, e.g. define it in the 6lowpan HC. This is then free to 
some extent to specify how the compression is done. Although I doubt 
this would go down well in the 6lowpan WG...
 
The tag scheme would work but it specifically scopes the source routing 
to nodes which operate the scheme. This is probably acceptable 
practically but doesn't 'smell right' somehow.
 
With regard to the original proposal: it is probably necessary to carry 
the full source route all the way to at least the penultimate node and 
use an index to show the current position in the route for potential 
backtrace and error reporting back along the same route (assuming link 
symmetry). This is how RH0 works.
 
Robert
 
Robert Cragie (Pacific Gas & Electric)
 
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  

 
 
On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
    

Hi Daniel:
 
Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.
 
OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach
 
So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.
 
What do you think?
 
Pascal
 
 
  
      

-----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,
 
Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)
    
        

L2
  
      

forwarding instead of (IPv6 address based) L3 forwarding.
 
This brings two advantages:
 - avoid processing each transit packets up to L3.
 - use MAC addresses that - in ROLL environment - have inherently
    
        

shorter
  
      

length than an IPv6 address.
 
Cheers,
Daniel
 
 
 
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
    
        

Of
  
      

Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi John:
 
IPv6 already has a number of routing headers, in particular RH0,
    
        

though it is
  
      

being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
    
        

it is
  
      

easy to spot the consumed entries.
 
On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
    
        

downwards
  
      

that should be doable)
- control the size (that probably means compress)
 
Cheers,
 
Pascal
 
 
    
        

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
      
          

Of
    
        

JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations
 
Hi!
 
Great to see all this discussions on downwards route establishment!
      
          

To
  
      

add
    
        

one more to the conversations here is a proposal for source routing
      
          

headers.
    
        

In non-storing mode (where only the root has individual path
      
          

information)
    
        

the root will be attaching a source routing header to the data
      
          

packet
  
      

that a
    
        

source node wants to send to a specific destination. We can always
      
          

make the
    
        

header super fancy but in my opinion I think we only need two fields
      
          

in this
    
        

header and here it is! Feel free to break the stuff and mangle with
      
          

it
  
      

so that it
    
        

looks great in the specs later on. FYI, this is the format that I am
      
          

using in my
    
        

implementations so it does work :)
 
1. Source Routing Header Format
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |
      
          

|
    
        

+-+-+-+-+-+-+-+-+
      
          

+
    
        

|                       Source Route Entry (128*NEntry bits)
      
          

|
    
        

+
      
          

+
    
        

|
      
          

|
    
        

      Figure 1. Proposed Source Routing Header Format; each line is
      
          

32
  
      

bits:)
    
        

- NEntry: Indicates the number of 128 bit addresses that the source
      
          

route
    
        

entry field is carrying.
 
- Source Route Entry: List of 128 bit address that consist the route
      
          

to the
    
        

destination. Here, the address of the node that is one hop away from
      
          

the
    
        

*destination* comes first.
 
2. Source Routing Packet Operations
 
When source routing is initiated at a storing node (e.g., root of
      
          

the
  
      

DODAG),
    
        

the header is attached on the data packet for the entire route
      
          

(i.e.,
  
      

from
    
        

next hop node to the destination). This header is positioned in
      
          

front
  
      

of the
    
        

user payload. When the next hop node receives a packet that is not
      
          

destined
    
        

to itself AND the network is NOT provisioned to be in 'storing mode'
      
          

then it
    
        

checks NEntry to find what the next hop is in the source route
      
          

entry.
  
      

Since
    
        

the 'Source Route Entry' is ordered in 'farthest -> closest' (in
      
          

terms
  
      

of hops)
    
        

order, a node can figure out what the next hop address is with only
      
          

the
    
        

NEntry value (since it already knows how big an ipv6 address is).
      
          

After
    
        

collecting the next hop node's address, the node erases this address
element from the entry and decreases NEntry by one. This assures
      
          

that
  
      

we
    
        

avoid the overhead of carrying the entire source route throughout
      
          

the
  
      

data
    
        

path.
 
The approach itself should be very simple and trivial for everyone
      
          

to
  
      

follow.
    
        

So we can start from here and build on!
 
Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko
 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
      
          

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

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

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

 
  

------=_NextPart_000_0120_01CAD6F1.682E07F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    I think the issue is this:
    


    1)     
 ROLL cannot meet its charter without source =
routing
    


    2)     
 Claiming the feature is now to be addressed in =
6LowPAN seems a
bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE =
802.15.4.  How are
those addressed?
    


     
    


    Don
    


     
    


     
    


    


    


    From: Robert Cragie
[mailto:robert.cragie@gridmerge.com] 
    
Sent: Thursday, April 08, 2010 7:52 AM
    
To: d.sturek@att.net
    
Cc: daniel.gavelle@jennic.com; roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
    


    


    


     
    


    Hi Don,
    

    
It's not so much that 6lowpan is concerning itself with source routing, =
it is
concerning itself with efficient header compression, which would include =
IPv6
extension headers such as RH0.
Whatever ends up getting used for source routing needs to be some sort =
of IPv6
extension header. Source routing for IPv6 would naturally contain IPv6
addresses. The question is whether we want to invent some new extension =
header
specifically for ROLL which uses something other (i.e. smaller) than =
IPv6
addresses, e.g. the tag scheme mentioned.
    

    
I agree, ROLL must accommodate source routing one way or another.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 2:35 PM, Don Sturek wrote: 
    


    I can't see why 6LowPAN (and specifically the HC draft) would =
concern itself
    with source =
routing.
     
    Surely source =
routing is a concern of ROLL (and not =
6LowPAN).
     
    I don't see =
how ROLL completes its charter or addresses its =
requirements
    without adding source =
routing.
     
    Don<=
/pre>
     
     
    -----Or=
iginal Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf Of
    Daniel =
Gavelle
    Sent: Thursday, April 08, 2010 6:12 =
AM
    To: robert.cragie@gridmerge.com
    Cc: roll@ietf.org
    Subj=
ect: Re: [Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Rob,
     
    I agree that the source routing for the data frames should be done =
as 
    part of the 6LowPAN HC.  This already has =
a stateful IPV6 address 
    compression based on =
contexts.  It should be possible to compress the =

    addresses down to two bytes per address if IPv6 =
addresses are derived 
    from the 16 bit short =
address are being used in the =
LowPAN.
     
    We don't want =
to hold up the current HC draft that is going through last =

    call but the work could be done as a new RFC / =
amendment.  Source 
    routing compression may =
need a fix for the problem of HC compression =

    extending beyond the first =
fragment.
     
    Doing the =
work in the 6LowPAN group means that the compression can =

    easily be used for any source routing protocol, =
not just ROLL.  It could 
    be done as a =
compression for the existing R0 routing header.  Maybe this =

    thread needs moving to the 6LowPAN =
reflector.
     
    Daniel.<=
/o:p>
     
     
    R=
obert Cragie wrote:
      
    


    Hi =
Pascal,
     
    Source routing =
should of course use the IPv6 addresses which means a lot =

    of overhead for certain underlying link layers, =
e.g. 802.15.4. I think 
    it is generally cleaner to =
do the compression at a layer which may 
    require it =
only, e.g. define it in the 6lowpan HC. This is then free to =

    some extent to specify how the compression is =
done. Although I doubt 
    this would go down well in =
the 6lowpan WG...
     
    The =
tag scheme would work but it specifically scopes the source routing =

    to nodes which operate the scheme. This is =
probably acceptable 
    practically but doesn't 'smell =
right' somehow.
     
    With =
regard to the original proposal: it is probably necessary to carry =

    the full source route all the way to at least the =
penultimate node and 
    use an index to show the =
current position in the route for potential =

    backtrace and error reporting back along the same =
route (assuming link 
    symmetry). This is how RH0 =
works.
     
    Robert=

     
    Robert Cragie (Pacific Gas & =
Electric)
     
    Gridmerge =
Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, =
UK
    +44 (0) 1924 910888
    http://www.gridmerge.com <http://www.gridmerge.com/><=
o:p>
     
     
    <=
pre>On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) =
wrote:
        
    


    Hi =
Daniel:
     
    Routers might =
have multiple interfaces of multiple MAC types. Internet =
0
    even has a MAC-less =
format.
    So the result of you proposal, which looks =
like a great idea in a pure
    802.15.4 world with =
short addresses, becomes a nightmare to define in =
a
    fully generic =
fashion.
     
    OTOH, a =
locally significant opaque tag in which the parent could hide =
a
    short address of the child - if it cares to do it =
that way - looks like
    a way more acceptable =
approach
     
    So it seems to =
me that you can get what you want as long as we can =
make
    the tag big enough for short addresses. When =
the tag is too small to
    contain what the parent =
really needs, then the parent will have to store
    a =
state with the full information in memory, and then place an index =
of
    some sort in the =
tag.
     
    What do you =
think?
     
    Pascal=

     
     
     =
 =

          


    -----Original =
Message-----
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    Sent: Thursday, April 08, 2010 11:40 =
AM
    To: ROLL WG
    Cc: Pascal =
Thubert (pthubert); JeongGil Ko (John)
    Subject: RE: =
[Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Hi Pascal, =
John,
     
    Since source =
routing explicitly gives forwarding instruction to =
each
    intermediate node, it can make sense to use =
only (MAC address based)
        =

            
    


    L2
      =

          


    forwarding instead =
of (IPv6 address based) L3 =
forwarding.
     
    This brings =
two advantages:
     - avoid processing each transit =
packets up to L3.
     - use MAC addresses that - in =
ROLL environment - have =
inherently
        =

            
    


    shorter
      =

          


    length =
than an IPv6 =
address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
        =

            
    


    Of
      =

          


    Pascal =
Thubert (pthubert)
    Sent: jeudi 8 avril 2010 =
11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format =
and
    SourceRoutingOperations
     
    Hi =
John:
     
    IPv6 already has =
a number of routing headers, in particular =
RH0,
        =

            
    


    though it is
      =

          


    being =
deprecated for general use in the Internet.
    And =
there are reasons why the fields in RH0/1 are there and we need =
to
    make sure we lose none of that. In particular a =
RH is recoverable, and
        =

            
    


    it is
      =

          


    easy to =
spot the consumed =
entries.
     
    On top of this =
our new problems are:
    - make sure the RH stays =
within the RPL network (since it is =
used
        =

            
    


    downwards
      =

          


    that =
should be doable)
    - control the size (that probably =
means =
compress)
     
    Cheers,
     
    Pascal
     
     
        =

            
    


    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
          =

            &nb=
sp; 
    


    Of
        =

            
    


    JeongGil =
Ko (John)
    Sent: Wednesday, April 07, 2010 10:05 =
PM
    To: ROLL WG
    Subject: [Roll] =
Proposal for Source Routing Header Format and =
Source
    RoutingOperations
    &=
nbsp;
    Hi!
     
    Great to see all this discussions on downwards route =
establishment!
          =

            &nb=
sp; 
    




    To
      =

          


    add
    <=
pre>    =

            
    


    one more =
to the conversations here is a proposal for source =
routing
          =

            &nb=
sp; 
    


    headers.
        =

            
    


    In =
non-storing mode (where only the root has individual =
path
          =

            &nb=
sp; 
    


    information)
        =

            
    


    the root =
will be attaching a source routing header to the =
data
          =

            &nb=
sp; 
    




    packet
      =

          


    that =
a
        =

            
    


    source =
node wants to send to a specific destination. We can =
always
          =

            &nb=
sp; 
    


    make the
        =

            
    


    header =
super fancy but in my opinion I think we only need two =
fields
          =

            &nb=
sp; 
    


    in this
        =

            
    


    header =
and here it is! Feel free to break the stuff and mangle =
with
          =

            &nb=
sp; 
    


    


    it
      =

          


    so that =
it
        =

            
    


    looks =
great in the specs later on. FYI, this is the format that I =
am
          =

            &nb=
sp; 
    


    using in my
        =

            
    


    implementations so =
it does work :)
     
    1. =
Source Routing Header =
Format
     
    +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |&n=
bsp;  NEntry (8 bits)   =
|
          =

            &nb=
sp; 
    


    |
        =

            
    


    +-+-+-+-+-+-+-+-+
          =

            &nb=
sp; 
    


    +
        =

            
    


    |   &n=
bsp;      =
            &=
nbsp;Source Route Entry (128*NEntry =
bits)
          =

            &nb=
sp; 
    


    |
        =

            
    


    +
          =

            &nb=
sp; 
    


    +
        =

            
    


    |
          =

            &nb=
sp; 
    


    |
        =

            
    


       &nb=
sp;  Figure 1. Proposed Source Routing Header Format; each line =
is
          =

            &nb=
sp; 
    




    32
      =

          


    bits:)
        =

            
    


    - =
NEntry: Indicates the number of 128 bit addresses that the =
source
          =

            &nb=
sp; 
    


    route
        =

            
    


    entry =
field is carrying.
     
    - =
Source Route Entry: List of 128 bit address that consist the =
route
          =

            &nb=
sp; 
    


    to the
        =

            
    


    destination. Here, =
the address of the node that is one hop away =
from
          =

            &nb=
sp; 
    


    the
        =

            
    


    *destination* comes =
first.
     
    2. Source =
Routing Packet =
Operations
     
    When source =
routing is initiated at a storing node (e.g., root =
of
          =

            &nb=
sp; 
    


    


    the
      =

          


    DODAG),
        =

            
    


    the =
header is attached on the data packet for the entire =
route
          =

            &nb=
sp; 
    


    


    (i.e.,
      =

          


    from
    =

        =

            
    


    next hop =
node to the destination). This header is positioned =
in
          =

            &nb=
sp; 
    


    


    front
      =

          


    of =
the
        =

            
    


    user =
payload. When the next hop node receives a packet that is =
not
          =

            &nb=
sp; 
    


    destined
        =

            
    


    to =
itself AND the network is NOT provisioned to be in 'storing =
mode'
          =

            &nb=
sp; 
    


    then it
        =

            
    


    checks =
NEntry to find what the next hop is in the source =
route
          =

            &nb=
sp; 
    


    


    entry.
      =

          


    Since
        =

            
    


    the =
'Source Route Entry' is ordered in 'farthest -> closest' =
(in
          =

            &nb=
sp; 
    


    


    terms
      =

          


    of =
hops)
        =

            
    


    order, a =
node can figure out what the next hop address is with =
only
          =

            &nb=
sp; 
    


    the
        =

            
    


    NEntry =
value (since it already knows how big an ipv6 address =
is).
          =

            &nb=
sp; 
    


    After
        =

            
    


    collecting the next =
hop node's address, the node erases this =
address
    element from the entry and decreases NEntry =
by one. This assures
          =

            &nb=
sp; 
    


    


    that
      =

          


    we
        =

            
    


    avoid =
the overhead of carrying the entire source route =
throughout
          =

            &nb=
sp; 
    




    the
      =

          


    data
    =

        =

            
    


    path.
     
    The approach itself should be very =
simple and trivial for =
everyone
          =

            &nb=
sp; 
    


    


    to
      =

          


    follow.
        =

            
    


    So we =
can start from here and build =
on!
     
    Thanks.
     
    -John
    &nbs=
p;
    ------
    JeongGil Ko =
(John)
    Ph.D. =
Student
    Department of Computer =
Science
    Johns Hopkins =
University
    http://www.cs.jhu.edu/~jgko=

     
    ____________________________=
___________________
    Roll mailing =
list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
        &n=
bsp; =

            &nb=
sp; 
    


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

            
    


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

          


     
    ----------------------------------------=
--------------------------------
     
    _______________________________________________
    =

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

    


     
      
    





------=_NextPart_000_0120_01CAD6F1.682E07F0--


From d.sturek@att.net  Thu Apr  8 08:04:50 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC8E3A6A84 for ; Thu,  8 Apr 2010 08:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.382
X-Spam-Level: 
X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huKWrt3XuybK for ; Thu,  8 Apr 2010 08:04:49 -0700 (PDT)
Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 395383A6892 for ; Thu,  8 Apr 2010 08:04:49 -0700 (PDT)
Received: (qmail 63273 invoked from network); 8 Apr 2010 15:04:43 -0000
Received: from adsl-69-108-49-215.dsl.sndg02.pacbell.net (d.sturek@69.108.49.215 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 08 Apr 2010 08:04:43 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: 52dBee8VM1kaJRgc7R8LcVo9OTrbagqqiKA9iUV.RX9VGbkiH0FKGc_Syamsy49iAQ6u5xrLxmmPb300sP7qHjPG7O0eTv1vSfnSwvxZk.KeVE0oo_fNDaWRC6FrNi5s0jhVZH4_eCPHkIrggU0L9ZhbOsIH5Bfld6hubIeP2Fl49TYK62I1NcXbz0qUotguCsOmeD57uAUDYkdTtU37r3rQ2qL8App6FlgqCrfmJ_uVSNN7PcJInG7jv0eIlWmASYHZMYryS8ZUR4GYvAe7AuUQitj83twlEoSruL1tMUUfdH76VE8-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Jonathan Hui'" , "'Pascal Thubert \(pthubert\)'" 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
In-Reply-To: <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
Date: Thu, 8 Apr 2010 08:04:42 -0700
Message-ID: <012c01cad72c$d2027630$76076290$@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: AcrXK+Wnd6V1JFQpSwmEByvGAYL8SwAALo6A
Content-Language: en-us
Cc: 'ROLL WG' , "'Popa, Daniel'" 
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 15:04:50 -0000

I would prefer the tag/label approach defined in ROLL.  This can be
addressed in ROLL as a solution suitable over multiple MAC/PHYs.

I do not support the notion that each MAC/PHY will somehow create their own
scheme for source route forwarding.  I cannot see how that would scale or
work.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Jonathan Hui
Sent: Thursday, April 08, 2010 7:58 AM
To: Pascal Thubert (pthubert)
Cc: ROLL WG; Popa, Daniel
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations


To make the source route header compact, I favor the tag/label  
approach over some other compaction mechanism that operates directly  
on a list of IPv6 addresses.  Tags/labels can be made general enough  
such that they can be derived in different ways.  Because the tags/ 
labels have scope local to each node, the mechanism is pretty general  
already.  For those that are already managing unique 802.15.4 short  
addresses across a network, I can see that it is attractive to utilize  
the short address directly and reduce state on devices.  In other  
cases, it may be best for the node to dynamically assign tags/labels  
for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more  
flexible than an approach to compacting a list of IPv6 addresses.  And  
note that the idea of using tags/labels is nothing new.  Of course we  
will adapt the basic mechanism a bit (label distribution, headers  
formats, etc), but the core ideas have been deployed in traditional IP  
networks for quite some time.

I reiterated a lot of what was already stated before by others, but  
that is what I think.

--
Jonathan Hui

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:

> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types.  
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define  
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could  
> hide a
> short address of the child - if it cares to do it that way - looks  
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can  
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to  
> store
> a state with the full information in memory, and then place an index  
> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
> L2
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
> shorter
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
> though it is
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need  
>> to
>> make sure we lose none of that. In particular a RH is recoverable,  
>> and
> it is
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
> downwards
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>> JeongGil Ko (John)
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>> To: ROLL WG
>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>> RoutingOperations
>>>
>>> Hi!
>>>
>>> Great to see all this discussions on downwards route establishment!
> To
>> add
>>> one more to the conversations here is a proposal for source routing
>> headers.
>>> In non-storing mode (where only the root has individual path
>> information)
>>> the root will be attaching a source routing header to the data
> packet
>> that a
>>> source node wants to send to a specific destination. We can always
>> make the
>>> header super fancy but in my opinion I think we only need two fields
>> in this
>>> header and here it is! Feel free to break the stuff and mangle with
> it
>> so that it
>>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>> implementations so it does work :)
>>>
>>> 1. Source Routing Header Format
>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |   NEntry (8 bits)   |
>> |
>>> +-+-+-+-+-+-+-+-+
>> +
>>> |                       Source Route Entry (128*NEntry bits)
>> |
>>> +
>> +
>>> |
>> |
>>>
>>>      Figure 1. Proposed Source Routing Header Format; each line is
> 32
>> bits:)
>>>
>>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>> entry field is carrying.
>>>
>>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>> destination. Here, the address of the node that is one hop away from
>> the
>>> *destination* comes first.
>>>
>>> 2. Source Routing Packet Operations
>>>
>>> When source routing is initiated at a storing node (e.g., root of
> the
>> DODAG),
>>> the header is attached on the data packet for the entire route
> (i.e.,
>> from
>>> next hop node to the destination). This header is positioned in
> front
>> of the
>>> user payload. When the next hop node receives a packet that is not
>> destined
>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>> checks NEntry to find what the next hop is in the source route
> entry.
>> Since
>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> terms
>> of hops)
>>> order, a node can figure out what the next hop address is with only
>> the
>>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>> collecting the next hop node's address, the node erases this address
>>> element from the entry and decreases NEntry by one. This assures
> that
>> we
>>> avoid the overhead of carrying the entire source route throughout
> the
>> data
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
> to
>> follow.
>>> So we can start from here and build on!
>>>
>>> Thanks.
>>>
>>> -John
>>>
>>> ------
>>> JeongGil Ko (John)
>>> Ph.D. Student
>>> Department of Computer Science
>>> Johns Hopkins University
>>> http://www.cs.jhu.edu/~jgko
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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


From Daniel.Popa@itron.com  Thu Apr  8 08:38:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2413A6A46 for ; Thu,  8 Apr 2010 08:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh8o2GRUa7AR for ; Thu,  8 Apr 2010 08:38:52 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 55BCC3A6AB6 for ; Thu,  8 Apr 2010 08:38:06 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Apr 2010 11:38:01 -0400
Message-ID: 
In-Reply-To: <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations
Thread-Index: AcrXK+Y3XdQqQNGBSDeGIeFFeGfZYAAAYhDw
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>  <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
From: "Popa, Daniel" 
To: "Jonathan Hui" , "Pascal Thubert (pthubert)" , "ROLL WG" 
Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 15:38:54 -0000

I reiterate my preference for a generic tagging mechanism with the
capability of using "short addressing" for forwarding. For nodes belong
to the same subnet (i.e., same Network ID) we may want to allow the use
of the "Host ID" information from the IPv6 address - i.e., MAC/Link
Layer Address - (w/r/t IPv6 stateless address auto-configuration) to
create short address for forwarding rather than using the full IPv6
address. By doing so, the overhead reduction for source routing scheme
with explicit route specification can be significant. =20


Thanks.=20

Cheers,=20
Daniel=20


-----Original Message-----
From: Jonathan Hui [mailto:jhui@archrock.com]=20
Sent: jeudi 8 avril 2010 16:58
To: Pascal Thubert (pthubert)
Cc: Popa, Daniel; ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations


To make the source route header compact, I favor the tag/label =20
approach over some other compaction mechanism that operates directly =20
on a list of IPv6 addresses.  Tags/labels can be made general enough =20
such that they can be derived in different ways.  Because the tags/=20
labels have scope local to each node, the mechanism is pretty general =20
already.  For those that are already managing unique 802.15.4 short =20
addresses across a network, I can see that it is attractive to utilize =20
the short address directly and reduce state on devices.  In other =20
cases, it may be best for the node to dynamically assign tags/labels =20
for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more =20
flexible than an approach to compacting a list of IPv6 addresses.  And =20
note that the idea of using tags/labels is nothing new.  Of course we =20
will adapt the basic mechanism a bit (label distribution, headers =20
formats, etc), but the core ideas have been deployed in traditional IP =20
networks for quite some time.

I reiterated a lot of what was already stated before by others, but =20
that is what I think.

--
Jonathan Hui

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:

> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types. =20
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define =20
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could =20
> hide a
> short address of the child - if it cares to do it that way - looks =20
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can =20
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to =20
> store
> a state with the full information in memory, and then place an index =20
> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
> L2
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
> shorter
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
> though it is
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need =20
>> to
>> make sure we lose none of that. In particular a RH is recoverable, =20
>> and
> it is
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
> downwards
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>> JeongGil Ko (John)
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>> To: ROLL WG
>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>> RoutingOperations
>>>
>>> Hi!
>>>
>>> Great to see all this discussions on downwards route establishment!
> To
>> add
>>> one more to the conversations here is a proposal for source routing
>> headers.
>>> In non-storing mode (where only the root has individual path
>> information)
>>> the root will be attaching a source routing header to the data
> packet
>> that a
>>> source node wants to send to a specific destination. We can always
>> make the
>>> header super fancy but in my opinion I think we only need two fields
>> in this
>>> header and here it is! Feel free to break the stuff and mangle with
> it
>> so that it
>>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>> implementations so it does work :)
>>>
>>> 1. Source Routing Header Format
>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |   NEntry (8 bits)   |
>> |
>>> +-+-+-+-+-+-+-+-+
>> +
>>> |                       Source Route Entry (128*NEntry bits)
>> |
>>> +
>> +
>>> |
>> |
>>>
>>>      Figure 1. Proposed Source Routing Header Format; each line is
> 32
>> bits:)
>>>
>>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>> entry field is carrying.
>>>
>>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>> destination. Here, the address of the node that is one hop away from
>> the
>>> *destination* comes first.
>>>
>>> 2. Source Routing Packet Operations
>>>
>>> When source routing is initiated at a storing node (e.g., root of
> the
>> DODAG),
>>> the header is attached on the data packet for the entire route
> (i.e.,
>> from
>>> next hop node to the destination). This header is positioned in
> front
>> of the
>>> user payload. When the next hop node receives a packet that is not
>> destined
>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>> checks NEntry to find what the next hop is in the source route
> entry.
>> Since
>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> terms
>> of hops)
>>> order, a node can figure out what the next hop address is with only
>> the
>>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>> collecting the next hop node's address, the node erases this address
>>> element from the entry and decreases NEntry by one. This assures
> that
>> we
>>> avoid the overhead of carrying the entire source route throughout
> the
>> data
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
> to
>> follow.
>>> So we can start from here and build on!
>>>
>>> Thanks.
>>>
>>> -John
>>>
>>> ------
>>> JeongGil Ko (John)
>>> Ph.D. Student
>>> Department of Computer Science
>>> Johns Hopkins University
>>> http://www.cs.jhu.edu/~jgko
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From robert.cragie@gridmerge.com  Thu Apr  8 08:42:40 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A713A68DB for ; Thu,  8 Apr 2010 08:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.081
X-Spam-Level: 
X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=0.517,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxG2XlEQOqKN for ; Thu,  8 Apr 2010 08:42:37 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1B9003A680E for ; Thu,  8 Apr 2010 08:42:36 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1NztsD-0003hH-6K; Thu, 08 Apr 2010 16:42:30 +0100
Message-ID: <4BBDF95E.1000800@gridmerge.com>
Date: Thu, 08 Apr 2010 16:42:22 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: d.sturek@att.net
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net> <4BBDED7C.40009@gridmerge.com> <011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>
In-Reply-To: <011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010806080200070808040405"
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 15:42:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms010806080200070808040405
Content-Type: multipart/alternative;
 boundary="------------010907050608030104010201"

This is a multi-part message in MIME format.
--------------010907050608030104010201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Don,

I am not suggesting source routing is done in 6lowpan at all. I am=20
suggesting source routing is done using standard IPv6 extension headers. =

These would naturally include IPv6 addresses. It is precisely this point =

which makes it not only MAC/PHY agnostic but also routing scheme=20
agnostic. Using some sort of tag scheme would potentially make it=20
MAC/PHY agnostic but I can't see how it would make it routing scheme=20
agnostic.

What I am then suggesting is that these standard IPv6 extension headers=20
can be compressed using the 6lowpan adaptation layer just as it=20
compresses the rest of the IPv6 header. The fact that it contains source =

routing data is immaterial to 6lowpan; it is just a load of IPv6=20
addresses it can make smaller.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 08/04/2010 3:59 PM, Don Sturek wrote:
>
> I think the issue is this:
>
> 1)  ROLL cannot meet its charter without source routing
>
> 2)  Claiming the feature is now to be addressed in 6LowPAN seems a bit =

> wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  How=20
> are those addressed?
>
> Don
>
> *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com]
> *Sent:* Thursday, April 08, 2010 7:52 AM
> *To:* d.sturek@att.net
> *Cc:* daniel.gavelle@jennic.com; roll@ietf.org
> *Subject:* Re: [Roll] Proposal for Source Routing Header Format and=20
> SourceRoutingOperations
>
> Hi Don,
>
> It's not so much that 6lowpan is concerning itself with source=20
> routing, it is concerning itself with efficient header compression,=20
> which would include IPv6 extension headers such as RH0=20
> . Whatever ends up getting =

> used for source routing needs to be some sort of IPv6 extension=20
> header. Source routing for IPv6 would naturally contain IPv6=20
> addresses. The question is whether we want to invent some new=20
> extension header specifically for ROLL which uses something other=20
> (i.e. smaller) than IPv6 addresses, e.g. the tag scheme mentioned.
>
> I agree, ROLL must accommodate source routing one way or another.
>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com 
>
>
> On 08/04/2010 2:35 PM, Don Sturek wrote:
>
> I can't see why 6LowPAN (and specifically the HC draft) would concern i=
tself
> with source routing.
>  =20
> Surely source routing is a concern of ROLL (and not 6LowPAN).
>  =20
> I don't see how ROLL completes its charter or addresses its requirement=
s
> without adding source routing.
>  =20
> Don
>  =20
>  =20
> -----Original Message-----
> From:roll-bounces@ietf.org    [mailto:rol=
l-bounces@ietf.org] On Behalf Of
> Daniel Gavelle
> Sent: Thursday, April 08, 2010 6:12 AM
> To:robert.cragie@gridmerge.com  
> Cc:roll@ietf.org  
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>  =20
> Rob,
>  =20
> I agree that the source routing for the data frames should be done as
> part of the 6LowPAN HC.  This already has a stateful IPV6 address
> compression based on contexts.  It should be possible to compress the
> addresses down to two bytes per address if IPv6 addresses are derived
> from the 16 bit short address are being used in the LowPAN.
>  =20
> We don't want to hold up the current HC draft that is going through las=
t
> call but the work could be done as a new RFC / amendment.  Source
> routing compression may need a fix for the problem of HC compression
> extending beyond the first fragment.
>  =20
> Doing the work in the 6LowPAN group means that the compression can
> easily be used for any source routing protocol, not just ROLL.  It coul=
d
> be done as a compression for the existing R0 routing header.  Maybe thi=
s
> thread needs moving to the 6LowPAN reflector.
>  =20
> Daniel.
>  =20
>  =20
> Robert Cragie wrote:
>   =20
>
>     Hi Pascal,
>
>      =20
>
>     Source routing should of course use the IPv6 addresses which means =
a lot
>
>     of overhead for certain underlying link layers, e.g. 802.15.4. I th=
ink
>
>     it is generally cleaner to do the compression at a layer which may
>
>     require it only, e.g. define it in the 6lowpan HC. This is then fre=
e to
>
>     some extent to specify how the compression is done. Although I doub=
t
>
>     this would go down well in the 6lowpan WG...
>
>      =20
>
>     The tag scheme would work but it specifically scopes the source rou=
ting
>
>     to nodes which operate the scheme. This is probably acceptable
>
>     practically but doesn't 'smell right' somehow.
>
>      =20
>
>     With regard to the original proposal: it is probably necessary to c=
arry
>
>     the full source route all the way to at least the penultimate node =
and
>
>     use an index to show the current position in the route for potentia=
l
>
>     backtrace and error reporting back along the same route (assuming l=
ink
>
>     symmetry). This is how RH0 works.
>
>      =20
>
>     Robert
>
>      =20
>
>     Robert Cragie (Pacific Gas&  Electric)
>
>      =20
>
>     Gridmerge Ltd.
>
>     89 Greenfield Crescent,
>
>     Wakefield, WF4 4WA, UK
>
>     +44 (0) 1924 910888
>
>     http://www.gridmerge.com  
>
>      =20
>
>      =20
>
>     On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>
>         =20
>
>         Hi Daniel:
>
>          =20
>
>         Routers might have multiple interfaces of multiple MAC types. I=
nternet 0
>
>         even has a MAC-less format.
>
>         So the result of you proposal, which looks like a great idea in=
 a pure
>
>         802.15.4 world with short addresses, becomes a nightmare to def=
ine in a
>
>         fully generic fashion.
>
>          =20
>
>         OTOH, a locally significant opaque tag in which the parent coul=
d hide a
>
>         short address of the child - if it cares to do it that way - lo=
oks like
>
>         a way more acceptable approach
>
>          =20
>
>         So it seems to me that you can get what you want as long as we =
can make
>
>         the tag big enough for short addresses. When the tag is too sma=
ll to
>
>         contain what the parent really needs, then the parent will have=
 to store
>
>         a state with the full information in memory, and then place an =
index of
>
>         some sort in the tag.
>
>          =20
>
>         What do you think?
>
>          =20
>
>         Pascal
>
>          =20
>
>          =20
>
>           =20
>
>               =20
>
>             -----Original Message-----
>
>             From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>
>             Sent: Thursday, April 08, 2010 11:40 AM
>
>             To: ROLL WG
>
>             Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>
>             Subject: RE: [Roll] Proposal for Source Routing Header Form=
at and
>
>             SourceRoutingOperations
>
>              =20
>
>             Hi Pascal, John,
>
>              =20
>
>             Since source routing explicitly gives forwarding instructio=
n to each
>
>             intermediate node, it can make sense to use only (MAC addre=
ss based)
>
>                 =20
>
>                     =20
>
>         L2
>
>           =20
>
>               =20
>
>             forwarding instead of (IPv6 address based) L3 forwarding.
>
>              =20
>
>             This brings two advantages:
>
>               - avoid processing each transit packets up to L3.
>
>               - use MAC addresses that - in ROLL environment - have inh=
erently
>
>                 =20
>
>                     =20
>
>         shorter
>
>           =20
>
>               =20
>
>             length than an IPv6 address.
>
>              =20
>
>             Cheers,
>
>             Daniel
>
>              =20
>
>              =20
>
>              =20
>
>             -----Original Message-----
>
>             From:roll-bounces@ietf.org   =
 [mailto:roll-bounces@ietf.org] On Behalf
>
>                 =20
>
>                     =20
>
>         Of
>
>           =20
>
>               =20
>
>             Pascal Thubert (pthubert)
>
>             Sent: jeudi 8 avril 2010 11:15
>
>             To: JeongGil Ko (John); ROLL WG
>
>             Subject: Re: [Roll] Proposal for Source Routing Header Form=
at and
>
>             SourceRoutingOperations
>
>              =20
>
>             Hi John:
>
>              =20
>
>             IPv6 already has a number of routing headers, in particular=
 RH0,
>
>                 =20
>
>                     =20
>
>         though it is
>
>           =20
>
>               =20
>
>             being deprecated for general use in the Internet.
>
>             And there are reasons why the fields in RH0/1 are there and=
 we need to
>
>             make sure we lose none of that. In particular a RH is recov=
erable, and
>
>                 =20
>
>                     =20
>
>         it is
>
>           =20
>
>               =20
>
>             easy to spot the consumed entries.
>
>              =20
>
>             On top of this our new problems are:
>
>             - make sure the RH stays within the RPL network (since it i=
s used
>
>                 =20
>
>                     =20
>
>         downwards
>
>           =20
>
>               =20
>
>             that should be doable)
>
>             - control the size (that probably means compress)
>
>              =20
>
>             Cheers,
>
>              =20
>
>             Pascal
>
>              =20
>
>              =20
>
>                 =20
>
>                     =20
>
>                 -----Original Message-----
>
>                 From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf
>
>                       =20
>
>                           =20
>
>             Of
>
>                 =20
>
>                     =20
>
>                 JeongGil Ko (John)
>
>                 Sent: Wednesday, April 07, 2010 10:05 PM
>
>                 To: ROLL WG
>
>                 Subject: [Roll] Proposal for Source Routing Header Form=
at and Source
>
>                 RoutingOperations
>
>                  =20
>
>                 Hi!
>
>                  =20
>
>                 Great to see all this discussions on downwards route es=
tablishment!
>
>                       =20
>
>                           =20
>
>         To
>
>           =20
>
>               =20
>
>             add
>
>                 =20
>
>                     =20
>
>                 one more to the conversations here is a proposal for so=
urce routing
>
>                       =20
>
>                           =20
>
>             headers.
>
>                 =20
>
>                     =20
>
>                 In non-storing mode (where only the root has individual=
 path
>
>                       =20
>
>                           =20
>
>             information)
>
>                 =20
>
>                     =20
>
>                 the root will be attaching a source routing header to t=
he data
>
>                       =20
>
>                           =20
>
>         packet
>
>           =20
>
>               =20
>
>             that a
>
>                 =20
>
>                     =20
>
>                 source node wants to send to a specific destination. We=
 can always
>
>                       =20
>
>                           =20
>
>             make the
>
>                 =20
>
>                     =20
>
>                 header super fancy but in my opinion I think we only ne=
ed two fields
>
>                       =20
>
>                           =20
>
>             in this
>
>                 =20
>
>                     =20
>
>                 header and here it is! Feel free to break the stuff and=
 mangle with
>
>                       =20
>
>                           =20
>
>         it
>
>           =20
>
>               =20
>
>             so that it
>
>                 =20
>
>                     =20
>
>                 looks great in the specs later on. FYI, this is the for=
mat that I am
>
>                       =20
>
>                           =20
>
>             using in my
>
>                 =20
>
>                     =20
>
>                 implementations so it does work :)
>
>                  =20
>
>                 1. Source Routing Header Format
>
>                  =20
>
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+
>
>                 |   NEntry (8 bits)   |
>
>                       =20
>
>                           =20
>
>             |
>
>                 =20
>
>                     =20
>
>                 +-+-+-+-+-+-+-+-+
>
>                       =20
>
>                           =20
>
>             +
>
>                 =20
>
>                     =20
>
>                 |                       Source Route Entry (128*NEntry =
bits)
>
>                       =20
>
>                           =20
>
>             |
>
>                 =20
>
>                     =20
>
>                 +
>
>                       =20
>
>                           =20
>
>             +
>
>                 =20
>
>                     =20
>
>                 |
>
>                       =20
>
>                           =20
>
>             |
>
>                 =20
>
>                     =20
>
>                        Figure 1. Proposed Source Routing Header Format;=
 each line is
>
>                       =20
>
>                           =20
>
>         32
>
>           =20
>
>               =20
>
>             bits:)
>
>                 =20
>
>                     =20
>
>                 - NEntry: Indicates the number of 128 bit addresses tha=
t the source
>
>                       =20
>
>                           =20
>
>             route
>
>                 =20
>
>                     =20
>
>                 entry field is carrying.
>
>                  =20
>
>                 - Source Route Entry: List of 128 bit address that cons=
ist the route
>
>                       =20
>
>                           =20
>
>             to the
>
>                 =20
>
>                     =20
>
>                 destination. Here, the address of the node that is one =
hop away from
>
>                       =20
>
>                           =20
>
>             the
>
>                 =20
>
>                     =20
>
>                 *destination* comes first.
>
>                  =20
>
>                 2. Source Routing Packet Operations
>
>                  =20
>
>                 When source routing is initiated at a storing node (e.g=
=2E, root of
>
>                       =20
>
>                           =20
>
>         the
>
>           =20
>
>               =20
>
>             DODAG),
>
>                 =20
>
>                     =20
>
>                 the header is attached on the data packet for the entir=
e route
>
>                       =20
>
>                           =20
>
>         (i.e.,
>
>           =20
>
>               =20
>
>             from
>
>                 =20
>
>                     =20
>
>                 next hop node to the destination). This header is posit=
ioned in
>
>                       =20
>
>                           =20
>
>         front
>
>           =20
>
>               =20
>
>             of the
>
>                 =20
>
>                     =20
>
>                 user payload. When the next hop node receives a packet =
that is not
>
>                       =20
>
>                           =20
>
>             destined
>
>                 =20
>
>                     =20
>
>                 to itself AND the network is NOT provisioned to be in '=
storing mode'
>
>                       =20
>
>                           =20
>
>             then it
>
>                 =20
>
>                     =20
>
>                 checks NEntry to find what the next hop is in the sourc=
e route
>
>                       =20
>
>                           =20
>
>         entry.
>
>           =20
>
>               =20
>
>             Since
>
>                 =20
>
>                     =20
>
>                 the 'Source Route Entry' is ordered in 'farthest ->  cl=
osest' (in
>
>                       =20
>
>                           =20
>
>         terms
>
>           =20
>
>               =20
>
>             of hops)
>
>                 =20
>
>                     =20
>
>                 order, a node can figure out what the next hop address =
is with only
>
>                       =20
>
>                           =20
>
>             the
>
>                 =20
>
>                     =20
>
>                 NEntry value (since it already knows how big an ipv6 ad=
dress is).
>
>                       =20
>
>                           =20
>
>             After
>
>                 =20
>
>                     =20
>
>                 collecting the next hop node's address, the node erases=
 this address
>
>                 element from the entry and decreases NEntry by one. Thi=
s assures
>
>                       =20
>
>                           =20
>
>         that
>
>           =20
>
>               =20
>
>             we
>
>                 =20
>
>                     =20
>
>                 avoid the overhead of carrying the entire source route =
throughout
>
>                       =20
>
>                           =20
>
>         the
>
>           =20
>
>               =20
>
>             data
>
>                 =20
>
>                     =20
>
>                 path.
>
>                  =20
>
>                 The approach itself should be very simple and trivial f=
or everyone
>
>                       =20
>
>                           =20
>
>         to
>
>           =20
>
>               =20
>
>             follow.
>
>                 =20
>
>                     =20
>
>                 So we can start from here and build on!
>
>                  =20
>
>                 Thanks.
>
>                  =20
>
>                 -John
>
>                  =20
>
>                 ------
>
>                 JeongGil Ko (John)
>
>                 Ph.D. Student
>
>                 Department of Computer Science
>
>                 Johns Hopkins University
>
>                 http://www.cs.jhu.edu/~jgko  
>
>                  =20
>
>                 _______________________________________________
>
>                 Roll mailing list
>
>                 Roll@ietf.org  
>
>                 https://www.ietf.org/mailman/listinfo/roll
>
>                       =20
>
>                           =20
>
>             _______________________________________________
>
>             Roll mailing list
>
>             Roll@ietf.org  
>
>             https://www.ietf.org/mailman/listinfo/roll
>
>                 =20
>
>                     =20
>
>         _______________________________________________
>
>         Roll mailing list
>
>         Roll@ietf.org  
>
>         https://www.ietf.org/mailman/listinfo/roll
>
>          =20
>
>           =20
>
>               =20
>
>      =20
>
>     -------------------------------------------------------------------=
-----
>
>      =20
>
>     _______________________________________________
>
>     Roll mailing list
>
>     Roll@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/roll
>
>         =20
>
>  =20
>   =20

--------------010907050608030104010201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  
  


Hi Don,
    

    
I am not suggesting source routing is done in 6lowpan at all. I am
suggesting source routing is done using standard IPv6 extension
headers. These would naturally include IPv6 addresses. It is precisely
this point which makes it not only MAC/PHY agnostic but also routing
scheme agnostic. Using some sort of tag scheme would potentially make
it MAC/PHY agnostic but I can't see how it would make it routing scheme
agnostic.
    

    
What I am then suggesting is that these standard IPv6 extension headers
can be compressed using the 6lowpan adaptation layer just as it
compresses the rest of the IPv6 header. The fact that it contains
source routing data is immaterial to 6lowpan; it is just a load of IPv6
addresses it can make smaller.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 08/04/2010 3:59 PM, Don Sturek wrote:

    
  
  
  

  
    
  
    I
think the issue is this:
    
  
    1) ROLL
cannot meet its charter without source routing
    
  
    2) Claiming
the feature is now to be addressed in 6LowPAN seems a
bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.=
 
How are
those addressed?
    
  
     
    
  
    Don
    
  
     
    
  
     
    
  
    
  
    
  
    From:
Robert Cragie
[mailto:robert.cragie@gridmerge.com] 
    
  Sent: Thursday, April 08, 2010 7:52 AM
    
  To: d.sturek@att.net
    
  Cc: daniel.gavelle@jennic.com; roll@ietf.org
    
  Subject: Re: [Roll] Proposal for Source Routing Header Format
and
SourceRoutingOperations
    
  
    
  
    
  
     
    
  
    Hi Don,
    
  
    
It's not so much that 6lowpan is concerning itself with source routing,
it is
concerning itself with efficient header compression, which would
include IPv6
extension headers such as RH0.
Whatever ends up getting used for source routing needs to be some sort
of IPv6
extension header. Source routing for IPv6 would naturally contain IPv6
addresses. The question is whether we want to invent some new extension
header
specifically for ROLL which uses something other (i.e. smaller) than
IPv6
addresses, e.g. the tag scheme mentioned.
    
  
    
I agree, ROLL must accommodate source routing one way or another.
    
  
    
Robert
    
  
    
  
    Robert Cragie (Pacific Gas & Electric)=

    
  
    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
  http://w=
ww.gridmerge.com
    
  
    
  

    
On 08/04/2010 2:35 PM, Don Sturek wrote: 
    
  
    I can't see why 6LowPAN (and specifically the HC draft) would conc=
ern itself
    
  
    with source routing.
    
  
     
    
  
    Surely source routing is a concern of ROLL (and not 6LowPAN).=

    
  
     
    
  
    I don't see how ROLL completes its charter or addresses its requir=
ements
    
  
    without adding source routing.
    
  
     
    
  
    Don
    
  
     
    
  
     
    
  
    -----Original Message-----
    
  
    From: roll-bounces@ietf.org [mailto:ro=
ll-bounces@ietf.org] On Behalf Of
    
  
    Daniel Gavelle
    
  
    Sent: Thursday, April 08, 2010 6:12 AM
    
  
    To: robert.cragie@gridmerge.com<=
/a>
    
  
    Cc: roll=
@ietf.org
    
  
    Subject: Re: [Roll] Proposal for Source Routing Header Format and<=
o:p>
    
  
    SourceRoutingOperations
    
  
     
    
  
    Rob,
    
  
     
    
  
    I agree that the source routing for the data frames should be done=
 as 
    
  
    part of the 6LowPAN HC.  This already has a stateful IPV6 add=
ress 
    
  
    compression based on contexts.  It should be possible to comp=
ress the 
    
  
    addresses down to two bytes per address if IPv6 addresses are deri=
ved 
    
  
    from the 16 bit short address are being used in the LowPAN.
    
  
     
    
  
    We don't want to hold up the current HC draft that is going throug=
h last 
    
  
    call but the work could be done as a new RFC / amendment.  So=
urce 
    
  
    routing compression may need a fix for the problem of HC compressi=
on 
    
  
    extending beyond the first fragment.
    
  
     
    
  
    Doing the work in the 6LowPAN group means that the compression can=
 
    
  
    easily be used for any source routing protocol, not just ROLL.&nbs=
p; It could 
    
  
    be done as a compression for the existing R0 routing header. =
 Maybe this 
    
  
    thread needs moving to the 6LowPAN reflector.
    
  
     
    
  
    Daniel.
    
  
     
    
  
     
    
  
    Robert Cragie wrote:
    
  
      
    
  
    
    
    Hi Pascal,
    
    
     
    
    
    Source routing should of course use the IPv6 addresses which mea=
ns a lot 
    
    
    of overhead for certain underlying link layers, e.g. 802.15.4. I=
 think 
    
    
    it is generally cleaner to do the compression at a layer which m=
ay 
    
    
    require it only, e.g. define it in the 6lowpan HC. This is then =
free to 
    
    
    some extent to specify how the compression is done. Although I d=
oubt 
    
    
    this would go down well in the 6lowpan WG...
    
    
     
    
    
    The tag scheme would work but it specifically scopes the source =
routing 
    
    
    to nodes which operate the scheme. This is probably acceptable <=
o:p>
    
    
    practically but doesn't 'smell right' somehow.
    
    
     
    
    
    With regard to the original proposal: it is probably necessary t=
o carry 
    
    
    the full source route all the way to at least the penultimate no=
de and 
    
    
    use an index to show the current position in the route for poten=
tial 
    
    
    backtrace and error reporting back along the same route (assumin=
g link 
    
    
    symmetry). This is how RH0 works.
    
    
     
    
    
    Robert
    
    
     
    
    
    Robert Cragie (Pacific Gas & Electric)
    
    
     
    
    
    Gridmerge Ltd.
    
    
    89 Greenfield Crescent,
    
    
    Wakefield, WF4 4WA, UK
    
    
    +44 (0) 1924 910888
    
    
    ht=
tp://www.gridmerge.com <http://w=
ww.gridmerge.com/>
    
    
     
    
    
     
    
    
    On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
    
    
        
    
    
    
      
    Hi Daniel:
    
      
     
    
      
    Routers might have multiple interfaces of multiple MAC types. =
Internet 0
    
      
    even has a MAC-less format.
    
      
    So the result of you proposal, which looks like a great idea i=
n a pure
    
      
    802.15.4 world with short addresses, becomes a nightmare to de=
fine in a
    
      
    fully generic fashion.
    
      
     
    
      
    OTOH, a locally significant opaque tag in which the parent cou=
ld hide a
    
      
    short address of the child - if it cares to do it that way - l=
ooks like
    
      
    a way more acceptable approach
    
      
     
    
      
    So it seems to me that you can get what you want as long as we=
 can make
    
      
    the tag big enough for short addresses. When the tag is too sm=
all to
    
      
    contain what the parent really needs, then the parent will hav=
e to store
    
      
    a state with the full information in memory, and then place an=
 index of
    
      
    some sort in the tag.
    
      
     
    
      
    What do you think?
    
      
     
    
      
    Pascal
    
      
     
    
      
     
    
      
      
    
      
          
    
      
    
        
    -----Original Message-----
    
        
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]<=
o:p>
    
        
    Sent: Thursday, April 08, 2010 11:40 AM
    
        
    To: ROLL WG
    
        
    Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=

    
        
    Subject: RE: [Roll] Proposal for Source Routing Header Forma=
t and
    
        
    SourceRoutingOperations
    
        
     
    
        
    Hi Pascal, John,
    
        
     
    
        
    Since source routing explicitly gives forwarding instruction=
 to each
    
        
    intermediate node, it can make sense to use only (MAC addres=
s based)
    
        
        
    
        
            <=
/pre>
      
    
      
    L2
    
      
      
    
      
          
    
      
    
        
    forwarding instead of (IPv6 address based) L3 forwarding.
    
        
     
    
        
    This brings two advantages:
    
        
     - avoid processing each transit packets up to L3.
    
        
     - use MAC addresses that - in ROLL environment - have inher=
ently
    
        
        
    
        
            <=
/pre>
      
    
      
    shorter
    
      
      
    
      
          
    
      
    
        
    length than an IPv6 address.
    
        
     
    
        
    Cheers,
    
        
    Daniel
    
        
     
    
        
     
    
        
     
    
        
    -----Original Message-----
    
        
    From: roll-bounces@ietf.org [mailto:ro=
ll-bounces@ietf.org] On Behalf
    
        
        
    
        
            <=
/pre>
      
    
      
    Of
    
      
      
    
      
          
    
      
    
        
    Pascal Thubert (pthubert)
    
        
    Sent: jeudi 8 avril 2010 11:15
    
        
    To: JeongGil Ko (John); ROLL WG
    
        
    Subject: Re: [Roll] Proposal for Source Routing Header Forma=
t and
    
        
    SourceRoutingOperations
    
        
     
    
        
    Hi John:
    
        
     
    
        
    IPv6 already has a number of routing headers, in particular =
RH0,
    
        
        
    
        
            <=
/pre>
      
    
      
    though it is
    
      
      
    
      
          
    
      
    
        
    being deprecated for general use in the Internet.=

    
        
    And there are reasons why the fields in RH0/1 are there and =
we need to
    
        
    make sure we lose none of that. In particular a RH is recove=
rable, and
    
        
        
    
        
            <=
/pre>
      
    
      
    it is
    
      
      
    
      
          
    
      
    
        
    easy to spot the consumed entries.
    
        
     
    
        
    On top of this our new problems are:
    
        
    - make sure the RH stays within the RPL network (since it is=
 used
    
        
        
    
        
            <=
/pre>
      
    
      
    downwards
    
      
      
    
      
          
    
      
    
        
    that should be doable)
    
        
    - control the size (that probably means compress)=

    
        
     
    
        
    Cheers,
    
        
     
    
        
    Pascal
    
        
     
    
        
     
    
        
        
    
        
            <=
/pre>
        
    
          
    -----Original Message-----
    
          
    From: roll-bounces@ietf.org [mailto:ro=
ll-bounces@ietf.org] On Behalf
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    Of
    
        
        
    
        
            <=
/pre>
        
    
          
    JeongGil Ko (John)
    
          
    Sent: Wednesday, April 07, 2010 10:05 PM
    
          
    To: ROLL WG
    
          
    Subject: [Roll] Proposal for Source Routing Header Format =
and Source
    
          
    RoutingOperations
    
          
     
    
          
    Hi!
    
          
     
    
          
    Great to see all this discussions on downwards route estab=
lishment!
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    To
    
      
      
    
      
          
    
      
    
        
    add
    
        
        
    
        
            <=
/pre>
        
    
          
    one more to the conversations here is a proposal for sourc=
e routing
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    headers.
    
        
        
    
        
            <=
/pre>
        
    
          
    In non-storing mode (where only the root has individual pa=
th
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    information)
    
        
        
    
        
            <=
/pre>
        
    
          
    the root will be attaching a source routing header to the =
data
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    packet
    
      
      
    
      
          
    
      
    
        
    that a
    
        
        
    
        
            <=
/pre>
        
    
          
    source node wants to send to a specific destination. We ca=
n always
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    make the
    
        
        
    
        
            <=
/pre>
        
    
          
    header super fancy but in my opinion I think we only need =
two fields
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    in this
    
        
        
    
        
            <=
/pre>
        
    
          
    header and here it is! Feel free to break the stuff and ma=
ngle with
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    it
    
      
      
    
      
          
    
      
    
        
    so that it
    
        
        
    
        
            <=
/pre>
        
    
          
    looks great in the specs later on. FYI, this is the format=
 that I am
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    using in my
    
        
        
    
        
            <=
/pre>
        
    
          
    implementations so it does work :)
    
          
     
    
          
    1. Source Routing Header Format
    
          
     
    
          
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+
    
          
    |   NEntry (8 bits)   |
          
          
    
          
             &nbs=
p;
    
        
    
        
    |
    
        
        
    
        
            <=
/pre>
        
    
          
    +-+-+-+-+-+-+-+-+
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    +
    
        
        
    
        
            <=
/pre>
        
    
          
    |          &n=
bsp;           &nb=
sp;Source Route Entry (128*NEntry bits)
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    |
    
        
        
    
        
            <=
/pre>
        
    
          
    +
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    +
    
        
        
    
        
            <=
/pre>
        
    
          
    |
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    |
    
        
        
    
        
            <=
/pre>
        
    
          
          Figure 1. Proposed Source R=
outing Header Format; each line is
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    32
    
      
      
    
      
          
    
      
    
        
    bits:)
    
        
        
    
        
            <=
/pre>
        
    
          
    - NEntry: Indicates the number of 128 bit addresses that t=
he source
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    route
    
        
        
    
        
            <=
/pre>
        
    
          
    entry field is carrying.
    
          
     
    
          
    - Source Route Entry: List of 128 bit address that consist=
 the route
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    to the
    
        
        
    
        
            <=
/pre>
        
    
          
    destination. Here, the address of the node that is one hop=
 away from
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    the
    
        
        
    
        
            <=
/pre>
        
    
          
    *destination* comes first.
    
          
     
    
          
    2. Source Routing Packet Operations
    
          
     
    
          
    When source routing is initiated at a storing node (e.g., =
root of
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    the
    
      
      
    
      
          
    
      
    
        
    DODAG),
    
        
        
    
        
            <=
/pre>
        
    
          
    the header is attached on the data packet for the entire r=
oute
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    (i.e.,
    
      
      
    
      
          
    
      
    
        
    from
    
        
        
    
        
            <=
/pre>
        
    
          
    next hop node to the destination). This header is position=
ed in
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    front
    
      
      
    
      
          
    
      
    
        
    of the
    
        
        
    
        
            <=
/pre>
        
    
          
    user payload. When the next hop node receives a packet tha=
t is not
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    destined
    
        
        
    
        
            <=
/pre>
        
    
          
    to itself AND the network is NOT provisioned to be in 'sto=
ring mode'
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    then it
    
        
        
    
        
            <=
/pre>
        
    
          
    checks NEntry to find what the next hop is in the source r=
oute
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    entry.
    
      
      
    
      
          
    
      
    
        
    Since
    
        
        
    
        
            <=
/pre>
        
    
          
    the 'Source Route Entry' is ordered in 'farthest -> clo=
sest' (in
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    terms
    
      
      
    
      
          
    
      
    
        
    of hops)
    
        
        
    
        
            <=
/pre>
        
    
          
    order, a node can figure out what the next hop address is =
with only
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    the
    
        
        
    
        
            <=
/pre>
        
    
          
    NEntry value (since it already knows how big an ipv6 addre=
ss is).
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    After
    
        
        
    
        
            <=
/pre>
        
    
          
    collecting the next hop node's address, the node erases th=
is address
    
          
    element from the entry and decreases NEntry by one. This a=
ssures
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    that
    
      
      
    
      
          
    
      
    
        
    we
    
        
        
    
        
            <=
/pre>
        
    
          
    avoid the overhead of carrying the entire source route thr=
oughout
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    the
    
      
      
    
      
          
    
      
    
        
    data
    
        
        
    
        
            <=
/pre>
        
    
          
    path.
    
          
     
    
          
    The approach itself should be very simple and trivial for =
everyone
    
          
          
    
          
             &nbs=
p;
    
        
    
      
    
      
    to
    
      
      
    
      
          
    
      
    
        
    follow.
    
        
        
    
        
            <=
/pre>
        
    
          
    So we can start from here and build on!
    
          
     
    
          
    Thanks.
    
          
     
    
          
    -John
    
          
     
    
          
    ------
    
          
    JeongGil Ko (John)
    
          
    Ph.D. Student
    
          
    Department of Computer Science
    
          
    Johns Hopkins University
    
          
    http://www.cs.jhu.edu/~jgko
    
          
     
    
          
    _______________________________________________=

    
          
    Roll mailing list
    
          
    =
Roll@ietf.org
    
          
    https://www.ietf.org=
/mailman/listinfo/roll
    
          
          
    
          
             &nbs=
p;
    
        
    
        
    _______________________________________________
        
    Roll mailing list
    
        
    Ro=
ll@ietf.org
    
        
    https://www.ietf.org=
/mailman/listinfo/roll
    
        
        
    
        
            <=
/pre>
      
    
      
    _______________________________________________
      
    Roll mailing list
    
      
    Roll=
@ietf.org
    
      
    https://www.ietf.org=
/mailman/listinfo/roll
    
      
     
    
      
      
    
      
          
    
    
    
    
     
    
    
    ----------------------------------------------------------------=
--------
    
    
     
    
    
    _______________________________________________
    =

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

    



--------------010907050608030104010201--

--------------ms010806080200070808040405
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgxNTQyMjNaMCMGCSqGSIb3DQEJBDEWBBQitg44RvucC7iu0C0cLX92Peu59TBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAFaaM6gcm6TCThaKPuzhbcLARvMe1ULLUOiIig7cP3SF7oIZw5ElW5/NIheVkejEvHmB
h+keY6rPErUZlinAGGUTYDUrUQf06+MmOw162LdL+Y582q2OdRzgPxTH1KJAgrXHL+RkDz+u
n7KiKeK6s2xmS8/hKYxJxuKOQu9wJ1bdNeby0zKGiOqe2bvo/KOjgcqAkOfdh33cokJG4xpT
+o23k79xjy6/BQ7WUMKNF3Odee6fst2R01Z+t389a2YRbWe4yLYlmePxTLhUVnkjDMPDoLtF
X5K/Jz4eoI/bBF089fPOZATpQde9RRJG7kFEgGa+zUSSnp8aW29altQqcwgAAAAAAAA=
--------------ms010806080200070808040405--

From pal@cs.stanford.edu  Thu Apr  8 09:02:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466053A68CB for ; Thu,  8 Apr 2010 09:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level: 
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB6PrbFSYvIz for ; Thu,  8 Apr 2010 09:02:02 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7004C3A685D for ; Thu,  8 Apr 2010 09:02:00 -0700 (PDT)
Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzuB2-000694-MP; Thu, 08 Apr 2010 09:01:56 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <008801cad720$555a0a50$000e1ef0$@sturek@att.net>
Date: Thu, 8 Apr 2010 08:35:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net>
To: d.sturek@att.net
X-Mailer: Apple Mail (2.1077)
X-Scan-Signature: 5e15904e367bf57319d290d73554c551
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 16:02:03 -0000

On Apr 8, 2010, at 6:35 AM, Don Sturek wrote:

> I can't see why 6LowPAN (and specifically the HC draft) would concern =
itself
> with source routing.
>=20
> Surely source routing is a concern of ROLL (and not 6LowPAN).
>=20
> I don't see how ROLL completes its charter or addresses its =
requirements
> without adding source routing.


The basic guideline is that ROLL (or WGs in general) shouldn't replicate =
functionality or mechanisms that already exist, and that given WGs =
operate within a particular layer of the protocol stack.

In this particular case, the reason why 6lowpan was brought up is the =
RH0 header. In terms of charter, it's not ROLL's job to specify a way to =
compress the RH0 header. =46rom ROLL's perspective, there are IPv6 =
addresses and nothing less. 6lowpan, however, can specify ways in which =
IPv6 headers are compressed.=20

Does that make sense?

Phil=

From pal@cs.stanford.edu  Thu Apr  8 09:02:09 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925223A69A2 for ; Thu,  8 Apr 2010 09:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.483
X-Spam-Level: 
X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyFMFSEzcjoh for ; Thu,  8 Apr 2010 09:02:08 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C665A3A6810 for ; Thu,  8 Apr 2010 09:02:08 -0700 (PDT)
Received: from dnab4046d7.stanford.edu ([171.64.70.215]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NzuBB-000694-3o; Thu, 08 Apr 2010 09:02:05 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <7264daf93e85725bf0914cbb858394aa@mail.gmail.com>
Date: Thu, 8 Apr 2010 08:37:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0231C34B-FAE8-430D-9117-64FE2C1C13E4@cs.stanford.edu>
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>	 	<9317.1269879175@marajade.sandelman.ca>	 <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net>	<20100.1269887835@marajade.sandelman.ca>	 <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net>	<7375.1269904161@marajade.sandelman.ca>	 <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net>	<17256.1269912377@marajade.sandelman.ca>	 <4BB38ECC.5050604@eecs.berkeley.edu>	<5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu>	 <4BBCF150.4010701@eecs.berkeley.edu>	<706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu>	 <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com>
To: Yoav Ben-Yehezkel 
X-Mailer: Apple Mail (2.1077)
X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d
Cc: roll 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 16:02:09 -0000

On Apr 8, 2010, at 12:43 AM, Yoav Ben-Yehezkel wrote:

> Just a thought ...
>=20
> If a secured DIO will contain the trickle timer limit, the receiver of
> replayed DIOs can easily follow a specific node to see if it's a =
replaying
> attacker or not by sending out a DIS and expecting to see a reduced
> trickle timer limit on the DIO.

Suppression makes this a bit tricky. Or are you suggesting that a DIO =
contain the interval value as a field?


> Recording specific reduced trickle timers
> seems more difficult than regular DIOs. Another option is to specify =
the
> actual time difference between DIO transmissions (with some allowed
> margin). The response to DIS would most probably be much shorter than =
the
> time on the recorded message.

I see -- so the attacker is forced to replicate the timing as well. It =
seems like a node could detect when a replayed DIO has a longer time =
field than expected, but not a shorter one, as it could have lost the =
earlier packets.

>=20
> BTW - The DIS for credential re-check be trickle-timered as well, =
right?
> Otherwise, how do we approach the potential DIS storm problem with a
> credentials re-check, in case a replayed DIO will cause many other =
nodes
> to send DIS to recheck credentials with the replaying node.

Very good point. This is starting to become complicated, maybe there's =
an alternative, better way?

I propose we don't derail the security discussion by inflating one =
particular attack (I acknowledge I'm the one that brought it up, sorry). =
Instead, let's wait for the first protocol proposal draft before digging =
in further?

Phil=

From yoav@yitran.com  Thu Apr  8 09:23:29 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE8F3A693A for ; Thu,  8 Apr 2010 09:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.678
X-Spam-Level: 
X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQqkEA-8W7kV for ; Thu,  8 Apr 2010 09:23:25 -0700 (PDT)
Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 54E7F3A6977 for ; Thu,  8 Apr 2010 09:23:24 -0700 (PDT)
Received: from source ([72.14.220.159]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKS74C+JDj0yglYTDWmao8tjiHDg2PObIl@postini.com; Thu, 08 Apr 2010 09:23:21 PDT
Received: by fg-out-1718.google.com with SMTP id e12so854831fga.3 for ; Thu, 08 Apr 2010 09:23:20 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>	 	<9317.1269879175@marajade.sandelman.ca>	 <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net>	<20100.1269887835@marajade.sandelman.ca>	 <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net>	<7375.1269904161@marajade.sandelman.ca>	 <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net>	<17256.1269912377@marajade.sandelman.ca>	 <4BB38ECC.5050604@eecs.berkeley.edu>	<5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu>	 <4BBCF150.4010701@eecs.berkeley.edu>	<706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu>	 <4BBD03AF.9050803@eecs.berkeley.edu>   <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <0231C34B-FAE8-430D-9117-64FE2C1C13E4@cs.stanford.edu>
In-Reply-To: <0231C34B-FAE8-430D-9117-64FE2C1C13E4@cs.stanford.edu>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXNNqlb+pxjzSlS3StNpDBCsdKqQAAowrg
Date: Thu, 8 Apr 2010 19:23:20 +0300
Received: by 10.239.173.67 with SMTP id d3mr37419hbf.136.1270743800416; Thu,  08 Apr 2010 09:23:20 -0700 (PDT)
Message-ID: <6a07a42617b7c57df2dbfbcbcfa06d0f@mail.gmail.com>
To: Philip Levis 
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 16:23:29 -0000

Phil,

I agree with your final conclusion to postpone the digging.

Yoav


-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu]
Sent: Thursday, April 08, 2010 6:38 PM
To: Yoav Ben-Yehezkel
Cc: Kris Pister; roll
Subject: Re: [Roll] Mixed mode operation


On Apr 8, 2010, at 12:43 AM, Yoav Ben-Yehezkel wrote:

> Just a thought ...
>
> If a secured DIO will contain the trickle timer limit, the receiver of
> replayed DIOs can easily follow a specific node to see if it's a
replaying
> attacker or not by sending out a DIS and expecting to see a reduced
> trickle timer limit on the DIO.

Suppression makes this a bit tricky. Or are you suggesting that a DIO
contain the interval value as a field?


> Recording specific reduced trickle timers
> seems more difficult than regular DIOs. Another option is to specify the
> actual time difference between DIO transmissions (with some allowed
> margin). The response to DIS would most probably be much shorter than
the
> time on the recorded message.

I see -- so the attacker is forced to replicate the timing as well. It
seems like a node could detect when a replayed DIO has a longer time field
than expected, but not a shorter one, as it could have lost the earlier
packets.

>
> BTW - The DIS for credential re-check be trickle-timered as well, right?
> Otherwise, how do we approach the potential DIS storm problem with a
> credentials re-check, in case a replayed DIO will cause many other nodes
> to send DIS to recheck credentials with the replaying node.

Very good point. This is starting to become complicated, maybe there's an
alternative, better way?

I propose we don't derail the security discussion by inflating one
particular attack (I acknowledge I'm the one that brought it up, sorry).
Instead, let's wait for the first protocol proposal draft before digging
in further?

Phil

From d.sturek@att.net  Thu Apr  8 09:39:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D532E3A6978 for ; Thu,  8 Apr 2010 09:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.49
X-Spam-Level: 
X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+yOpqnPJvRu for ; Thu,  8 Apr 2010 09:39:38 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 2824B3A68F1 for ; Thu,  8 Apr 2010 09:39:37 -0700 (PDT)
Received: (qmail 35164 invoked from network); 8 Apr 2010 16:39:32 -0000
Received: from adsl-69-108-49-215.dsl.sndg02.pacbell.net (d.sturek@69.108.49.215 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 08 Apr 2010 09:39:31 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: uM9mjhkVM1mQcPkVb0v9NbtrtvfkL_MFVjtdqEBk_Byq.sAOSVeuDGY0NyzWKms.WXYtW3s859hNrS4jr4I_pwP7ZSIODST_iQfF3MP5FkzHHwcUeEe5mncFHBBA7tzibIzpFqWLTh4H0nSp3pdxhQfn8HY2D5qeLNBvLtH5tLqm6ZTVV5cYclKmXlKdXf4UsFx9hez.i5_aN0xB.1fi1ewvLPpPlGclVyFOHjBXl7fzUwn6VAmvTCMg9PG8cUkxkhTn_ISqfGSYmuNGw15MdzBJT3wlmF0iD33lcgKpYSO295Cwig--
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Philip Levis'" 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net> 
In-Reply-To: 
Date: Thu, 8 Apr 2010 09:39:30 -0700
Message-ID: <01e601cad73a$1016b8c0$30442a40$@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: AcrXNNEbHcu3WAf9R7mAdhEmkaVAUAAAZ5IA
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 16:39:38 -0000

Hi Phil,

It does make sense unless we see that ROLL creates different dependencies
with different MAC/PHYs.  

If we don't expect there to be dependencies on lower layer support for each
MAC/PHY then creating a dependency on RH0 support in 6LowPAN makes sense.
If instead each MAC/PHY will require similar changes then I still prefer to
use a MAC/PHY independent solution (like tags).

Don


-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu] 
Sent: Thursday, April 08, 2010 8:36 AM
To: d.sturek@att.net
Cc: daniel.gavelle@jennic.com; robert.cragie@gridmerge.com; roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations


On Apr 8, 2010, at 6:35 AM, Don Sturek wrote:

> I can't see why 6LowPAN (and specifically the HC draft) would concern
itself
> with source routing.
> 
> Surely source routing is a concern of ROLL (and not 6LowPAN).
> 
> I don't see how ROLL completes its charter or addresses its requirements
> without adding source routing.


The basic guideline is that ROLL (or WGs in general) shouldn't replicate
functionality or mechanisms that already exist, and that given WGs operate
within a particular layer of the protocol stack.

In this particular case, the reason why 6lowpan was brought up is the RH0
header. In terms of charter, it's not ROLL's job to specify a way to
compress the RH0 header. From ROLL's perspective, there are IPv6 addresses
and nothing less. 6lowpan, however, can specify ways in which IPv6 headers
are compressed. 

Does that make sense?

Phil=


From jeonggil.ko@gmail.com  Thu Apr  8 09:43:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80163A69A2 for ; Thu,  8 Apr 2010 09:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGX56sBQ7G9 for ; Thu,  8 Apr 2010 09:43:58 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 5DA413A6921 for ; Thu,  8 Apr 2010 09:43:58 -0700 (PDT)
Received: by pwj2 with SMTP id 2so2088660pwj.31 for ; Thu, 08 Apr 2010 09:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=p10T7nP+dHkcAEAhcoNg9kMeNtgFgBb39AVac/m87SA=; b=sAO/4GhxyGFrQokch67uEUjcqEItWmyNBjs46h/v8IHvlEdErzKmXkzHsIhML/0JRi yzb1Gy1+mK5Onrxw1beOqVJubQrgYKX6BhHSWvdCbS0mMBlsbDaON0PV+ywIdZRaYz1G JL5bT8Qho7N5v22D28rKphMqaWvs28Fzh7CnQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=rQ3Y3pTiBRUFhvbgqgmqH7Gh4CsTTx/inWmFGW02u7qytI6ptzgw8B2QNhQZG4QuEu 1EGS/UewBCgq88NrmUSDLl10I/pMQj+hKJtTB4k76LfX/21ChmlCvfSd2S6RYjohWkPF 9B2mNrpDZM18TMozDo8I4/K0N+kVE8FHuGfZI=
Received: by 10.140.251.19 with SMTP id y19mr570295rvh.161.1270745032557; Thu, 08 Apr 2010 09:43:52 -0700 (PDT)
Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id k17sm142641rvh.13.2010.04.08.09.43.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Apr 2010 09:43:51 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: "JeongGil Ko (John)" 
In-Reply-To: 
Date: Thu, 8 Apr 2010 09:43:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> 
To: "Popa, Daniel" 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Proposal for Source Routing Header Format and Source RoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 16:43:59 -0000

Hi!

We can't always assume that RPL will be running along with 6LoWPAN in =
all cases so we should be careful about this. Even the specs in some =
places say that 'if the implementation is using address compression like =
6LoWPAN then it can chose to do '. So it's not a must :) It =
will, however, be a nice optimization for those networks which do use =
6LoWPAN with RPL. Another positive aspect is that if we reduce the size =
of the neighbor status as well. So yes it is a nice optimization =
approach that is implementation specific.=20

I am happy that the discussions got going and I am not trying to argue =
that my simple header is the answer. With that said, I like Jonathan's =
approach of using tags/labels as well which can significantly decrease =
the overhead in a more 'general' way.=20

Thanks.

-John

On Apr 8, 2010, at 9:01 AM, Popa, Daniel wrote:

> Hi John,=20
>=20
>=20
> I like the principles of your proposal. I believe is something that
> should be adopted for source routing in ROLL.=20
>=20
> I was thinking at the following scenario: When nodes belong to the =
same
> subnet it can be interesting to extend your proposal with the =
capability
> of using some short addresses for forwarding (i.e., the MAC/Link Layer
> address from the "Host ID" field of an IPv6 address - w/r/t IPv6
> stateless address auto-configuration) rather than the full IPv6
> addresses.  =20
>=20
> What do you think?=20
>=20
> Thanks.=20
> Daniel=20
>=20
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of
> JeongGil Ko (John)
> Sent: mercredi 7 avril 2010 22:05
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>=20
> Hi!
>=20
> Great to see all this discussions on downwards route establishment! To
> add one more to the conversations here is a proposal for source =
routing
> headers. In non-storing mode (where only the root has individual path
> information) the root will be attaching a source routing header to the
> data packet that a source node wants to send to a specific =
destination.
> We can always make the header super fancy but in my opinion I think we
> only need two fields in this header and here it is! Feel free to break
> the stuff and mangle with it so that it looks great in the specs later
> on. FYI, this is the format that I am using in my implementations so =
it
> does work :)
>=20
> 1. Source Routing Header Format
>=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
> |
> +-+-+-+-+-+-+-+-+
> +
> |                       Source Route Entry (128*NEntry bits)
> |
> +
> +
> |
> |
>=20
>      Figure 1. Proposed Source Routing Header Format; each line is 32
> bits:)
>=20
> - NEntry: Indicates the number of 128 bit addresses that the source
> route entry field is carrying.
>=20
> - Source Route Entry: List of 128 bit address that consist the route =
to
> the destination. Here, the address of the node that is one hop away =
from
> the *destination* comes first.=20
>=20
> 2. Source Routing Packet Operations
>=20
> When source routing is initiated at a storing node (e.g., root of the
> DODAG), the header is attached on the data packet for the entire route
> (i.e., from next hop node to the destination). This header is =
positioned
> in front of the user payload. When the next hop node receives a packet
> that is not destined to itself AND the network is NOT provisioned to =
be
> in 'storing mode' then it checks NEntry to find what the next hop is =
in
> the source route entry. Since the 'Source Route Entry' is ordered in
> 'farthest -> closest' (in terms of hops) order, a node can figure out
> what the next hop address is with only the NEntry value (since it
> already knows how big an ipv6 address is). After collecting the next =
hop
> node's address, the node erases this address element from the entry =
and
> decreases NEntry by one. This assures that we avoid the overhead of
> carrying the entire source route throughout the data path.=20
>=20
> The approach itself should be very simple and trivial for everyone to
> follow. So we can start from here and build on!
>=20
> Thanks.
>=20
> -John
>=20
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From Daniel.Popa@itron.com  Thu Apr  8 09:59:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A481E3A6946 for ; Thu,  8 Apr 2010 09:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rKju4h1c0mt for ; Thu,  8 Apr 2010 09:59:43 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 305583A68DB for ; Thu,  8 Apr 2010 09:59:43 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Apr 2010 12:59:38 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing Header Format and Source RoutingOperations
Thread-Index: AcrXOq7DY4ybqcPfR/CHrYvOah3qjAAAOFNg
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>  
From: "Popa, Daniel" 
To: "JeongGil Ko (John)" 
Cc: ROLL WG 
Subject: Re: [Roll] Proposal for Source Routing Header Format and Source RoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 16:59:44 -0000

We may want to consider a tagging approach with the following (non
exhaustive) contexts:
=20
  - When RPL will be running along with 6lowPAN the tag/label will/can
be generated by the 6lowPAN HC.
  - when RPL will be running alone the tag/label will/can be generated
by the mechanism "To Be Defined".
  - When RPL will be running along with some adaptation layer (other
than 6lowPAN) the tag/label will/can be generated by the adaptation
layer.

So the system designers can chose whatever context fits their
requirements.=20

Thanks.
Daniel=20

-----Original Message-----
From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of
JeongGil Ko (John)
Sent: jeudi 8 avril 2010 18:44
To: Popa, Daniel
Cc: ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

We can't always assume that RPL will be running along with 6LoWPAN in
all cases so we should be careful about this. Even the specs in some
places say that 'if the implementation is using address compression like
6LoWPAN then it can chose to do '. So it's not a must :) It
will, however, be a nice optimization for those networks which do use
6LoWPAN with RPL. Another positive aspect is that if we reduce the size
of the neighbor status as well. So yes it is a nice optimization
approach that is implementation specific.=20

I am happy that the discussions got going and I am not trying to argue
that my simple header is the answer. With that said, I like Jonathan's
approach of using tags/labels as well which can significantly decrease
the overhead in a more 'general' way.=20

Thanks.

-John

On Apr 8, 2010, at 9:01 AM, Popa, Daniel wrote:

> Hi John,=20
>=20
>=20
> I like the principles of your proposal. I believe is something that
> should be adopted for source routing in ROLL.=20
>=20
> I was thinking at the following scenario: When nodes belong to the
same
> subnet it can be interesting to extend your proposal with the
capability
> of using some short addresses for forwarding (i.e., the MAC/Link Layer
> address from the "Host ID" field of an IPv6 address - w/r/t IPv6
> stateless address auto-configuration) rather than the full IPv6
> addresses.  =20
>=20
> What do you think?=20
>=20
> Thanks.=20
> Daniel=20
>=20
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> JeongGil Ko (John)
> Sent: mercredi 7 avril 2010 22:05
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>=20
> Hi!
>=20
> Great to see all this discussions on downwards route establishment! To
> add one more to the conversations here is a proposal for source
routing
> headers. In non-storing mode (where only the root has individual path
> information) the root will be attaching a source routing header to the
> data packet that a source node wants to send to a specific
destination.
> We can always make the header super fancy but in my opinion I think we
> only need two fields in this header and here it is! Feel free to break
> the stuff and mangle with it so that it looks great in the specs later
> on. FYI, this is the format that I am using in my implementations so
it
> does work :)
>=20
> 1. Source Routing Header Format
>=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
> |
> +-+-+-+-+-+-+-+-+
> +
> |                       Source Route Entry (128*NEntry bits)
> |
> +
> +
> |
> |
>=20
>      Figure 1. Proposed Source Routing Header Format; each line is 32
> bits:)
>=20
> - NEntry: Indicates the number of 128 bit addresses that the source
> route entry field is carrying.
>=20
> - Source Route Entry: List of 128 bit address that consist the route
to
> the destination. Here, the address of the node that is one hop away
from
> the *destination* comes first.=20
>=20
> 2. Source Routing Packet Operations
>=20
> When source routing is initiated at a storing node (e.g., root of the
> DODAG), the header is attached on the data packet for the entire route
> (i.e., from next hop node to the destination). This header is
positioned
> in front of the user payload. When the next hop node receives a packet
> that is not destined to itself AND the network is NOT provisioned to
be
> in 'storing mode' then it checks NEntry to find what the next hop is
in
> the source route entry. Since the 'Source Route Entry' is ordered in
> 'farthest -> closest' (in terms of hops) order, a node can figure out
> what the next hop address is with only the NEntry value (since it
> already knows how big an ipv6 address is). After collecting the next
hop
> node's address, the node erases this address element from the entry
and
> decreases NEntry by one. This assures that we avoid the overhead of
> carrying the entire source route throughout the data path.=20
>=20
> The approach itself should be very simple and trivial for everyone to
> follow. So we can start from here and build on!
>=20
> Thanks.
>=20
> -John
>=20
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From cabo@tzi.org  Thu Apr  8 10:56:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B633A68B6 for ; Thu,  8 Apr 2010 10:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XizLemoki-XN for ; Thu,  8 Apr 2010 10:56:02 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id F0A7F3A6894 for ; Thu,  8 Apr 2010 10:55:57 -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 o38CjJtf010338; Thu, 8 Apr 2010 14:45:19 +0200 (CEST)
Received: from [134.102.2.179] (unknown [134.102.2.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5F9A1E47C;  Thu,  8 Apr 2010 14:45:19 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <4BBDC39F.3040601@gridmerge.com>
Date: Thu, 8 Apr 2010 14:45:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <4BBDC39F.3040601@gridmerge.com>
To: robert.cragie@gridmerge.com
X-Mailer: Apple Mail (2.1078)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 17:56:03 -0000

On Apr 8, 2010, at 13:53, Robert Cragie wrote:

> Although I doubt this would go down well in the 6lowpan WG...

I can't speak for the 6LoWPAN WG, as I don't think we have discussed =
this in sufficient detail.
So far, we seem to have assumed that protocols designed for constrained =
networks would be frugal enough with their space requirements that we =
didn't have anything additional to do.  However, where IPv6 addresses =
are needed, this is hard to optimize at the higher level protocol alone.

I personally could imagine that 6LoWPAN could define a compression =
scheme specifically for protocols that contain lots of IPv6 addresses.  =
In a 6LoWPAN, it is quite likely that many of these would contain =
prefixes that are in the context, so the 16-byte addresses could be =
compressed down to 8.5 or even 2.5 bytes.
A decoder would not need to know anything about the formats where the =
addresses occur if the positions are indicated explicitly (which would =
cost maybe another byte per address plus a byte per frame); this makes =
sure we don't have to change the adaptation layer compression each time =
ROLL comes up with a new field.
6LoWPAN as it is has a limitation that would limit this scheme to =
compression within a fragment (HC-07 can compress only in the first =
fragment, but the scheme I'm talking about now could easily be extended =
to other fragments -- just not between fragments, but that should never =
be necessary with proper alignment).
This scheme could also get rid of MBZ fields.  We could even generalize =
it to an LZ77 (much simpler than it sounds), if we expect repetitions.=20=

The possibilities for adding more complexity are endless.

Yes, doing compression at the adaptation layer has the advantage that it =
is only done where it is needed.
The disadvantage may be that this introduces some complexity at a place =
where that may be expensive.

Gruesse, Carsten


From pister@eecs.berkeley.edu  Thu Apr  8 11:45:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448B23A6A15 for ; Thu,  8 Apr 2010 11:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mcnb+iVv1r1 for ; Thu,  8 Apr 2010 11:45:54 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id B5FDA3A691E for ; Thu,  8 Apr 2010 11:45:54 -0700 (PDT)
Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o38Ijk14027005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Apr 2010 11:45:48 -0700 (PDT)
Message-ID: <4BBE2455.6040700@eecs.berkeley.edu>
Date: Thu, 08 Apr 2010 11:45:41 -0700
From: Kris Pister 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Jonathan Hui 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>  <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
In-Reply-To: <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ROLL WG , "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 18:45:56 -0000

+1

Jonathan Hui wrote:
>
> To make the source route header compact, I favor the tag/label 
> approach over some other compaction mechanism that operates directly 
> on a list of IPv6 addresses.  Tags/labels can be made general enough 
> such that they can be derived in different ways.  Because the 
> tags/labels have scope local to each node, the mechanism is pretty 
> general already.  For those that are already managing unique 802.15.4 
> short addresses across a network, I can see that it is attractive to 
> utilize the short address directly and reduce state on devices.  In 
> other cases, it may be best for the node to dynamically assign 
> tags/labels for its neighbors.
>
> Either way, while the tag/label mechanism is simple, it is far more 
> flexible than an approach to compacting a list of IPv6 addresses.  And 
> note that the idea of using tags/labels is nothing new.  Of course we 
> will adapt the basic mechanism a bit (label distribution, headers 
> formats, etc), but the core ideas have been deployed in traditional IP 
> networks for quite some time.
>
> I reiterated a lot of what was already stated before by others, but 
> that is what I think.
>
> -- 
> Jonathan Hui
>
> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. Internet 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a pure
>> 802.15.4 world with short addresses, becomes a nightmare to define in a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could hide a
>> short address of the child - if it cares to do it that way - looks like
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can make
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to store
>> a state with the full information in memory, and then place an index of
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>> To: ROLL WG
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi Pascal, John,
>>>
>>> Since source routing explicitly gives forwarding instruction to each
>>> intermediate node, it can make sense to use only (MAC address based)
>> L2
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>> This brings two advantages:
>>> - avoid processing each transit packets up to L3.
>>> - use MAC addresses that - in ROLL environment - have inherently
>> shorter
>>> length than an IPv6 address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>> Pascal Thubert (pthubert)
>>> Sent: jeudi 8 avril 2010 11:15
>>> To: JeongGil Ko (John); ROLL WG
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi John:
>>>
>>> IPv6 already has a number of routing headers, in particular RH0,
>> though it is
>>> being deprecated for general use in the Internet.
>>> And there are reasons why the fields in RH0/1 are there and we need to
>>> make sure we lose none of that. In particular a RH is recoverable, and
>> it is
>>> easy to spot the consumed entries.
>>>
>>> On top of this our new problems are:
>>> - make sure the RH stays within the RPL network (since it is used
>> downwards
>>> that should be doable)
>>> - control the size (that probably means compress)
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>> Of
>>>> JeongGil Ko (John)
>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>> To: ROLL WG
>>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>>> RoutingOperations
>>>>
>>>> Hi!
>>>>
>>>> Great to see all this discussions on downwards route establishment!
>> To
>>> add
>>>> one more to the conversations here is a proposal for source routing
>>> headers.
>>>> In non-storing mode (where only the root has individual path
>>> information)
>>>> the root will be attaching a source routing header to the data
>> packet
>>> that a
>>>> source node wants to send to a specific destination. We can always
>>> make the
>>>> header super fancy but in my opinion I think we only need two fields
>>> in this
>>>> header and here it is! Feel free to break the stuff and mangle with
>> it
>>> so that it
>>>> looks great in the specs later on. FYI, this is the format that I am
>>> using in my
>>>> implementations so it does work :)
>>>>
>>>> 1. Source Routing Header Format
>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> |   NEntry (8 bits)   |
>>> |
>>>> +-+-+-+-+-+-+-+-+
>>> +
>>>> |                       Source Route Entry (128*NEntry bits)
>>> |
>>>> +
>>> +
>>>> |
>>> |
>>>>
>>>>      Figure 1. Proposed Source Routing Header Format; each line is
>> 32
>>> bits:)
>>>>
>>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>> route
>>>> entry field is carrying.
>>>>
>>>> - Source Route Entry: List of 128 bit address that consist the route
>>> to the
>>>> destination. Here, the address of the node that is one hop away from
>>> the
>>>> *destination* comes first.
>>>>
>>>> 2. Source Routing Packet Operations
>>>>
>>>> When source routing is initiated at a storing node (e.g., root of
>> the
>>> DODAG),
>>>> the header is attached on the data packet for the entire route
>> (i.e.,
>>> from
>>>> next hop node to the destination). This header is positioned in
>> front
>>> of the
>>>> user payload. When the next hop node receives a packet that is not
>>> destined
>>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>>> then it
>>>> checks NEntry to find what the next hop is in the source route
>> entry.
>>> Since
>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>> terms
>>> of hops)
>>>> order, a node can figure out what the next hop address is with only
>>> the
>>>> NEntry value (since it already knows how big an ipv6 address is).
>>> After
>>>> collecting the next hop node's address, the node erases this address
>>>> element from the entry and decreases NEntry by one. This assures
>> that
>>> we
>>>> avoid the overhead of carrying the entire source route throughout
>> the
>>> data
>>>> path.
>>>>
>>>> The approach itself should be very simple and trivial for everyone
>> to
>>> follow.
>>>> So we can start from here and build on!
>>>>
>>>> Thanks.
>>>>
>>>> -John
>>>>
>>>> ------
>>>> JeongGil Ko (John)
>>>> Ph.D. Student
>>>> Department of Computer Science
>>>> Johns Hopkins University
>>>> http://www.cs.jhu.edu/~jgko
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From pister@eecs.berkeley.edu  Thu Apr  8 11:57:33 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855EA3A6ABD for ; Thu,  8 Apr 2010 11:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level: 
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu34JtCf+dsY for ; Thu,  8 Apr 2010 11:57:32 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id AB59D3A6ABC for ; Thu,  8 Apr 2010 11:57:32 -0700 (PDT)
Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o38IvOLw027281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Apr 2010 11:57:25 -0700 (PDT)
Message-ID: <4BBE2713.1000200@eecs.berkeley.edu>
Date: Thu, 08 Apr 2010 11:57:23 -0700
From: Kris Pister 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Philip Levis 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080400090400060307020000"
Cc: 'roll' 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 18:57:33 -0000

This is a multi-part message in MIME format.
--------------080400090400060307020000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Philip Levis wrote:
> On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:
>   
>  
>   
>>   If C hears a DIO from P, then there is a lot of context in that message.  The mechanisms that we're proposing to use to protect DIOs will contain a nonce.  
>> If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce. 
>>     
>
> I don't think this is sufficient. I am an attacker. I hear and record DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.
>
>   
This attack won't work (see below).
>   
>> Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes? 
>>     
>
> Only if the DIO is sent as a unicast (uniquely tied to the DIS).
>   
That's exactly right Phil, and that's exactly what the spec says the 
parent must do.  "When a node receives a unicast DIS message, it MUST 
unicast a DIO message in response".  So the attacker can NOT just replay 
some DIO with nonce n+1 that it recorded.  Any DIO response must be 
unicast, with the address of both C and P, and have a nonce that C is 
happy with.
>   
>> Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation? 
>>     
>
> Yes, something like that. Could be something such that multicast DIOs have an incrementing sequence number, responds to unicast DISes are unicast and use the nonce in the DIS. Otherwise it becomes tricky, there are DoS attacks (node C sends a DIS with a nonce, I immediately send a DIS with another nonce, which nonce will P use).
>
>   
>> I guess if I were really paranoid I could make up a random address to put in the DIS.
>> So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy.
>>     
>
> I'm just worried about the basic case of an adversary replaying DIOs.
>
> Phil
Happy now?

ksjp

--------------080400090400060307020000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Philip Levis wrote:

    
  
    On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:
  
    
  
     
  
    
  
    
    
      If C hears a DIO from P, then there is a lot of context in that message.  The mechanisms that we're proposing to use to protect DIOs will contain a nonce.  
If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce. 
    
    
  
    
  
    
I don't think this is sufficient. I am an attacker. I hear and record DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.

  
    

    
This attack won't work (see below).
    

    
  
      
    
  
    
    
    Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes? 
    
    
  
    
  
    
Only if the DIO is sent as a unicast (uniquely tied to the DIS).
  
    

    
That's exactly right Phil, and that's exactly what the spec says the
parent must do.  "When a node receives a unicast DIS message, it MUST
unicast a DIO message in response".  So the attacker can NOT just
replay some DIO with nonce n+1 that it recorded.  Any DIO response must
be unicast, with the address of both C and P, and have a nonce that C
is happy with.
    

    
  
      
    
  
    
    
    Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation? 
    
    
  
    
  
    
Yes, something like that. Could be something such that multicast DIOs have an incrementing sequence number, responds to unicast DISes are unicast and use the nonce in the DIS. Otherwise it becomes tricky, there are DoS attacks (node C sends a DIS with a nonce, I immediately send a DIS with another nonce, which nonce will P use).

  
    
  
    
    
    I guess if I were really paranoid I could make up a random address to put in the DIS.
So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy.
    
    
  
    
  
    
I'm just worried about the basic case of an adversary replaying DIOs.

Phil
    

    
Happy now?
    

    
ksjp
    



--------------080400090400060307020000--

From pister@eecs.berkeley.edu  Thu Apr  8 11:59:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD983A688C for ; Thu,  8 Apr 2010 11:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8Y8SpamdRal for ; Thu,  8 Apr 2010 11:59:26 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id F02B53A687F for ; Thu,  8 Apr 2010 11:59:25 -0700 (PDT)
Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o38IxIbS027328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Apr 2010 11:59:19 -0700 (PDT)
Message-ID: <4BBE2785.60000@eecs.berkeley.edu>
Date: Thu, 08 Apr 2010 11:59:17 -0700
From: Kris Pister 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Yoav Ben-Yehezkel 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com>
In-Reply-To: <7264daf93e85725bf0914cbb858394aa@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060608030700080506080302"
Cc: roll 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 18:59:27 -0000

This is a multi-part message in MIME format.
--------------060608030700080506080302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yoav -
 "When a node receives a unicast DIS [...]   In this case the node 
SHOULD NOT reset the trickle timer".

ksjp

Yoav Ben-Yehezkel wrote:
> Just a thought ...
>
> If a secured DIO will contain the trickle timer limit, the receiver of
> replayed DIOs can easily follow a specific node to see if it's a replaying
> attacker or not by sending out a DIS and expecting to see a reduced
> trickle timer limit on the DIO. Recording specific reduced trickle timers
> seems more difficult than regular DIOs. Another option is to specify the
> actual time difference between DIO transmissions (with some allowed
> margin). The response to DIS would most probably be much shorter than the
> time on the recorded message.
>
> BTW - The DIS for credential re-check be trickle-timered as well, right?
> Otherwise, how do we approach the potential DIS storm problem with a
> credentials re-check, in case a replayed DIO will cause many other nodes
> to send DIS to recheck credentials with the replaying node.
>
> Regards,
> Yoav
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Philip Levis
> Sent: Thursday, April 08, 2010 4:21 AM
> To: Kris Pister
> Cc: 'roll'
> Subject: Re: [Roll] Mixed mode operation
>
>
> On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:
>
>   
>> My guess is that you're more concerned with replay though (yes?).
>>     
>
> Yes.
>
>   
>>   If C hears a DIO from P, then there is a lot of context in that
>>     
> message.  The mechanisms that we're proposing to use to protect DIOs will
> contain a nonce.
>   
>> If C is worried about the authenticity and timeliness of the DIO, then C
>>     
> can send a unicast DIS after hearing the DIO and make sure that the
> response has an incremented nonce.
>
> I don't think this is sufficient. I am an attacker. I hear and record DIOs
> n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.
>
>
>   
>> Assuming that the MIC is calculated over the headers (which include both
>>     
> P and C addresses) then we should be OK, yes?
>
> Only if the DIO is sent as a unicast (uniquely tied to the DIS).
>
>   
>> Or are you suggesting the need for a random number/challenge in the DIS
>>     
> that is also a part of the MIC calculation?
>
> Yes, something like that. Could be something such that multicast DIOs have
> an incrementing sequence number, responds to unicast DISes are unicast and
> use the nonce in the DIS. Otherwise it becomes tricky, there are DoS
> attacks (node C sends a DIS with a nonce, I immediately send a DIS with
> another nonce, which nonce will P use).
>
>   
>> I guess if I were really paranoid I could make up a random address to
>>     
> put in the DIS.
>   
>> So I think that we have the (proposed) *mechanisms* that we need to do
>>     
> what you want, and it will be up to implementers to decide on policy.
>
> I'm just worried about the basic case of an adversary replaying DIOs.
>
> Phil
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>   

--------------060608030700080506080302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Yoav - 
    
 "When a node receives a unicast DIS [...]   In this case the node
SHOULD NOT reset the trickle timer".
    

    
ksjp
    

    
Yoav Ben-Yehezkel wrote:

    
  
    Just a thought ...

If a secured DIO will contain the trickle timer limit, the receiver of
replayed DIOs can easily follow a specific node to see if it's a replaying
attacker or not by sending out a DIS and expecting to see a reduced
trickle timer limit on the DIO. Recording specific reduced trickle timers
seems more difficult than regular DIOs. Another option is to specify the
actual time difference between DIO transmissions (with some allowed
margin). The response to DIS would most probably be much shorter than the
time on the recorded message.

BTW - The DIS for credential re-check be trickle-timered as well, right?
Otherwise, how do we approach the potential DIS storm problem with a
credentials re-check, in case a replayed DIO will cause many other nodes
to send DIS to recheck credentials with the replaying node.

Regards,
Yoav


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Philip Levis
Sent: Thursday, April 08, 2010 4:21 AM
To: Kris Pister
Cc: 'roll'
Subject: Re: [Roll] Mixed mode operation


On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:

  
    
  
    
    
    My guess is that you're more concerned with replay though (yes?).
    
    
  
    
  
    
Yes.

  
    
  
    
    
      If C hears a DIO from P, then there is a lot of context in that
    
    
  
    
  
    message.  The mechanisms that we're proposing to use to protect DIOs will
contain a nonce.
  
    
  
    
    
    If C is worried about the authenticity and timeliness of the DIO, then C
    
    
  
    
  
    can send a unicast DIS after hearing the DIO and make sure that the
response has an incremented nonce.

I don't think this is sufficient. I am an attacker. I hear and record DIOs
n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.


  
    
  
    
    
    Assuming that the MIC is calculated over the headers (which include both
    
    
  
    
  
    P and C addresses) then we should be OK, yes?

Only if the DIO is sent as a unicast (uniquely tied to the DIS).

  
    
  
    
    
    Or are you suggesting the need for a random number/challenge in the DIS
    
    
  
    
  
    that is also a part of the MIC calculation?

Yes, something like that. Could be something such that multicast DIOs have
an incrementing sequence number, responds to unicast DISes are unicast and
use the nonce in the DIS. Otherwise it becomes tricky, there are DoS
attacks (node C sends a DIS with a nonce, I immediately send a DIS with
another nonce, which nonce will P use).

  
    
  
    
    
    I guess if I were really paranoid I could make up a random address to
    
    
  
    
  
    put in the DIS.
  
    
  
    
    
    So I think that we have the (proposed) *mechanisms* that we need to do
    
    
  
    
  
    what you want, and it will be up to implementers to decide on policy.

I'm just worried about the basic case of an adversary replaying DIOs.

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

    



--------------060608030700080506080302--

From yoav@yitran.com  Thu Apr  8 13:46:15 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D36D3A6A04 for ; Thu,  8 Apr 2010 13:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.081
X-Spam-Level: 
X-Spam-Status: No, score=-5.081 tagged_above=-999 required=5 tests=[AWL=0.896,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqehiEHqSiBO for ; Thu,  8 Apr 2010 13:46:14 -0700 (PDT)
Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 4BF393A6A7A for ; Thu,  8 Apr 2010 13:46:13 -0700 (PDT)
Received: from source ([209.85.220.214]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKS75AkZTjt1X2jQ8jLSVmIW5pMFilGrVC@postini.com; Thu, 08 Apr 2010 13:46:10 PDT
Received: by mail-fx0-f214.google.com with SMTP id 6so2669686fxm.17 for ; Thu, 08 Apr 2010 13:46:09 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca>  <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca>  <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca>  <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca>  <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu>  <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu>  <4BBD03AF.9050803@eecs.berkeley.edu>   <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu>
In-Reply-To: <4BBE2785.60000@eecs.berkeley.edu>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXTZ2ZPaQZekKfRcCflIQXrAM/YwADhzmA
Date: Thu, 8 Apr 2010 23:46:09 +0300
Received: by 10.239.188.67 with SMTP id o3mr55488hbh.209.1270759569263; Thu,  08 Apr 2010 13:46:09 -0700 (PDT)
Message-ID: <4d3d664ff702246cebfef17d696f073f@mail.gmail.com>
To: Kris Pister 
Content-Type: multipart/alternative; boundary=001485f5b142b88e2f0483bfc404
Cc: roll 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 20:46:15 -0000

--001485f5b142b88e2f0483bfc404
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

mmm=85. I actually thought that the unicast DIO response is immediate, and
that on top of that the next (unreset) trickle timer a DIO would be
multicast. Otherwise, an attacker can send out a DIS and that will cause
DIOs from all surrounding nodes to be unicast, i.e. not reach any other
nodes=85i.e. no DODAG



Thanks,

Yoav







*From:* Kris Pister [mailto:pister@eecs.berkeley.edu]
*Sent:* Thursday, April 08, 2010 9:59 PM
*To:* Yoav Ben-Yehezkel
*Cc:* Philip Levis; roll
*Subject:* Re: [Roll] Mixed mode operation



Yoav -
 "When a node receives a unicast DIS [...]   In this case the node SHOULD
NOT reset the trickle timer".

ksjp

Yoav Ben-Yehezkel wrote:

Just a thought ...



If a secured DIO will contain the trickle timer limit, the receiver of

replayed DIOs can easily follow a specific node to see if it's a replaying

attacker or not by sending out a DIS and expecting to see a reduced

trickle timer limit on the DIO. Recording specific reduced trickle timers

seems more difficult than regular DIOs. Another option is to specify the

actual time difference between DIO transmissions (with some allowed

margin). The response to DIS would most probably be much shorter than the

time on the recorded message.



BTW - The DIS for credential re-check be trickle-timered as well, right?

Otherwise, how do we approach the potential DIS storm problem with a

credentials re-check, in case a replayed DIO will cause many other nodes

to send DIS to recheck credentials with the replaying node.



Regards,

Yoav





-----Original Message-----

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

Philip Levis

Sent: Thursday, April 08, 2010 4:21 AM

To: Kris Pister

Cc: 'roll'

Subject: Re: [Roll] Mixed mode operation





On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:





My guess is that you're more concerned with replay though (yes?).





Yes.





  If C hears a DIO from P, then there is a lot of context in that



message.  The mechanisms that we're proposing to use to protect DIOs will

contain a nonce.



If C is worried about the authenticity and timeliness of the DIO, then C



can send a unicast DIS after hearing the DIO and make sure that the

response has an incremented nonce.



I don't think this is sufficient. I am an attacker. I hear and record DIOs

n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.







Assuming that the MIC is calculated over the headers (which include both



P and C addresses) then we should be OK, yes?



Only if the DIO is sent as a unicast (uniquely tied to the DIS).





Or are you suggesting the need for a random number/challenge in the DIS



that is also a part of the MIC calculation?



Yes, something like that. Could be something such that multicast DIOs have

an incrementing sequence number, responds to unicast DISes are unicast and

use the nonce in the DIS. Otherwise it becomes tricky, there are DoS

attacks (node C sends a DIS with a nonce, I immediately send a DIS with

another nonce, which nonce will P use).





I guess if I were really paranoid I could make up a random address to



put in the DIS.



So I think that we have the (proposed) *mechanisms* that we need to do



what you want, and it will be up to implementers to decide on policy.



I'm just worried about the basic case of an adversary replaying DIOs.



Phil

_______________________________________________

Roll mailing list

Roll@ietf.org

https://www.ietf.org/mailman/listinfo/roll

--001485f5b142b88e2f0483bfc404
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable













    


    mmm=85. I actually thought that the unicast DIO response is
immediate, and that on top of that the next (unreset) trickle timer a DIO w=
ould
be multicast. Otherwise, an attacker can send out a DIS and that will cause
DIOs from all surrounding nodes to be unicast, i.e. not reach any other nod=
es=85i.e.
no DODAG
    


    =A0
    


    Thanks,
    


    Yoav
    


    =A0
    


    =A0
    


    =A0
    




    =A0
    


    Yoav - 
    
=A0"When a node receives a unicast DIS [...]=A0=A0 In this case
the node SHOULD NOT reset the trickle timer".
    

    
ksjp
    

    
Yoav Ben-Yehezkel wrote: 
    


    Just a thought ...
    =A0
    If a secured DIO will conta=
in the trickle timer limit, the receiver of
    replayed DIOs can eas=
ily follow a specific node to see if it's a replaying
    attacke=
r or not by sending out a DIS and expecting to see a reduced
    

    trickle timer limit on the DIO. Recording specific reduced trickle tim=
ers
    seems more difficult than regular DIOs. Another option is to =
specify the
    actual time difference between DIO transmissions (wit=
h some allowed
    

    margin). The response to DIS would most probably be much shorter than =
the
    time on the recorded message.
    =A0
    BTW - T=
he DIS for credential re-check be trickle-timered as well, right?
    
Otherwise, how do we approach the potential DIS storm problem with a<=
pre>credentials re-check, in case a replayed DIO will cause many other node=
s
    to send DIS to recheck credentials with the replaying node.

    =A0
    Regards,
    Yoav
    =A0
    =A0
    -----Original Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
    

    Philip Levis
    Sent: Thursday, April 08, 2010 4:21 AM
    To: Kris Pister
    Cc: 'roll'
    Subject: Re: [Roll=
] Mixed mode operation
    =A0
    =A0
    On Apr 7, 2010=
, at 3:14 PM, Kris Pister wrote:
    

    =A0
    =A0 
    


    My guess is=
 that you're more concerned with replay though (yes?).
    =A0=A0=
=A0 
    


    =A0
    Yes.
    =A0
    =A0 
    


    =A0 If C he=
ars a DIO from P, then there is a lot of context in that
    =A0=A0 =
=A0
    


    message.=A0 The mechanisms that we're proposing to use to protect =
DIOs will
    contain a nonce.
    =A0 
    


    If C is wor=
ried about the authenticity and timeliness of the DIO, then C
    =A0=
=A0=A0 
    


    can send a unicast DIS after hearing the DIO and make sure that the
    response has an incremented nonce.
    =A0
    I don=
9;t think this is sufficient. I am an attacker. I hear and record DIOs

    n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.
    =A0
    =A0
    =A0 
    


    Assuming th=
at the MIC is calculated over the headers (which include both
    =A0=
=A0=A0 
    


    P and C addresses) then we should be OK, yes?
    =A0
    =
Only if the DIO is sent as a unicast (uniquely tied to the DIS).
    =
=A0
    =A0 
    


    Or are you =
suggesting the need for a random number/challenge in the DIS
    =A0=
=A0=A0 
    


    that is also a part of the MIC calculation?
    =A0
    Ye=
s, something like that. Could be something such that multicast DIOs have
    an incrementing sequence number, responds to unicast DISes are unic=
ast and
    

    use the nonce in the DIS. Otherwise it becomes tricky, there are DoS
    attacks (node C sends a DIS with a nonce, I immediately send a DIS=
 with
    another nonce, which nonce will P use).
    =A0
    

    =A0 
    


    I guess if =
I were really paranoid I could make up a random address to
    =A0=A0=
=A0 
    


    put in the DIS.
    =A0 
    


    So I think =
that we have the (proposed) *mechanisms* that we need to do
    =A0=
=A0=A0 
    


    what you want, and it will be up to implementers to decide on policy.<=
/pre>
    =A0
    I'm just worried about the basic case of an adv=
ersary replaying DIOs.
    =A0
    Phil
    _____________=
__________________________________
    

    Roll mailing list
    Roll@ietf=
.org
    h=
ttps://www.ietf.org/mailman/listinfo/roll
    =A0 
    





--001485f5b142b88e2f0483bfc404--

From robert.cragie@gridmerge.com  Thu Apr  8 14:06:20 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831573A6AF0 for ; Thu,  8 Apr 2010 14:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsB-COtKgTOW for ; Thu,  8 Apr 2010 14:06:18 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 7FFE83A6A93 for ; Thu,  8 Apr 2010 14:06:17 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1NzyvU-0002mA-AR for roll@ietf.org; Thu, 08 Apr 2010 22:06:13 +0100
Message-ID: <4BBE453E.7070508@gridmerge.com>
Date: Thu, 08 Apr 2010 22:06:06 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
In-Reply-To: <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080107020306010106070807"
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 21:06:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms080107020306010106070807
Content-Type: multipart/alternative;
 boundary="------------010206080301000907030506"

This is a multi-part message in MIME format.
--------------010206080301000907030506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

A couple of questions:

    * I presume the source route header using these tags/labels is an
      IPv6 extension header. What value for extension header type would
      this be? Would we need to specify a LOWPAN_NHC value for this so
      we can still use LOWPAN_NCH for UDP frames?
    * Can you point to where the 'core ideas have been deployed in
      traditional IP networks for quite some time'?


Thanks

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>
> To make the source route header compact, I favor the tag/label=20
> approach over some other compaction mechanism that operates directly=20
> on a list of IPv6 addresses.  Tags/labels can be made general enough=20
> such that they can be derived in different ways.  Because the=20
> tags/labels have scope local to each node, the mechanism is pretty=20
> general already.  For those that are already managing unique 802.15.4=20
> short addresses across a network, I can see that it is attractive to=20
> utilize the short address directly and reduce state on devices.  In=20
> other cases, it may be best for the node to dynamically assign=20
> tags/labels for its neighbors.
>
> Either way, while the tag/label mechanism is simple, it is far more=20
> flexible than an approach to compacting a list of IPv6 addresses.  And =

> note that the idea of using tags/labels is nothing new.  Of course we=20
> will adapt the basic mechanism a bit (label distribution, headers=20
> formats, etc), but the core ideas have been deployed in traditional IP =

> networks for quite some time.
>
> I reiterated a lot of what was already stated before by others, but=20
> that is what I think.
>
> --=20
> Jonathan Hui
>
> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. Internet=
 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a pure=

>> 802.15.4 world with short addresses, becomes a nightmare to define in =
a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could hide =
a
>> short address of the child - if it cares to do it that way - looks lik=
e
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can mak=
e
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to sto=
re
>> a state with the full information in memory, and then place an index o=
f
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>> To: ROLL WG
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi Pascal, John,
>>>
>>> Since source routing explicitly gives forwarding instruction to each
>>> intermediate node, it can make sense to use only (MAC address based)
>> L2
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>> This brings two advantages:
>>> - avoid processing each transit packets up to L3.
>>> - use MAC addresses that - in ROLL environment - have inherently
>> shorter
>>> length than an IPv6 address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>> Pascal Thubert (pthubert)
>>> Sent: jeudi 8 avril 2010 11:15
>>> To: JeongGil Ko (John); ROLL WG
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi John:
>>>
>>> IPv6 already has a number of routing headers, in particular RH0,
>> though it is
>>> being deprecated for general use in the Internet.
>>> And there are reasons why the fields in RH0/1 are there and we need t=
o
>>> make sure we lose none of that. In particular a RH is recoverable, an=
d
>> it is
>>> easy to spot the consumed entries.
>>>
>>> On top of this our new problems are:
>>> - make sure the RH stays within the RPL network (since it is used
>> downwards
>>> that should be doable)
>>> - control the size (that probably means compress)
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=

>>> Of
>>>> JeongGil Ko (John)
>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>> To: ROLL WG
>>>> Subject: [Roll] Proposal for Source Routing Header Format and Source=

>>>> RoutingOperations
>>>>
>>>> Hi!
>>>>
>>>> Great to see all this discussions on downwards route establishment!
>> To
>>> add
>>>> one more to the conversations here is a proposal for source routing
>>> headers.
>>>> In non-storing mode (where only the root has individual path
>>> information)
>>>> the root will be attaching a source routing header to the data
>> packet
>>> that a
>>>> source node wants to send to a specific destination. We can always
>>> make the
>>>> header super fancy but in my opinion I think we only need two fields=

>>> in this
>>>> header and here it is! Feel free to break the stuff and mangle with
>> it
>>> so that it
>>>> looks great in the specs later on. FYI, this is the format that I am=

>>> using in my
>>>> implementations so it does work :)
>>>>
>>>> 1. Source Routing Header Format
>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> |   NEntry (8 bits)   |
>>> |
>>>> +-+-+-+-+-+-+-+-+
>>> +
>>>> |                       Source Route Entry (128*NEntry bits)
>>> |
>>>> +
>>> +
>>>> |
>>> |
>>>>
>>>>      Figure 1. Proposed Source Routing Header Format; each line is
>> 32
>>> bits:)
>>>>
>>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>> route
>>>> entry field is carrying.
>>>>
>>>> - Source Route Entry: List of 128 bit address that consist the route=

>>> to the
>>>> destination. Here, the address of the node that is one hop away from=

>>> the
>>>> *destination* comes first.
>>>>
>>>> 2. Source Routing Packet Operations
>>>>
>>>> When source routing is initiated at a storing node (e.g., root of
>> the
>>> DODAG),
>>>> the header is attached on the data packet for the entire route
>> (i.e.,
>>> from
>>>> next hop node to the destination). This header is positioned in
>> front
>>> of the
>>>> user payload. When the next hop node receives a packet that is not
>>> destined
>>>> to itself AND the network is NOT provisioned to be in 'storing mode'=

>>> then it
>>>> checks NEntry to find what the next hop is in the source route
>> entry.
>>> Since
>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>> terms
>>> of hops)
>>>> order, a node can figure out what the next hop address is with only
>>> the
>>>> NEntry value (since it already knows how big an ipv6 address is).
>>> After
>>>> collecting the next hop node's address, the node erases this address=

>>>> element from the entry and decreases NEntry by one. This assures
>> that
>>> we
>>>> avoid the overhead of carrying the entire source route throughout
>> the
>>> data
>>>> path.
>>>>
>>>> The approach itself should be very simple and trivial for everyone
>> to
>>> follow.
>>>> So we can start from here and build on!
>>>>
>>>> Thanks.
>>>>
>>>> -John
>>>>
>>>> ------
>>>> JeongGil Ko (John)
>>>> Ph.D. Student
>>>> Department of Computer Science
>>>> Johns Hopkins University
>>>> http://www.cs.jhu.edu/~jgko
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

--------------010206080301000907030506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


Hi Jonathan,
    

    
A couple of questions:
    

      
  
    • I presume the source route header using these tags/labels is an
IPv6 extension header. What value for extension header type would this
be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames?
      • 
  
    • Can you point to where the 'core ideas have been deployed in
traditional IP networks for quite some time'?
      • 

    

    
Thanks
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote:


    
To make the source route header compact, I favor the tag/label approach
over some other compaction mechanism that operates directly on a list
of IPv6 addresses.  Tags/labels can be made general enough such that=

they can be derived in different ways.  Because the tags/labels have=

scope local to each node, the mechanism is pretty general already.  =
For
those that are already managing unique 802.15.4 short addresses across
a network, I can see that it is attractive to utilize the short address
directly and reduce state on devices.  In other cases, it may be bes=
t
for the node to dynamically assign tags/labels for its neighbors.
  
    
  
    
Either way, while the tag/label mechanism is simple, it is far more
flexible than an approach to compacting a list of IPv6 addresses.  A=
nd
note that the idea of using tags/labels is nothing new.  Of course w=
e
will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.
  
    
  
    
I reiterated a lot of what was already stated before by others, but
that is what I think.
  
    
  
    
--
  
    
Jonathan Hui
  
    
  
    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
  
    
  
    
  
    Hi Daniel:
    
    
    
    
Routers might have multiple interfaces of multiple MAC types. Internet
0
    
    
even has a MAC-less format.
    
    
So the result of you proposal, which looks like a great idea in a pure
    
    
802.15.4 world with short addresses, becomes a nightmare to define in a
    
    
fully generic fashion.
    
    
    
    
OTOH, a locally significant opaque tag in which the parent could hide a
    
    
short address of the child - if it cares to do it that way - looks like
    
    
a way more acceptable approach
    
    
    
    
So it seems to me that you can get what you want as long as we can make
    
    
the tag big enough for short addresses. When the tag is too small to
    
    
contain what the parent really needs, then the parent will have to
store
    
    
a state with the full information in memory, and then place an index of
    
    
some sort in the tag.
    
    
    
    
What do you think?
    
    
    
    
Pascal
    
    
    
    
    
    
    
    -----Original Message-----
      
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
      
    
Sent: Thursday, April 08, 2010 11:40 AM
      
    
To: ROLL WG
      
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
      
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and
      
    
SourceRoutingOperations
      
    
      
    
Hi Pascal, John,
      
    
      
    
Since source routing explicitly gives forwarding instruction to each
      
    
intermediate node, it can make sense to use only (MAC address based)
      
    
    
    
L2
    
    
    
    forwarding instead of (IPv6 address based)
L3 forwarding.
      
    
      
    
This brings two advantages:
      
    
- avoid processing each transit packets up to L3.
      
    
- use MAC addresses that - in ROLL environment - have inherently
      
    
    
    
shorter
    
    
    
    length than an IPv6 address.
      
    
      
    
Cheers,
      
    
Daniel
      
    
      
    
      
    
      
    
-----Original Message-----
      
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
      
    
    
    
Of
    
    
    
    Pascal Thubert (pthubert)
      
    
Sent: jeudi 8 avril 2010 11:15
      
    
To: JeongGil Ko (John); ROLL WG
      
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and
      
    
SourceRoutingOperations
      
    
      
    
Hi John:
      
    
      
    
IPv6 already has a number of routing headers, in particular RH0,
      
    
    
    
though it is
    
    
    
    being deprecated for general use in the
Internet.
      
    
And there are reasons why the fields in RH0/1 are there and we need to
      
    
make sure we lose none of that. In particular a RH is recoverable, and
      
    
    
    
it is
    
    
    
    easy to spot the consumed entries.
      
    
      
    
On top of this our new problems are:
      
    
- make sure the RH stays within the RPL network (since it is used
      
    
    
    
downwards
    
    
    
    that should be doable)
      
    
- control the size (that probably means compress)
      
    
      
    
Cheers,
      
    
      
    
Pascal
      
    
      
    
      
    
      
    -----Original Message-----
        
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
        
    
      
    
Of
      
    
      
    JeongGil Ko (John)
        
    
Sent: Wednesday, April 07, 2010 10:05 PM
        
    
To: ROLL WG
        
    
Subject: [Roll] Proposal for Source Routing Header Format and Source
        
    
RoutingOperations
        
    
        
    
Hi!
        
    
        
    
Great to see all this discussions on downwards route establishment!
        
    
      
    
    
    
To
    
    
    
    add
      
    
      
    one more to the conversations here is a
proposal for source routing
        
    
      
    
headers.
      
    
      
    In non-storing mode (where only the root
has individual path
        
    
      
    
information)
      
    
      
    the root will be attaching a source
routing header to the data
        
    
      
    
    
    
packet
    
    
    
    that a
      
    
      
    source node wants to send to a specific
destination. We can always
        
    
      
    
make the
      
    
      
    header super fancy but in my opinion I
think we only need two fields
        
    
      
    
in this
      
    
      
    header and here it is! Feel free to break=

the stuff and mangle with
        
    
      
    
    
    
it
    
    
    
    so that it
      
    
      
    looks great in the specs later on. FYI,
this is the format that I am
        
    
      
    
using in my
      
    
      
    implementations so it does work :)
        
    
        
    
1. Source Routing Header Format
        
    
        
    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    
|   NEntry (8 bits)   |
        
    
      
    
|
      
    
      
    +-+-+-+-+-+-+-+-+
        
    
      
    
+
      
    
      
    |      &nbs=
p;            =
;    Source Route
Entry (128*NEntry bits)
        
    
      
    
|
      
    
      
    +
        
    
      
    
+
      
    
      
    |
        
    
      
    
|
      
    
      

    
     Figure 1. Proposed Source Routing Header Format;=
 each line is
        
    
      
    
    
    
32
    
    
    
    bits:)
      
    
      

    
- NEntry: Indicates the number of 128 bit addresses that the source
        
    
      
    
route
      
    
      
    entry field is carrying.
        
    
        
    
- Source Route Entry: List of 128 bit address that consist the route
        
    
      
    
to the
      
    
      
    destination. Here, the address of the
node that is one hop away from
        
    
      
    
the
      
    
      
    *destination* comes first.
        
    
        
    
2. Source Routing Packet Operations
        
    
        
    
When source routing is initiated at a storing node (e.g., root of
        
    
      
    
    
    
the
    
    
    
    DODAG),
      
    
      
    the header is attached on the data packet=

for the entire route
        
    
      
    
    
    
(i.e.,
    
    
    
    from
      
    
      
    next hop node to the destination). This
header is positioned in
        
    
      
    
    
    
front
    
    
    
    of the
      
    
      
    user payload. When the next hop node
receives a packet that is not
        
    
      
    
destined
      
    
      
    to itself AND the network is NOT
provisioned to be in 'storing mode'
        
    
      
    
then it
      
    
      
    checks NEntry to find what the next hop
is in the source route
        
    
      
    
    
    
entry.
    
    
    
    Since
      
    
      
    the 'Source Route Entry' is ordered in
'farthest -> closest' (in
        
    
      
    
    
    
terms
    
    
    
    of hops)
      
    
      
    order, a node can figure out what the
next hop address is with only
        
    
      
    
the
      
    
      
    NEntry value (since it already knows how
big an ipv6 address is).
        
    
      
    
After
      
    
      
    collecting the next hop node's address,
the node erases this address
        
    
element from the entry and decreases NEntry by one. This assures
        
    
      
    
    
    
that
    
    
    
    we
      
    
      
    avoid the overhead of carrying the entire=

source route throughout
        
    
      
    
    
    
the
    
    
    
    data
      
    
      
    path.
        
    
        
    
The approach itself should be very simple and trivial for everyone
        
    
      
    
    
    
to
    
    
    
    follow.
      
    
      
    So we can start from here and build on!
        
    
        
    
Thanks.
        
    
        
    
-John
        
    
        
    
------
        
    
JeongGil Ko (John)
        
    
Ph.D. Student
        
    
Department of Computer Science
        
    
Johns Hopkins University
        
    
h=
ttp://www.cs.jhu.edu/~jgko
        
    
        
    
_______________________________________________
        
    
Roll mailing list
        
    
Roll@=
ietf.org
        
    
https://www.ietf.org/mailman/listinfo/roll
        
    
      
    
_______________________________________________
      
    
Roll mailing list
      
    
Roll@=
ietf.org
      
    
https://www.ietf.org/mailman/listinfo/roll
      
    
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
  
    
  
    
_______________________________________________
  
    
Roll mailing list
  
    
Roll@=
ietf.org
  
    
https://www.ietf.org/mailman/listinfo/roll
  
    
  
    

    



--------------010206080301000907030506--

--------------ms080107020306010106070807
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgyMTA2MDZaMCMGCSqGSIb3DQEJBDEWBBSrtUmTpL1zq6izyiady6iUAmKIxjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAEx7pACxdBeheS6GcaDlmMrHPd8XMvHo9AnoVrhaNaGzc2hu2H141hWVfZ4qaMs4P1Qh
VG6U/ZWYzS8EyixY2kJAzLFa6N/MtuI0lsxuRs8CchpbwEebL6hKNgGMbunJ1WXUylJtRSfv
ioxapbZvhwPVJ9hdTdDUrsjMxHfUnRfgXJdRpFAb950yasZnAeDhW/e12c/U7NEtq7I5XRqo
cK0yqllnoxypL1EXtQN0WSNItsB5s9wo26wbcH5jMsfKmydBECFoN/rVziBpfzMpaCqhUcXn
vGr0ElyO4AKY2wpB468jPnIzIJJ3lBWolIYRWbl0Ieg+pMLf7dnYeswKjeUAAAAAAAA=
--------------ms080107020306010106070807--

From jhui@archrock.com  Thu Apr  8 14:18:17 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2E33A6952 for ; Thu,  8 Apr 2010 14:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNah2fcVLfQA for ; Thu,  8 Apr 2010 14:18:08 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5CCCE3A6B12 for ; Thu,  8 Apr 2010 14:17:58 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 37680AF9B0; Thu,  8 Apr 2010 14:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhpFDvHNeFzd; Thu,  8 Apr 2010 14:17:51 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 75FB8AF913; Thu,  8 Apr 2010 14:17:51 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: robert.cragie@gridmerge.com
In-Reply-To: <4BBE453E.7070508@gridmerge.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 8 Apr 2010 14:17:50 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com> <4BBE453E.7070508@gridmerge.com>
X-Mailer: Apple Mail (2.936)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 08 Apr 2010 21:18:17 -0000

Hi Robert,

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:

> A couple of questions:
> 	=95 I presume the source route header using these tags/labels is =
an =20
> IPv6 extension header. What value for extension header type would =20
> this be? Would we need to specify a LOWPAN_NHC value for this so we =20=

> can still use LOWPAN_NCH for UDP frames?

We already have a draft requesting a new IPv6 Hop-by-Hop Option and =20
presented it at 6man in Anaheim.  The option is designed to carry RPL-=20=

specific information.  6lowpan-hc already has a LOWPAN_NHC value for =20
the IPv6 Hop-by-Hop Option header.

> 	=95 Can you point to where the 'core ideas have been deployed in =
=20
> traditional IP networks for quite some time'?

MPLS.  Again, I think the mechanisms will need to be adapted, but the =20=

core ideas are not new.

--
Jonathan Hui

> Thanks
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>
>>
>> To make the source route header compact, I favor the tag/label =20
>> approach over some other compaction mechanism that operates =20
>> directly on a list of IPv6 addresses.  Tags/labels can be made =20
>> general enough such that they can be derived in different ways.  =20
>> Because the tags/labels have scope local to each node, the =20
>> mechanism is pretty general already.  For those that are already =20
>> managing unique 802.15.4 short addresses across a network, I can =20
>> see that it is attractive to utilize the short address directly and =20=

>> reduce state on devices.  In other cases, it may be best for the =20
>> node to dynamically assign tags/labels for its neighbors.
>>
>> Either way, while the tag/label mechanism is simple, it is far more =20=

>> flexible than an approach to compacting a list of IPv6 addresses.  =20=

>> And note that the idea of using tags/labels is nothing new.  Of =20
>> course we will adapt the basic mechanism a bit (label distribution, =20=

>> headers formats, etc), but the core ideas have been deployed in =20
>> traditional IP networks for quite some time.
>>
>> I reiterated a lot of what was already stated before by others, but =20=

>> that is what I think.
>>
>> --=20
>> Jonathan Hui
>>
>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>> Hi Daniel:
>>>
>>> Routers might have multiple interfaces of multiple MAC types. =20
>>> Internet 0
>>> even has a MAC-less format.
>>> So the result of you proposal, which looks like a great idea in a =20=

>>> pure
>>> 802.15.4 world with short addresses, becomes a nightmare to define =20=

>>> in a
>>> fully generic fashion.
>>>
>>> OTOH, a locally significant opaque tag in which the parent could =20
>>> hide a
>>> short address of the child - if it cares to do it that way - looks =20=

>>> like
>>> a way more acceptable approach
>>>
>>> So it seems to me that you can get what you want as long as we can =20=

>>> make
>>> the tag big enough for short addresses. When the tag is too small to
>>> contain what the parent really needs, then the parent will have to =20=

>>> store
>>> a state with the full information in memory, and then place an =20
>>> index of
>>> some sort in the tag.
>>>
>>> What do you think?
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>>> Sent: Thursday, April 08, 2010 11:40 AM
>>>> To: ROLL WG
>>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi Pascal, John,
>>>>
>>>> Since source routing explicitly gives forwarding instruction to =20
>>>> each
>>>> intermediate node, it can make sense to use only (MAC address =20
>>>> based)
>>> L2
>>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>>
>>>> This brings two advantages:
>>>> - avoid processing each transit packets up to L3.
>>>> - use MAC addresses that - in ROLL environment - have inherently
>>> shorter
>>>> length than an IPv6 address.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>>>> Behalf
>>> Of
>>>> Pascal Thubert (pthubert)
>>>> Sent: jeudi 8 avril 2010 11:15
>>>> To: JeongGil Ko (John); ROLL WG
>>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi John:
>>>>
>>>> IPv6 already has a number of routing headers, in particular RH0,
>>> though it is
>>>> being deprecated for general use in the Internet.
>>>> And there are reasons why the fields in RH0/1 are there and we =20
>>>> need to
>>>> make sure we lose none of that. In particular a RH is =20
>>>> recoverable, and
>>> it is
>>>> easy to spot the consumed entries.
>>>>
>>>> On top of this our new problems are:
>>>> - make sure the RH stays within the RPL network (since it is used
>>> downwards
>>>> that should be doable)
>>>> - control the size (that probably means compress)
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>>>>> Behalf
>>>> Of
>>>>> JeongGil Ko (John)
>>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>>> To: ROLL WG
>>>>> Subject: [Roll] Proposal for Source Routing Header Format and =20
>>>>> Source
>>>>> RoutingOperations
>>>>>
>>>>> Hi!
>>>>>
>>>>> Great to see all this discussions on downwards route =20
>>>>> establishment!
>>> To
>>>> add
>>>>> one more to the conversations here is a proposal for source =20
>>>>> routing
>>>> headers.
>>>>> In non-storing mode (where only the root has individual path
>>>> information)
>>>>> the root will be attaching a source routing header to the data
>>> packet
>>>> that a
>>>>> source node wants to send to a specific destination. We can always
>>>> make the
>>>>> header super fancy but in my opinion I think we only need two =20
>>>>> fields
>>>> in this
>>>>> header and here it is! Feel free to break the stuff and mangle =20
>>>>> with
>>> it
>>>> so that it
>>>>> looks great in the specs later on. FYI, this is the format that =20=

>>>>> I am
>>>> using in my
>>>>> implementations so it does work :)
>>>>>
>>>>> 1. Source Routing Header Format
>>>>>
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> |   NEntry (8 bits)   |
>>>> |
>>>>> +-+-+-+-+-+-+-+-+
>>>> +
>>>>> |                       Source Route Entry (128*NEntry bits)
>>>> |
>>>>> +
>>>> +
>>>>> |
>>>> |
>>>>>
>>>>>      Figure 1. Proposed Source Routing Header Format; each line is
>>> 32
>>>> bits:)
>>>>>
>>>>> - NEntry: Indicates the number of 128 bit addresses that the =20
>>>>> source
>>>> route
>>>>> entry field is carrying.
>>>>>
>>>>> - Source Route Entry: List of 128 bit address that consist the =20
>>>>> route
>>>> to the
>>>>> destination. Here, the address of the node that is one hop away =20=

>>>>> from
>>>> the
>>>>> *destination* comes first.
>>>>>
>>>>> 2. Source Routing Packet Operations
>>>>>
>>>>> When source routing is initiated at a storing node (e.g., root of
>>> the
>>>> DODAG),
>>>>> the header is attached on the data packet for the entire route
>>> (i.e.,
>>>> from
>>>>> next hop node to the destination). This header is positioned in
>>> front
>>>> of the
>>>>> user payload. When the next hop node receives a packet that is not
>>>> destined
>>>>> to itself AND the network is NOT provisioned to be in 'storing =20
>>>>> mode'
>>>> then it
>>>>> checks NEntry to find what the next hop is in the source route
>>> entry.
>>>> Since
>>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>> terms
>>>> of hops)
>>>>> order, a node can figure out what the next hop address is with =20
>>>>> only
>>>> the
>>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>> After
>>>>> collecting the next hop node's address, the node erases this =20
>>>>> address
>>>>> element from the entry and decreases NEntry by one. This assures
>>> that
>>>> we
>>>>> avoid the overhead of carrying the entire source route throughout
>>> the
>>>> data
>>>>> path.
>>>>>
>>>>> The approach itself should be very simple and trivial for everyone
>>> to
>>>> follow.
>>>>> So we can start from here and build on!
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -John
>>>>>
>>>>> ------
>>>>> JeongGil Ko (John)
>>>>> Ph.D. Student
>>>>> Department of Computer Science
>>>>> Johns Hopkins University
>>>>> http://www.cs.jhu.edu/~jgko
>>>>>
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From robert.cragie@gridmerge.com  Thu Apr  8 14:34:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BCD3A68E1 for ; Thu,  8 Apr 2010 14:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level: 
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZcPmyJw1rfd for ; Thu,  8 Apr 2010 14:34:35 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 6A6D13A6870 for ; Thu,  8 Apr 2010 14:34:30 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1NzzMn-0001tD-GL; Thu, 08 Apr 2010 22:34:26 +0100
Message-ID: <4BBE4BDB.5070901@gridmerge.com>
Date: Thu, 08 Apr 2010 22:34:19 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jonathan Hui 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com> <4BBE453E.7070508@gridmerge.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070103020404060608060607"
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Apr 2010 21:34:37 -0000

This is a cryptographically signed message in MIME format.

--------------ms070103020404060608060607
Content-Type: multipart/alternative;
 boundary="------------060501020201050101010803"

This is a multi-part message in MIME format.
--------------060501020201050101010803
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>
> Hi Robert,
>
> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>
>> A couple of questions:
>>     =95 I presume the source route header using these tags/labels is a=
n=20
>> IPv6 extension header. What value for extension header type would=20
>> this be? Would we need to specify a LOWPAN_NHC value for this so we=20
>> can still use LOWPAN_NCH for UDP frames?
>
> We already have a draft requesting a new IPv6 Hop-by-Hop Option and=20
> presented it at 6man in Anaheim.  The option is designed to carry=20
> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value=20
> for the IPv6 Hop-by-Hop Option header.
>
>>     =95 Can you point to where the 'core ideas have been deployed in=20
>> traditional IP networks for quite some time'?
>
> MPLS.  Again, I think the mechanisms will need to be adapted, but the=20
> core ideas are not new.
>
> --=20
> Jonathan Hui
>
>> Thanks
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>>
>>>
>>> To make the source route header compact, I favor the tag/label=20
>>> approach over some other compaction mechanism that operates directly =

>>> on a list of IPv6 addresses.  Tags/labels can be made general enough =

>>> such that they can be derived in different ways.  Because the=20
>>> tags/labels have scope local to each node, the mechanism is pretty=20
>>> general already.  For those that are already managing unique=20
>>> 802.15.4 short addresses across a network, I can see that it is=20
>>> attractive to utilize the short address directly and reduce state on =

>>> devices.  In other cases, it may be best for the node to dynamically =

>>> assign tags/labels for its neighbors.
>>>
>>> Either way, while the tag/label mechanism is simple, it is far more=20
>>> flexible than an approach to compacting a list of IPv6 addresses. =20
>>> And note that the idea of using tags/labels is nothing new.  Of=20
>>> course we will adapt the basic mechanism a bit (label distribution,=20
>>> headers formats, etc), but the core ideas have been deployed in=20
>>> traditional IP networks for quite some time.
>>>
>>> I reiterated a lot of what was already stated before by others, but=20
>>> that is what I think.
>>>
>>> --=20
>>> Jonathan Hui
>>>
>>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>>
>>>> Hi Daniel:
>>>>
>>>> Routers might have multiple interfaces of multiple MAC types.=20
>>>> Internet 0
>>>> even has a MAC-less format.
>>>> So the result of you proposal, which looks like a great idea in a pu=
re
>>>> 802.15.4 world with short addresses, becomes a nightmare to define=20
>>>> in a
>>>> fully generic fashion.
>>>>
>>>> OTOH, a locally significant opaque tag in which the parent could=20
>>>> hide a
>>>> short address of the child - if it cares to do it that way - looks=20
>>>> like
>>>> a way more acceptable approach
>>>>
>>>> So it seems to me that you can get what you want as long as we can=20
>>>> make
>>>> the tag big enough for short addresses. When the tag is too small to=

>>>> contain what the parent really needs, then the parent will have to=20
>>>> store
>>>> a state with the full information in memory, and then place an=20
>>>> index of
>>>> some sort in the tag.
>>>>
>>>> What do you think?
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>>>> Sent: Thursday, April 08, 2010 11:40 AM
>>>>> To: ROLL WG
>>>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>>>> SourceRoutingOperations
>>>>>
>>>>> Hi Pascal, John,
>>>>>
>>>>> Since source routing explicitly gives forwarding instruction to eac=
h
>>>>> intermediate node, it can make sense to use only (MAC address based=
)
>>>> L2
>>>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>>>
>>>>> This brings two advantages:
>>>>> - avoid processing each transit packets up to L3.
>>>>> - use MAC addresses that - in ROLL environment - have inherently
>>>> shorter
>>>>> length than an IPv6 address.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behal=
f
>>>> Of
>>>>> Pascal Thubert (pthubert)
>>>>> Sent: jeudi 8 avril 2010 11:15
>>>>> To: JeongGil Ko (John); ROLL WG
>>>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>>>> SourceRoutingOperations
>>>>>
>>>>> Hi John:
>>>>>
>>>>> IPv6 already has a number of routing headers, in particular RH0,
>>>> though it is
>>>>> being deprecated for general use in the Internet.
>>>>> And there are reasons why the fields in RH0/1 are there and we=20
>>>>> need to
>>>>> make sure we lose none of that. In particular a RH is recoverable, =

>>>>> and
>>>> it is
>>>>> easy to spot the consumed entries.
>>>>>
>>>>> On top of this our new problems are:
>>>>> - make sure the RH stays within the RPL network (since it is used
>>>> downwards
>>>>> that should be doable)
>>>>> - control the size (that probably means compress)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Beha=
lf
>>>>> Of
>>>>>> JeongGil Ko (John)
>>>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>>>> To: ROLL WG
>>>>>> Subject: [Roll] Proposal for Source Routing Header Format and Sour=
ce
>>>>>> RoutingOperations
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> Great to see all this discussions on downwards route establishment=
!
>>>> To
>>>>> add
>>>>>> one more to the conversations here is a proposal for source routin=
g
>>>>> headers.
>>>>>> In non-storing mode (where only the root has individual path
>>>>> information)
>>>>>> the root will be attaching a source routing header to the data
>>>> packet
>>>>> that a
>>>>>> source node wants to send to a specific destination. We can always=

>>>>> make the
>>>>>> header super fancy but in my opinion I think we only need two fiel=
ds
>>>>> in this
>>>>>> header and here it is! Feel free to break the stuff and mangle wit=
h
>>>> it
>>>>> so that it
>>>>>> looks great in the specs later on. FYI, this is the format that I =
am
>>>>> using in my
>>>>>> implementations so it does work :)
>>>>>>
>>>>>> 1. Source Routing Header Format
>>>>>>
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>> |   NEntry (8 bits)   |
>>>>> |
>>>>>> +-+-+-+-+-+-+-+-+
>>>>> +
>>>>>> |                       Source Route Entry (128*NEntry bits)
>>>>> |
>>>>>> +
>>>>> +
>>>>>> |
>>>>> |
>>>>>>
>>>>>>      Figure 1. Proposed Source Routing Header Format; each line is=

>>>> 32
>>>>> bits:)
>>>>>>
>>>>>> - NEntry: Indicates the number of 128 bit addresses that the sourc=
e
>>>>> route
>>>>>> entry field is carrying.
>>>>>>
>>>>>> - Source Route Entry: List of 128 bit address that consist the rou=
te
>>>>> to the
>>>>>> destination. Here, the address of the node that is one hop away fr=
om
>>>>> the
>>>>>> *destination* comes first.
>>>>>>
>>>>>> 2. Source Routing Packet Operations
>>>>>>
>>>>>> When source routing is initiated at a storing node (e.g., root of
>>>> the
>>>>> DODAG),
>>>>>> the header is attached on the data packet for the entire route
>>>> (i.e.,
>>>>> from
>>>>>> next hop node to the destination). This header is positioned in
>>>> front
>>>>> of the
>>>>>> user payload. When the next hop node receives a packet that is not=

>>>>> destined
>>>>>> to itself AND the network is NOT provisioned to be in 'storing mod=
e'
>>>>> then it
>>>>>> checks NEntry to find what the next hop is in the source route
>>>> entry.
>>>>> Since
>>>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>>> terms
>>>>> of hops)
>>>>>> order, a node can figure out what the next hop address is with onl=
y
>>>>> the
>>>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>>> After
>>>>>> collecting the next hop node's address, the node erases this addre=
ss
>>>>>> element from the entry and decreases NEntry by one. This assures
>>>> that
>>>>> we
>>>>>> avoid the overhead of carrying the entire source route throughout
>>>> the
>>>>> data
>>>>>> path.
>>>>>>
>>>>>> The approach itself should be very simple and trivial for everyone=

>>>> to
>>>>> follow.
>>>>>> So we can start from here and build on!
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -John
>>>>>>
>>>>>> ------
>>>>>> JeongGil Ko (John)
>>>>>> Ph.D. Student
>>>>>> Department of Computer Science
>>>>>> Johns Hopkins University
>>>>>> http://www.cs.jhu.edu/~jgko
>>>>>>
>>>>>> _______________________________________________
>>>>>> Roll mailing list
>>>>>> Roll@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
>

--------------060501020201050101010803
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




  
  


OK, sounds good. End of topic as far as I am concerned. +1
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 08/04/2010 10:17 PM, Jonathan Hui wrote:


    
Hi Robert,
  
    
  
    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
  
    
  
    
  
    A couple of questions:
    
    
=A0=A0=A0=A0=95 I presume the source route header using these tags/labels=
 is an
IPv6 extension header. What value for extension header type would this
be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames?
    
    
  
    
  
    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.=A0 The option is designed to carry
RPL-specific information.=A0 6lowpan-hc already has a LOWPAN_NHC value
for the IPv6 Hop-by-Hop Option header.
  
    
  
    
  
    =A0=A0=A0=A0=95 Can you point to where the 'c=
ore ideas
have been deployed in traditional IP networks for quite some time'?
    
    
  
    
  
    
MPLS.=A0 Again, I think the mechanisms will need to be adapted, but the
core ideas are not new.
  
    
  
    
--
  
    
Jonathan Hui
  
    
  
    
  
    Thanks
    
    
    
    
Robert
    
    
Robert Cragie (Pacific Gas & Electric)
    
    
    
    
Gridmerge Ltd.
    
    
89 Greenfield Crescent,
    
    
Wakefield, WF4 4WA, UK
    
    
+44 (0) 1924 910888
    
    
http=
://www.gridmerge.com
    
    
    
    
    
    
On 08/04/2010 3:57 PM, Jonathan Hui wrote:
    
    
    

    
      
    
To make the source route header compact, I favor the tag/label approach
over some other compaction mechanism that operates directly on a list
of IPv6 addresses.=A0 Tags/labels can be made general enough such that
they can be derived in different ways.=A0 Because the tags/labels have
scope local to each node, the mechanism is pretty general already.=A0 For=

those that are already managing unique 802.15.4 short addresses across
a network, I can see that it is attractive to utilize the short address
directly and reduce state on devices.=A0 In other cases, it may be best
for the node to dynamically assign tags/labels for its neighbors.
      
    
      
    
Either way, while the tag/label mechanism is simple, it is far more
flexible than an approach to compacting a list of IPv6 addresses.=A0 And
note that the idea of using tags/labels is nothing new.=A0 Of course we
will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.
      
    
      
    
I reiterated a lot of what was already stated before by others, but
that is what I think.
      
    
      
    
--=A0
    
Jonathan Hui
      
    
      
    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
      
    
      
    
      
    Hi Daniel:
        
    
        
    
Routers might have multiple interfaces of multiple MAC types. Internet
0
        
    
even has a MAC-less format.
        
    
So the result of you proposal, which looks like a great idea in a pure
        
    
802.15.4 world with short addresses, becomes a nightmare to define in a
        
    
fully generic fashion.
        
    
        
    
OTOH, a locally significant opaque tag in which the parent could hide a
        
    
short address of the child - if it cares to do it that way - looks like
        
    
a way more acceptable approach
        
    
        
    
So it seems to me that you can get what you want as long as we can make
        
    
the tag big enough for short addresses. When the tag is too small to
        
    
contain what the parent really needs, then the parent will have to
store
        
    
a state with the full information in memory, and then place an index of
        
    
some sort in the tag.
        
    
        
    
What do you think?
        
    
        
    
Pascal
        
    
        
    
        
    
        
    -----Original Message-----
          
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
          
    
Sent: Thursday, April 08, 2010 11:40 AM
          
    
To: ROLL WG
          
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
          
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and
          
    
SourceRoutingOperations
          
    
          
    
Hi Pascal, John,
          
    
          
    
Since source routing explicitly gives forwarding instruction to each
          
    
intermediate node, it can make sense to use only (MAC address based)
          
    
        
    
L2
        
    
        
    forwarding instead of (IPv6 address
based) L3 forwarding.
          
    
          
    
This brings two advantages:
          
    
- avoid processing each transit packets up to L3.
          
    
- use MAC addresses that - in ROLL environment - have inherently
          
    
        
    
shorter
        
    
        
    length than an IPv6 address.
          
    
          
    
Cheers,
          
    
Daniel
          
    
          
    
          
    
          
    
-----Original Message-----
          
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
          
    
        
    
Of
        
    
        
    Pascal Thubert (pthubert)
          
    
Sent: jeudi 8 avril 2010 11:15
          
    
To: JeongGil Ko (John); ROLL WG
          
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and
          
    
SourceRoutingOperations
          
    
          
    
Hi John:
          
    
          
    
IPv6 already has a number of routing headers, in particular RH0,
          
    
        
    
though it is
        
    
        
    being deprecated for general use in the=

Internet.
          
    
And there are reasons why the fields in RH0/1 are there and we need to
          
    
make sure we lose none of that. In particular a RH is recoverable, and
          
    
        
    
it is
        
    
        
    easy to spot the consumed entries.
          
    
          
    
On top of this our new problems are:
          
    
- make sure the RH stays within the RPL network (since it is used
          
    
        
    
downwards
        
    
        
    that should be doable)
          
    
- control the size (that probably means compress)
          
    
          
    
Cheers,
          
    
          
    
Pascal
          
    
          
    
          
    
          
    -----Original Message-----
            
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
            
    
          
    
Of
          
    
          
    JeongGil Ko (John)
            
    
Sent: Wednesday, April 07, 2010 10:05 PM
            
    
To: ROLL WG
            
    
Subject: [Roll] Proposal for Source Routing Header Format and Source
            
    
RoutingOperations
            
    
            
    
Hi!
            
    
            
    
Great to see all this discussions on downwards route establishment!
            
    
          
    
        
    
To
        
    
        
    add
          
    
          
    one more to the conversations here is=

a proposal for source routing
            
    
          
    
headers.
          
    
          
    In non-storing mode (where only the
root has individual path
            
    
          
    
information)
          
    
          
    the root will be attaching a source
routing header to the data
            
    
          
    
        
    
packet
        
    
        
    that a
          
    
          
    source node wants to send to a
specific destination. We can always
            
    
          
    
make the
          
    
          
    header super fancy but in my opinion
I think we only need two fields
            
    
          
    
in this
          
    
          
    header and here it is! Feel free to
break the stuff and mangle with
            
    
          
    
        
    
it
        
    
        
    so that it
          
    
          
    looks great in the specs later on.
FYI, this is the format that I am
            
    
          
    
using in my
          
    
          
    implementations so it does work :)
            
    
            
    
1. Source Routing Header Format
            
    
            
    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            
    
|=A0=A0 NEntry (8 bits)=A0=A0 |
            
    
          
    
|
          
    
          
    +-+-+-+-+-+-+-+-+
            
    
          
    
+
          
    
          
    |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source Route
Entry (128*NEntry bits)
            
    
          
    
|
          
    
          
    +
            
    
          
    
+
          
    
          
    |
            
    
          
    
|
          
    
          

    
=A0=A0=A0=A0 Figure 1. Proposed Source Routing Header Format; each line i=
s
            
    
          
    
        
    
32
        
    
        
    bits:)
          
    
          

    
- NEntry: Indicates the number of 128 bit addresses that the source
            
    
          
    
route
          
    
          
    entry field is carrying.
            
    
            
    
- Source Route Entry: List of 128 bit address that consist the route
            
    
          
    
to the
          
    
          
    destination. Here, the address of the=

node that is one hop away from
            
    
          
    
the
          
    
          
    *destination* comes first.
            
    
            
    
2. Source Routing Packet Operations
            
    
            
    
When source routing is initiated at a storing node (e.g., root of
            
    
          
    
        
    
the
        
    
        
    DODAG),
          
    
          
    the header is attached on the data
packet for the entire route
            
    
          
    
        
    
(i.e.,
        
    
        
    from
          
    
          
    next hop node to the destination).
This header is positioned in
            
    
          
    
        
    
front
        
    
        
    of the
          
    
          
    user payload. When the next hop node
receives a packet that is not
            
    
          
    
destined
          
    
          
    to itself AND the network is NOT
provisioned to be in 'storing mode'
            
    
          
    
then it
          
    
          
    checks NEntry to find what the next
hop is in the source route
            
    
          
    
        
    
entry.
        
    
        
    Since
          
    
          
    the 'Source Route Entry' is ordered
in 'farthest -> closest' (in
            
    
          
    
        
    
terms
        
    
        
    of hops)
          
    
          
    order, a node can figure out what the=

next hop address is with only
            
    
          
    
the
          
    
          
    NEntry value (since it already knows
how big an ipv6 address is).
            
    
          
    
After
          
    
          
    collecting the next hop node's
address, the node erases this address
            
    
element from the entry and decreases NEntry by one. This assures
            
    
          
    
        
    
that
        
    
        
    we
          
    
          
    avoid the overhead of carrying the
entire source route throughout
            
    
          
    
        
    
the
        
    
        
    data
          
    
          
    path.
            
    
            
    
The approach itself should be very simple and trivial for everyone
            
    
          
    
        
    
to
        
    
        
    follow.
          
    
          
    So we can start from here and build
on!
            
    
            
    
Thanks.
            
    
            
    
-John
            
    
            
    
------
            
    
JeongGil Ko (John)
            
    
Ph.D. Student
            
    
Department of Computer Science
            
    
Johns Hopkins University
            
    
h=
ttp://www.cs.jhu.edu/~jgko
            
    
            
    
_______________________________________________
            
    
Roll mailing list
            
    
Roll@=
ietf.org
            
    
https://www.ietf.org/mailman/listinfo/roll
            
    
          
    
_______________________________________________
          
    
Roll mailing list
          
    
Roll@=
ietf.org
          
    
https://www.ietf.org/mailman/listinfo/roll
          
    
        
    
_______________________________________________
        
    
Roll mailing list
        
    
Roll@=
ietf.org
        
    
https://www.ietf.org/mailman/listinfo/roll
        
    
      
    
      
    
_______________________________________________
      
    
Roll mailing list
      
    
Roll@=
ietf.org
      
    
https://www.ietf.org/mailman/listinfo/roll
      
    
      
    
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
  
    
  
    
  
    

    



--------------060501020201050101010803--

--------------ms070103020404060608060607
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDgyMTM0MTlaMCMGCSqGSIb3DQEJBDEWBBT8ozU+LTkvYz4zz/rm5lHvVxRejzBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBADM5QOdwVaUIAACI8j29AMFP2vOlF5SYqDlJwWFyK7xnDl2tvferJeqjGr3NKfDdEIUR
tHIaTbCVSDCE0AS8UyhnmqFPj5PosSL/XlklalOsTOaf55G2pHWY92ett4ISyRNsgNKWuNSv
Pa7dpFf/zRzy0iazFSFfEtOj4ATvJpzpZGrrXr6NZR2OmgnRU8DTHvDoHP+QrmFriwYJYvRI
vFUQInOaljWQTLoYjpLV+/9XH0nG379DXDjJKzxjO4kWBm7Ty6aZMxMGOCQjahLZTQdrKFLC
VI+OF17fxd0ENRCE0p8CkwuAdWZZ07L1nufDVu9pGuYvgrQjNoVZv6rJMlAAAAAAAAA=
--------------ms070103020404060608060607--

From mcr@sandelman.ca  Thu Apr  8 17:52:01 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C993A6AC8 for ; Thu,  8 Apr 2010 17:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.553
X-Spam-Level: 
X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fwbx7cFHLp9 for ; Thu,  8 Apr 2010 17:52:00 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 393D13A6852 for ; Thu,  8 Apr 2010 17:52:00 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 8A16034715; Thu,  8 Apr 2010 20:51:56 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id CC75D4E799; Thu,  8 Apr 2010 20:51:54 -0400 (EDT)
From: Michael Richardson 
To: Yoav Ben-Yehezkel 
In-Reply-To: <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu> <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Date: Thu, 08 Apr 2010 20:51:54 -0400
Message-ID: <6643.1270774314@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 00:52:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Yoav" == Yoav Ben-Yehezkel  writes:
    Yoav> mmm…. I actually thought that the unicast DIO response is
    Yoav> immediate, and that on top of that the next (unreset) trickle
    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
    Yoav> send out a DIS and that will cause DIOs from all surrounding
    Yoav> nodes to be unicast, i.e. not reach any other nodes…i.e. no
    Yoav> DODAG

The threat model that you describe, where an attacker has access to send
original data into the link appears to be out of scope from what I have
read.

It seems that we will assume the layer-2 has sufficient protection that
an external attacker can not do what you describe.  

It has also been asserted that some layer-2s provide for replay
protection within the protocol, although this is far from universal. 
We will have to address that at layer-3 for layer-2s that do not supply
it.

So I don't think the attack you describe (which has worried me in the
past), can be done by intruder.  

Note it can still occur by compromising an existing node, but I'm not
sure that this is in scope.  I'd like us to think about these kind of
attacks, at least from the point of view of defending against
egreviously misconfigured nodes, rather than intentionally malicious ones.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS756KICLcPvd0N1lAQLmQwgAmu4RUojVJic5RdCk0s304Nu65ii9/hCU
as7QyIfiyeN+AmarKwF26FIMmoKsN6lpNdBHUsw/oK8EEb0rE5EVdwIIkChNwqBE
WK0Ay4GF/mi+Rwso/bOxjXqDbMOBQ3UklMO/MiuY+yWrSZW9znUdpUynC48sAUEZ
9rKIP20aVchngVcv9PFRKEEOAwlvvUy3bNzTMcEd2c8EPLpkU3OcL1pQBv41It58
2uZ4H2Di//yY6FvZFJe/ynTaDhsFgb6fz/TKBRYQQ6GkQTBJs+16tUFY94f9KmM4
fy/xK8VND5OA8vcPF54u6lUUP1OHbDznqWk5kSR0jRyfMwAG9PR5cg==
=WKmP
-----END PGP SIGNATURE-----

From pal@cs.stanford.edu  Thu Apr  8 19:11:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9933A6842 for ; Thu,  8 Apr 2010 19:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoy86NJ5VN76 for ; Thu,  8 Apr 2010 19:11:36 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 749663A659C for ; Thu,  8 Apr 2010 19:11:36 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O03gy-0002qr-QZ; Thu, 08 Apr 2010 19:11:33 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=utf-8
From: Philip Levis 
In-Reply-To: <6643.1270774314@marajade.sandelman.ca>
Date: Thu, 8 Apr 2010 19:11:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu>
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu> <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> <6643.1270774314@marajade.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1077)
X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a
Cc: roll WG 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 02:11:38 -0000

On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
>>>>>> "Yoav" =3D=3D Yoav Ben-Yehezkel  writes:
>    Yoav> mmm=E2=88=91. I actually thought that the unicast DIO =
response is
>    Yoav> immediate, and that on top of that the next (unreset) trickle
>    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
>    Yoav> send out a DIS and that will cause DIOs from all surrounding
>    Yoav> nodes to be unicast, i.e. not reach any other nodes=E2=88=91i.e=
. no
>    Yoav> DODAG
>=20
> The threat model that you describe, where an attacker has access to =
send
> original data into the link appears to be out of scope from what I =
have
> read.
>=20
> It seems that we will assume the layer-2 has sufficient protection =
that
> an external attacker can not do what you describe. =20

Michael,

Unfortunately, we can't assume that layer-2 has any protection. This is =
the operating assumption behind all of the security work. Note that the =
possible presence of layer 2 mechanisms are why RPL's mechanisms are =
intended to be options: in networks with sufficient layer 2 protection =
they can be left out, but they can be used in those that need it.

Phil



From yoav@yitran.com  Thu Apr  8 21:52:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588F93A6AE7 for ; Thu,  8 Apr 2010 21:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.529
X-Spam-Level: 
X-Spam-Status: No, score=-5.529 tagged_above=-999 required=5 tests=[AWL=0.448,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfH07Nxlur3B for ; Thu,  8 Apr 2010 21:52:25 -0700 (PDT)
Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id E34D23A67BD for ; Thu,  8 Apr 2010 21:52:24 -0700 (PDT)
Received: from source ([209.85.220.213]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKS76yhRxcyczq34/55cciKHvz/XMBi1FQ@postini.com; Thu, 08 Apr 2010 21:52:22 PDT
Received: by fxm5 with SMTP id 5so2662024fxm.29 for ; Thu, 08 Apr 2010 21:52:20 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>	 	<9317.1269879175@marajade.sandelman.ca>	 <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net>	<20100.1269887835@marajade.sandelman.ca>	 <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net>	<7375.1269904161@marajade.sandelman.ca>	 <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net>	<17256.1269912377@marajade.sandelman.ca>	 <4BB38ECC.5050604@eecs.berkeley.edu>	<5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu>	 <4BBCF150.4010701@eecs.berkeley.edu>	<706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu>	 <4BBD03AF.9050803@eecs.berkeley.edu>		 <7264daf93e85725bf0914cbb858394aa@mail.gmail.com>	<4BBE2785.60000@eecs.berkeley.edu>	 <4d3d664ff702246cebfef17d696f073f@mail.gmail.com>	<6643.1270774314@marajade.sandelman.ca> <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu>
In-Reply-To: <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXif5GzkMhOUESQmmURNr0MTLGHwAFiDaw
Date: Fri, 9 Apr 2010 07:52:19 +0300
Received: by 10.239.180.198 with SMTP id j6mr111551hbg.163.1270788739445; Thu,  08 Apr 2010 21:52:19 -0700 (PDT)
Message-ID: 
To: Philip Levis , Michael Richardson 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: roll WG 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 04:52:26 -0000

Even if what Michael saying is true, I still do not understand what's the
meaning of not responding immediately to a unicast DIS by a unicast DIO.
There is no congestion in this case. If there is no reset of the trickle
timer, the node sending the DIS might as well not send it, and wait till th=
e
node sending the DIO will send out the multicast DIO. DIS seems meaningless
in this context to me.

What am I missing here?

Yoav



-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Philip Levis
Sent: Friday, April 09, 2010 5:11 AM
To: Michael Richardson
Cc: roll WG
Subject: Re: [Roll] Mixed mode operation


On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Yoav" =3D=3D Yoav Ben-Yehezkel  writes:
>    Yoav> mmm=E2=88=91. I actually thought that the unicast DIO response i=
s
>    Yoav> immediate, and that on top of that the next (unreset) trickle
>    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
>    Yoav> send out a DIS and that will cause DIOs from all surrounding
>    Yoav> nodes to be unicast, i.e. not reach any other nodes=E2=88=91i.e.=
 no
>    Yoav> DODAG
>
> The threat model that you describe, where an attacker has access to send
> original data into the link appears to be out of scope from what I have
> read.
>
> It seems that we will assume the layer-2 has sufficient protection that
> an external attacker can not do what you describe.

Michael,

Unfortunately, we can't assume that layer-2 has any protection. This is the
operating assumption behind all of the security work. Note that the possibl=
e
presence of layer 2 mechanisms are why RPL's mechanisms are intended to be
options: in networks with sufficient layer 2 protection they can be left
out, but they can be used in those that need it.

Phil


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

From pthubert@cisco.com  Fri Apr  9 01:36:00 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A793A6944 for ; Fri,  9 Apr 2010 01:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.159
X-Spam-Level: 
X-Spam-Status: No, score=-9.159 tagged_above=-999 required=5 tests=[AWL=1.439,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4enCNM8RHXeE for ; Fri,  9 Apr 2010 01:35:47 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 975463A67FD for ; Fri,  9 Apr 2010 01:35:47 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEaEvkurR7Hu/2dsb2JhbACBPZl+cZ97mSyFCQQ
X-IronPort-AV: E=Sophos;i="4.52,176,1270425600";  d="scan'208,217";a="112809056"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2010 08:35:43 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o398Zbuh003065; Fri, 9 Apr 2010 08:35:43 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 9 Apr 2010 10:35:42 +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_01CAD7BF.A3B7928F"
Date: Fri, 9 Apr 2010 10:35:36 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
In-Reply-To: <4BBE4BDB.5070901@gridmerge.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQ
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com> <4BBE4BDB.5070901@gridmerge.com>
From: "Pascal Thubert (pthubert)" 
To: , "Jonathan Hui" 
X-OriginalArrivalTime: 09 Apr 2010 08:35:42.0247 (UTC) FILETIME=[A3EDB370:01CAD7BF]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 08:36:00 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7BF.A3B7928F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I read this as a consensus to use tags J If anyone disagree please speak
up now!

=20

There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM's HPR (pure source route), Cisco's tag switching
and MPLS. More often than not, a combination of the 2 models is used so
that tags can be both swapped and stacked.=20

=20

-          In pure switching, there's only one tag in the packet. A tag
can be locally significant, in which case it has to be swapped as the
packet progresses. For RPL, it means that a node uses as many tags as it
has children that use it has DAO targets in its subdag.

=20

-          In the pure source route model, tags are stacked in an
ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent.=20

=20

It also appears that the 2 tagging models map quite well with the DAO
models we have in RPL since the split that we decided with issue #26.
The fact that the combination of the 2 models is possible in the real
world today gives us a hint that we are not closing the door to the
mixed model in the future.

=20

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by
the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need
to dig further)

-          Tag content and size (people have asked for at least 2 octets
to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of
addresses? What about the tag swapping  case, RH as well?)

=20

Advice?

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

=20

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20


Hi Robert,=20

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20




A couple of questions:=20
    * I presume the source route header using these tags/labels is an
IPv6 extension header. What value for extension header type would this
be? Would we need to specify a LOWPAN_NHC value for this so we can still
use LOWPAN_NCH for UDP frames?=20


We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for
the IPv6 Hop-by-Hop Option header.=20




    * Can you point to where the 'core ideas have been deployed in
traditional IP networks for quite some time'?=20


MPLS.  Again, I think the mechanisms will need to be adapted, but the
core ideas are not new.=20

--=20
Jonathan Hui=20




Thanks=20

Robert=20
Robert Cragie (Pacific Gas & Electric)=20

Gridmerge Ltd.=20
89 Greenfield Crescent,=20
Wakefield, WF4 4WA, UK=20
+44 (0) 1924 910888=20
http://www.gridmerge.com=20


On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20





To make the source route header compact, I favor the tag/label approach
over some other compaction mechanism that operates directly on a list of
IPv6 addresses.  Tags/labels can be made general enough such that they
can be derived in different ways.  Because the tags/labels have scope
local to each node, the mechanism is pretty general already.  For those
that are already managing unique 802.15.4 short addresses across a
network, I can see that it is attractive to utilize the short address
directly and reduce state on devices.  In other cases, it may be best
for the node to dynamically assign tags/labels for its neighbors.=20

Either way, while the tag/label mechanism is simple, it is far more
flexible than an approach to compacting a list of IPv6 addresses.  And
note that the idea of using tags/labels is nothing new.  Of course we
will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.=20

I reiterated a lot of what was already stated before by others, but that
is what I think.=20

--=20
Jonathan Hui=20

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20




Hi Daniel:=20

Routers might have multiple interfaces of multiple MAC types. Internet 0

even has a MAC-less format.=20
So the result of you proposal, which looks like a great idea in a pure=20
802.15.4 world with short addresses, becomes a nightmare to define in a=20
fully generic fashion.=20

OTOH, a locally significant opaque tag in which the parent could hide a=20
short address of the child - if it cares to do it that way - looks like=20
a way more acceptable approach=20

So it seems to me that you can get what you want as long as we can make=20
the tag big enough for short addresses. When the tag is too small to=20
contain what the parent really needs, then the parent will have to store

a state with the full information in memory, and then place an index of=20
some sort in the tag.=20

What do you think?=20

Pascal=20





-----Original Message-----=20
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
Sent: Thursday, April 08, 2010 11:40 AM=20
To: ROLL WG=20
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
Subject: RE: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi Pascal, John,=20

Since source routing explicitly gives forwarding instruction to each=20
intermediate node, it can make sense to use only (MAC address based)=20

L2=20



forwarding instead of (IPv6 address based) L3 forwarding.=20

This brings two advantages:=20
- avoid processing each transit packets up to L3.=20
- use MAC addresses that - in ROLL environment - have inherently=20

shorter=20



length than an IPv6 address.=20

Cheers,=20
Daniel=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20



Pascal Thubert (pthubert)=20
Sent: jeudi 8 avril 2010 11:15=20
To: JeongGil Ko (John); ROLL WG=20
Subject: Re: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi John:=20

IPv6 already has a number of routing headers, in particular RH0,=20

though it is=20



being deprecated for general use in the Internet.=20
And there are reasons why the fields in RH0/1 are there and we need to=20
make sure we lose none of that. In particular a RH is recoverable, and=20

it is=20



easy to spot the consumed entries.=20

On top of this our new problems are:=20
- make sure the RH stays within the RPL network (since it is used=20

downwards=20



that should be doable)=20
- control the size (that probably means compress)=20

Cheers,=20

Pascal=20





-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20



JeongGil Ko (John)=20
Sent: Wednesday, April 07, 2010 10:05 PM=20
To: ROLL WG=20
Subject: [Roll] Proposal for Source Routing Header Format and Source=20
RoutingOperations=20

Hi!=20

Great to see all this discussions on downwards route establishment!=20

To=20



add=20



one more to the conversations here is a proposal for source routing=20

headers.=20



In non-storing mode (where only the root has individual path=20

information)=20



the root will be attaching a source routing header to the data=20

packet=20



that a=20



source node wants to send to a specific destination. We can always=20

make the=20



header super fancy but in my opinion I think we only need two fields=20

in this=20



header and here it is! Feel free to break the stuff and mangle with=20

it=20



so that it=20



looks great in the specs later on. FYI, this is the format that I am=20

using in my=20



implementations so it does work :)=20

1. Source Routing Header Format=20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|   NEntry (8 bits)   |=20

|=20



+-+-+-+-+-+-+-+-+=20

+=20



|                       Source Route Entry (128*NEntry bits)=20

|=20



+=20

+=20



|=20

|=20




     Figure 1. Proposed Source Routing Header Format; each line is=20

32=20



bits:)=20




- NEntry: Indicates the number of 128 bit addresses that the source=20

route=20



entry field is carrying.=20

- Source Route Entry: List of 128 bit address that consist the route=20

to the=20



destination. Here, the address of the node that is one hop away from=20

the=20



*destination* comes first.=20

2. Source Routing Packet Operations=20

When source routing is initiated at a storing node (e.g., root of=20

the=20



DODAG),=20



the header is attached on the data packet for the entire route=20

(i.e.,=20



from=20



next hop node to the destination). This header is positioned in=20

front=20



of the=20



user payload. When the next hop node receives a packet that is not=20

destined=20



to itself AND the network is NOT provisioned to be in 'storing mode'=20

then it=20



checks NEntry to find what the next hop is in the source route=20

entry.=20



Since=20



the 'Source Route Entry' is ordered in 'farthest -> closest' (in=20

terms=20



of hops)=20



order, a node can figure out what the next hop address is with only=20

the=20



NEntry value (since it already knows how big an ipv6 address is).=20

After=20



collecting the next hop node's address, the node erases this address=20
element from the entry and decreases NEntry by one. This assures=20

that=20



we=20



avoid the overhead of carrying the entire source route throughout=20

the=20



data=20



path.=20

The approach itself should be very simple and trivial for everyone=20

to=20



follow.=20



So we can start from here and build on!=20

Thanks.=20

-John=20

------=20
JeongGil Ko (John)=20
Ph.D. Student=20
Department of Computer Science=20
Johns Hopkins University=20
http://www.cs.jhu.edu/~jgko=20

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

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

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


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

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

=20


------_=_NextPart_001_01CAD7BF.A3B7928F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    I read this as a consensus to use tags J If anyone disagree please speak up now!
     
    There have been plenty iterations/versions of tagging since Frame =
Relay (pure switching), IBM’s HPR (pure source route), =
Cisco’s tag switching and MPLS. More often than not, a combination =
of the 2 models is used so that tags can be both swapped and stacked. =

     
    -          =
In pure switching, there’s only one tag in the packet. A tag =
can be locally significant, in which case it has to be swapped as the =
packet progresses. For RPL, it means that a node uses as many tags as it =
has children that use it has DAO targets in its =
subdag.
     
    -          =
In the pure source route model, tags are stacked in an ordered list =
that forms a strict routing header. A tag can be locally significant to =
the interpreter and is consumed (marked or removed) as the packet =
progresses. For RPL, it means that a node uses as many tags as it has =
children that use this node as DAO parent. 
     
    It also appears that the 2 tagging models map quite well with the DAO =
models we have in RPL since the split that we decided with issue #26. =
The fact that the combination of the 2 models is possible in the real =
world today gives us a hint that we are not closing the door to the =
mixed model in the future.
     
    The next step I wish to agree upon:
    -          =
Use locally significant tags which implies tag assignment by the node =
that uses it later and tag swapping for the stateful =
case.
    -          =
Tag distribution in DAO (there are options there that we need to dig =
further)
    -          =
Tag content and size (people have asked for at least 2 octets to fit =
15.4 short addresses, do we need some control field as =
well?)
    -          =
RH format (inherit RH0 fields with labels instead of addresses? What =
about the tag swapping  case, RH as well?)
     
    Advice?
     
    Pascal
     
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of Robert Cragie
    Sent: Thursday, April 08, 2010 11:34 =
PM
    To: Jonathan Hui
    Cc: =
roll@ietf.org
    Subject: Re: [Roll] Proposal for Source Routing =
Header Formatand =
SourceRoutingOperations
     
    OK, sounds =
good. End of topic as far as I am concerned. =
+1

    Robert
    Robert Cragie =
(Pacific Gas & Electric)
    Gridmerge Ltd.
    89 =
Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 =
910888
    http://www.gridmerge.com

    On 08/04/2010 10:17 PM, Jonathan Hui =
wrote: 

    Hi Robert, 

    On Apr =
8, 2010, at 2:06 PM, Robert Cragie wrote: 


    A couple of questions: =

        • I presume the source route header =
using these tags/labels is an IPv6 extension header. What value for =
extension header type would this be? Would we need to specify a =
LOWPAN_NHC value for this so we can still use LOWPAN_NCH for UDP frames? =


    We already have a draft =
requesting a new IPv6 Hop-by-Hop Option and presented it at 6man in =
Anaheim.  The option is designed to carry RPL-specific =
information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6 Hop-by-Hop Option header. 


        • Can you point to where =
the 'core ideas have been deployed in traditional IP networks for quite =
some time'? 

    MPLS.  Again, I =
think the mechanisms will need to be adapted, but the core ideas are not =
new. 

    -- 
    Jonathan Hui 


    Thanks 

    Robert 
    Robert Cragie (Pacific Gas =
& Electric) 

    Gridmerge Ltd. 
    89 Greenfield Crescent, =

    Wakefield, WF4 4WA, UK 
    +44 (0) 1924 910888 
    http://www.gridmerge.com =



    On 08/04/2010 3:57 PM, Jonathan Hui wrote: =




    To make the source =
route header compact, I favor the tag/label approach over some other =
compaction mechanism that operates directly on a list of IPv6 =
addresses.  Tags/labels can be made general enough such that they =
can be derived in different ways.  Because the tags/labels have =
scope local to each node, the mechanism is pretty general already.  =
For those that are already managing unique 802.15.4 short addresses =
across a network, I can see that it is attractive to utilize the short =
address directly and reduce state on devices.  In other cases, it =
may be best for the node to dynamically assign tags/labels for its =
neighbors. 

    Either way, while the tag/label mechanism is simple, =
it is far more flexible than an approach to compacting a list of IPv6 =
addresses.  And note that the idea of using tags/labels is nothing =
new.  Of course we will adapt the basic mechanism a bit (label =
distribution, headers formats, etc), but the core ideas have been =
deployed in traditional IP networks for quite some time. 

    I =
reiterated a lot of what was already stated before by others, but that =
is what I think. 

    -- 
    Jonathan Hui 

    On Apr 8, =
2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =



    Hi Daniel: =


    Routers might have multiple interfaces of multiple MAC types. =
Internet 0 
    even has a MAC-less format. 
    So the result of you =
proposal, which looks like a great idea in a pure 
    802.15.4 world =
with short addresses, becomes a nightmare to define in a 
    fully =
generic fashion. 

    OTOH, a locally significant opaque tag in which =
the parent could hide a 
    short address of the child - if it cares to =
do it that way - looks like 
    a way more acceptable approach =


    So it seems to me that you can get what you want as long as we =
can make 
    the tag big enough for short addresses. When the tag is too =
small to 
    contain what the parent really needs, then the parent will =
have to store 
    a state with the full information in memory, and then =
place an index of 
    some sort in the tag. 

    What do you think? =


    Pascal 



    -----Original Message----- 
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com] =

    Sent: Thursday, April 08, 2010 11:40 AM 
    To: ROLL WG 
    Cc: =
Pascal Thubert (pthubert); JeongGil Ko (John) 
    Subject: RE: [Roll] =
Proposal for Source Routing Header Format and =

    SourceRoutingOperations 

    Hi Pascal, John, 

    Since =
source routing explicitly gives forwarding instruction to each =

    intermediate node, it can make sense to use only (MAC address based) =

    L2 

    forwarding instead of (IPv6 address based) L3 =
forwarding. 

    This brings two advantages: 
    - avoid processing =
each transit packets up to L3. 
    - use MAC addresses that - in ROLL =
environment - have inherently 
    shorter 

    length than an IPv6 address. 

    Cheers, =

    Daniel 



    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf 
    Of =


    Pascal Thubert (pthubert) =

    Sent: jeudi 8 avril 2010 11:15 
    To: JeongGil Ko (John); ROLL WG =

    Subject: Re: [Roll] Proposal for Source Routing Header Format and =

    SourceRoutingOperations 

    Hi John: 

    IPv6 already has a =
number of routing headers, in particular RH0, 
    though it is 

    being deprecated for general use in the Internet. =

    And there are reasons why the fields in RH0/1 are there and we need =
to 
    make sure we lose none of that. In particular a RH is =
recoverable, and 
    it is =


    easy to spot the consumed =
entries. 

    On top of this our new problems are: 
    - make sure =
the RH stays within the RPL network (since it is used 
    downwards 

    that should be doable) 
    - control the size (that =
probably means compress) 

    Cheers, 

    Pascal =




    -----Original =
Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf 
    Of =


    JeongGil Ko (John) 
    Sent: =
Wednesday, April 07, 2010 10:05 PM 
    To: ROLL WG 
    Subject: [Roll] =
Proposal for Source Routing Header Format and Source =

    RoutingOperations 

    Hi! 

    Great to see all this =
discussions on downwards route establishment! 
    To 

    add =


    one more to the =
conversations here is a proposal for source routing 
    headers. 

    In non-storing mode (where only the root has =
individual path 
    information) =


    the root will be attaching a =
source routing header to the data 
    packet 

    that a 

    source node wants to send to a specific destination. =
We can always 
    make the =


    header super fancy but in my =
opinion I think we only need two fields 
    in this 

    header and here it is! Feel free to break the stuff =
and mangle with 
    it =


    so that it =


    looks great in the specs =
later on. FYI, this is the format that I am 
    using in my 

    implementations so it does work :) 

    1. Source =
Routing Header Format =


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
 
    |   NEntry (8 bits)   | 
    | 

    +-+-+-+-+-+-+-+-+ 
    + 

    |         =
            &=
nbsp; Source Route Entry (128*NEntry bits) 
    | 

    + =

    + 

    | 
    | =



         =
Figure 1. Proposed Source Routing Header Format; each line is =

    32 

    bits:) 


    - NEntry: Indicates the number of 128 bit =
addresses that the source 
    route =


    entry field is carrying. =


    - Source Route Entry: List of 128 bit address that consist the =
route 
    to the =


    destination. Here, the =
address of the node that is one hop away from 
    the 

    *destination* comes first. 

    2. Source Routing =
Packet Operations 

    When source routing is initiated at a storing =
node (e.g., root of 
    the =


    DODAG), =


    the header is attached on =
the data packet for the entire route 
    (i.e., 

    from 

    next =
hop node to the destination). This header is positioned in =

    front 

    of the 

    user payload. When the next hop node receives a packet =
that is not 
    destined =


    to itself AND the network is =
NOT provisioned to be in 'storing mode' 
    then it 

    checks NEntry to find what the next hop is in the =
source route 
    entry. =


    Since =


    the 'Source Route Entry' is =
ordered in 'farthest -> closest' (in 
    terms 

    of =
hops) 

    order, a node can =
figure out what the next hop address is with only 
    the 

    NEntry =
value (since it already knows how big an ipv6 address is). =

    After 

    collecting the next hop node's address, the node =
erases this address 
    element from the entry and decreases NEntry by =
one. This assures 
    that =


    we 

    avoid the overhead of carrying the entire source route =
throughout 
    the =


    data =


    path. 

    The approach =
itself should be very simple and trivial for everyone 
    to 

    follow. =


    So we can start from here =
and build on! 

    Thanks. 

    -John 

    ------ 
    JeongGil =
Ko (John) 
    Ph.D. Student 
    Department of Computer Science 
    Johns =
Hopkins University 
    http://www.cs.jhu.edu/~jgko =


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

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

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

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

    Roll mailing list 
    Roll@ietf.org 
    https://www.ietf.org/=
mailman/listinfo/roll 
     
    
------_=_NextPart_001_01CAD7BF.A3B7928F--

From abr@sdesigns.dk  Fri Apr  9 01:43:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EF63A69F5 for ; Fri,  9 Apr 2010 01:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.663
X-Spam-Level: 
X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.935,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8rNt2Qr-ebc for ; Fri,  9 Apr 2010 01:43:16 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 4AA9D3A69E7 for ; Fri,  9 Apr 2010 01:42:43 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7C0.9C4B5FF8"
Date: Fri, 9 Apr 2010 10:42:38 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQA=
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
From: "Anders Brandt" 
To: "Pascal Thubert (pthubert)" , , "Jonathan Hui" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 08:43:27 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7C0.9C4B5FF8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Admitted, I have been absent from this thread; trying to catch up on
others...
=20
> I read this as a consensus to use tags J If anyone disagree please
speak up now!

I have to comment respectfully but loudly that this may at best some
sort of rough concensus..
=20
In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.
For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to
16 bits and a common subnet.
=20
Just my $0.05
=20
=20



________________________________

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Pascal Thubert (pthubert)
	Sent: Friday, April 09, 2010 10:36
	To: robert.cragie@gridmerge.com; Jonathan Hui
	Cc: roll@ietf.org
	Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
=09
=09

	I read this as a consensus to use tags J If anyone disagree
please speak up now!

	=20

	There have been plenty iterations/versions of tagging since
Frame Relay (pure switching), IBM's HPR (pure source route), Cisco's tag
switching and MPLS. More often than not, a combination of the 2 models
is used so that tags can be both swapped and stacked.=20

	=20

	-          In pure switching, there's only one tag in the
packet. A tag can be locally significant, in which case it has to be
swapped as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use it has DAO targets in its subdag.

	=20

	-          In the pure source route model, tags are stacked in
an ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent.=20

	=20

	It also appears that the 2 tagging models map quite well with
the DAO models we have in RPL since the split that we decided with issue
#26. The fact that the combination of the 2 models is possible in the
real world today gives us a hint that we are not closing the door to the
mixed model in the future.

	=20

	The next step I wish to agree upon:

	-          Use locally significant tags which implies tag
assignment by the node that uses it later and tag swapping for the
stateful case.

	-          Tag distribution in DAO (there are options there that
we need to dig further)

	-          Tag content and size (people have asked for at least
2 octets to fit 15.4 short addresses, do we need some control field as
well?)

	-          RH format (inherit RH0 fields with labels instead of
addresses? What about the tag swapping  case, RH as well?)

	=20

	Advice?

	=20

	Pascal

	=20

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Robert Cragie
	Sent: Thursday, April 08, 2010 11:34 PM
	To: Jonathan Hui
	Cc: roll@ietf.org
	Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

	=20

	OK, sounds good. End of topic as far as I am concerned. +1
=09
	Robert

	Robert Cragie (Pacific Gas & Electric)

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888
	http://www.gridmerge.com =20

=09
	On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20

=09
	Hi Robert,=20
=09
	On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20
=09
=09
=09

	A couple of questions:=20
	    * I presume the source route header using these tags/labels
is an IPv6 extension header. What value for extension header type would
this be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames?=20

=09
	We already have a draft requesting a new IPv6 Hop-by-Hop Option
and presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for
the IPv6 Hop-by-Hop Option header.=20
=09
=09
=09

	    * Can you point to where the 'core ideas have been deployed
in traditional IP networks for quite some time'?=20

=09
	MPLS.  Again, I think the mechanisms will need to be adapted,
but the core ideas are not new.=20
=09
	--=20
	Jonathan Hui=20
=09
=09
=09

	Thanks=20
=09
	Robert=20
	Robert Cragie (Pacific Gas & Electric)=20
=09
	Gridmerge Ltd.=20
	89 Greenfield Crescent,=20
	Wakefield, WF4 4WA, UK=20
	+44 (0) 1924 910888=20
	http://www.gridmerge.com=20
=09
=09
	On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20
=09
=09

=09
=09
	To make the source route header compact, I favor the tag/label
approach over some other compaction mechanism that operates directly on
a list of IPv6 addresses.  Tags/labels can be made general enough such
that they can be derived in different ways.  Because the tags/labels
have scope local to each node, the mechanism is pretty general already.
For those that are already managing unique 802.15.4 short addresses
across a network, I can see that it is attractive to utilize the short
address directly and reduce state on devices.  In other cases, it may be
best for the node to dynamically assign tags/labels for its neighbors.=20
=09
	Either way, while the tag/label mechanism is simple, it is far
more flexible than an approach to compacting a list of IPv6 addresses.
And note that the idea of using tags/labels is nothing new.  Of course
we will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.=20
=09
	I reiterated a lot of what was already stated before by others,
but that is what I think.=20
=09
	--=20
	Jonathan Hui=20
=09
	On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20
=09
=09
=09

	Hi Daniel:=20
=09
	Routers might have multiple interfaces of multiple MAC types.
Internet 0=20
	even has a MAC-less format.=20
	So the result of you proposal, which looks like a great idea in
a pure=20
	802.15.4 world with short addresses, becomes a nightmare to
define in a=20
	fully generic fashion.=20
=09
	OTOH, a locally significant opaque tag in which the parent could
hide a=20
	short address of the child - if it cares to do it that way -
looks like=20
	a way more acceptable approach=20
=09
	So it seems to me that you can get what you want as long as we
can make=20
	the tag big enough for short addresses. When the tag is too
small to=20
	contain what the parent really needs, then the parent will have
to store=20
	a state with the full information in memory, and then place an
index of=20
	some sort in the tag.=20
=09
	What do you think?=20
=09
	Pascal=20
=09
=09
=09
=09

	-----Original Message-----=20
	From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
	Sent: Thursday, April 08, 2010 11:40 AM=20
	To: ROLL WG=20
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and=20
	SourceRoutingOperations=20
=09
	Hi Pascal, John,=20
=09
	Since source routing explicitly gives forwarding instruction to
each=20
	intermediate node, it can make sense to use only (MAC address
based)=20

	L2=20
=09
=09

	forwarding instead of (IPv6 address based) L3 forwarding.=20
=09
	This brings two advantages:=20
	- avoid processing each transit packets up to L3.=20
	- use MAC addresses that - in ROLL environment - have inherently


	shorter=20
=09
=09

	length than an IPv6 address.=20
=09
	Cheers,=20
	Daniel=20
=09
=09
=09
	-----Original Message-----=20
	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf=20

	Of=20
=09
=09

	Pascal Thubert (pthubert)=20
	Sent: jeudi 8 avril 2010 11:15=20
	To: JeongGil Ko (John); ROLL WG=20
	Subject: Re: [Roll] Proposal for Source Routing Header Format
and=20
	SourceRoutingOperations=20
=09
	Hi John:=20
=09
	IPv6 already has a number of routing headers, in particular RH0,


	though it is=20
=09
=09

	being deprecated for general use in the Internet.=20
	And there are reasons why the fields in RH0/1 are there and we
need to=20
	make sure we lose none of that. In particular a RH is
recoverable, and=20

	it is=20
=09
=09

	easy to spot the consumed entries.=20
=09
	On top of this our new problems are:=20
	- make sure the RH stays within the RPL network (since it is
used=20

	downwards=20
=09
=09

	that should be doable)=20
	- control the size (that probably means compress)=20
=09
	Cheers,=20
=09
	Pascal=20
=09
=09
=09
=09

	-----Original Message-----=20
	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf=20

	Of=20
=09
=09

	JeongGil Ko (John)=20
	Sent: Wednesday, April 07, 2010 10:05 PM=20
	To: ROLL WG=20
	Subject: [Roll] Proposal for Source Routing Header Format and
Source=20
	RoutingOperations=20
=09
	Hi!=20
=09
	Great to see all this discussions on downwards route
establishment!=20

	To=20
=09
=09

	add=20
=09
=09

	one more to the conversations here is a proposal for source
routing=20

	headers.=20
=09
=09

	In non-storing mode (where only the root has individual path=20

	information)=20
=09
=09

	the root will be attaching a source routing header to the data=20

	packet=20
=09
=09

	that a=20
=09
=09

	source node wants to send to a specific destination. We can
always=20

	make the=20
=09
=09

	header super fancy but in my opinion I think we only need two
fields=20

	in this=20
=09
=09

	header and here it is! Feel free to break the stuff and mangle
with=20

	it=20
=09
=09

	so that it=20
=09
=09

	looks great in the specs later on. FYI, this is the format that
I am=20

	using in my=20
=09
=09

	implementations so it does work :)=20
=09
	1. Source Routing Header Format=20
=09
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	|   NEntry (8 bits)   |=20

	|=20
=09
=09

	+-+-+-+-+-+-+-+-+=20

	+=20
=09
=09

	|                       Source Route Entry (128*NEntry bits)=20

	|=20
=09
=09

	+=20

	+=20
=09
=09

	|=20

	|=20
=09
=09

=09
	     Figure 1. Proposed Source Routing Header Format; each line
is=20

	32=20
=09
=09

	bits:)=20
=09
=09

=09
	- NEntry: Indicates the number of 128 bit addresses that the
source=20

	route=20
=09
=09

	entry field is carrying.=20
=09
	- Source Route Entry: List of 128 bit address that consist the
route=20

	to the=20
=09
=09

	destination. Here, the address of the node that is one hop away
from=20

	the=20
=09
=09

	*destination* comes first.=20
=09
	2. Source Routing Packet Operations=20
=09
	When source routing is initiated at a storing node (e.g., root
of=20

	the=20
=09
=09

	DODAG),=20
=09
=09

	the header is attached on the data packet for the entire route=20

	(i.e.,=20
=09
=09

	from=20
=09
=09

	next hop node to the destination). This header is positioned in=20

	front=20
=09
=09

	of the=20
=09
=09

	user payload. When the next hop node receives a packet that is
not=20

	destined=20
=09
=09

	to itself AND the network is NOT provisioned to be in 'storing
mode'=20

	then it=20
=09
=09

	checks NEntry to find what the next hop is in the source route=20

	entry.=20
=09
=09

	Since=20
=09
=09

	the 'Source Route Entry' is ordered in 'farthest -> closest' (in


	terms=20
=09
=09

	of hops)=20
=09
=09

	order, a node can figure out what the next hop address is with
only=20

	the=20
=09
=09

	NEntry value (since it already knows how big an ipv6 address
is).=20

	After=20
=09
=09

	collecting the next hop node's address, the node erases this
address=20
	element from the entry and decreases NEntry by one. This assures


	that=20
=09
=09

	we=20
=09
=09

	avoid the overhead of carrying the entire source route
throughout=20

	the=20
=09
=09

	data=20
=09
=09

	path.=20
=09
	The approach itself should be very simple and trivial for
everyone=20

	to=20
=09
=09

	follow.=20
=09
=09

	So we can start from here and build on!=20
=09
	Thanks.=20
=09
	-John=20
=09
	------=20
	JeongGil Ko (John)=20
	Ph.D. Student=20
	Department of Computer Science=20
	Johns Hopkins University=20
	http://www.cs.jhu.edu/~jgko=20
=09
	_______________________________________________=20
	Roll mailing list=20
	Roll@ietf.org=20
	https://www.ietf.org/mailman/listinfo/roll=20

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

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

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

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

	=20


------_=_NextPart_001_01CAD7C0.9C4B5FF8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    Admitted, I have been absent from this thread; =
trying to=20
catch up on others...
    

     
    

    

    > I read this as a consensus to use =
tags=20
J If=20
anyone disagree please speak up now!
    I have to =
comment=20
respectfully but loudly that this may at best some sort of rough=20
concensus..
    

     
    

    In a non-storing mode, I see no way of storing =
and/or=20
swapping labels/tags in each node.
    

    For this kind of nodes we need a complete =
routing stack in=20
the frame. As mentioned earlier, I am perfectly
    fine with limitations =
such as=20
max n entries; Compression of addresses to 16 bits and a common=20
subnet.
    

     
    

    Just my $0.05
    

     
    

     

    

    
  
    
  
    
  From: roll-bounces@ietf.org=20
  [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert=20
  (pthubert)
    Sent: Friday, April 09, 2010 10:36
    To:=20
  robert.cragie@gridmerge.com; Jonathan Hui
    Cc:=20
  roll@ietf.org
    Subject: Re: [Roll] Proposal for Source =
Routing=20
  HeaderFormatand SourceRoutingOperations

    
  
    
  
    
  
    I=20
  read this as a consensus to use tags J=20
  If anyone disagree please speak up now!
    
  
     
    
  
    There=20
  have been plenty iterations/versions of tagging since Frame Relay =
(pure=20
  switching), IBM’s HPR (pure source route), Cisco’s tag =
switching and MPLS.=20
  More often than not, a combination of the 2 models is used so that =
tags can be=20
  both swapped and stacked. 
    
  
     
    
  
    -         =20
  In=20
  pure switching, there’s only one tag in the packet. A tag can be =
locally=20
  significant, in which case it has to be swapped as the packet =
progresses. For=20
  RPL, it means that a node uses as many tags as it has children that =
use it has=20
  DAO targets in its subdag.
    
  
     
    
  
    -         =20
  In=20
  the pure source route model, tags are stacked in an ordered list that =
forms a=20
  strict routing header. A tag can be locally significant to the =
interpreter and=20
  is consumed (marked or removed) as the packet progresses. For RPL, it =
means=20
  that a node uses as many tags as it has children that use this node as =
DAO=20
  parent. 
    
  
     
    
  
    It=20
  also appears that the 2 tagging models map quite well with the DAO =
models we=20
  have in RPL since the split that we decided with issue #26. The fact =
that the=20
  combination of the 2 models is possible in the real world today gives =
us a=20
  hint that we are not closing the door to the mixed model in the=20
  future.
    
  
     
    
  
    The=20
  next step I wish to agree upon:
    
  
    -         =20
  Use=20
  locally significant tags which implies tag assignment by the node that =
uses it=20
  later and tag swapping for the stateful case.
    
  
    -         =20
  Tag=20
  distribution in DAO (there are options there that we need to dig=20
  further)
    
  
    -         =20
  Tag=20
  content and size (people have asked for at least 2 octets to fit 15.4 =
short=20
  addresses, do we need some control field as =
well?)
    
  
    -         =20
  RH=20
  format (inherit RH0 fields with labels instead of addresses? What =
about the=20
  tag swapping  case, RH as well?)
    
  
     
    
  
    Advice?
    
  
     
    
  
    
  
    Pascal
    
  
     
    
  
  
    
  
  
    From:=20
  roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20
  Robert Cragie
    Sent: Thursday, April 08, 2010 11:34=20
  PM
    To: Jonathan Hui
    Cc: =
roll@ietf.org
    Subject:=20
  Re: [Roll] Proposal for Source Routing Header Formatand=20
  SourceRoutingOperations
    
  
     
    
  
    OK, sounds good. End of topic as far as I am =
concerned.=20
  +1

    Robert
    
  
    
  
    Robert Cragie (Pacific Gas & =
Electric)
    
  
    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, =
UK
    +44=20
  (0) 1924 910888
    http://www.gridmerge.com
    
  

    On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20
  
    
  

    Hi Robert, 

    On Apr 8, 2010, at 2:06 =
PM, Robert=20
  Cragie wrote: 


    
  
    A couple of questions: =

        • I=20
  presume the source route header using these tags/labels is an IPv6 =
extension=20
  header. What value for extension header type would this be? Would we =
need to=20
  specify a LOWPAN_NHC value for this so we can still use LOWPAN_NCH for =
UDP=20
  frames? 
    
  

    We already have a draft requesting a new IPv6 =

  Hop-by-Hop Option and presented it at 6man in Anaheim.  The =
option is=20
  designed to carry RPL-specific information.  6lowpan-hc already =
has a=20
  LOWPAN_NHC value for the IPv6 Hop-by-Hop Option header.=20
  


    
  
        • Can you point to =
where the 'core=20
  ideas have been deployed in traditional IP networks for quite some =
time'?=20
  
    
  

    MPLS.  Again, I think the mechanisms =
will need to=20
  be adapted, but the core ideas are not new. 

    -- 
    Jonathan =
Hui=20
  


    
  
    Thanks 

    Robert 
    Robert Cragie (Pacific =
Gas &=20
  Electric) 

    Gridmerge Ltd. 
    89 Greenfield Crescent, =

    Wakefield,=20
  WF4 4WA, UK 
    +44 (0) 1924 910888 
    http://www.gridmerge.com =



    On=20
  08/04/2010 3:57 PM, Jonathan Hui wrote: 

    
  


    To make the source route header compact, =
I favor=20
  the tag/label approach over some other compaction mechanism that =
operates=20
  directly on a list of IPv6 addresses.  Tags/labels can be made =
general=20
  enough such that they can be derived in different ways.  Because =
the=20
  tags/labels have scope local to each node, the mechanism is pretty =
general=20
  already.  For those that are already managing unique 802.15.4 =
short=20
  addresses across a network, I can see that it is attractive to utilize =
the=20
  short address directly and reduce state on devices.  In other =
cases, it=20
  may be best for the node to dynamically assign tags/labels for its =
neighbors.=20
  

    Either way, while the tag/label mechanism is simple, it is far =
more=20
  flexible than an approach to compacting a list of IPv6 =
addresses.  And=20
  note that the idea of using tags/labels is nothing new.  Of =
course we=20
  will adapt the basic mechanism a bit (label distribution, headers =
formats,=20
  etc), but the core ideas have been deployed in traditional IP networks =
for=20
  quite some time. 

    I reiterated a lot of what was already stated =
before=20
  by others, but that is what I think. 

    -- 
    Jonathan Hui=20
  

    On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20
  


    
  
    Hi Daniel: 

    Routers might have multiple =
interfaces=20
  of multiple MAC types. Internet 0 
    even has a MAC-less format. =

    So the=20
  result of you proposal, which looks like a great idea in a pure =

    802.15.4=20
  world with short addresses, becomes a nightmare to define in a =

    fully=20
  generic fashion. 

    OTOH, a locally significant opaque tag in =
which the=20
  parent could hide a 
    short address of the child - if it cares to do =
it that=20
  way - looks like 
    a way more acceptable approach 

    So it =
seems to me=20
  that you can get what you want as long as we can make 
    the tag big =
enough=20
  for short addresses. When the tag is too small to 
    contain what the =
parent=20
  really needs, then the parent will have to store 
    a state with the =
full=20
  information in memory, and then place an index of 
    some sort in the =
tag.=20
  

    What do you think? 

    Pascal =




    
  
    -----Original Message----- 
    From: Popa, Daniel =
[mailto:Daniel.Popa@itron.com]=20
  
    Sent: Thursday, April 08, 2010 11:40 AM 
    To: ROLL WG 
    Cc: =
Pascal=20
  Thubert (pthubert); JeongGil Ko (John) 
    Subject: RE: [Roll] =
Proposal for=20
  Source Routing Header Format and 
    SourceRoutingOperations =


    Hi=20
  Pascal, John, 

    Since source routing explicitly gives forwarding =

  instruction to each 
    intermediate node, it can make sense to use =
only (MAC=20
  address based) 
    
  
    L2 

    
  
    forwarding instead of (IPv6 address based) L3 =
forwarding.=20
  

    This brings two advantages: 
    - avoid processing each =
transit=20
  packets up to L3. 
    - use MAC addresses that - in ROLL environment - =
have=20
  inherently 
    
  
    shorter 

    
  
    length than an IPv6 address. 

    Cheers, =

    Daniel=20
  



    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On=20
  Behalf 
    
  
    Of 

    
  
    Pascal Thubert (pthubert) 
    Sent: jeudi 8 avril =
2010=20
  11:15 
    To: JeongGil Ko (John); ROLL WG 
    Subject: Re: [Roll] =
Proposal for=20
  Source Routing Header Format and 
    SourceRoutingOperations =


    Hi John:=20
  

    IPv6 already has a number of routing headers, in particular =
RH0,=20
  
    
  
    though it is 

    
  
    being deprecated for general use in the Internet. =

    And=20
  there are reasons why the fields in RH0/1 are there and we need to =

    make=20
  sure we lose none of that. In particular a RH is recoverable, and=20
  
    
  
    it is 

    
  
    easy to spot the consumed entries. 

    On top =
of this=20
  our new problems are: 
    - make sure the RH stays within the RPL =
network=20
  (since it is used 
    
  
    downwards 

    
  
    that should be doable) 
    - control the size =
(that=20
  probably means compress) 

    Cheers, 

    Pascal=20
  



    
  
    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On=20
  Behalf 
    
  
    Of 

    
  
    JeongGil Ko (John) 
    Sent: Wednesday, April 07, =
2010=20
  10:05 PM 
    To: ROLL WG 
    Subject: [Roll] Proposal for Source =
Routing=20
  Header Format and Source 
    RoutingOperations 

    Hi! =


    Great to=20
  see all this discussions on downwards route establishment! =

    
  
    To 

    
  
    add 

    
  
    one more to the conversations here is a proposal =
for source=20
  routing 
    
  
    headers. 

    
  
    In non-storing mode (where only the root has =
individual=20
  path 
    
  
    information) 

    
  
    the root will be attaching a source routing =
header to the=20
  data 
    
  
    packet 

    
  
    that a 

    
  
    source node wants to send to a specific =
destination. We can=20
  always 
    
  
    make the 

    
  
    header super fancy but in my opinion I think we =
only need=20
  two fields 
    
  
    in this 

    
  
    header and here it is! Feel free to break the =
stuff and=20
  mangle with 
    
  
    it 

    
  
    so that it 

    
  
    looks great in the specs later on. FYI, this is =
the format=20
  that I am 
    
  
    using in my 

    
  
    implementations so it does work :) 

    1. =
Source=20
  Routing Header Format=20
  =


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
=20
  
    |   NEntry (8 bits)   | 
    
  
    | 

    
  
    +-+-+-+-+-+-+-+-+ 
    
  
    + 

    
  |         =
            &=
nbsp;=20
  Source Route Entry (128*NEntry bits) 
    
  
    | 

    
  
    + 
    
  
    + 

    
  
    | 
    
  
    | 

    
  

         Figure 1. Proposed =
Source=20
  Routing Header Format; each line is 
    
  
    32 

    
  
    bits:) 

    
  

    - NEntry: Indicates the number of 128 bit =
addresses=20
  that the source 
    
  
    route 

    
  
    entry field is carrying. 

    - Source Route =
Entry: List=20
  of 128 bit address that consist the route 
    
  
    to the 

    
  
    destination. Here, the address of the node that =
is one hop=20
  away from 
    
  
    the 

    
  
    *destination* comes first. 

    2. Source =
Routing Packet=20
  Operations 

    When source routing is initiated at a storing node =
(e.g.,=20
  root of 
    
  
    the 

    
  
    DODAG), 

    
  
    the header is attached on the data packet for the =
entire=20
  route 
    
  
    (i.e., 

    
  
    from 

    
  
    next hop node to the destination). This header is =

  positioned in 
    
  
    front 

    
  
    of the 

    
  
    user payload. When the next hop node receives a =
packet that=20
  is not 
    
  
    destined 

    
  
    to itself AND the network is NOT provisioned to =
be in=20
  'storing mode' 
    
  
    then it 

    
  
    checks NEntry to find what the next hop is in the =
source=20
  route 
    
  
    entry. 

    
  
    Since 

    
  
    the 'Source Route Entry' is ordered in 'farthest =
->=20
  closest' (in 
    
  
    terms 

    
  
    of hops) 

    
  
    order, a node can figure out what the next hop =
address is=20
  with only 
    
  
    the 

    
  
    NEntry value (since it already knows how big an =
ipv6=20
  address is). 
    
  
    After 

    
  
    collecting the next hop node's address, the node =
erases=20
  this address 
    element from the entry and decreases NEntry by one. =
This=20
  assures 
    
  
    that 

    
  
    we 

    
  
    avoid the overhead of carrying the entire source =
route=20
  throughout 
    
  
    the 

    
  
    data 

    
  
    path. 

    The approach itself should be very =
simple and=20
  trivial for everyone 
    
  
    to 

    
  
    follow. 

    
  
    So we can start from here and build on! =


    Thanks.=20
  

    -John 

    ------ 
    JeongGil Ko (John) 
    Ph.D. Student=20
  
    Department of Computer Science 
    Johns Hopkins University 
    http://www.cs.jhu.edu/~jgko=20
  

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

    Roll=20
  mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
  
    
  
    _______________________________________________ =

    Roll=20
  mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
  
    
  

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

    Roll=20
  mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
  
    
  
     
    

------_=_NextPart_001_01CAD7C0.9C4B5FF8--

From pthubert@cisco.com  Fri Apr  9 01:52:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD913A6B12 for ; Fri,  9 Apr 2010 01:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.255
X-Spam-Level: 
X-Spam-Status: No, score=-9.255 tagged_above=-999 required=5 tests=[AWL=1.343,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jNW6K3ZhRr4 for ; Fri,  9 Apr 2010 01:52:24 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CD5673A69EE for ; Fri,  9 Apr 2010 01:52:00 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFKHvkurR7H+/2dsb2JhbACBPZl+cZ9vmSyFCQQ
X-IronPort-AV: E=Sophos;i="4.52,176,1270425600";  d="scan'208,217";a="511962749"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2010 08:51:56 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o398pi6m000631; Fri, 9 Apr 2010 08:51:56 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 9 Apr 2010 10:51:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7C1.E7F5F7B5"
Date: Fri, 9 Apr 2010 10:51:51 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQAAAGJtUA==
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>
From: "Pascal Thubert (pthubert)" 
To: "Anders Brandt" , , "Jonathan Hui" 
X-OriginalArrivalTime: 09 Apr 2010 08:51:55.0706 (UTC) FILETIME=[E827C1A0:01CAD7C1]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 08:52:38 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7C1.E7F5F7B5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Anders:

=20

You did not miss much. But maybe the fact that the tag could be
stateless as long as the node knows how to do that.=20

For instance a short address could be encoded in there, as long as this
is opaque to the rest of the L3 network.

One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?

=20

Pascal

=20

From: Anders Brandt [mailto:abr@sdesigns.dk]=20
Sent: Friday, April 09, 2010 10:43 AM
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
Cc: roll@ietf.org
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

=20

Admitted, I have been absent from this thread; trying to catch up on
others...

=20

> I read this as a consensus to use tags J If anyone disagree please
speak up now!

I have to comment respectfully but loudly that this may at best some
sort of rough concensus..

=20

In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.

For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to
16 bits and a common subnet.

=20

Just my $0.05

=20

=20

	=20

=09
________________________________


	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Pascal Thubert (pthubert)
	Sent: Friday, April 09, 2010 10:36
	To: robert.cragie@gridmerge.com; Jonathan Hui
	Cc: roll@ietf.org
	Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	I read this as a consensus to use tags J If anyone disagree
please speak up now!

	=20

	There have been plenty iterations/versions of tagging since
Frame Relay (pure switching), IBM's HPR (pure source route), Cisco's tag
switching and MPLS. More often than not, a combination of the 2 models
is used so that tags can be both swapped and stacked.=20

	=20

	-          In pure switching, there's only one tag in the
packet. A tag can be locally significant, in which case it has to be
swapped as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use it has DAO targets in its subdag.

	=20

	-          In the pure source route model, tags are stacked in
an ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent.=20

	=20

	It also appears that the 2 tagging models map quite well with
the DAO models we have in RPL since the split that we decided with issue
#26. The fact that the combination of the 2 models is possible in the
real world today gives us a hint that we are not closing the door to the
mixed model in the future.

	=20

	The next step I wish to agree upon:

	-          Use locally significant tags which implies tag
assignment by the node that uses it later and tag swapping for the
stateful case.

	-          Tag distribution in DAO (there are options there that
we need to dig further)

	-          Tag content and size (people have asked for at least
2 octets to fit 15.4 short addresses, do we need some control field as
well?)

	-          RH format (inherit RH0 fields with labels instead of
addresses? What about the tag swapping  case, RH as well?)

	=20

	Advice?

	=20

	Pascal

	=20

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Robert Cragie
	Sent: Thursday, April 08, 2010 11:34 PM
	To: Jonathan Hui
	Cc: roll@ietf.org
	Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

	=20

	OK, sounds good. End of topic as far as I am concerned. +1
=09
	Robert

	Robert Cragie (Pacific Gas & Electric)

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888
	http://www.gridmerge.com =20

=09
	On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20

=09
	Hi Robert,=20
=09
	On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20
=09
=09

	A couple of questions:=20
	    * I presume the source route header using these tags/labels
is an IPv6 extension header. What value for extension header type would
this be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames?=20

=09
	We already have a draft requesting a new IPv6 Hop-by-Hop Option
and presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for
the IPv6 Hop-by-Hop Option header.=20
=09
=09

	    * Can you point to where the 'core ideas have been deployed
in traditional IP networks for quite some time'?=20

=09
	MPLS.  Again, I think the mechanisms will need to be adapted,
but the core ideas are not new.=20
=09
	--=20
	Jonathan Hui=20
=09
=09

	Thanks=20
=09
	Robert=20
	Robert Cragie (Pacific Gas & Electric)=20
=09
	Gridmerge Ltd.=20
	89 Greenfield Crescent,=20
	Wakefield, WF4 4WA, UK=20
	+44 (0) 1924 910888=20
	http://www.gridmerge.com=20
=09
=09
	On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20

=09
=09
	To make the source route header compact, I favor the tag/label
approach over some other compaction mechanism that operates directly on
a list of IPv6 addresses.  Tags/labels can be made general enough such
that they can be derived in different ways.  Because the tags/labels
have scope local to each node, the mechanism is pretty general already.
For those that are already managing unique 802.15.4 short addresses
across a network, I can see that it is attractive to utilize the short
address directly and reduce state on devices.  In other cases, it may be
best for the node to dynamically assign tags/labels for its neighbors.=20
=09
	Either way, while the tag/label mechanism is simple, it is far
more flexible than an approach to compacting a list of IPv6 addresses.
And note that the idea of using tags/labels is nothing new.  Of course
we will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.=20
=09
	I reiterated a lot of what was already stated before by others,
but that is what I think.=20
=09
	--=20
	Jonathan Hui=20
=09
	On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20
=09
=09

	Hi Daniel:=20
=09
	Routers might have multiple interfaces of multiple MAC types.
Internet 0=20
	even has a MAC-less format.=20
	So the result of you proposal, which looks like a great idea in
a pure=20
	802.15.4 world with short addresses, becomes a nightmare to
define in a=20
	fully generic fashion.=20
=09
	OTOH, a locally significant opaque tag in which the parent could
hide a=20
	short address of the child - if it cares to do it that way -
looks like=20
	a way more acceptable approach=20
=09
	So it seems to me that you can get what you want as long as we
can make=20
	the tag big enough for short addresses. When the tag is too
small to=20
	contain what the parent really needs, then the parent will have
to store=20
	a state with the full information in memory, and then place an
index of=20
	some sort in the tag.=20
=09
	What do you think?=20
=09
	Pascal=20
=09
=09
=09

	-----Original Message-----=20
	From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
	Sent: Thursday, April 08, 2010 11:40 AM=20
	To: ROLL WG=20
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and=20
	SourceRoutingOperations=20
=09
	Hi Pascal, John,=20
=09
	Since source routing explicitly gives forwarding instruction to
each=20
	intermediate node, it can make sense to use only (MAC address
based)=20

	L2=20

	forwarding instead of (IPv6 address based) L3 forwarding.=20
=09
	This brings two advantages:=20
	- avoid processing each transit packets up to L3.=20
	- use MAC addresses that - in ROLL environment - have inherently


	shorter=20

	length than an IPv6 address.=20
=09
	Cheers,=20
	Daniel=20
=09
=09
=09
	-----Original Message-----=20
	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf=20

	Of=20

	Pascal Thubert (pthubert)=20
	Sent: jeudi 8 avril 2010 11:15=20
	To: JeongGil Ko (John); ROLL WG=20
	Subject: Re: [Roll] Proposal for Source Routing Header Format
and=20
	SourceRoutingOperations=20
=09
	Hi John:=20
=09
	IPv6 already has a number of routing headers, in particular RH0,


	though it is=20

	being deprecated for general use in the Internet.=20
	And there are reasons why the fields in RH0/1 are there and we
need to=20
	make sure we lose none of that. In particular a RH is
recoverable, and=20

	it is=20

	easy to spot the consumed entries.=20
=09
	On top of this our new problems are:=20
	- make sure the RH stays within the RPL network (since it is
used=20

	downwards=20

	that should be doable)=20
	- control the size (that probably means compress)=20
=09
	Cheers,=20
=09
	Pascal=20
=09
=09
=09

	-----Original Message-----=20
	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf=20

	Of=20

	JeongGil Ko (John)=20
	Sent: Wednesday, April 07, 2010 10:05 PM=20
	To: ROLL WG=20
	Subject: [Roll] Proposal for Source Routing Header Format and
Source=20
	RoutingOperations=20
=09
	Hi!=20
=09
	Great to see all this discussions on downwards route
establishment!=20

	To=20

	add=20

	one more to the conversations here is a proposal for source
routing=20

	headers.=20

	In non-storing mode (where only the root has individual path=20

	information)=20

	the root will be attaching a source routing header to the data=20

	packet=20

	that a=20

	source node wants to send to a specific destination. We can
always=20

	make the=20

	header super fancy but in my opinion I think we only need two
fields=20

	in this=20

	header and here it is! Feel free to break the stuff and mangle
with=20

	it=20

	so that it=20

	looks great in the specs later on. FYI, this is the format that
I am=20

	using in my=20

	implementations so it does work :)=20
=09
	1. Source Routing Header Format=20
=09
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	|   NEntry (8 bits)   |=20

	|=20

	+-+-+-+-+-+-+-+-+=20

	+=20

	|                       Source Route Entry (128*NEntry bits)=20

	|=20

	+=20

	+=20

	|=20

	|=20

=09
	     Figure 1. Proposed Source Routing Header Format; each line
is=20

	32=20

	bits:)=20

=09
	- NEntry: Indicates the number of 128 bit addresses that the
source=20

	route=20

	entry field is carrying.=20
=09
	- Source Route Entry: List of 128 bit address that consist the
route=20

	to the=20

	destination. Here, the address of the node that is one hop away
from=20

	the=20

	*destination* comes first.=20
=09
	2. Source Routing Packet Operations=20
=09
	When source routing is initiated at a storing node (e.g., root
of=20

	the=20

	DODAG),=20

	the header is attached on the data packet for the entire route=20

	(i.e.,=20

	from=20

	next hop node to the destination). This header is positioned in=20

	front=20

	of the=20

	user payload. When the next hop node receives a packet that is
not=20

	destined=20

	to itself AND the network is NOT provisioned to be in 'storing
mode'=20

	then it=20

	checks NEntry to find what the next hop is in the source route=20

	entry.=20

	Since=20

	the 'Source Route Entry' is ordered in 'farthest -> closest' (in


	terms=20

	of hops)=20

	order, a node can figure out what the next hop address is with
only=20

	the=20

	NEntry value (since it already knows how big an ipv6 address
is).=20

	After=20

	collecting the next hop node's address, the node erases this
address=20
	element from the entry and decreases NEntry by one. This assures


	that=20

	we=20

	avoid the overhead of carrying the entire source route
throughout=20

	the=20

	data=20

	path.=20
=09
	The approach itself should be very simple and trivial for
everyone=20

	to=20

	follow.=20

	So we can start from here and build on!=20
=09
	Thanks.=20
=09
	-John=20
=09
	------=20
	JeongGil Ko (John)=20
	Ph.D. Student=20
	Department of Computer Science=20
	Johns Hopkins University=20
	http://www.cs.jhu.edu/~jgko=20
=09
	_______________________________________________=20
	Roll mailing list=20
	Roll@ietf.org=20
	https://www.ietf.org/mailman/listinfo/roll=20

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

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

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

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

	=20


------_=_NextPart_001_01CAD7C1.E7F5F7B5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Hi Anders:
     
    You did not miss much. But maybe the fact that the tag could be =
stateless as long as the node knows how to do that. =

    For instance a short address could be encoded in there, as long as =
this is opaque to the rest of the L3 network.
    One question though. In your case, do you / can you maintain any =
information about neighbors? Like security ?
     
    Pascal
     
    From: Anders Brandt [mailto:abr@sdesigns.dk] 
    Sent: Friday, =
April 09, 2010 10:43 AM
    To: Pascal Thubert (pthubert); =
robert.cragie@gridmerge.com; Jonathan Hui
    Cc: =
roll@ietf.org
    Subject: RE: [Roll] Proposal for Source Routing =
HeaderFormatand =
SourceRoutingOperations
     
    Ad=
mitted, I have been absent from this thread; trying to catch up on =
others...
     
    > I read this as a consensus to use tags J If anyone disagree please speak up now!
    I =
have to comment respectfully but loudly that this may at best some sort =
of rough concensus..
     
    In=
 a non-storing mode, I see no way of storing and/or swapping labels/tags =
in each node.
    Fo=
r this kind of nodes we need a complete routing stack in the frame. As =
mentioned earlier, I am perfectly
    fine with limitations such as max n =
entries; Compression of addresses to 16 bits and a common =
subnet.
     
    Ju=
st my $0.05
     
     
     
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of Pascal Thubert (pthubert)
    Sent: Friday, April 09, 2010 =
10:36
    To: robert.cragie@gridmerge.com; Jonathan =
Hui
    Cc: roll@ietf.org
    Subject: Re: [Roll] Proposal =
for Source Routing HeaderFormatand SourceRoutingOperations
    I read this as a consensus to use tags J If anyone disagree please speak up now!
     
    There have been plenty iterations/versions of tagging since Frame =
Relay (pure switching), IBM’s HPR (pure source route), =
Cisco’s tag switching and MPLS. More often than not, a combination =
of the 2 models is used so that tags can be both swapped and stacked. =

     
    -     &nb=
sp;    In pure switching, there’s only one tag in the packet. A tag =
can be locally significant, in which case it has to be swapped as the =
packet progresses. For RPL, it means that a node uses as many tags as it =
has children that use it has DAO targets in its =
subdag.
     
    -     &nb=
sp;    In the pure source route model, tags are stacked in an ordered list =
that forms a strict routing header. A tag can be locally significant to =
the interpreter and is consumed (marked or removed) as the packet =
progresses. For RPL, it means that a node uses as many tags as it has =
children that use this node as DAO parent. 
     
    It also appears that the 2 tagging models map quite well with the DAO =
models we have in RPL since the split that we decided with issue #26. =
The fact that the combination of the 2 models is possible in the real =
world today gives us a hint that we are not closing the door to the =
mixed model in the future.
     
    The next step I wish to agree upon:
    -     &nb=
sp;    Use locally significant tags which implies tag assignment by the node =
that uses it later and tag swapping for the stateful =
case.
    -     &nb=
sp;    Tag distribution in DAO (there are options there that we need to dig =
further)
    -     &nb=
sp;    Tag content and size (people have asked for at least 2 octets to fit =
15.4 short addresses, do we need some control field as =
well?)
    -     &nb=
sp;    RH format (inherit RH0 fields with labels instead of addresses? What =
about the tag swapping  case, RH as well?)
     
    Advice?
     
    Pascal
     
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of Robert Cragie
    Sent: Thursday, April 08, 2010 11:34 =
PM
    To: Jonathan Hui
    Cc: =
roll@ietf.org
    Subject: Re: [Roll] Proposal for Source Routing =
Header Formatand =
SourceRoutingOperations
     
    OK, sounds =
good. End of topic as far as I am concerned. =
+1

    Robert
    Robert Cragie =
(Pacific Gas & Electric)
    Gridmerge Ltd.
    89 =
Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 =
910888
    http://www.gridmerge.com

    On 08/04/2010 10:17 PM, Jonathan Hui =
wrote: 

    Hi Robert, 

    On Apr 8, 2010, at =
2:06 PM, Robert Cragie wrote: 

    A couple of questions: =

        • I presume the source route header =
using these tags/labels is an IPv6 extension header. What value for =
extension header type would this be? Would we need to specify a =
LOWPAN_NHC value for this so we can still use LOWPAN_NCH for UDP frames? =


    We already have a draft requesting a =
new IPv6 Hop-by-Hop Option and presented it at 6man in Anaheim.  =
The option is designed to carry RPL-specific information.  =
6lowpan-hc already has a LOWPAN_NHC value for the IPv6 Hop-by-Hop Option =
header. 

        • Can you point to where =
the 'core ideas have been deployed in traditional IP networks for quite =
some time'? 

    MPLS.  Again, I think the =
mechanisms will need to be adapted, but the core ideas are not new. =


    -- 
    Jonathan Hui 

    Thanks 

    Robert 
    Robert Cragie =
(Pacific Gas & Electric) 

    Gridmerge Ltd. 
    89 Greenfield =
Crescent, 
    Wakefield, WF4 4WA, UK 
    +44 (0) 1924 910888 
    http://www.gridmerge.com =



    On 08/04/2010 3:57 PM, Jonathan Hui wrote: 


    To make the =
source route header compact, I favor the tag/label approach over some =
other compaction mechanism that operates directly on a list of IPv6 =
addresses.  Tags/labels can be made general enough such that they =
can be derived in different ways.  Because the tags/labels have =
scope local to each node, the mechanism is pretty general already.  =
For those that are already managing unique 802.15.4 short addresses =
across a network, I can see that it is attractive to utilize the short =
address directly and reduce state on devices.  In other cases, it =
may be best for the node to dynamically assign tags/labels for its =
neighbors. 

    Either way, while the tag/label mechanism is simple, =
it is far more flexible than an approach to compacting a list of IPv6 =
addresses.  And note that the idea of using tags/labels is nothing =
new.  Of course we will adapt the basic mechanism a bit (label =
distribution, headers formats, etc), but the core ideas have been =
deployed in traditional IP networks for quite some time. 

    I =
reiterated a lot of what was already stated before by others, but that =
is what I think. 

    -- 
    Jonathan Hui 

    On Apr 8, =
2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =


    Hi Daniel: 

    Routers might have =
multiple interfaces of multiple MAC types. Internet 0 
    even has a =
MAC-less format. 
    So the result of you proposal, which looks like a =
great idea in a pure 
    802.15.4 world with short addresses, becomes a =
nightmare to define in a 
    fully generic fashion. 

    OTOH, a =
locally significant opaque tag in which the parent could hide a =

    short address of the child - if it cares to do it that way - looks =
like 
    a way more acceptable approach 

    So it seems to me that =
you can get what you want as long as we can make 
    the tag big enough =
for short addresses. When the tag is too small to 
    contain what the =
parent really needs, then the parent will have to store 
    a state with =
the full information in memory, and then place an index of 
    some sort =
in the tag. 

    What do you think? 

    Pascal =



    -----Original =
Message----- 
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com] =

    Sent: Thursday, April 08, 2010 11:40 AM 
    To: ROLL WG 
    Cc: =
Pascal Thubert (pthubert); JeongGil Ko (John) 
    Subject: RE: [Roll] =
Proposal for Source Routing Header Format and =

    SourceRoutingOperations 

    Hi Pascal, John, 

    Since =
source routing explicitly gives forwarding instruction to each =

    intermediate node, it can make sense to use only (MAC address based) =

    L2 =

    forwarding instead of (IPv6 address =
based) L3 forwarding. 

    This brings two advantages: 
    - avoid =
processing each transit packets up to L3. 
    - use MAC addresses that - =
in ROLL environment - have inherently 
    shorter =

    length than an IPv6 address. =


    Cheers, 
    Daniel 



    -----Original Message----- =

    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf 
    Of 
    Pascal Thubert (pthubert) 
    Sent: jeudi 8 avril 2010 =
11:15 
    To: JeongGil Ko (John); ROLL WG 
    Subject: Re: [Roll] =
Proposal for Source Routing Header Format and =

    SourceRoutingOperations 

    Hi John: 

    IPv6 already has a =
number of routing headers, in particular RH0, 
    though it is =

    being deprecated for general use in =
the Internet. 
    And there are reasons why the fields in RH0/1 are =
there and we need to 
    make sure we lose none of that. In particular a =
RH is recoverable, and 
    it is 
    easy to spot the consumed entries. 

    On top of =
this our new problems are: 
    - make sure the RH stays within the RPL =
network (since it is used 
    downwards 
    that should be doable) =

    - control the size (that probably means compress) 

    Cheers, =


    Pascal 


    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf 
    Of 
    JeongGil Ko (John) 
    Sent: Wednesday, April 07, 2010 =
10:05 PM 
    To: ROLL WG 
    Subject: [Roll] Proposal for Source Routing =
Header Format and Source 
    RoutingOperations 

    Hi! 

    Great =
to see all this discussions on downwards route establishment! =

    To =

    add =

    one more to the conversations here =
is a proposal for source routing 
    headers. 
    In non-storing mode (where only the root has =
individual path 
    information) 
    the root will be attaching a source routing header to =
the data 
    packet 
    that a =

    source node wants to send to a =
specific destination. We can always 
    make the 
    header super fancy but in my opinion I think we only =
need two fields 
    in this 
    header and here it is! Feel free to break the stuff =
and mangle with 
    it 
    so that it 
    looks great in the specs later on. FYI, this is the =
format that I am 
    using in my 
    implementations so it does work :) 

    1. Source =
Routing Header Format =


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
 
    |   NEntry (8 bits)   | 
    | 
    +-+-+-+-+-+-+-+-+ 
    + 
    |         =
            &=
nbsp; Source Route Entry (128*NEntry bits) 
    | 
    + 
    + 
    | =

    | =


         Figure =
1. Proposed Source Routing Header Format; each line is 
    32 
    bits:) =


    - NEntry: Indicates the number =
of 128 bit addresses that the source 
    route 
    entry field is carrying. 

    - Source Route Entry: =
List of 128 bit address that consist the route 
    to the =

    destination. Here, the address of =
the node that is one hop away from 
    the 
    *destination* comes first. 

    2. Source Routing =
Packet Operations 

    When source routing is initiated at a storing =
node (e.g., root of 
    the 
    DODAG), 
    the header is attached on the data packet for the =
entire route 
    (i.e., 
    from 
    next hop node to the destination). This header is =
positioned in 
    front 
    of the 
    user payload. When the next hop node receives a packet =
that is not 
    destined 
    to itself AND the network is NOT provisioned to be in =
'storing mode' 
    then it 
    checks NEntry to find what the next hop is in the =
source route 
    entry. 
    Since 
    the 'Source Route Entry' is ordered in 'farthest -> =
closest' (in 
    terms 
    of hops) 
    order, a node can figure out what the next hop address =
is with only 
    the 
    NEntry value (since it already knows how big an ipv6 =
address is). 
    After 
    collecting the next hop node's address, the node =
erases this address 
    element from the entry and decreases NEntry by =
one. This assures 
    that 
    we 
    avoid the overhead of carrying the entire source route =
throughout 
    the 
    data 
    path. 

    The approach itself should be very =
simple and trivial for everyone 
    to 
    follow. 
    So we can start from here and build on! =


    Thanks. 

    -John 

    ------ 
    JeongGil Ko (John) =

    Ph.D. Student 
    Department of Computer Science 
    Johns Hopkins =
University 
    http://www.cs.jhu.edu/~jgko =


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

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

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

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

    Roll mailing list 
    Roll@ietf.org 
    https://www.ietf.org/=
mailman/listinfo/roll 
     
    
------_=_NextPart_001_01CAD7C1.E7F5F7B5--

From ulrich@herberg.name  Fri Apr  9 02:25:09 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BDF3A689C for ; Fri,  9 Apr 2010 02:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0dVKd6UVdYA for ; Fri,  9 Apr 2010 02:25:08 -0700 (PDT)
Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 7D3793A6359 for ; Fri,  9 Apr 2010 02:23:33 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2485781bwz.29 for ; Fri, 09 Apr 2010 02:23:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.114.66 with HTTP; Fri, 9 Apr 2010 02:23:23 -0700 (PDT)
In-Reply-To: <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu>
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu> <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> <6643.1270774314@marajade.sandelman.ca> <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu>
Date: Fri, 9 Apr 2010 11:23:23 +0200
Received: by 10.204.82.36 with SMTP id z36mr1608272bkk.88.1270805003816; Fri,  09 Apr 2010 02:23:23 -0700 (PDT)
Message-ID: 
From: Ulrich Herberg 
To: Philip Levis 
Content-Type: multipart/alternative; boundary=0016e6dd96afd4ce410483ca5899
Cc: roll WG 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 09:25:09 -0000

--0016e6dd96afd4ce410483ca5899
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 9, 2010 at 4:11 AM, Philip Levis  wrote:

>
> On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:
>
[...]

> >
> > The threat model that you describe, where an attacker has access to send
> > original data into the link appears to be out of scope from what I have
> > read.
> >
> > It seems that we will assume the layer-2 has sufficient protection that
> > an external attacker can not do what you describe.
>
> Michael,
>
> Unfortunately, we can't assume that layer-2 has any protection. This is the
> operating assumption behind all of the security work. Note that the possible
> presence of layer 2 mechanisms are why RPL's mechanisms are intended to be
> options: in networks with sufficient layer 2 protection they can be left
> out, but they can be used in those that need it.
>
> Phil
>


I agree with Phil. Since ROLL does not assume a particular L2, we cannot
assume any security protection in lower layers.

Ulrich

--0016e6dd96afd4ce410483ca5899
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    On Fri, Apr 9, 2010 at 4:11 AM, Philip Levis=
 <pal@cs.stanfo=
rd.edu> wrote:
    


    
On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:
    [...] 
    

    
>
    
> The threat model that you describe, where an attacker has access to se=
nd
    
> original data into the link appears to be out of scope from what I hav=
e
    
> read.
    
>
    
> It seems that we will assume the layer-2 has sufficient protection tha=
t
    
> an external attacker can not do what you describe.
    

    

    Michael,
    

    
Unfortunately, we can't assume that layer-2 has any protection. This is=
 the operating assumption behind all of the security work. Note that the po=
ssible presence of layer 2 mechanisms are why RPL's mechanisms are inte=
nded to be options: in networks with sufficient layer 2 protection they can=
 be left out, but they can be used in those that need it.
    



    
Phil


    I agree with Phil. Since ROLL=
 does not assume a particular L2, we cannot assume any security protection =
in lower layers.

    Ulrich
    

--0016e6dd96afd4ce410483ca5899--

From roll@tanglewoodnet.com  Fri Apr  9 02:30:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4343A6782 for ; Fri,  9 Apr 2010 02:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.352
X-Spam-Level: 
X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcKJ7cKPTySu for ; Fri,  9 Apr 2010 02:30:14 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id E4B1E3A6946 for ; Fri,  9 Apr 2010 02:30:12 -0700 (PDT)
Received: from oxltgw04.schlund.de (oxltgw04.schlund.de [172.19.158.42]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lb92n-1NG59Y3Itd-00kHam; Fri, 09 Apr 2010 11:30:05 +0200
Date: Fri, 9 Apr 2010 10:30:05 +0100 (BST)
From: "roll@tanglewoodnet.com" 
To: ROLL WG 
Message-ID: <1728700890.472279.1270805405793.JavaMail.open-xchange@oxltgw04.schlund.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_472278_1239962606.1270805405653"
X-Priority: 3
X-Mailer: Open-Xchange Mailer v6.14.0-Rev14
X-Provags-ID: V01U2FsdGVkX1/ONNZiFwdgEpUkQPfu3Oz4/YinmzvQ9yVw+F2 VEdatIXdsoTUAEK1rrHcCItlOTtomtPlCO3nJKj0HVxOMnQ/uQ n1A4ozFz4kjBeyFx8tqSJmiPMb4cyVg
Subject: [Roll] Resolving link quality values
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 09:30:14 -0000

------=_Part_472278_1239962606.1270805405653
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have a question on how to resolve link costs derived from LQI.
=C2=A0
Is it the intention that the metric container in a DIO can be used to repor=
t
incoming link quality metrics for a small set of 'selected neighbors'?
=C2=A0
I'm supposing that the selected set will include just parents plus children=
. A
newly joined node will just put parents in its selected set but if it sees =
a
report for itself in a DIO from a device of lower rank it will assume that =
it is
a child and add it to its selected set for reporting.
=C2=A0
Or is this assumed to be the role some layer 2 mechanism?
=C2=A0
Thanks
=C2=A0
Peter Burnett
=C2=A0
------=_Part_472278_1239962606.1270805405653
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit




  
    
    
  

  
    
    I have a question on how to resolve link costs derived from LQI.
    

    
     
    

    
    Is it the intention that the metric container in a DIO can be used to report incoming link quality metrics for a small set of 'selected neighbors'?
    

    
     
    

    
    I'm supposing that the selected set will include just parents plus children. A newly joined node will just put parents in its selected set but if it sees a report for itself in a DIO from a device of lower rank it will assume that it is a child and add it to its selected set for reporting.
    

    
     
    

    
    Or is this assumed to be the role some layer 2 mechanism?
    

    
     
    

    
    Thanks
    

    
     
    

    
    Peter Burnett
    

    
     
    
  


------=_Part_472278_1239962606.1270805405653--

From Daniel.Popa@itron.com  Fri Apr  9 02:45:52 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E423A68D9 for ; Fri,  9 Apr 2010 02:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfHE-sZsLjen for ; Fri,  9 Apr 2010 02:45:38 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 486273A6827 for ; Fri,  9 Apr 2010 02:45:37 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7C9.64AFA60A"
Date: Fri, 9 Apr 2010 05:45:29 -0400
Message-ID: 
X-MimeOLE: Produced By Microsoft Exchange V6.5
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAJQ/eA=
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
From: "Popa, Daniel" 
To: "Pascal Thubert (pthubert)" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 09:45:52 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7C9.64AFA60A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Pascal,=20

=20

I have first set of proposals concerning the tag/label size and content:

=20

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address =
and 64-bit extended address for Src and Dest Addressing Mode, I think we =
should have the same flexibility for tag/label addressing mode =3D> =
tag/label should potentially accommodate values represented on a field =
with a length up to 64 bits.=20

o   Currently, there are ongoing activities to amend MAC Layer for =
802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC =
address size. I will try have some further information about MAC Addr =
Length issue and be back on the mailing list asap.  =20

=20

-          Tag/Label contents:

=20

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

| Control fields | Label Value |=20

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

=20

o   Control fields

=A7  2 bits to signal labeling/tagging mode:  short/extended labels  =
=3D> the bit-length of the "Label Value (LV)"  field=20

=B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.=20

=A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 =
priority field into label priority).

=A7  Eventually, 1 bit for bottom of the stack flag - for source =
routing;  if set to 1 =3D> the current label/tag is last in the stack.

=A7  1 or 2 bits RFU.

=A7  Eventually, some bits for hop counts (?).

o   Label Value (LV) field

=A7  The value of the label/tag

=20

=20

Thanks.

=20

Cheers,

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Pascal Thubert (pthubert)
Sent: vendredi 9 avril 2010 10:36
To: robert.cragie@gridmerge.com; Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations

=20

I read this as a consensus to use tags J If anyone disagree please speak =
up now!

=20

There have been plenty iterations/versions of tagging since Frame Relay =
(pure switching), IBM's HPR (pure source route), Cisco's tag switching =
and MPLS. More often than not, a combination of the 2 models is used so =
that tags can be both swapped and stacked.=20

=20

-          In pure switching, there's only one tag in the packet. A tag =
can be locally significant, in which case it has to be swapped as the =
packet progresses. For RPL, it means that a node uses as many tags as it =
has children that use it has DAO targets in its subdag.

=20

-          In the pure source route model, tags are stacked in an =
ordered list that forms a strict routing header. A tag can be locally =
significant to the interpreter and is consumed (marked or removed) as =
the packet progresses. For RPL, it means that a node uses as many tags =
as it has children that use this node as DAO parent.=20

=20

It also appears that the 2 tagging models map quite well with the DAO =
models we have in RPL since the split that we decided with issue #26. =
The fact that the combination of the 2 models is possible in the real =
world today gives us a hint that we are not closing the door to the =
mixed model in the future.

=20

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by =
the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need =
to dig further)

-          Tag content and size (people have asked for at least 2 octets =
to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of =
addresses? What about the tag swapping  case, RH as well?)

=20

Advice?

=20

=20

=20

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand =
SourceRoutingOperations

=20

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20


Hi Robert,=20

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20



A couple of questions:=20
    * I presume the source route header using these tags/labels is an =
IPv6 extension header. What value for extension header type would this =
be? Would we need to specify a LOWPAN_NHC value for this so we can still =
use LOWPAN_NCH for UDP frames?=20


We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented it at 6man in Anaheim.  The option is designed to carry =
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for =
the IPv6 Hop-by-Hop Option header.=20



    * Can you point to where the 'core ideas have been deployed in =
traditional IP networks for quite some time'?=20


MPLS.  Again, I think the mechanisms will need to be adapted, but the =
core ideas are not new.=20

--=20
Jonathan Hui=20



Thanks=20

Robert=20
Robert Cragie (Pacific Gas & Electric)=20

Gridmerge Ltd.=20
89 Greenfield Crescent,=20
Wakefield, WF4 4WA, UK=20
+44 (0) 1924 910888=20
http://www.gridmerge.com=20


On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20



To make the source route header compact, I favor the tag/label approach =
over some other compaction mechanism that operates directly on a list of =
IPv6 addresses.  Tags/labels can be made general enough such that they =
can be derived in different ways.  Because the tags/labels have scope =
local to each node, the mechanism is pretty general already.  For those =
that are already managing unique 802.15.4 short addresses across a =
network, I can see that it is attractive to utilize the short address =
directly and reduce state on devices.  In other cases, it may be best =
for the node to dynamically assign tags/labels for its neighbors.=20

Either way, while the tag/label mechanism is simple, it is far more =
flexible than an approach to compacting a list of IPv6 addresses.  And =
note that the idea of using tags/labels is nothing new.  Of course we =
will adapt the basic mechanism a bit (label distribution, headers =
formats, etc), but the core ideas have been deployed in traditional IP =
networks for quite some time.=20

I reiterated a lot of what was already stated before by others, but that =
is what I think.=20

--=20
Jonathan Hui=20

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20



Hi Daniel:=20

Routers might have multiple interfaces of multiple MAC types. Internet 0 =

even has a MAC-less format.=20
So the result of you proposal, which looks like a great idea in a pure=20
802.15.4 world with short addresses, becomes a nightmare to define in a=20
fully generic fashion.=20

OTOH, a locally significant opaque tag in which the parent could hide a=20
short address of the child - if it cares to do it that way - looks like=20
a way more acceptable approach=20

So it seems to me that you can get what you want as long as we can make=20
the tag big enough for short addresses. When the tag is too small to=20
contain what the parent really needs, then the parent will have to store =

a state with the full information in memory, and then place an index of=20
some sort in the tag.=20

What do you think?=20

Pascal=20




-----Original Message-----=20
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
Sent: Thursday, April 08, 2010 11:40 AM=20
To: ROLL WG=20
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
Subject: RE: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi Pascal, John,=20

Since source routing explicitly gives forwarding instruction to each=20
intermediate node, it can make sense to use only (MAC address based)=20

L2=20

forwarding instead of (IPv6 address based) L3 forwarding.=20

This brings two advantages:=20
- avoid processing each transit packets up to L3.=20
- use MAC addresses that - in ROLL environment - have inherently=20

shorter=20

length than an IPv6 address.=20

Cheers,=20
Daniel=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

Pascal Thubert (pthubert)=20
Sent: jeudi 8 avril 2010 11:15=20
To: JeongGil Ko (John); ROLL WG=20
Subject: Re: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi John:=20

IPv6 already has a number of routing headers, in particular RH0,=20

though it is=20

being deprecated for general use in the Internet.=20
And there are reasons why the fields in RH0/1 are there and we need to=20
make sure we lose none of that. In particular a RH is recoverable, and=20

it is=20

easy to spot the consumed entries.=20

On top of this our new problems are:=20
- make sure the RH stays within the RPL network (since it is used=20

downwards=20

that should be doable)=20
- control the size (that probably means compress)=20

Cheers,=20

Pascal=20




-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

JeongGil Ko (John)=20
Sent: Wednesday, April 07, 2010 10:05 PM=20
To: ROLL WG=20
Subject: [Roll] Proposal for Source Routing Header Format and Source=20
RoutingOperations=20

Hi!=20

Great to see all this discussions on downwards route establishment!=20

To=20

add=20

one more to the conversations here is a proposal for source routing=20

headers.=20

In non-storing mode (where only the root has individual path=20

information)=20

the root will be attaching a source routing header to the data=20

packet=20

that a=20

source node wants to send to a specific destination. We can always=20

make the=20

header super fancy but in my opinion I think we only need two fields=20

in this=20

header and here it is! Feel free to break the stuff and mangle with=20

it=20

so that it=20

looks great in the specs later on. FYI, this is the format that I am=20

using in my=20

implementations so it does work :)=20

1. Source Routing Header Format=20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|   NEntry (8 bits)   |=20

|=20

+-+-+-+-+-+-+-+-+=20

+=20

|                       Source Route Entry (128*NEntry bits)=20

|=20

+=20

+=20

|=20

|=20


     Figure 1. Proposed Source Routing Header Format; each line is=20

32=20

bits:)=20


- NEntry: Indicates the number of 128 bit addresses that the source=20

route=20

entry field is carrying.=20

- Source Route Entry: List of 128 bit address that consist the route=20

to the=20

destination. Here, the address of the node that is one hop away from=20

the=20

*destination* comes first.=20

2. Source Routing Packet Operations=20

When source routing is initiated at a storing node (e.g., root of=20

the=20

DODAG),=20

the header is attached on the data packet for the entire route=20

(i.e.,=20

from=20

next hop node to the destination). This header is positioned in=20

front=20

of the=20

user payload. When the next hop node receives a packet that is not=20

destined=20

to itself AND the network is NOT provisioned to be in 'storing mode'=20

then it=20

checks NEntry to find what the next hop is in the source route=20

entry.=20

Since=20

the 'Source Route Entry' is ordered in 'farthest -> closest' (in=20

terms=20

of hops)=20

order, a node can figure out what the next hop address is with only=20

the=20

NEntry value (since it already knows how big an ipv6 address is).=20

After=20

collecting the next hop node's address, the node erases this address=20
element from the entry and decreases NEntry by one. This assures=20

that=20

we=20

avoid the overhead of carrying the entire source route throughout=20

the=20

data=20

path.=20

The approach itself should be very simple and trivial for everyone=20

to=20

follow.=20

So we can start from here and build on!=20

Thanks.=20

-John=20

------=20
JeongGil Ko (John)=20
Ph.D. Student=20
Department of Computer Science=20
Johns Hopkins University=20
http://www.cs.jhu.edu/~jgko=20

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

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

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


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

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

=20


------_=_NextPart_001_01CAD7C9.64AFA60A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













    


    Hi Pascal, 
    


     
    


    I have first set of proposals concerning the tag/label =
size
and content:
    


     
    


    -         
Tag/Label =
size:
    


    o   =
As
802.15.4-2006 defines addressing modes with 16-bit short address and =
64-bit
extended address for Src and Dest Addressing Mode, I think we should =
have the
same flexibility for tag/label addressing mode =3D> tag/label should =
potentially
accommodate values represented on a field with a length up to 64 bits. =

    


    o   =
Currently,
there are ongoing activities to amend MAC Layer for 802.15.4-2006 (TG =
4e) that
might alter the aforementioned values for MAC address size. I will try =
have
some further information about MAC Addr Length issue and be back on the =
mailing
list asap. =A0=A0
    


     
    


    -         
Tag/Label =
contents:
    


     
    


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

    


    | Control fields | Label Value | =

    


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

    


     
    


    o   =
Control
fields
    


    =A7  =
2
bits to signal labeling/tagging mode: =A0short/extended labels =
=A0=3D> the bit-length
of the “Label Value (LV)” =A0field =

    


    =B7        
2 bits =3D> 4 modes for LV length : 8, 16, 32 and =
64 bits. 
    


    =A7  =
Eventually,
few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 priority field =
into label
priority).
    


    =A7  =
Eventually,
1 bit for bottom of the stack flag - for source routing; =A0if =
set to 1
=3D> the current label/tag is last in the =
stack.
    


    =A7  =
1
or 2 bits RFU.
    


    =A7  =
Eventually,
some bits for hop counts (?).
    


    o   =
Label
Value (LV) field
    


    =A7  =
The
value of the label/tag
    


     
    


    =A0
    


    Thanks.
    


    =A0
    


    Cheers,
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert =
(pthubert)
    
Sent: vendredi 9 avril 2010 10:36
    
To: robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


     
    


    There have been plenty iterations/versions of tagging =
since
Frame Relay (pure switching), IBM’s HPR (pure source route), =
Cisco’s
tag switching and MPLS. More often than not, a combination of the 2 =
models is
used so that tags can be both swapped and stacked. =

    


     
    


    -         
In pure switching, there’s only one tag in the =
packet. A
tag can be locally significant, in which case it has to be swapped as =
the
packet progresses. For RPL, it means that a node uses as many tags as it =
has
children that use it has DAO targets in its =
subdag.
    


     
    


    -         
In the pure source route model, tags are stacked in an =
ordered
list that forms a strict routing header. A tag can be locally =
significant to
the interpreter and is consumed (marked or removed) as the packet =
progresses.
For RPL, it means that a node uses as many tags as it has children that =
use
this node as DAO parent. 
    


     
    


    It also appears that the 2 tagging models map quite well =
with
the DAO models we have in RPL since the split that we decided with issue =
#26.
The fact that the combination of the 2 models is possible in the real =
world
today gives us a hint that we are not closing the door to the mixed =
model in
the future.
    


     
    


    The next step I wish to agree upon:
    


    -         
Use locally significant tags which implies tag assignment =
by the
node that uses it later and tag swapping for the stateful =
case.
    


    -         
Tag distribution in DAO (there are options there that we =
need to
dig further)
    


    -         
Tag content and size (people have asked for at least 2 =
octets to
fit 15.4 short addresses, do we need some control field as =
well?)
    


    -         
RH format (inherit RH0 fields with labels instead of =
addresses?
What about the tag swapping  case, RH as =
well?)
    


     
    


    Advice?
    


     
    


     
    


     
    


     
    


    


    Pascal
    


    


     
    


    


    


    


    From: =
roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    OK, sounds good. End of topic as far as I am =
concerned. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    

    

    


    A couple of questions: 
    
    • I presume the source route header using =
these
tags/labels is an IPv6 extension header. What value for extension header =
type
would this be? Would we need to specify a LOWPAN_NHC value for this so =
we can
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented
it at 6man in Anaheim.  The option is designed to carry =
RPL-specific
information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6
Hop-by-Hop Option header. 
    

    

    


        • Can you point to =
where the
'core ideas have been deployed in traditional IP networks for quite some =
time'?

    



    
MPLS.  Again, I think the mechanisms will need to be adapted, but =
the core
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    

    

    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach =
over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they =
can be
derived in different ways.  Because the tags/labels have scope =
local to
each node, the mechanism is pretty general already.  For those that =
are
already managing unique 802.15.4 short addresses across a network, I can =
see
that it is attractive to utilize the short address directly and reduce =
state on
devices.  In other cases, it may be best for the node to =
dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more =
flexible
than an approach to compacting a list of IPv6 addresses.  And note =
that
the idea of using tags/labels is nothing new.  Of course we will =
adapt the
basic mechanism a bit (label distribution, headers formats, etc), but =
the core
ideas have been deployed in traditional IP networks for quite some time. =

    

    
I reiterated a lot of what was already stated before by others, but that =
is
what I think. 
    

    
-- 
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: 
    

    

    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 =

    
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure =

    
802.15.4 world with short addresses, becomes a nightmare to define in a =

    
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a =

    
short address of the child - if it cares to do it that way - looks like =

    
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make =

    
the tag big enough for short addresses. When the tag is too small to =

    
contain what the parent really needs, then the parent will have to store =

    
a state with the full information in memory, and then place an index of =

    
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    

    

    

    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each =

    
intermediate node, it can make sense to use only (MAC address based) =

    


    L2 
    


    forwarding instead of (IPv6 address based) L3 =
forwarding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently =

    


    shorter =

    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, =

    


    though it is =

    


    being deprecated for general use in the Internet. =

    
And there are reasons why the fields in RH0/1 are there and we need to =

    
make sure we lose none of that. In particular a RH is recoverable, and =

    


    it is =

    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used =

    


    downwards =

    


    that should be =
doable) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    

    

    

    


    -----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source =

    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! =

    


    To 
    


    add 
    


    one more to the conversations here is a proposal =
for source
routing 
    


    headers. =

    


    In non-storing mode (where only the root has =
individual path

    


    information) =

    


    the root will be attaching a source routing header =
to the
data 
    


    packet =

    


    that a =

    


    source node wants to send to a specific =
destination. We can
always 
    


    make the =

    


    header super fancy but in my opinion I think we =
only need
two fields 
    


    in this =

    


    header and here it is! Feel free to break the stuff =
and
mangle with 
    


    it 
    


    so that it =

    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my =

    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|   NEntry (8 bits)   | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |         =
            &=
nbsp;
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
     Figure 1. Proposed Source Routing Header =
Format; each
line is 
    


    32 
    


    bits:) =

    



    
- NEntry: Indicates the number of 128 bit addresses that the source =

    


    route =

    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route =

    


    to the =

    


    destination. Here, the address of the node that is =
one hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of =

    


    the 
    


    DODAG), =

    


    the header is attached on the data packet for the =
entire
route 
    


    (i.e., =

    


    from 
    


    next hop node to the destination). This header is =
positioned
in 
    


    front =

    


    of the =

    


    user payload. When the next hop node receives a =
packet that
is not 
    


    destined =

    


    to itself AND the network is NOT provisioned to be =
in
'storing mode' 
    


    then it =

    


    checks NEntry to find what the next hop is in the =
source
route 
    


    entry. =

    


    Since =

    


    the 'Source Route Entry' is ordered in 'farthest =
->
closest' (in 
    


    terms =

    


    of hops) =

    


    order, a node can figure out what the next hop =
address is
with only 
    


    the 
    


    NEntry value (since it already knows how big an =
ipv6 address
is). 
    


    After =

    


    collecting the next hop node's address, the node =
erases this
address 
    
element from the entry and decreases NEntry by one. This assures =

    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source =
route
throughout 
    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone =

    


    to 
    


    follow. =

    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko =

    

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

    


    _______________________________________________ =

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

    


    _______________________________________________ =

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

    



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

    


    _______________________________________________ =

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

    


     
    


    


    





------_=_NextPart_001_01CAD7C9.64AFA60A--

From abr@sdesigns.dk  Fri Apr  9 03:04:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAD43A69D7 for ; Fri,  9 Apr 2010 03:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level: 
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.780,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDXLuSYSSBo0 for ; Fri,  9 Apr 2010 03:04:13 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 012FB3A6987 for ; Fri,  9 Apr 2010 03:03:53 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7CB.F3866140"
Date: Fri, 9 Apr 2010 12:03:49 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A013@zensys17.zensys.local>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQAAAGJtUAACdZkg
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local> <6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com>
From: "Anders Brandt" 
To: "Pascal Thubert (pthubert)" , , "Jonathan Hui" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 10:04:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7CB.F3866140
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Pascal,

=20

>One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?

=20
Typically a network key is shared among all nodes. A few nodes (e.g.
electronic door locks with extra high security requirements) may have
dedicated link keys.
The link keys work end-to-end and do not require storage in all other
nodes.
Thus, the most simple nodes need only storage for a network key.
=20
- Anders


________________________________

	From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20
	Sent: Friday, April 09, 2010 10:52
	To: Anders Brandt; robert.cragie@gridmerge.com; Jonathan Hui
	Cc: roll@ietf.org
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
=09
=09

	Hi Anders:

	=20

	You did not miss much. But maybe the fact that the tag could be
stateless as long as the node knows how to do that.=20

	For instance a short address could be encoded in there, as long
as this is opaque to the rest of the L3 network.

	One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?

	=20

	Pascal

	=20

	From: Anders Brandt [mailto:abr@sdesigns.dk]=20
	Sent: Friday, April 09, 2010 10:43 AM
	To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com;
Jonathan Hui
	Cc: roll@ietf.org
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	=20

	Admitted, I have been absent from this thread; trying to catch
up on others...

	=20

	> I read this as a consensus to use tags J If anyone disagree
please speak up now!

	I have to comment respectfully but loudly that this may at best
some sort of rough concensus..

	=20

	In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.

	For this kind of nodes we need a complete routing stack in the
frame. As mentioned earlier, I am perfectly
	fine with limitations such as max n entries; Compression of
addresses to 16 bits and a common subnet.

	=20

	Just my $0.05

	=20

	=20

		=20

	=09
________________________________


		From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
		Sent: Friday, April 09, 2010 10:36
		To: robert.cragie@gridmerge.com; Jonathan Hui
		Cc: roll@ietf.org
		Subject: Re: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		I read this as a consensus to use tags J If anyone
disagree please speak up now!

		=20

		There have been plenty iterations/versions of tagging
since Frame Relay (pure switching), IBM's HPR (pure source route),
Cisco's tag switching and MPLS. More often than not, a combination of
the 2 models is used so that tags can be both swapped and stacked.=20

		=20

		-          In pure switching, there's only one tag in
the packet. A tag can be locally significant, in which case it has to be
swapped as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use it has DAO targets in its subdag.

		=20

		-          In the pure source route model, tags are
stacked in an ordered list that forms a strict routing header. A tag can
be locally significant to the interpreter and is consumed (marked or
removed) as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use this node as DAO parent.=20

		=20

		It also appears that the 2 tagging models map quite well
with the DAO models we have in RPL since the split that we decided with
issue #26. The fact that the combination of the 2 models is possible in
the real world today gives us a hint that we are not closing the door to
the mixed model in the future.

		=20

		The next step I wish to agree upon:

		-          Use locally significant tags which implies
tag assignment by the node that uses it later and tag swapping for the
stateful case.

		-          Tag distribution in DAO (there are options
there that we need to dig further)

		-          Tag content and size (people have asked for
at least 2 octets to fit 15.4 short addresses, do we need some control
field as well?)

		-          RH format (inherit RH0 fields with labels
instead of addresses? What about the tag swapping  case, RH as well?)

		=20

		Advice?

		=20

		Pascal

		=20

		From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
		Sent: Thursday, April 08, 2010 11:34 PM
		To: Jonathan Hui
		Cc: roll@ietf.org
		Subject: Re: [Roll] Proposal for Source Routing Header
Formatand SourceRoutingOperations

		=20

		OK, sounds good. End of topic as far as I am concerned.
+1
	=09
		Robert

		Robert Cragie (Pacific Gas & Electric)

		Gridmerge Ltd.
		89 Greenfield Crescent,
		Wakefield, WF4 4WA, UK
		+44 (0) 1924 910888
		http://www.gridmerge.com =20

	=09
		On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20

	=09
		Hi Robert,=20
	=09
		On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20
	=09
	=09

		A couple of questions:=20
		    * I presume the source route header using these
tags/labels is an IPv6 extension header. What value for extension header
type would this be? Would we need to specify a LOWPAN_NHC value for this
so we can still use LOWPAN_NCH for UDP frames?=20

	=09
		We already have a draft requesting a new IPv6 Hop-by-Hop
Option and presented it at 6man in Anaheim.  The option is designed to
carry RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC
value for the IPv6 Hop-by-Hop Option header.=20
	=09
	=09

		    * Can you point to where the 'core ideas have been
deployed in traditional IP networks for quite some time'?=20

	=09
		MPLS.  Again, I think the mechanisms will need to be
adapted, but the core ideas are not new.=20
	=09
		--=20
		Jonathan Hui=20
	=09
	=09

		Thanks=20
	=09
		Robert=20
		Robert Cragie (Pacific Gas & Electric)=20
	=09
		Gridmerge Ltd.=20
		89 Greenfield Crescent,=20
		Wakefield, WF4 4WA, UK=20
		+44 (0) 1924 910888=20
		http://www.gridmerge.com=20
	=09
	=09
		On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20

	=09
	=09
		To make the source route header compact, I favor the
tag/label approach over some other compaction mechanism that operates
directly on a list of IPv6 addresses.  Tags/labels can be made general
enough such that they can be derived in different ways.  Because the
tags/labels have scope local to each node, the mechanism is pretty
general already.  For those that are already managing unique 802.15.4
short addresses across a network, I can see that it is attractive to
utilize the short address directly and reduce state on devices.  In
other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors.=20
	=09
		Either way, while the tag/label mechanism is simple, it
is far more flexible than an approach to compacting a list of IPv6
addresses.  And note that the idea of using tags/labels is nothing new.
Of course we will adapt the basic mechanism a bit (label distribution,
headers formats, etc), but the core ideas have been deployed in
traditional IP networks for quite some time.=20
	=09
		I reiterated a lot of what was already stated before by
others, but that is what I think.=20
	=09
		--=20
		Jonathan Hui=20
	=09
		On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert)
wrote:=20
	=09
	=09

		Hi Daniel:=20
	=09
		Routers might have multiple interfaces of multiple MAC
types. Internet 0=20
		even has a MAC-less format.=20
		So the result of you proposal, which looks like a great
idea in a pure=20
		802.15.4 world with short addresses, becomes a nightmare
to define in a=20
		fully generic fashion.=20
	=09
		OTOH, a locally significant opaque tag in which the
parent could hide a=20
		short address of the child - if it cares to do it that
way - looks like=20
		a way more acceptable approach=20
	=09
		So it seems to me that you can get what you want as long
as we can make=20
		the tag big enough for short addresses. When the tag is
too small to=20
		contain what the parent really needs, then the parent
will have to store=20
		a state with the full information in memory, and then
place an index of=20
		some sort in the tag.=20
	=09
		What do you think?=20
	=09
		Pascal=20
	=09
	=09
	=09

		-----Original Message-----=20
		From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
		Sent: Thursday, April 08, 2010 11:40 AM=20
		To: ROLL WG=20
		Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
		Subject: RE: [Roll] Proposal for Source Routing Header
Format and=20
		SourceRoutingOperations=20
	=09
		Hi Pascal, John,=20
	=09
		Since source routing explicitly gives forwarding
instruction to each=20
		intermediate node, it can make sense to use only (MAC
address based)=20

		L2=20

		forwarding instead of (IPv6 address based) L3
forwarding.=20
	=09
		This brings two advantages:=20
		- avoid processing each transit packets up to L3.=20
		- use MAC addresses that - in ROLL environment - have
inherently=20

		shorter=20

		length than an IPv6 address.=20
	=09
		Cheers,=20
		Daniel=20
	=09
	=09
	=09
		-----Original Message-----=20
		From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf=20

		Of=20

		Pascal Thubert (pthubert)=20
		Sent: jeudi 8 avril 2010 11:15=20
		To: JeongGil Ko (John); ROLL WG=20
		Subject: Re: [Roll] Proposal for Source Routing Header
Format and=20
		SourceRoutingOperations=20
	=09
		Hi John:=20
	=09
		IPv6 already has a number of routing headers, in
particular RH0,=20

		though it is=20

		being deprecated for general use in the Internet.=20
		And there are reasons why the fields in RH0/1 are there
and we need to=20
		make sure we lose none of that. In particular a RH is
recoverable, and=20

		it is=20

		easy to spot the consumed entries.=20
	=09
		On top of this our new problems are:=20
		- make sure the RH stays within the RPL network (since
it is used=20

		downwards=20

		that should be doable)=20
		- control the size (that probably means compress)=20
	=09
		Cheers,=20
	=09
		Pascal=20
	=09
	=09
	=09

		-----Original Message-----=20
		From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf=20

		Of=20

		JeongGil Ko (John)=20
		Sent: Wednesday, April 07, 2010 10:05 PM=20
		To: ROLL WG=20
		Subject: [Roll] Proposal for Source Routing Header
Format and Source=20
		RoutingOperations=20
	=09
		Hi!=20
	=09
		Great to see all this discussions on downwards route
establishment!=20

		To=20

		add=20

		one more to the conversations here is a proposal for
source routing=20

		headers.=20

		In non-storing mode (where only the root has individual
path=20

		information)=20

		the root will be attaching a source routing header to
the data=20

		packet=20

		that a=20

		source node wants to send to a specific destination. We
can always=20

		make the=20

		header super fancy but in my opinion I think we only
need two fields=20

		in this=20

		header and here it is! Feel free to break the stuff and
mangle with=20

		it=20

		so that it=20

		looks great in the specs later on. FYI, this is the
format that I am=20

		using in my=20

		implementations so it does work :)=20
	=09
		1. Source Routing Header Format=20
	=09
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
		|   NEntry (8 bits)   |=20

		|=20

		+-+-+-+-+-+-+-+-+=20

		+=20

		|                       Source Route Entry (128*NEntry
bits)=20

		|=20

		+=20

		+=20

		|=20

		|=20

	=09
		     Figure 1. Proposed Source Routing Header Format;
each line is=20

		32=20

		bits:)=20

	=09
		- NEntry: Indicates the number of 128 bit addresses that
the source=20

		route=20

		entry field is carrying.=20
	=09
		- Source Route Entry: List of 128 bit address that
consist the route=20

		to the=20

		destination. Here, the address of the node that is one
hop away from=20

		the=20

		*destination* comes first.=20
	=09
		2. Source Routing Packet Operations=20
	=09
		When source routing is initiated at a storing node
(e.g., root of=20

		the=20

		DODAG),=20

		the header is attached on the data packet for the entire
route=20

		(i.e.,=20

		from=20

		next hop node to the destination). This header is
positioned in=20

		front=20

		of the=20

		user payload. When the next hop node receives a packet
that is not=20

		destined=20

		to itself AND the network is NOT provisioned to be in
'storing mode'=20

		then it=20

		checks NEntry to find what the next hop is in the source
route=20

		entry.=20

		Since=20

		the 'Source Route Entry' is ordered in 'farthest ->
closest' (in=20

		terms=20

		of hops)=20

		order, a node can figure out what the next hop address
is with only=20

		the=20

		NEntry value (since it already knows how big an ipv6
address is).=20

		After=20

		collecting the next hop node's address, the node erases
this address=20
		element from the entry and decreases NEntry by one. This
assures=20

		that=20

		we=20

		avoid the overhead of carrying the entire source route
throughout=20

		the=20

		data=20

		path.=20
	=09
		The approach itself should be very simple and trivial
for everyone=20

		to=20

		follow.=20

		So we can start from here and build on!=20
	=09
		Thanks.=20
	=09
		-John=20
	=09
		------=20
		JeongGil Ko (John)=20
		Ph.D. Student=20
		Department of Computer Science=20
		Johns Hopkins University=20
		http://www.cs.jhu.edu/~jgko=20
	=09
		_______________________________________________=20
		Roll mailing list=20
		Roll@ietf.org=20
		https://www.ietf.org/mailman/listinfo/roll=20

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

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

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

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

		=20


------_=_NextPart_001_01CAD7CB.F3866140
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    Pascal,
    

     
    

    >One question though. In your case, =
do you /=20
can you maintain any information about neighbors? Like security=20
?
    

     
    

    Typically a =
network key=20
is shared among all nodes. A few nodes (e.g. electronic door locks with =
extra=20
high security requirements) may have dedicated link keys.
    The link =
keys work=20
end-to-end and do not require storage in all other nodes.
    Thus, the =
most=20
simple nodes need only storage for a network key.
    

     
    

    -=20
Anders

    

    
  
    
  
    
  From: Pascal Thubert (pthubert)=20
  [mailto:pthubert@cisco.com] 
    Sent: Friday, April 09, 2010=20
  10:52
    To: Anders Brandt; robert.cragie@gridmerge.com; =
Jonathan=20
  Hui
    Cc: roll@ietf.org
    Subject: RE: [Roll] Proposal =
for=20
  Source Routing HeaderFormatand =
SourceRoutingOperations

    
  
    
  
    
  
    Hi=20
  Anders:
    
  
     
    
  
    You=20
  did not miss much. But maybe the fact that the tag could be stateless =
as long=20
  as the node knows how to do that. 
    
  
    For=20
  instance a short address could be encoded in there, as long as this is =
opaque=20
  to the rest of the L3 network.
    
  
    One=20
  question though. In your case, do you / can you maintain any =
information about=20
  neighbors? Like security ?
    
  
     
    
  
    
  
    Pascal
    
  
     
    
  
  
    
  
  
    From:=20
  Anders Brandt [mailto:abr@sdesigns.dk] 
    Sent: Friday, April =
09, 2010=20
  10:43 AM
    To: Pascal Thubert (pthubert); =
robert.cragie@gridmerge.com;=20
  Jonathan Hui
    Cc: roll@ietf.org
    Subject: RE: [Roll] =

  Proposal for Source Routing HeaderFormatand=20
  SourceRoutingOperations
    
  
     
    
  
    Admitted,=20
  I have been absent from this thread; trying to catch up on=20
  others...
    
  
     
    
  
    >=20
  I read this as a consensus to use tags J=20
  If anyone disagree please speak up now!
    
  
    I have=20
  to comment respectfully but loudly that this may at best some sort of =
rough=20
  concensus..
    
  
     
    
  
    In a=20
  non-storing mode, I see no way of storing and/or swapping labels/tags =
in each=20
  node.
    
  
    For=20
  this kind of nodes we need a complete routing stack in the frame. As =
mentioned=20
  earlier, I am perfectly
    fine with limitations such as max n =
entries;=20
  Compression of addresses to 16 bits and a common subnet.
    
  
     
    
  
    Just=20
  my $0.05
    
  
     
    
  
     
    
  
    
     
    
    
    
    
    
    
    
    
    From:=20
    roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =

    Pascal Thubert (pthubert)
    Sent: Friday, April 09, 2010 =

    10:36
    To: robert.cragie@gridmerge.com; Jonathan =
Hui
    Cc:=20
    roll@ietf.org
    Subject: Re: [Roll] Proposal for Source =
Routing=20
    HeaderFormatand SourceRoutingOperations
    
    
    I=20
    read this as a consensus to use tags J=20
    If anyone disagree please speak up now!
    
    
     
    
    
    There=20
    have been plenty iterations/versions of tagging since Frame Relay =
(pure=20
    switching), IBM’s HPR (pure source route), Cisco’s tag =
switching and MPLS.=20
    More often than not, a combination of the 2 models is used so that =
tags can=20
    be both swapped and stacked. 
    
    
     
    
    
    -         =20
    In=20
    pure switching, there’s only one tag in the packet. A tag can =
be locally=20
    significant, in which case it has to be swapped as the packet =
progresses.=20
    For RPL, it means that a node uses as many tags as it has children =
that use=20
    it has DAO targets in its subdag.
    
    
     
    
    
    -         =20
    In=20
    the pure source route model, tags are stacked in an ordered list =
that forms=20
    a strict routing header. A tag can be locally significant to the =
interpreter=20
    and is consumed (marked or removed) as the packet progresses. For =
RPL, it=20
    means that a node uses as many tags as it has children that use this =
node as=20
    DAO parent. 
    
    
     
    
    
    It=20
    also appears that the 2 tagging models map quite well with the DAO =
models we=20
    have in RPL since the split that we decided with issue #26. The fact =
that=20
    the combination of the 2 models is possible in the real world today =
gives us=20
    a hint that we are not closing the door to the mixed model in the=20
    future.
    
    
     
    
    
    The=20
    next step I wish to agree upon:
    
    
    -         =20
    Use=20
    locally significant tags which implies tag assignment by the node =
that uses=20
    it later and tag swapping for the stateful =
case.
    
    
    -         =20
    Tag=20
    distribution in DAO (there are options there that we need to dig=20
    further)
    
    
    -         =20
    Tag=20
    content and size (people have asked for at least 2 octets to fit =
15.4 short=20
    addresses, do we need some control field as =
well?)
    
    
    -         =20
    RH=20
    format (inherit RH0 fields with labels instead of addresses? What =
about the=20
    tag swapping  case, RH as well?)
    
    
     
    
    
    Advice?
    
    
     
    
    
    
    
    Pascal
    
    
     
    
    
    
    
    
    
    From:=20
    roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =

    Robert Cragie
    Sent: Thursday, April 08, 2010 11:34=20
    PM
    To: Jonathan Hui
    Cc: =
roll@ietf.org
    Subject:=20
    Re: [Roll] Proposal for Source Routing Header Formatand=20
    SourceRoutingOperations
    
    
     
    
    
    OK, sounds good. End of topic as far as I am =
concerned.=20
    +1

    Robert
    
    
    
    
    Robert Cragie (Pacific Gas & =
Electric)
    
    
    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA,=20
    UK
    +44 (0) 1924 910888
    http://www.gridmerge.com
    
    

    On 08/04/2010 10:17 PM, Jonathan Hui wrote: =

    
    
    

    Hi Robert, =


    On Apr=20
    8, 2010, at 2:06 PM, Robert Cragie wrote: 

    
    
    A couple of questions: =

        • I=20
    presume the source route header using these tags/labels is an IPv6 =
extension=20
    header. What value for extension header type would this be? Would we =
need to=20
    specify a LOWPAN_NHC value for this so we can still use LOWPAN_NCH =
for UDP=20
    frames? 
    
    

    We already =
have a draft=20
    requesting a new IPv6 Hop-by-Hop Option and presented it at 6man in=20
    Anaheim.  The option is designed to carry RPL-specific=20
    information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6=20
    Hop-by-Hop Option header. 

    
    
        • Can you point =
to where the=20
    'core ideas have been deployed in traditional IP networks for quite =
some=20
    time'? 
    
    

    MPLS.  =
Again, I=20
    think the mechanisms will need to be adapted, but the core ideas are =
not=20
    new. 

    -- 
    Jonathan Hui 

    
    
    Thanks =


    Robert=20
    
    Robert Cragie (Pacific Gas & Electric) 

    Gridmerge =
Ltd. 
    89=20
    Greenfield Crescent, 
    Wakefield, WF4 4WA, UK 
    +44 (0) 1924 =
910888=20
    
    http://www.gridmerge.com=20
    


    On 08/04/2010 3:57 PM, Jonathan Hui wrote: =

    
    


    To make =
the source=20
    route header compact, I favor the tag/label approach over some other =

    compaction mechanism that operates directly on a list of IPv6=20
    addresses.  Tags/labels can be made general enough such that =
they can=20
    be derived in different ways.  Because the tags/labels have =
scope local=20
    to each node, the mechanism is pretty general already.  For =
those that=20
    are already managing unique 802.15.4 short addresses across a =
network, I can=20
    see that it is attractive to utilize the short address directly and =
reduce=20
    state on devices.  In other cases, it may be best for the node =
to=20
    dynamically assign tags/labels for its neighbors. 

    Either =
way, while=20
    the tag/label mechanism is simple, it is far more flexible than an =
approach=20
    to compacting a list of IPv6 addresses.  And note that the idea =
of=20
    using tags/labels is nothing new.  Of course we will adapt the =
basic=20
    mechanism a bit (label distribution, headers formats, etc), but the =
core=20
    ideas have been deployed in traditional IP networks for quite some =
time.=20
    

    I reiterated a lot of what was already stated before by =
others, but=20
    that is what I think. 

    -- 
    Jonathan Hui 

    On =
Apr 8,=20
    2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =


    
    
    Hi Daniel: =


    Routers=20
    might have multiple interfaces of multiple MAC types. Internet 0 =

    even=20
    has a MAC-less format. 
    So the result of you proposal, which =
looks like a=20
    great idea in a pure 
    802.15.4 world with short addresses, =
becomes a=20
    nightmare to define in a 
    fully generic fashion. 

    OTOH, a =
locally=20
    significant opaque tag in which the parent could hide a 
    short =
address of=20
    the child - if it cares to do it that way - looks like 
    a way =
more=20
    acceptable approach 

    So it seems to me that you can get what =
you want=20
    as long as we can make 
    the tag big enough for short addresses. =
When the=20
    tag is too small to 
    contain what the parent really needs, then =
the=20
    parent will have to store 
    a state with the full information in =
memory,=20
    and then place an index of 
    some sort in the tag. 

    What do =
you=20
    think? 

    Pascal 


    
    
    -----Original Message----- 
    From: Popa, =
Daniel [mailto:Daniel.Popa@itron.com]=20
    
    Sent: Thursday, April 08, 2010 11:40 AM 
    To: ROLL WG 
    Cc: =
Pascal=20
    Thubert (pthubert); JeongGil Ko (John) 
    Subject: RE: [Roll] =
Proposal for=20
    Source Routing Header Format and 
    SourceRoutingOperations =


    Hi=20
    Pascal, John, 

    Since source routing explicitly gives =
forwarding=20
    instruction to each 
    intermediate node, it can make sense to use =
only=20
    (MAC address based) 
    
    
    L2 =

    
    
    forwarding instead of (IPv6 address based) L3 =
forwarding.=20
    

    This brings two advantages: 
    - avoid processing each =
transit=20
    packets up to L3. 
    - use MAC addresses that - in ROLL environment =
- have=20
    inherently 
    
    
    shorter =

    
    
    length than an IPv6 address. 

    Cheers, =

    Daniel=20
    



    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On=20
    Behalf 
    
    
    Of =

    
    
    Pascal Thubert (pthubert) 
    Sent: jeudi 8 =
avril 2010=20
    11:15 
    To: JeongGil Ko (John); ROLL WG 
    Subject: Re: [Roll] =
Proposal=20
    for Source Routing Header Format and 
    SourceRoutingOperations =


    Hi=20
    John: 

    IPv6 already has a number of routing headers, in =
particular=20
    RH0, 
    
    
    though it is =

    
    
    being deprecated for general use in the =
Internet. 
    And=20
    there are reasons why the fields in RH0/1 are there and we need to =

    make=20
    sure we lose none of that. In particular a RH is recoverable, and=20
    
    
    
    it is =

    
    
    easy to spot the consumed entries. 

    On =
top of this=20
    our new problems are: 
    - make sure the RH stays within the RPL =
network=20
    (since it is used 
    
    
    downwards =

    
    
    that should be =
doable) 
    -=20
    control the size (that probably means compress) 

    Cheers,=20
    

    Pascal 


    
    
    -----Original Message----- 
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On=20
    Behalf 
    
    
    Of =

    
    
    JeongGil Ko (John) 
    Sent: Wednesday, April =
07, 2010=20
    10:05 PM 
    To: ROLL WG 
    Subject: [Roll] Proposal for Source =
Routing=20
    Header Format and Source 
    RoutingOperations 

    Hi! =


    Great to=20
    see all this discussions on downwards route establishment! =

    
    
    To =

    
    
    add =

    
    
    one more to the conversations here is a =
proposal for=20
    source routing 
    
    
    headers. =

    
    
    In non-storing mode (where only the root has =
individual=20
    path 
    
    
    information) =

    
    
    the root will be attaching a source routing =
header to the=20
    data 
    
    
    packet =

    
    
    that a =

    
    
    source node wants to send to a specific =
destination. We=20
    can always 
    
    
    make the =

    
    
    header super fancy but in my opinion I think we =
only need=20
    two fields 
    
    
    in this =

    
    
    header and here it is! Feel free to break the =
stuff and=20
    mangle with 
    
    
    it =

    
    
    so that it =

    
    
    looks great in the specs later on. FYI, this is =
the=20
    format that I am 
    
    
    using in my =

    
    
    implementations so it does work :) 

    1. =
Source=20
    Routing Header Format=20
    =


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
=20
    
    |   NEntry (8 bits)   | 
    
    
    | 
    
    
    +-+-+-+-+-+-+-+-+ 
    
    
    + 
    
    |         =
            &=
nbsp;=20
    Source Route Entry (128*NEntry bits) 
    
    
    | 
    
    
    + 
    
    
    + 
    
    
    | 
    
    
    | 
    
    

         Figure 1. Proposed =
Source=20
    Routing Header Format; each line is 
    
    
    32 =

    
    
    bits:) =

    
    

    - NEntry: Indicates the number of 128 bit =
addresses=20
    that the source 
    
    
    route =

    
    
    entry field is carrying. 

    - Source Route =
Entry:=20
    List of 128 bit address that consist the route 
    
    
    to the =

    
    
    destination. Here, the address of the node that =
is one=20
    hop away from 
    
    
    the =

    
    
    *destination* comes first. 

    2. Source =
Routing=20
    Packet Operations 

    When source routing is initiated at a =
storing node=20
    (e.g., root of 
    
    
    the =

    
    
    DODAG), =

    
    
    the header is attached on the data packet for =
the entire=20
    route 
    
    
    (i.e., =

    
    
    from =

    
    
    next hop node to the destination). This header =
is=20
    positioned in 
    
    
    front =

    
    
    of the =

    
    
    user payload. When the next hop node receives a =
packet=20
    that is not 
    
    
    destined =

    
    
    to itself AND the network is NOT provisioned to =
be in=20
    'storing mode' 
    
    
    then it =

    
    
    checks NEntry to find what the next hop is in =
the source=20
    route 
    
    
    entry. =

    
    
    Since =

    
    
    the 'Source Route Entry' is ordered in =
'farthest ->=20
    closest' (in 
    
    
    terms =

    
    
    of hops) =

    
    
    order, a node can figure out what the next hop =
address is=20
    with only 
    
    
    the =

    
    
    NEntry value (since it already knows how big an =
ipv6=20
    address is). 
    
    
    After =

    
    
    collecting the next hop node's address, the =
node erases=20
    this address 
    element from the entry and decreases NEntry by one. =
This=20
    assures 
    
    
    that =

    
    
    we =

    
    
    avoid the overhead of carrying the entire =
source route=20
    throughout 
    
    
    the =

    
    
    data =

    
    
    path. 

    The approach itself should be =
very simple=20
    and trivial for everyone 
    
    
    to =

    
    
    follow. =

    
    
    So we can start from here and build on! =


    Thanks.=20
    

    -John 

    ------ 
    JeongGil Ko (John) 
    Ph.D. =
Student=20
    
    Department of Computer Science 
    Johns Hopkins University =

    http://www.cs.jhu.edu/~jgko =

    

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

    Roll=20
    mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
    
    
    
    _______________________________________________ =

    Roll=20
    mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
    
    
    

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

    Roll=20
    mailing list 
    Roll@ietf.org =

    https://www.ietf.org/=
mailman/listinfo/roll=20
    
    
    
     
    

------_=_NextPart_001_01CAD7CB.F3866140--

From yoav@yitran.com  Fri Apr  9 03:17:25 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1708C3A6994 for ; Fri,  9 Apr 2010 03:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.063
X-Spam-Level: 
X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.535,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qlDNWLeGrGI for ; Fri,  9 Apr 2010 03:17:21 -0700 (PDT)
Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 248973A6827 for ; Fri,  9 Apr 2010 03:17:19 -0700 (PDT)
Received: from source ([72.14.220.159]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKS77+qmNzGITMWzVuNG+NdC6HoNcLTjJj@postini.com; Fri, 09 Apr 2010 03:17:16 PDT
Received: by fg-out-1718.google.com with SMTP id d23so89617fga.4 for ; Fri, 09 Apr 2010 03:17:14 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 	 <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>	 <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com>  <6D9687E95918C04A8B30A7D6DA805A3E0142A013@zensys17.zensys.local>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A013@zensys17.zensys.local>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQAAAGJtUAACdZkgAAB8m5A=
Date: Fri, 9 Apr 2010 13:17:13 +0300
Received: by 10.239.134.13 with SMTP id 13mr152546hbx.21.1270808233656; Fri,  09 Apr 2010 03:17:13 -0700 (PDT)
Message-ID: <015301cad7cd$d3046ab0$790d4010$@com>
To: Anders Brandt , "Pascal Thubert (pthubert)" , robert.cragie@gridmerge.com, Jonathan Hui 
Content-Type: multipart/alternative; boundary=001485f03c085842130483cb1973
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 10:17:25 -0000

--001485f03c085842130483cb1973
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Small comments on that=85

To be able to re-distribute (update) keys, it is sometimes customary to
maintain two network keys.

One key for regular communication and one in case a node for some reason
didn=92t receive the new network key (for example, wasn=92t online).

Another thing is the freshness counters vs. replay attacks=85

For MAC priorities =96 it is best to maintain freshness counters per priori=
ty
(since packets may replace order of transmissions).

So that=92s two network keys and a set of freshness counters (per priority =
per
key).



Thanks,

Yoav





*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Anders
Brandt
*Sent:* Friday, April 09, 2010 1:04 PM
*To:* Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations



Pascal,



>One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?



Typically a network key is shared among all nodes. A few nodes (e.g.
electronic door locks with extra high security requirements) may have
dedicated link keys.
The link keys work end-to-end and do not require storage in all other nodes=
.
Thus, the most simple nodes need only storage for a network key.



- Anders


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

*From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
*Sent:* Friday, April 09, 2010 10:52
*To:* Anders Brandt; robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Hi Anders:



You did not miss much. But maybe the fact that the tag could be stateless a=
s
long as the node knows how to do that.

For instance a short address could be encoded in there, as long as this is
opaque to the rest of the L3 network.

One question though. In your case, do you / can you maintain any informatio=
n
about neighbors? Like security ?



Pascal



*From:* Anders Brandt [mailto:abr@sdesigns.dk]
*Sent:* Friday, April 09, 2010 10:43 AM
*To:* Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations



Admitted, I have been absent from this thread; trying to catch up on
others...



> I read this as a consensus to use tags J If anyone disagree please speak
up now!

I have to comment respectfully but loudly that this may at best some sort o=
f
rough concensus..



In a non-storing mode, I see no way of storing and/or swapping labels/tags
in each node.

For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to 16
bits and a common subnet.



Just my $0.05






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

*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Pascal
Thubert (pthubert)
*Sent:* Friday, April 09, 2010 10:36
*To:* robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

I read this as a consensus to use tags J If anyone disagree please speak up
now!



There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM=92s HPR (pure source route), Cisco=92s tag switching =
and
MPLS. More often than not, a combination of the 2 models is used so that
tags can be both swapped and stacked.



-          In pure switching, there=92s only one tag in the packet. A tag c=
an
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use it has DAO targets in its subdag.



-          In the pure source route model, tags are stacked in an ordered
list that forms a strict routing header. A tag can be locally significant t=
o
the interpreter and is consumed (marked or removed) as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use this node as DAO parent.



It also appears that the 2 tagging models map quite well with the DAO model=
s
we have in RPL since the split that we decided with issue #26. The fact tha=
t
the combination of the 2 models is possible in the real world today gives u=
s
a hint that we are not closing the door to the mixed model in the future.



The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by the
node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need to
dig further)

-          Tag content and size (people have asked for at least 2 octets to
fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of addresses?
What about the tag swapping  case, RH as well?)



Advice?



Pascal



*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Robert
Cragie
*Sent:* Thursday, April 08, 2010 11:34 PM
*To:* Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations



OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 08/04/2010 10:17 PM, Jonathan Hui wrote:


Hi Robert,

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:

A couple of questions:
    =95 I presume the source route header using these tags/labels is an IPv=
6
extension header. What value for extension header type would this be? Would
we need to specify a LOWPAN_NHC value for this so we can still use
LOWPAN_NCH for UDP frames?


We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for th=
e
IPv6 Hop-by-Hop Option header.

    =95 Can you point to where the 'core ideas have been deployed in
traditional IP networks for quite some time'?


MPLS.  Again, I think the mechanisms will need to be adapted, but the core
ideas are not new.

--=20
Jonathan Hui

Thanks

Robert
Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 08/04/2010 3:57 PM, Jonathan Hui wrote:



To make the source route header compact, I favor the tag/label approach ove=
r
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they can be
derived in different ways.  Because the tags/labels have scope local to eac=
h
node, the mechanism is pretty general already.  For those that are already
managing unique 802.15.4 short addresses across a network, I can see that i=
t
is attractive to utilize the short address directly and reduce state on
devices.  In other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more flexibl=
e
than an approach to compacting a list of IPv6 addresses.  And note that the
idea of using tags/labels is nothing new.  Of course we will adapt the basi=
c
mechanism a bit (label distribution, headers formats, etc), but the core
ideas have been deployed in traditional IP networks for quite some time.

I reiterated a lot of what was already stated before by others, but that is
what I think.

--=20
Jonathan Hui

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:

Hi Daniel:

Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.

OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach

So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.

What do you think?

Pascal

 -----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com ]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)

L2

forwarding instead of (IPv6 address based) L3 forwarding.

This brings two advantages:
- avoid processing each transit packets up to L3.
- use MAC addresses that - in ROLL environment - have inherently

shorter

length than an IPv6 address.

Cheers,
Daniel



-----Original Message-----
From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]
On Behalf

Of

Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

IPv6 already has a number of routing headers, in particular RH0,

though it is

being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and

it is

easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used

downwards

that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal

 -----Original Message-----
From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]
On Behalf

Of

JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

Great to see all this discussions on downwards route establishment!

To

add

one more to the conversations here is a proposal for source routing

headers.

In non-storing mode (where only the root has individual path

information)

the root will be attaching a source routing header to the data

packet

that a

source node wants to send to a specific destination. We can always

make the

header super fancy but in my opinion I think we only need two fields

in this

header and here it is! Feel free to break the stuff and mangle with

it

so that it

looks great in the specs later on. FYI, this is the format that I am

using in my

implementations so it does work :)

1. Source Routing Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |

|

+-+-+-+-+-+-+-+-+

+

|                       Source Route Entry (128*NEntry bits)

|

+

+

|

|


     Figure 1. Proposed Source Routing Header Format; each line is

32

bits:)


- NEntry: Indicates the number of 128 bit addresses that the source

route

entry field is carrying.

- Source Route Entry: List of 128 bit address that consist the route

to the

destination. Here, the address of the node that is one hop away from

the

*destination* comes first.

2. Source Routing Packet Operations

When source routing is initiated at a storing node (e.g., root of

the

DODAG),

the header is attached on the data packet for the entire route

(i.e.,

from

next hop node to the destination). This header is positioned in

front

of the

user payload. When the next hop node receives a packet that is not

destined

to itself AND the network is NOT provisioned to be in 'storing mode'

then it

checks NEntry to find what the next hop is in the source route

entry.

Since

the 'Source Route Entry' is ordered in 'farthest -> closest' (in

terms

of hops)

order, a node can figure out what the next hop address is with only

the

NEntry value (since it already knows how big an ipv6 address is).

After

collecting the next hop node's address, the node erases this address
element from the entry and decreases NEntry by one. This assures

that

we

avoid the overhead of carrying the entire source route throughout

the

data

path.

The approach itself should be very simple and trivial for everyone

to

follow.

So we can start from here and build on!

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

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

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

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


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

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

--001485f03c085842130483cb1973
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable














    


    Small comments on that=85
    


    To be able to re-distribute (update) keys, it is sometimes c=
ustomary
to maintain two network keys.
    


    One key for regular communication and one in case a node for
some reason didn=92t receive the new network key (for example, wasn=92t onl=
ine).
    


    Another thing is the freshness counters vs. replay attacks=
=85
    


    For MAC priorities =96 it is best to maintain freshness coun=
ters per
priority (since packets may replace order of transmissions).
    


    So that=92s two network keys and a set of freshness counters=
 (per
priority per key).
    


    =A0
    


    Thanks,
    


    Yoav
    


    =A0
    


    =A0
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]=
 On Behalf Of Anders Brandt
    
Sent: Friday, April 09, 2010 1:04 PM
    
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


    =A0
    


    Pascal,
    


    =A0
    


    >One question though. In your case, do you / can you main=
tain
any information about neighbors? Like security ?
    


    


    =A0
    


    


    Typically a network key is shared among all nodes. A few nodes
(e.g. electronic door locks with extra high security requirements) may have
dedicated link keys.
    
The link keys work end-to-end and do not require storage in all other nodes=
.
    
Thus, the most simple nodes need only storage for a network key.
    


    =A0
    


    - Anders
    


    


    =A0
    


    


    


    


    Fro=
m:
Pascal Thubert (pthubert) [mailto:pth=
ubert@cisco.com] 
    
Sent: Friday, April 09, 2010 10:52
    
To: Anders Brandt; ro=
bert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    Hi Anders:
    


    =A0
    


    You did not miss much. But maybe the fact that the tag could=
 be
stateless as long as the node knows how to do that. 
    


    For instance a short address could be encoded in there, as l=
ong
as this is opaque to the rest of the L3 network.
    


    One question though. In your case, do you / can you maintain=
 any
information about neighbors? Like security ?
    


    =A0
    


    


    Pascal
    


    


    =A0
    


    


    


    


    From: An=
ders Brandt
[mailto:abr@sdesigns.dk] 
    
Sent: Friday, April 09, 2010 10:43 AM
    
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


    =A0
    


    Admitted, I have been absent from this thread; trying to catch =
up
on others...
    


    =A0
    


    > I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


    I have to comment respectfully but loudly that this may at best
some sort of rough concensus..
    


    =A0
    


    In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.


    For this kind of nodes we need a complete routing stack in the
frame. As mentioned earlier, I am perfectly
    
fine with limitations such as max n entries; Compression of addresses to 16
bits and a common subnet.    


    =A0
    


    Just my $0.05


    =A0
    


    =A0
    


    


    =A0
    


    


    


    


    Fro=
m:
roll-bounces@ietf.org [mailto:=
roll-bounces@ietf.org] On B=
ehalf Of Pascal
Thubert (pthubert)
    
Sent: Friday, April 09, 2010 10:36
    
To: robert.cragie@gri=
dmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


    =A0
    


    There have been plenty iterations/versions of tagging since
Frame Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s ta=
g
switching and MPLS. More often than not, a combination of the 2 models is u=
sed
so that tags can be both swapped and stacked. 
    


    =A0
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
In pure switching, there=92s only one tag in the packet. A t=
ag can
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has child=
ren
that use it has DAO targets in its subdag.
    


    =A0
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
In the pure source route model, tags are stacked in an order=
ed
list that forms a strict routing header. A tag can be locally significant t=
o
the interpreter and is consumed (marked or removed) as the packet progresse=
s.
For RPL, it means that a node uses as many tags as it has children that use
this node as DAO parent. 
    


    =A0
    


    It also appears that the 2 tagging models map quite well wit=
h
the DAO models we have in RPL since the split that we decided with issue #2=
6.
The fact that the combination of the 2 models is possible in the real world
today gives us a hint that we are not closing the door to the mixed model i=
n
the future.
    


    =A0
    


    The next step I wish to agree upon:
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Use locally significant tags which implies tag assignment by=
 the
node that uses it later and tag swapping for the stateful case.
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Tag distribution in DAO (there are options there that we nee=
d to
dig further)
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Tag content and size (people have asked for at least 2 octet=
s to
fit 15.4 short addresses, do we need some control field as well?)


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
RH format (inherit RH0 fields with labels instead of address=
es?
What about the tag swapping=A0 case, RH as well?)
    


    =A0
    


    Advice?
    


    =A0
    


    


    Pascal
    


    


    =A0
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]=
 On Behalf Of Robert Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


    =A0
    


    OK, sounds good. End of topic as far as I am concern=
ed. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    


    A couple of questions: 
    
=A0=A0=A0=A0=95 I presume the source route header using these
tags/labels is an IPv6 extension header. What value for extension header ty=
pe
would this be? Would we need to specify a LOWPAN_NHC value for this so we c=
an
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and present=
ed
it at 6man in Anaheim.=A0 The option is designed to carry RPL-specific
information.=A0 6lowpan-hc already has a LOWPAN_NHC value for the IPv6
Hop-by-Hop Option header. 
    


    =A0=A0=A0=A0=95 Can you point to where the 'core
ideas have been deployed in traditional IP networks for quite some time'=
;? 
    



    
MPLS.=A0 Again, I think the mechanisms will need to be adapted, but the cor=
e
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach ove=
r
some other compaction mechanism that operates directly on a list of IPv6
addresses.=A0 Tags/labels can be made general enough such that they can be
derived in different ways.=A0 Because the tags/labels have scope local to
each node, the mechanism is pretty general already.=A0 For those that are
already managing unique 802.15.4 short addresses across a network, I can se=
e
that it is attractive to utilize the short address directly and reduce stat=
e on
devices.=A0 In other cases, it may be best for the node to dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more flexibl=
e
than an approach to compacting a list of IPv6 addresses.=A0 And note that
the idea of using tags/labels is nothing new.=A0 Of course we will adapt th=
e
basic mechanism a bit (label distribution, headers formats, etc), but the c=
ore
ideas have been deployed in traditional IP networks for quite some time. 

    
I reiterated a lot of what was already stated before by others, but that is
what I think. 
    

    
--=A0
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure 
    
802.15.4 world with short addresses, becomes a nightmare to define in a 
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a 
short address of the child - if it cares to do it that way - looks like 
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make 
the tag big enough for short addresses. When the tag is too small to 
    
contain what the parent really needs, then the parent will have to store 
a state with the full information in memory, and then place an index of 
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    

    

    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.=
Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each 
    
intermediate node, it can make sense to use only (MAC address based) 
    


    L2 
    


    forwarding instead of (IPv6 address based) L3 forwar=
ding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently 
    


    shorter 
    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org [<=
a href=3D"mailto:roll-bounces@ietf.org">mailto:roll-bounces@ietf.org] O=
n Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, 
    


    though it is 
    


    being deprecated for general use in the Internet. 
And there are reasons why the fields in RH0/1 are there and we need to 
    
make sure we lose none of that. In particular a RH is recoverable, and 
    


    it is 
    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used 
    


    downwards 
    


    that should be doable=
) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    

    

    


    -----Original Message----- 
    
From: roll-bounces@ietf.org [<=
a href=3D"mailto:roll-bounces@ietf.org">mailto:roll-bounces@ietf.org] O=
n Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source 
    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! 
    


    To 
    


    add 
    


    one more to the conversations here is a proposal for=
 source
routing 
    


    headers. 
    


    In non-storing mode (where only the root has individ=
ual path

    


    information) 
    


    the root will be attaching a source routing header t=
o the
data 
    


    packet 
    


    that a 
    


    source node wants to send to a specific destination.=
 We can
always 
    


    make the 
    


    header super fancy but in my opinion I think we only=
 need
two fields 
    


    in this 
    


    header and here it is! Feel free to break the stuff =
and
mangle with 
    


    it 
    


    so that it 
    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my 
    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|=A0=A0 NEntry (8 bits)=A0=A0 | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
=A0=A0=A0=A0 Figure 1. Proposed Source Routing Header Format; each
line is 
    


    32 
    


    bits:) 
    



    
- NEntry: Indicates the number of 128 bit addresses that the source 
    


    route 
    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route 
    


    to the 
    


    destination. Here, the address of the node that is o=
ne hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of 
    


    the 
    


    DODAG), 
    


    the header is attached on the data packet for the en=
tire
route 
    


    (i.e., 
    


    from 
    


    next hop node to the destination). This header is po=
sitioned
in 
    


    front 
    


    of the 
    


    user payload. When the next hop node receives a pack=
et that
is not 
    


    destined 
    


    to itself AND the network is NOT provisioned to be i=
n
'storing mode' 
    


    then it 
    


    checks NEntry to find what the next hop is in the so=
urce
route 
    


    entry. 
    


    Since 
    


    the 'Source Route Entry' is ordered in '=
farthest ->
closest' (in 
    


    terms 
    


    of hops) 
    


    order, a node can figure out what the next hop addre=
ss is
with only 
    


    the 
    


    NEntry value (since it already knows how big an ipv6=
 address
is). 
    


    After 
    


    collecting the next hop node's address, the node=
 erases this
address 
    
element from the entry and decreases NEntry by one. This assures 
    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source rou=
te throughout

    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone 
    


    to 
    


    follow. 
    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko 

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

    


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

    


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

    



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

    


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

    


    =A0
    


    


    


    


    


    





--001485f03c085842130483cb1973--

From abr@sdesigns.dk  Fri Apr  9 03:32:21 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CFE3A68EB for ; Fri,  9 Apr 2010 03:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.93
X-Spam-Level: 
X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.668,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf2fTqgWP91F for ; Fri,  9 Apr 2010 03:32:05 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 10C9A3A67FD for ; Fri,  9 Apr 2010 03:32:03 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7CF.E2FBAD86"
Date: Fri, 9 Apr 2010 12:31:59 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A014@zensys17.zensys.local>
In-Reply-To: <015301cad7cd$d3046ab0$790d4010$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQAAAGJtUAACdZkgAAB8m5AAAHy3kA==
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com>	<6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>	<6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A013@zensys17.zensys.local> <015301cad7cd$d3046ab0$790d4010$@com>
From: "Anders Brandt" 
To: "Yoav Ben-Yehezkel" , "Pascal Thubert (pthubert)" , , "Jonathan Hui" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 10:32:22 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7CF.E2FBAD86
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yoav,

=20

>So that's two network keys and a set of freshness counters (per
priority per key).

=20

The two network keys may make sense but freshness counters are
problematic - in home control at least.
Some targets may be controlled by a high number of controllers. Counters
would require targets to hold many
instances. Since many controllers may be battery operated it is not an
option to keep the counters synchronized.
Challenge-response is also replay-proof and it requires no additional
state in nodes - except for a temporary nonce.
=20
Cheers,
  Anders
=20



________________________________

	From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com]=20
	Sent: Friday, April 09, 2010 12:17
	To: Anders Brandt; Pascal Thubert (pthubert);
robert.cragie@gridmerge.com; Jonathan Hui
	Cc: roll@ietf.org
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
=09
=09

	Small comments on that...

	To be able to re-distribute (update) keys, it is sometimes
customary to maintain two network keys.

	One key for regular communication and one in case a node for
some reason didn't receive the new network key (for example, wasn't
online).

	Another thing is the freshness counters vs. replay attacks...

	For MAC priorities - it is best to maintain freshness counters
per priority (since packets may replace order of transmissions).

	So that's two network keys and a set of freshness counters (per
priority per key).

	=20

	Thanks,

	Yoav

	=20

	=20

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Anders Brandt
	Sent: Friday, April 09, 2010 1:04 PM
	To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com;
Jonathan Hui
	Cc: roll@ietf.org
	Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	=20

	Pascal,

	=20

	>One question though. In your case, do you / can you maintain
any information about neighbors? Like security ?

	=20

	Typically a network key is shared among all nodes. A few nodes
(e.g. electronic door locks with extra high security requirements) may
have dedicated link keys.
	The link keys work end-to-end and do not require storage in all
other nodes.
	Thus, the most simple nodes need only storage for a network key.

	=20

	- Anders

		=20

	=09
________________________________


		From: Pascal Thubert (pthubert)
[mailto:pthubert@cisco.com]=20
		Sent: Friday, April 09, 2010 10:52
		To: Anders Brandt; robert.cragie@gridmerge.com; Jonathan
Hui
		Cc: roll@ietf.org
		Subject: RE: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		Hi Anders:

		=20

		You did not miss much. But maybe the fact that the tag
could be stateless as long as the node knows how to do that.=20

		For instance a short address could be encoded in there,
as long as this is opaque to the rest of the L3 network.

		One question though. In your case, do you / can you
maintain any information about neighbors? Like security ?

		=20

		Pascal

		=20

		From: Anders Brandt [mailto:abr@sdesigns.dk]=20
		Sent: Friday, April 09, 2010 10:43 AM
		To: Pascal Thubert (pthubert);
robert.cragie@gridmerge.com; Jonathan Hui
		Cc: roll@ietf.org
		Subject: RE: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		=20

		Admitted, I have been absent from this thread; trying to
catch up on others...

		=20

		> I read this as a consensus to use tags J If anyone
disagree please speak up now!

		I have to comment respectfully but loudly that this may
at best some sort of rough concensus..

		=20

		In a non-storing mode, I see no way of storing and/or
swapping labels/tags in each node.

		For this kind of nodes we need a complete routing stack
in the frame. As mentioned earlier, I am perfectly
		fine with limitations such as max n entries; Compression
of addresses to 16 bits and a common subnet.

		=20

		Just my $0.05

		=20

		=20

			=20

		=09
________________________________


			From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
			Sent: Friday, April 09, 2010 10:36
			To: robert.cragie@gridmerge.com; Jonathan Hui
			Cc: roll@ietf.org
			Subject: Re: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

			I read this as a consensus to use tags J If
anyone disagree please speak up now!

			=20

			There have been plenty iterations/versions of
tagging since Frame Relay (pure switching), IBM's HPR (pure source
route), Cisco's tag switching and MPLS. More often than not, a
combination of the 2 models is used so that tags can be both swapped and
stacked.=20

			=20

			-          In pure switching, there's only one
tag in the packet. A tag can be locally significant, in which case it
has to be swapped as the packet progresses. For RPL, it means that a
node uses as many tags as it has children that use it has DAO targets in
its subdag.

			=20

			-          In the pure source route model, tags
are stacked in an ordered list that forms a strict routing header. A tag
can be locally significant to the interpreter and is consumed (marked or
removed) as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use this node as DAO parent.=20

			=20

			It also appears that the 2 tagging models map
quite well with the DAO models we have in RPL since the split that we
decided with issue #26. The fact that the combination of the 2 models is
possible in the real world today gives us a hint that we are not closing
the door to the mixed model in the future.

			=20

			The next step I wish to agree upon:

			-          Use locally significant tags which
implies tag assignment by the node that uses it later and tag swapping
for the stateful case.

			-          Tag distribution in DAO (there are
options there that we need to dig further)

			-          Tag content and size (people have
asked for at least 2 octets to fit 15.4 short addresses, do we need some
control field as well?)

			-          RH format (inherit RH0 fields with
labels instead of addresses? What about the tag swapping  case, RH as
well?)

			=20

			Advice?

			=20

			Pascal

			=20

			From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
			Sent: Thursday, April 08, 2010 11:34 PM
			To: Jonathan Hui
			Cc: roll@ietf.org
			Subject: Re: [Roll] Proposal for Source Routing
Header Formatand SourceRoutingOperations

			=20

			OK, sounds good. End of topic as far as I am
concerned. +1
		=09
			Robert

			Robert Cragie (Pacific Gas & Electric)

			Gridmerge Ltd.
			89 Greenfield Crescent,
			Wakefield, WF4 4WA, UK
			+44 (0) 1924 910888
			http://www.gridmerge.com
=20

		=09
			On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20

		=09
			Hi Robert,=20
		=09
			On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:


			A couple of questions:=20
			    * I presume the source route header using
these tags/labels is an IPv6 extension header. What value for extension
header type would this be? Would we need to specify a LOWPAN_NHC value
for this so we can still use LOWPAN_NCH for UDP frames?=20

		=09
			We already have a draft requesting a new IPv6
Hop-by-Hop Option and presented it at 6man in Anaheim.  The option is
designed to carry RPL-specific information.  6lowpan-hc already has a
LOWPAN_NHC value for the IPv6 Hop-by-Hop Option header.=20

			    * Can you point to where the 'core ideas
have been deployed in traditional IP networks for quite some time'?=20

		=09
			MPLS.  Again, I think the mechanisms will need
to be adapted, but the core ideas are not new.=20
		=09
			--=20
			Jonathan Hui=20

			Thanks=20
		=09
			Robert=20
			Robert Cragie (Pacific Gas & Electric)=20
		=09
			Gridmerge Ltd.=20
			89 Greenfield Crescent,=20
			Wakefield, WF4 4WA, UK=20
			+44 (0) 1924 910888=20
			http://www.gridmerge.com=20
		=09
		=09
			On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20

		=09
		=09
			To make the source route header compact, I favor
the tag/label approach over some other compaction mechanism that
operates directly on a list of IPv6 addresses.  Tags/labels can be made
general enough such that they can be derived in different ways.  Because
the tags/labels have scope local to each node, the mechanism is pretty
general already.  For those that are already managing unique 802.15.4
short addresses across a network, I can see that it is attractive to
utilize the short address directly and reduce state on devices.  In
other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors.=20
		=09
			Either way, while the tag/label mechanism is
simple, it is far more flexible than an approach to compacting a list of
IPv6 addresses.  And note that the idea of using tags/labels is nothing
new.  Of course we will adapt the basic mechanism a bit (label
distribution, headers formats, etc), but the core ideas have been
deployed in traditional IP networks for quite some time.=20
		=09
			I reiterated a lot of what was already stated
before by others, but that is what I think.=20
		=09
			--=20
			Jonathan Hui=20
		=09
			On Apr 8, 2010, at 2:57 AM, Pascal Thubert
(pthubert) wrote:=20

			Hi Daniel:=20
		=09
			Routers might have multiple interfaces of
multiple MAC types. Internet 0=20
			even has a MAC-less format.=20
			So the result of you proposal, which looks like
a great idea in a pure=20
			802.15.4 world with short addresses, becomes a
nightmare to define in a=20
			fully generic fashion.=20
		=09
			OTOH, a locally significant opaque tag in which
the parent could hide a=20
			short address of the child - if it cares to do
it that way - looks like=20
			a way more acceptable approach=20
		=09
			So it seems to me that you can get what you want
as long as we can make=20
			the tag big enough for short addresses. When the
tag is too small to=20
			contain what the parent really needs, then the
parent will have to store=20
			a state with the full information in memory, and
then place an index of=20
			some sort in the tag.=20
		=09
			What do you think?=20
		=09
			Pascal=20
		=09
		=09

			-----Original Message-----=20
			From: Popa, Daniel
[mailto:Daniel.Popa@itron.com]=20
			Sent: Thursday, April 08, 2010 11:40 AM=20
			To: ROLL WG=20
			Cc: Pascal Thubert (pthubert); JeongGil Ko
(John)=20
			Subject: RE: [Roll] Proposal for Source Routing
Header Format and=20
			SourceRoutingOperations=20
		=09
			Hi Pascal, John,=20
		=09
			Since source routing explicitly gives forwarding
instruction to each=20
			intermediate node, it can make sense to use only
(MAC address based)=20

			L2=20

			forwarding instead of (IPv6 address based) L3
forwarding.=20
		=09
			This brings two advantages:=20
			- avoid processing each transit packets up to
L3.=20
			- use MAC addresses that - in ROLL environment -
have inherently=20

			shorter=20

			length than an IPv6 address.=20
		=09
			Cheers,=20
			Daniel=20
		=09
		=09
		=09
			-----Original Message-----=20
			From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf=20

			Of=20

			Pascal Thubert (pthubert)=20
			Sent: jeudi 8 avril 2010 11:15=20
			To: JeongGil Ko (John); ROLL WG=20
			Subject: Re: [Roll] Proposal for Source Routing
Header Format and=20
			SourceRoutingOperations=20
		=09
			Hi John:=20
		=09
			IPv6 already has a number of routing headers, in
particular RH0,=20

			though it is=20

			being deprecated for general use in the
Internet.=20
			And there are reasons why the fields in RH0/1
are there and we need to=20
			make sure we lose none of that. In particular a
RH is recoverable, and=20

			it is=20

			easy to spot the consumed entries.=20
		=09
			On top of this our new problems are:=20
			- make sure the RH stays within the RPL network
(since it is used=20

			downwards=20

			that should be doable)=20
			- control the size (that probably means
compress)=20
		=09
			Cheers,=20
		=09
			Pascal=20
		=09
		=09

			-----Original Message-----=20
			From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf=20

			Of=20

			JeongGil Ko (John)=20
			Sent: Wednesday, April 07, 2010 10:05 PM=20
			To: ROLL WG=20
			Subject: [Roll] Proposal for Source Routing
Header Format and Source=20
			RoutingOperations=20
		=09
			Hi!=20
		=09
			Great to see all this discussions on downwards
route establishment!=20

			To=20

			add=20

			one more to the conversations here is a proposal
for source routing=20

			headers.=20

			In non-storing mode (where only the root has
individual path=20

			information)=20

			the root will be attaching a source routing
header to the data=20

			packet=20

			that a=20

			source node wants to send to a specific
destination. We can always=20

			make the=20

			header super fancy but in my opinion I think we
only need two fields=20

			in this=20

			header and here it is! Feel free to break the
stuff and mangle with=20

			it=20

			so that it=20

			looks great in the specs later on. FYI, this is
the format that I am=20

			using in my=20

			implementations so it does work :)=20
		=09
			1. Source Routing Header Format=20
		=09
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
			|   NEntry (8 bits)   |=20

			|=20

			+-+-+-+-+-+-+-+-+=20

			+=20

			|                       Source Route Entry
(128*NEntry bits)=20

			|=20

			+=20

			+=20

			|=20

			|=20

		=09
			     Figure 1. Proposed Source Routing Header
Format; each line is=20

			32=20

			bits:)=20

		=09
			- NEntry: Indicates the number of 128 bit
addresses that the source=20

			route=20

			entry field is carrying.=20
		=09
			- Source Route Entry: List of 128 bit address
that consist the route=20

			to the=20

			destination. Here, the address of the node that
is one hop away from=20

			the=20

			*destination* comes first.=20
		=09
			2. Source Routing Packet Operations=20
		=09
			When source routing is initiated at a storing
node (e.g., root of=20

			the=20

			DODAG),=20

			the header is attached on the data packet for
the entire route=20

			(i.e.,=20

			from=20

			next hop node to the destination). This header
is positioned in=20

			front=20

			of the=20

			user payload. When the next hop node receives a
packet that is not=20

			destined=20

			to itself AND the network is NOT provisioned to
be in 'storing mode'=20

			then it=20

			checks NEntry to find what the next hop is in
the source route=20

			entry.=20

			Since=20

			the 'Source Route Entry' is ordered in 'farthest
-> closest' (in=20

			terms=20

			of hops)=20

			order, a node can figure out what the next hop
address is with only=20

			the=20

			NEntry value (since it already knows how big an
ipv6 address is).=20

			After=20

			collecting the next hop node's address, the node
erases this address=20
			element from the entry and decreases NEntry by
one. This assures=20

			that=20

			we=20

			avoid the overhead of carrying the entire source
route throughout=20

			the=20

			data=20

			path.=20
		=09
			The approach itself should be very simple and
trivial for everyone=20

			to=20

			follow.=20

			So we can start from here and build on!=20
		=09
			Thanks.=20
		=09
			-John=20
		=09
			------=20
			JeongGil Ko (John)=20
			Ph.D. Student=20
			Department of Computer Science=20
			Johns Hopkins University=20
			http://www.cs.jhu.edu/~jgko=20
		=09
			_______________________________________________=20
			Roll mailing list=20
			Roll@ietf.org=20
			https://www.ietf.org/mailman/listinfo/roll=20

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

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

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

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

			=20


------_=_NextPart_001_01CAD7CF.E2FBAD86
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

    Yoav,
    

     
    

    >So that’s two network keys =
and a set of=20
freshness counters (per priority per key).
    

     
    

    The two network keys may make sense but =
freshness counters=20
are problematic - in home control at least.
    

    Some targets may be controlled by a high number =
of=20
controllers. Counters would require targets to hold many
    instances. =
Since=20
many controllers may be battery operated it is not an option to keep the =

counters synchronized.
    

    Challenge-response is also replay-proof and it =
requires no=20
additional state in nodes - except for a temporary =
nonce.
    

     
    

    Cheers,
    

      Anders
    

     

    

    
  
    
  
    
  From: Yoav Ben-Yehezkel=20
  [mailto:yoav@yitran.com] 
    Sent: Friday, April 09, 2010=20
  12:17
    To: Anders Brandt; Pascal Thubert (pthubert);=20
  robert.cragie@gridmerge.com; Jonathan Hui
    Cc:=20
  roll@ietf.org
    Subject: RE: [Roll] Proposal for Source =
Routing=20
  HeaderFormatand SourceRoutingOperations

    
  
    
  
    
  
    Small=20
  comments on that…
    
  
    To=20
  be able to re-distribute (update) keys, it is sometimes customary to =
maintain=20
  two network keys.
    
  
    One=20
  key for regular communication and one in case a node for some reason =
didn’t=20
  receive the new network key (for example, wasn’t =
online).
    
  
    Another=20
  thing is the freshness counters vs. replay attacks…
    
  
    For=20
  MAC priorities – it is best to maintain freshness counters per =
priority (since=20
  packets may replace order of transmissions).
    
  
    So=20
  that’s two network keys and a set of freshness counters (per =
priority per=20
  key).
    
  
     
    
  
    Thanks,
    
  
    Yoav
    
  
     
    
  
     
    
  
    
  
  
    From:=20
  roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] On =
Behalf Of=20
  Anders Brandt
    Sent: Friday, April 09, 2010 1:04 =
PM
    To:=20
  Pascal Thubert (pthubert); robert.cragie@gridmerge.com;=20
  Jonathan Hui
    Cc: roll@ietf.org
    Subject: Re: =
[Roll]=20
  Proposal for Source Routing HeaderFormatand=20
  SourceRoutingOperations
    
  
     
    
  
    Pascal,
    
  
     
    
  
    >One=20
  question though. In your case, do you / can you maintain any =
information about=20
  neighbors? Like security ?
    
  
    
  
     
    
  
    Typically=20
  a network key is shared among all nodes. A few nodes (e.g. electronic =
door=20
  locks with extra high security requirements) may have dedicated link=20
  keys.
    The link keys work end-to-end and do not require storage in =
all other=20
  nodes.
    Thus, the most simple nodes need only storage for a network=20
  key.
    
  
     
    
  
    -=20
  Anders
    
  
    
     
    
    
    
    
    
    
    
    
    From:=20
    Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =

    Sent:=20
    Friday, April 09, 2010 10:52
    To: Anders Brandt; robert.cragie@gridmerge.com;=20
    Jonathan Hui
    Cc: roll@ietf.org
    Subject: =
RE: [Roll]=20
    Proposal for Source Routing HeaderFormatand=20
    SourceRoutingOperations
    
    
    Hi=20
    Anders:
    
    
     
    
    
    You=20
    did not miss much. But maybe the fact that the tag could be =
stateless as=20
    long as the node knows how to do that. 
    
    
    For=20
    instance a short address could be encoded in there, as long as this =
is=20
    opaque to the rest of the L3 network.
    
    
    One=20
    question though. In your case, do you / can you maintain any =
information=20
    about neighbors? Like security ?
    
    
     
    
    
    
    
    Pascal
    
    
     
    
    
    
    
    
    
    From:=20
    Anders Brandt [mailto:abr@sdesigns.dk]=20
    
    Sent: Friday, April 09, 2010 10:43 AM
    To: =
Pascal=20
    Thubert (pthubert); robert.cragie@gridmerge.com;=20
    Jonathan Hui
    Cc: roll@ietf.org
    Subject: =
RE: [Roll]=20
    Proposal for Source Routing HeaderFormatand=20
    SourceRoutingOperations
    
    
     
    
    
    Admitted,=20
    I have been absent from this thread; trying to catch up on=20
    others...
    
    
     
    
    
    >=20
    I read this as a consensus to use tags J=20
    If anyone disagree please speak up now!
    
    
    I=20
    have to comment respectfully but loudly that this may at best some =
sort of=20
    rough concensus..
    
    
     
    
    
    In a=20
    non-storing mode, I see no way of storing and/or swapping =
labels/tags in=20
    each node.
    
    
    For=20
    this kind of nodes we need a complete routing stack in the frame. As =

    mentioned earlier, I am perfectly
    fine with limitations such as =
max n=20
    entries; Compression of addresses to 16 bits and a common=20
    subnet.
    
    
     
    
    
    Just=20
    my $0.05
    
    
     
    
    
     
    
    
      
     
    
      
    
      
    
      
    
      
    From:=20
      roll-bounces@ietf.org =

      [mailto:roll-bounces@ietf.org]=20
      On Behalf Of Pascal Thubert (pthubert)
    Sent: =
Friday,=20
      April 09, 2010 10:36
    To: robert.cragie@gridmerge.com;=20
      Jonathan Hui
    Cc: roll@ietf.org
    Subject: =
Re:=20
      [Roll] Proposal for Source Routing HeaderFormatand=20
      SourceRoutingOperations
    
      
    I=20
      read this as a consensus to use tags J=20
      If anyone disagree please speak up now!
    
      
     
    
      
    There=20
      have been plenty iterations/versions of tagging since Frame Relay =
(pure=20
      switching), IBM’s HPR (pure source route), Cisco’s tag =
switching and MPLS.=20
      More often than not, a combination of the 2 models is used so that =
tags=20
      can be both swapped and stacked. 
    
      
     
    
      
    -         =20
      In=20
      pure switching, there’s only one tag in the packet. A tag =
can be locally=20
      significant, in which case it has to be swapped as the packet =
progresses.=20
      For RPL, it means that a node uses as many tags as it has children =
that=20
      use it has DAO targets in its subdag.
    
      
     
    
      
    -         =20
      In=20
      the pure source route model, tags are stacked in an ordered list =
that=20
      forms a strict routing header. A tag can be locally significant to =
the=20
      interpreter and is consumed (marked or removed) as the packet =
progresses.=20
      For RPL, it means that a node uses as many tags as it has children =
that=20
      use this node as DAO parent. 
    
      
     
    
      
    It=20
      also appears that the 2 tagging models map quite well with the DAO =
models=20
      we have in RPL since the split that we decided with issue #26. The =
fact=20
      that the combination of the 2 models is possible in the real world =
today=20
      gives us a hint that we are not closing the door to the mixed =
model in the=20
      future.
    
      
     
    
      
    The=20
      next step I wish to agree upon:
    
      
    -         =20
      Use=20
      locally significant tags which implies tag assignment by the node =
that=20
      uses it later and tag swapping for the stateful case.
    
      
    -         =20
      Tag=20
      distribution in DAO (there are options there that we need to dig=20
      further)
    
      
    -         =20
      Tag=20
      content and size (people have asked for at least 2 octets to fit =
15.4=20
      short addresses, do we need some control field as =
well?)
    
      
    -         =20
      RH=20
      format (inherit RH0 fields with labels instead of addresses? What =
about=20
      the tag swapping  case, RH as well?)
    
      
     
    
      
    Advice?
    
      
     
    
      
    
      
    Pascal
    
      
     
    
      
      
    
      
      
    From:=20
      roll-bounces@ietf.org =

      [mailto:roll-bounces@ietf.org]=20
      On Behalf Of Robert Cragie
    Sent: Thursday, April =
08, 2010=20
      11:34 PM
    To: Jonathan Hui
    Cc: roll@ietf.org
    Subject: =
Re:=20
      [Roll] Proposal for Source Routing Header Formatand=20
      SourceRoutingOperations
    
      
     
    
      
    OK, sounds good. End of topic as far as I am =
concerned.=20
      +1

    Robert
    
      
    
      
    Robert Cragie (Pacific Gas & Electric)
    
      
    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 =
4WA,=20
      UK
    +44 (0) 1924 910888
    http://www.gridmerge.com
    =

      

    On 08/04/2010 10:17 PM, Jonathan Hui =
wrote: 
    
      

    Hi Robert, =


    On=20
      Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    
      
    A couple of questions: =

        • I=20
      presume the source route header using these tags/labels is an IPv6 =

      extension header. What value for extension header type would this =
be?=20
      Would we need to specify a LOWPAN_NHC value for this so we can =
still use=20
      LOWPAN_NCH for UDP frames? 
    
      

    We already =
have a draft=20
      requesting a new IPv6 Hop-by-Hop Option and presented it at 6man =
in=20
      Anaheim.  The option is designed to carry RPL-specific=20
      information.  6lowpan-hc already has a LOWPAN_NHC value for =
the IPv6=20
      Hop-by-Hop Option header. 
    
      
        • Can you point =
to where the=20
      'core ideas have been deployed in traditional IP networks for =
quite some=20
      time'? 
    
      

    MPLS.  =
Again, I=20
      think the mechanisms will need to be adapted, but the core ideas =
are not=20
      new. 

    -- 
    Jonathan Hui 
    
      
    Thanks =


    Robert=20
      
    Robert Cragie (Pacific Gas & Electric) 

    Gridmerge =
Ltd.=20
      
    89 Greenfield Crescent, 
    Wakefield, WF4 4WA, UK 
    +44 (0) =
1924=20
      910888 
    http://www.gridmerge.com=20
      


    On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    
      


    To make =
the source=20
      route header compact, I favor the tag/label approach over some =
other=20
      compaction mechanism that operates directly on a list of IPv6=20
      addresses.  Tags/labels can be made general enough such that =
they can=20
      be derived in different ways.  Because the tags/labels have =
scope=20
      local to each node, the mechanism is pretty general already.  =
For=20
      those that are already managing unique 802.15.4 short addresses =
across a=20
      network, I can see that it is attractive to utilize the short =
address=20
      directly and reduce state on devices.  In other cases, it may =
be best=20
      for the node to dynamically assign tags/labels for its neighbors.=20
      

    Either way, while the tag/label mechanism is simple, it is =
far=20
      more flexible than an approach to compacting a list of IPv6=20
      addresses.  And note that the idea of using tags/labels is =
nothing=20
      new.  Of course we will adapt the basic mechanism a bit =
(label=20
      distribution, headers formats, etc), but the core ideas have been =
deployed=20
      in traditional IP networks for quite some time. 

    I =
reiterated a lot=20
      of what was already stated before by others, but that is what I =
think.=20
      

    -- 
    Jonathan Hui 

    On Apr 8, 2010, at 2:57 =
AM,=20
      Pascal Thubert (pthubert) wrote: 
    
      
    Hi Daniel: =


    Routers=20
      might have multiple interfaces of multiple MAC types. Internet 0 =

    even=20
      has a MAC-less format. 
    So the result of you proposal, which =
looks like=20
      a great idea in a pure 
    802.15.4 world with short addresses, =
becomes a=20
      nightmare to define in a 
    fully generic fashion. 

    OTOH, =
a=20
      locally significant opaque tag in which the parent could hide a =

    short=20
      address of the child - if it cares to do it that way - looks like =

    a=20
      way more acceptable approach 

    So it seems to me that you =
can get=20
      what you want as long as we can make 
    the tag big enough for =
short=20
      addresses. When the tag is too small to 
    contain what the =
parent really=20
      needs, then the parent will have to store 
    a state with the =
full=20
      information in memory, and then place an index of 
    some sort in =
the=20
      tag. 

    What do you think? 

    Pascal 

    
      
    -----Original Message----- 
    From: Popa, =
Daniel [mailto:Daniel.Popa@itron.com]=20
      
    Sent: Thursday, April 08, 2010 11:40 AM 
    To: ROLL WG =

    Cc: Pascal=20
      Thubert (pthubert); JeongGil Ko (John) 
    Subject: RE: [Roll] =
Proposal=20
      for Source Routing Header Format and 
    SourceRoutingOperations=20
      

    Hi Pascal, John, 

    Since source routing explicitly =
gives=20
      forwarding instruction to each 
    intermediate node, it can make =
sense to=20
      use only (MAC address based) 
    
      
    L2 
    
      
    forwarding instead of (IPv6 address based) L3 =

      forwarding. 

    This brings two advantages: 
    - avoid =
processing=20
      each transit packets up to L3. 
    - use MAC addresses that - in =
ROLL=20
      environment - have inherently 
    
      
    shorter 
    
      
    length than an IPv6 address. 

    Cheers, =

    Daniel=20
      



    -----Original Message----- 
    From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On=20
      Behalf 
    
      
    Of 
    
      
    Pascal Thubert (pthubert) 
    Sent: jeudi 8 =
avril 2010=20
      11:15 
    To: JeongGil Ko (John); ROLL WG 
    Subject: Re: [Roll] =
Proposal=20
      for Source Routing Header Format and 
    SourceRoutingOperations=20
      

    Hi John: 

    IPv6 already has a number of routing =
headers, in=20
      particular RH0, 
    
      
    though it is =

    
      
    being deprecated for general use in the =
Internet.=20
      
    And there are reasons why the fields in RH0/1 are there and we =
need to=20
      
    make sure we lose none of that. In particular a RH is =
recoverable, and=20
      
    
      
    it is 
    
      
    easy to spot the consumed entries. 

    On =
top of=20
      this our new problems are: 
    - make sure the RH stays within the =
RPL=20
      network (since it is used 
    
      
    downwards 
    
      
    that should be =
doable)=20
      
    - control the size (that probably means compress) =


    Cheers,=20
      

    Pascal 

    
      
    -----Original Message----- 
    From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On=20
      Behalf 
    
      
    Of 
    
      
    JeongGil Ko (John) 
    Sent: Wednesday, April =
07, 2010=20
      10:05 PM 
    To: ROLL WG 
    Subject: [Roll] Proposal for Source =
Routing=20
      Header Format and Source 
    RoutingOperations 

    Hi! =


    Great=20
      to see all this discussions on downwards route establishment! 
    
      
    To 
    
      
    add 
    
      
    one more to the conversations here is a =
proposal for=20
      source routing 
    
      
    headers. 
    
      
    In non-storing mode (where only the root has =
individual=20
      path 
    
      
    information) =

    
      
    the root will be attaching a source routing =
header to=20
      the data 
    
      
    packet 
    
      
    that a 
    
      
    source node wants to send to a specific =
destination. We=20
      can always 
    
      
    make the 
    
      
    header super fancy but in my opinion I think =
we only=20
      need two fields 
    
      
    in this 
    
      
    header and here it is! Feel free to break the =
stuff and=20
      mangle with 
    
      
    it 
    
      
    so that it 
    
      
    looks great in the specs later on. FYI, this =
is the=20
      format that I am 
    
      
    using in my =

    
      
    implementations so it does work :) 

    1. =
Source=20
      Routing Header Format=20
      =


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
=20
      
    |   NEntry (8 bits)   | 
    
      
    | 
    
      
    +-+-+-+-+-+-+-+-+ 
    
      
    + 
    
      |         =
            &=
nbsp;=20
      Source Route Entry (128*NEntry bits) 
    
      
    | 
    
      
    + 
    
      
    + 
    
      
    | 
    
      
    | 
    
      

         Figure 1. =
Proposed Source=20
      Routing Header Format; each line is 
    
      
    32 
    
      
    bits:) 
    
      

    - NEntry: Indicates the number of 128 bit =
addresses=20
      that the source 
    
      
    route 
    
      
    entry field is carrying. 

    - Source =
Route Entry:=20
      List of 128 bit address that consist the route 
    
      
    to the 
    
      
    destination. Here, the address of the node =
that is one=20
      hop away from 
    
      
    the 
    
      
    *destination* comes first. 

    2. Source =
Routing=20
      Packet Operations 

    When source routing is initiated at a =
storing=20
      node (e.g., root of 
    
      
    the 
    
      
    DODAG), 
    
      
    the header is attached on the data packet for =
the=20
      entire route 
    
      
    (i.e., 
    
      
    from 
    
      
    next hop node to the destination). This =
header is=20
      positioned in 
    
      
    front 
    
      
    of the 
    
      
    user payload. When the next hop node receives =
a packet=20
      that is not 
    
      
    destined 
    
      
    to itself AND the network is NOT provisioned =
to be in=20
      'storing mode' 
    
      
    then it 
    
      
    checks NEntry to find what the next hop is in =
the=20
      source route 
    
      
    entry. 
    
      
    Since 
    
      
    the 'Source Route Entry' is ordered in =
'farthest ->=20
      closest' (in 
    
      
    terms 
    
      
    of hops) 
    
      
    order, a node can figure out what the next =
hop address=20
      is with only 
    
      
    the 
    
      
    NEntry value (since it already knows how big =
an ipv6=20
      address is). 
    
      
    After 
    
      
    collecting the next hop node's address, the =
node erases=20
      this address 
    element from the entry and decreases NEntry by =
one. This=20
      assures 
    
      
    that 
    
      
    we 
    
      
    avoid the overhead of carrying the entire =
source route=20
      throughout 
    
      
    the 
    
      
    data 
    
      
    path. 

    The approach itself should be =
very simple=20
      and trivial for everyone 
    
      
    to 
    
      
    follow. 
    
      
    So we can start from here and build on! =


    Thanks.=20
      

    -John 

    ------ 
    JeongGil Ko (John) 
    Ph.D. =
Student=20
      
    Department of Computer Science 
    Johns Hopkins University =

    http://www.cs.jhu.edu/~jgko=20
      

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

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


------_=_NextPart_001_01CAD7CF.E2FBAD86--

From Daniel.Popa@itron.com  Fri Apr  9 04:10:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3779E3A68EB for ; Fri,  9 Apr 2010 04:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBNt00wnlYoG for ; Fri,  9 Apr 2010 04:09:46 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 668CF3A67FA for ; Fri,  9 Apr 2010 04:09:46 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7D5.277DA12F"
Date: Fri, 9 Apr 2010 07:09:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source RoutingHeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAJQ/eAABMLP4A==
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com> 
From: "Popa, Daniel" 
To: "Pascal Thubert (pthubert)" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 11:10:08 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7D5.277DA12F
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Pascal, all,=20

=20

The proposed 4e MAC Amendment for 802.15.4 introduces a "8-bit simple =
address" in addition to the 16-bit short and 64-bit extended addresses, =
from 802.15.4-2006.

So, we need 2 bits to signal the size (e.g., 8, 16, 32, and 64) of the =
"Label Value" Field.=20

=20

Below is the link to the proposed amendment draft (refer to rev6).=20

https://mentor.ieee.org/802.15/documents?is_dcn=3D604&is_group=3D004e

=20

Thanks.

=20

Cheers,=20

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Popa, Daniel
Sent: vendredi 9 avril 2010 11:45
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand =
SourceRoutingOperations

=20

Hi Pascal,=20

=20

I have first set of proposals concerning the tag/label size and content:

=20

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address =
and 64-bit extended address for Src and Dest Addressing Mode, I think we =
should have the same flexibility for tag/label addressing mode =3D> =
tag/label should potentially accommodate values represented on a field =
with a length up to 64 bits.=20

o   Currently, there are ongoing activities to amend MAC Layer for =
802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC =
address size. I will try have some further information about MAC Addr =
Length issue and be back on the mailing list asap.  =20

=20

-          Tag/Label contents:

=20

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

| Control fields | Label Value |=20

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

=20

o   Control fields

=A7  2 bits to signal labeling/tagging mode:  short/extended labels  =
=3D> the bit-length of the "Label Value (LV)"  field=20

=B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.=20

=A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 =
priority field into label priority).

=A7  Eventually, 1 bit for bottom of the stack flag - for source =
routing;  if set to 1 =3D> the current label/tag is last in the stack.

=A7  1 or 2 bits RFU.

=A7  Eventually, some bits for hop counts (?).

o   Label Value (LV) field

=A7  The value of the label/tag

=20

=20

Thanks.

=20

Cheers,

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Pascal Thubert (pthubert)
Sent: vendredi 9 avril 2010 10:36
To: robert.cragie@gridmerge.com; Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations

=20

I read this as a consensus to use tags J If anyone disagree please speak =
up now!

=20

There have been plenty iterations/versions of tagging since Frame Relay =
(pure switching), IBM's HPR (pure source route), Cisco's tag switching =
and MPLS. More often than not, a combination of the 2 models is used so =
that tags can be both swapped and stacked.=20

=20

-          In pure switching, there's only one tag in the packet. A tag =
can be locally significant, in which case it has to be swapped as the =
packet progresses. For RPL, it means that a node uses as many tags as it =
has children that use it has DAO targets in its subdag.

=20

-          In the pure source route model, tags are stacked in an =
ordered list that forms a strict routing header. A tag can be locally =
significant to the interpreter and is consumed (marked or removed) as =
the packet progresses. For RPL, it means that a node uses as many tags =
as it has children that use this node as DAO parent.=20

=20

It also appears that the 2 tagging models map quite well with the DAO =
models we have in RPL since the split that we decided with issue #26. =
The fact that the combination of the 2 models is possible in the real =
world today gives us a hint that we are not closing the door to the =
mixed model in the future.

=20

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by =
the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need =
to dig further)

-          Tag content and size (people have asked for at least 2 octets =
to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of =
addresses? What about the tag swapping  case, RH as well?)

=20

Advice?

=20

=20

=20

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand =
SourceRoutingOperations

=20

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20


Hi Robert,=20

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20

A couple of questions:=20
    * I presume the source route header using these tags/labels is an =
IPv6 extension header. What value for extension header type would this =
be? Would we need to specify a LOWPAN_NHC value for this so we can still =
use LOWPAN_NCH for UDP frames?=20


We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented it at 6man in Anaheim.  The option is designed to carry =
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for =
the IPv6 Hop-by-Hop Option header.=20

    * Can you point to where the 'core ideas have been deployed in =
traditional IP networks for quite some time'?=20


MPLS.  Again, I think the mechanisms will need to be adapted, but the =
core ideas are not new.=20

--=20
Jonathan Hui=20

Thanks=20

Robert=20
Robert Cragie (Pacific Gas & Electric)=20

Gridmerge Ltd.=20
89 Greenfield Crescent,=20
Wakefield, WF4 4WA, UK=20
+44 (0) 1924 910888=20
http://www.gridmerge.com=20


On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20



To make the source route header compact, I favor the tag/label approach =
over some other compaction mechanism that operates directly on a list of =
IPv6 addresses.  Tags/labels can be made general enough such that they =
can be derived in different ways.  Because the tags/labels have scope =
local to each node, the mechanism is pretty general already.  For those =
that are already managing unique 802.15.4 short addresses across a =
network, I can see that it is attractive to utilize the short address =
directly and reduce state on devices.  In other cases, it may be best =
for the node to dynamically assign tags/labels for its neighbors.=20

Either way, while the tag/label mechanism is simple, it is far more =
flexible than an approach to compacting a list of IPv6 addresses.  And =
note that the idea of using tags/labels is nothing new.  Of course we =
will adapt the basic mechanism a bit (label distribution, headers =
formats, etc), but the core ideas have been deployed in traditional IP =
networks for quite some time.=20

I reiterated a lot of what was already stated before by others, but that =
is what I think.=20

--=20
Jonathan Hui=20

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20

Hi Daniel:=20

Routers might have multiple interfaces of multiple MAC types. Internet 0 =

even has a MAC-less format.=20
So the result of you proposal, which looks like a great idea in a pure=20
802.15.4 world with short addresses, becomes a nightmare to define in a=20
fully generic fashion.=20

OTOH, a locally significant opaque tag in which the parent could hide a=20
short address of the child - if it cares to do it that way - looks like=20
a way more acceptable approach=20

So it seems to me that you can get what you want as long as we can make=20
the tag big enough for short addresses. When the tag is too small to=20
contain what the parent really needs, then the parent will have to store =

a state with the full information in memory, and then place an index of=20
some sort in the tag.=20

What do you think?=20

Pascal=20



-----Original Message-----=20
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
Sent: Thursday, April 08, 2010 11:40 AM=20
To: ROLL WG=20
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
Subject: RE: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi Pascal, John,=20

Since source routing explicitly gives forwarding instruction to each=20
intermediate node, it can make sense to use only (MAC address based)=20

L2=20

forwarding instead of (IPv6 address based) L3 forwarding.=20

This brings two advantages:=20
- avoid processing each transit packets up to L3.=20
- use MAC addresses that - in ROLL environment - have inherently=20

shorter=20

length than an IPv6 address.=20

Cheers,=20
Daniel=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

Pascal Thubert (pthubert)=20
Sent: jeudi 8 avril 2010 11:15=20
To: JeongGil Ko (John); ROLL WG=20
Subject: Re: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi John:=20

IPv6 already has a number of routing headers, in particular RH0,=20

though it is=20

being deprecated for general use in the Internet.=20
And there are reasons why the fields in RH0/1 are there and we need to=20
make sure we lose none of that. In particular a RH is recoverable, and=20

it is=20

easy to spot the consumed entries.=20

On top of this our new problems are:=20
- make sure the RH stays within the RPL network (since it is used=20

downwards=20

that should be doable)=20
- control the size (that probably means compress)=20

Cheers,=20

Pascal=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

JeongGil Ko (John)=20
Sent: Wednesday, April 07, 2010 10:05 PM=20
To: ROLL WG=20
Subject: [Roll] Proposal for Source Routing Header Format and Source=20
RoutingOperations=20

Hi!=20

Great to see all this discussions on downwards route establishment!=20

To=20

add=20

one more to the conversations here is a proposal for source routing=20

headers.=20

In non-storing mode (where only the root has individual path=20

information)=20

the root will be attaching a source routing header to the data=20

packet=20

that a=20

source node wants to send to a specific destination. We can always=20

make the=20

header super fancy but in my opinion I think we only need two fields=20

in this=20

header and here it is! Feel free to break the stuff and mangle with=20

it=20

so that it=20

looks great in the specs later on. FYI, this is the format that I am=20

using in my=20

implementations so it does work :)=20

1. Source Routing Header Format=20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|   NEntry (8 bits)   |=20

|=20

+-+-+-+-+-+-+-+-+=20

+=20

|                       Source Route Entry (128*NEntry bits)=20

|=20

+=20

+=20

|=20

|=20


     Figure 1. Proposed Source Routing Header Format; each line is=20

32=20

bits:)=20


- NEntry: Indicates the number of 128 bit addresses that the source=20

route=20

entry field is carrying.=20

- Source Route Entry: List of 128 bit address that consist the route=20

to the=20

destination. Here, the address of the node that is one hop away from=20

the=20

*destination* comes first.=20

2. Source Routing Packet Operations=20

When source routing is initiated at a storing node (e.g., root of=20

the=20

DODAG),=20

the header is attached on the data packet for the entire route=20

(i.e.,=20

from=20

next hop node to the destination). This header is positioned in=20

front=20

of the=20

user payload. When the next hop node receives a packet that is not=20

destined=20

to itself AND the network is NOT provisioned to be in 'storing mode'=20

then it=20

checks NEntry to find what the next hop is in the source route=20

entry.=20

Since=20

the 'Source Route Entry' is ordered in 'farthest -> closest' (in=20

terms=20

of hops)=20

order, a node can figure out what the next hop address is with only=20

the=20

NEntry value (since it already knows how big an ipv6 address is).=20

After=20

collecting the next hop node's address, the node erases this address=20
element from the entry and decreases NEntry by one. This assures=20

that=20

we=20

avoid the overhead of carrying the entire source route throughout=20

the=20

data=20

path.=20

The approach itself should be very simple and trivial for everyone=20

to=20

follow.=20

So we can start from here and build on!=20

Thanks.=20

-John=20

------=20
JeongGil Ko (John)=20
Ph.D. Student=20
Department of Computer Science=20
Johns Hopkins University=20
http://www.cs.jhu.edu/~jgko=20

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

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

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


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

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

=20


------_=_NextPart_001_01CAD7D5.277DA12F
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













    


    Pascal, all, 
    


     
    


    The proposed 4e MAC Amendment for 802.15.4 introduces a =
“8-bit
simple address” in addition to the 16-bit short and 64-bit =
extended addresses,
from 802.15.4-2006.
    


    So, we need 2 bits to signal the size (e.g., 8, 16, 32, =
and 64)
of the “Label Value” Field. 
    


     
    


    Below is the link to the proposed amendment draft (refer =
to rev6).

    


    https://mentor.ieee.org/802.15/documents?is_dcn=3D604&is_gr=
oup=3D004e
    


     
    


    Thanks.
    


     
    


    Cheers, 
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: vendredi 9 avril 2010 11:45
    
To: Pascal Thubert (pthubert)
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    Hi Pascal, 
    


     
    


    I have first set of proposals concerning the tag/label =
size
and content:
    


     
    


    -         
Tag/Label =
size:
    


    o   =
As
802.15.4-2006 defines addressing modes with 16-bit short address and =
64-bit
extended address for Src and Dest Addressing Mode, I think we should =
have the
same flexibility for tag/label addressing mode =3D> tag/label should
potentially accommodate values represented on a field with a length up =
to 64
bits. 
    


    o   =
Currently,
there are ongoing activities to amend MAC Layer for 802.15.4-2006 (TG =
4e) that
might alter the aforementioned values for MAC address size. I will try =
have
some further information about MAC Addr Length issue and be back on the =
mailing
list asap.   
    


     
    


    -         
Tag/Label =
contents:
    


     
    


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

    


    | Control fields | Label Value | =

    


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

    


     
    


    o   =
Control
fields
    


    =A7  =
2
bits to signal labeling/tagging mode:  short/extended labels =
 =3D>
the bit-length of the “Label Value (LV)” =
 field 
    


    =B7        
2 bits =3D> 4 modes for LV length : 8, 16, 32 and =
64 bits. 
    


    =A7  =
Eventually,
few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 priority field =
into
label priority).
    


    =A7  =
Eventually,
1 bit for bottom of the stack flag - for source routing;  if =
set to
1 =3D> the current label/tag is last in the =
stack.
    


    =A7  =
1
or 2 bits RFU.
    


    =A7  =
Eventually,
some bits for hop counts (?).
    


    o   =
Label
Value (LV) field
    


    =A7  =
The
value of the label/tag
    


     
    


     
    


    Thanks.
    


     
    


    Cheers,
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert =
(pthubert)
    
Sent: vendredi 9 avril 2010 10:36
    
To: robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    I read this as a consensus to use tags J If anyone
disagree please speak up now!
    


     
    


    There have been plenty iterations/versions of tagging =
since
Frame Relay (pure switching), IBM’s HPR (pure source route),
Cisco’s tag switching and MPLS. More often than not, a combination =
of the
2 models is used so that tags can be both swapped and stacked. =

    


     
    


    -         
In pure switching, there’s only one tag in the =
packet. A
tag can be locally significant, in which case it has to be swapped as =
the
packet progresses. For RPL, it means that a node uses as many tags as it =
has
children that use it has DAO targets in its =
subdag.
    


     
    


    -         
In the pure source route model, tags are stacked in an =
ordered
list that forms a strict routing header. A tag can be locally =
significant to
the interpreter and is consumed (marked or removed) as the packet =
progresses.
For RPL, it means that a node uses as many tags as it has children that =
use
this node as DAO parent. 
    


     
    


    It also appears that the 2 tagging models map quite well =
with
the DAO models we have in RPL since the split that we decided with issue =
#26.
The fact that the combination of the 2 models is possible in the real =
world
today gives us a hint that we are not closing the door to the mixed =
model in
the future.
    


     
    


    The next step I wish to agree upon:
    


    -         
Use locally significant tags which implies tag assignment =
by the
node that uses it later and tag swapping for the stateful =
case.
    


    -         
Tag distribution in DAO (there are options there that we =
need to
dig further)
    


    -         
Tag content and size (people have asked for at least 2 =
octets to
fit 15.4 short addresses, do we need some control field as =
well?)
    


    -         
RH format (inherit RH0 fields with labels instead of =
addresses?
What about the tag swapping  case, RH as =
well?)
    


     
    


    Advice?
    


     
    


     
    


     
    


     
    


    


    Pascal
    


    


     
    


    


    


    


    From: =
roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    OK, sounds good. End of topic as far as I am =
concerned. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    


    A couple of questions: 
    
    • I presume the source route header using =
these
tags/labels is an IPv6 extension header. What value for extension header =
type
would this be? Would we need to specify a LOWPAN_NHC value for this so =
we can
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented
it at 6man in Anaheim.  The option is designed to carry =
RPL-specific
information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6
Hop-by-Hop Option header. 
    


        • Can you point to =
where the
'core ideas have been deployed in traditional IP networks for quite some =
time'?

    



    
MPLS.  Again, I think the mechanisms will need to be adapted, but =
the core
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach =
over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they =
can be
derived in different ways.  Because the tags/labels have scope =
local to
each node, the mechanism is pretty general already.  For those that =
are
already managing unique 802.15.4 short addresses across a network, I can =
see
that it is attractive to utilize the short address directly and reduce =
state on
devices.  In other cases, it may be best for the node to =
dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more =
flexible
than an approach to compacting a list of IPv6 addresses.  And note =
that
the idea of using tags/labels is nothing new.  Of course we will =
adapt the
basic mechanism a bit (label distribution, headers formats, etc), but =
the core
ideas have been deployed in traditional IP networks for quite some time. =

    

    
I reiterated a lot of what was already stated before by others, but that =
is
what I think. 
    

    
-- 
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =

    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 =

    
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure =

    
802.15.4 world with short addresses, becomes a nightmare to define in a =

    
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a =

    
short address of the child - if it cares to do it that way - looks like =

    
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make =

    
the tag big enough for short addresses. When the tag is too small to =

    
contain what the parent really needs, then the parent will have to store =

    
a state with the full information in memory, and then place an index of =

    
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    

    

    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each =

    
intermediate node, it can make sense to use only (MAC address based) =

    


    L2 
    


    forwarding instead of (IPv6 address based) L3 =
forwarding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently =

    


    shorter =

    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, =

    


    though it is =

    


    being deprecated for general use in the Internet. =

    
And there are reasons why the fields in RH0/1 are there and we need to =

    
make sure we lose none of that. In particular a RH is recoverable, and =

    


    it is =

    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used =

    


    downwards =

    


    that should be =
doable) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    

    

    


    -----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source =

    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! =

    


    To 
    


    add 
    


    one more to the conversations here is a proposal =
for source
routing 
    


    headers. =

    


    In non-storing mode (where only the root has =
individual path

    


    information) =

    


    the root will be attaching a source routing header =
to the
data 
    


    packet =

    


    that a =

    


    source node wants to send to a specific =
destination. We can
always 
    


    make the =

    


    header super fancy but in my opinion I think we =
only need
two fields 
    


    in this =

    


    header and here it is! Feel free to break the stuff =
and mangle
with 
    


    it 
    


    so that it =

    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my =

    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|   NEntry (8 bits)   | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |         =
            &=
nbsp;
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
     Figure 1. Proposed Source Routing Header =
Format; each
line is 
    


    32 
    


    bits:) =

    



    
- NEntry: Indicates the number of 128 bit addresses that the source =

    


    route =

    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route =

    


    to the =

    


    destination. Here, the address of the node that is =
one hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of =

    


    the 
    


    DODAG), =

    


    the header is attached on the data packet for the =
entire
route 
    


    (i.e., =

    


    from 
    


    next hop node to the destination). This header is =
positioned
in 
    


    front =

    


    of the =

    


    user payload. When the next hop node receives a =
packet that
is not 
    


    destined =

    


    to itself AND the network is NOT provisioned to be =
in
'storing mode' 
    


    then it =

    


    checks NEntry to find what the next hop is in the =
source
route 
    


    entry. =

    


    Since =

    


    the 'Source Route Entry' is ordered in 'farthest =
->
closest' (in 
    


    terms =

    


    of hops) =

    


    order, a node can figure out what the next hop =
address is
with only 
    


    the 
    


    NEntry value (since it already knows how big an =
ipv6 address
is). 
    


    After =

    


    collecting the next hop node's address, the node =
erases this
address 
    
element from the entry and decreases NEntry by one. This assures =

    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source =
route
throughout 
    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone =

    


    to 
    


    follow. =

    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko =

    

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

    


    _______________________________________________ =

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

    


    _______________________________________________ =

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

    



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

    


    _______________________________________________ =

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

    


     
    


    


    





------_=_NextPart_001_01CAD7D5.277DA12F--

From d.sturek@att.net  Fri Apr  9 07:00:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE16A3A688F for ; Fri,  9 Apr 2010 07:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.814
X-Spam-Level: 
X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AmRoaKjVh3h for ; Fri,  9 Apr 2010 07:00:16 -0700 (PDT)
Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 5C9673A688A for ; Fri,  9 Apr 2010 07:00:10 -0700 (PDT)
Received: (qmail 87323 invoked from network); 9 Apr 2010 14:00:03 -0000
Received: from adsl-69-108-50-59.dsl.sndg02.pacbell.net (d.sturek@69.108.50.59 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 09 Apr 2010 07:00:02 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: JZlv65cVM1m.rWshF2okxFxtecQ4vJOSxHQnelr.QPJGJgtM_wVUTBH0co8m0kN1EBSA8pt_bdoxgHTokMQUTyAV82hjrMxpcpX2h6xAcaqUiXHB6sC8XCFCjubvsgPpoCKf5oeq2BLHucGTwmdnwfixZSqZjes5H4e4fvgBc0php3eR1hs8y6qEY4lQbCUGyGuZoPmwwRRzKeALVOUv9hzkg4I7qGn.IHbOeSzXl5KgHP2KTe05MeXbNtTpu31xRdL4QybRPg3ALrySCeGiwsweh1Wdb_xmzHg.WKoHnHLqYGPBUBhnLhrwpbi72soKfId9IyUb2KwKYJ.76wl7WJTrQl0-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Popa, Daniel'" , "'Pascal Thubert \(pthubert\)'" 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>	 
In-Reply-To: 
Date: Fri, 9 Apr 2010 06:59:58 -0700
Message-ID: <00d501cad7ec$f34f88d0$d9ee9a70$@sturek@att.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01CAD7B2.46F0B0D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAJQ/eAABMLP4AAGJZ5w
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source	RoutingHeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Apr 2010 14:00:30 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00D6_01CAD7B2.46F0B0D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

4e is a ways away from ratification in IEEE.  I would not assume 8 bit
simple addresses quite yet.  Note that these would only be useful in a
subset of deployed networks given the extremely small address range they
would provide.


Don

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Popa, Daniel
Sent: Friday, April 09, 2010 4:10 AM
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations

=20

Pascal, all,=20

=20

The proposed 4e MAC Amendment for 802.15.4 introduces a =938-bit simple
address=94 in addition to the 16-bit short and 64-bit extended =
addresses, from
802.15.4-2006.

So, we need 2 bits to signal the size (e.g., 8, 16, 32, and 64) of the
=93Label Value=94 Field.=20

=20

Below is the link to the proposed amendment draft (refer to rev6).=20

https://mentor.ieee.org/802.15/documents?is_dcn=3D604

&is_group=3D004e

=20

Thanks.

=20

Cheers,=20

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Popa, Daniel
Sent: vendredi 9 avril 2010 11:45
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations

=20

Hi Pascal,=20

=20

I have first set of proposals concerning the tag/label size and content:

=20

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address =
and
64-bit extended address for Src and Dest Addressing Mode, I think we =
should
have the same flexibility for tag/label addressing mode =3D> tag/label =
should
potentially accommodate values represented on a field with a length up =
to 64
bits.=20

o   Currently, there are ongoing activities to amend MAC Layer for
802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC
address size. I will try have some further information about MAC Addr =
Length
issue and be back on the mailing list asap.  =20

=20

-          Tag/Label contents:

=20

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

| Control fields | Label Value |=20

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

=20

o   Control fields

=A7  2 bits to signal labeling/tagging mode:  short/extended labels  =
=3D> the
bit-length of the =93Label Value (LV)=94  field=20

=B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.=20

=A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6
priority field into label priority).

=A7  Eventually, 1 bit for bottom of the stack flag - for source =
routing;  if
set to 1 =3D> the current label/tag is last in the stack.

=A7  1 or 2 bits RFU.

=A7  Eventually, some bits for hop counts (?).

o   Label Value (LV) field

=A7  The value of the label/tag

=20

=20

Thanks.

=20

Cheers,

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Pascal Thubert (pthubert)
Sent: vendredi 9 avril 2010 10:36
To: robert.cragie@gridmerge.com; Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

=20

I read this as a consensus to use tags J If anyone disagree please speak =
up
now!

=20

There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM=92s HPR (pure source route), Cisco=92s tag =
switching and
MPLS. More often than not, a combination of the 2 models is used so that
tags can be both swapped and stacked.=20

=20

-          In pure switching, there=92s only one tag in the packet. A =
tag can
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use it has DAO targets in its subdag.

=20

-          In the pure source route model, tags are stacked in an =
ordered
list that forms a strict routing header. A tag can be locally =
significant to
the interpreter and is consumed (marked or removed) as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use this node as DAO parent.=20

=20

It also appears that the 2 tagging models map quite well with the DAO =
models
we have in RPL since the split that we decided with issue #26. The fact =
that
the combination of the 2 models is possible in the real world today =
gives us
a hint that we are not closing the door to the mixed model in the =
future.

=20

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by =
the
node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need =
to
dig further)

-          Tag content and size (people have asked for at least 2 octets =
to
fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of =
addresses?
What about the tag swapping  case, RH as well?)

=20

Advice?

=20

=20

=20

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

=20

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20


Hi Robert,=20

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20

A couple of questions:=20
    =95 I presume the source route header using these tags/labels is an =
IPv6
extension header. What value for extension header type would this be? =
Would
we need to specify a LOWPAN_NHC value for this so we can still use
LOWPAN_NCH for UDP frames?=20


We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for =
the
IPv6 Hop-by-Hop Option header.=20

    =95 Can you point to where the 'core ideas have been deployed in
traditional IP networks for quite some time'?=20


MPLS.  Again, I think the mechanisms will need to be adapted, but the =
core
ideas are not new.=20

--=20
Jonathan Hui=20

Thanks=20

Robert=20
Robert Cragie (Pacific Gas & Electric)=20

Gridmerge Ltd.=20
89 Greenfield Crescent,=20
Wakefield, WF4 4WA, UK=20
+44 (0) 1924 910888=20
http://www.gridmerge.com=20


On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20



To make the source route header compact, I favor the tag/label approach =
over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they can be
derived in different ways.  Because the tags/labels have scope local to =
each
node, the mechanism is pretty general already.  For those that are =
already
managing unique 802.15.4 short addresses across a network, I can see =
that it
is attractive to utilize the short address directly and reduce state on
devices.  In other cases, it may be best for the node to dynamically =
assign
tags/labels for its neighbors.=20

Either way, while the tag/label mechanism is simple, it is far more =
flexible
than an approach to compacting a list of IPv6 addresses.  And note that =
the
idea of using tags/labels is nothing new.  Of course we will adapt the =
basic
mechanism a bit (label distribution, headers formats, etc), but the core
ideas have been deployed in traditional IP networks for quite some time. =


I reiterated a lot of what was already stated before by others, but that =
is
what I think.=20

--=20
Jonathan Hui=20

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20

Hi Daniel:=20

Routers might have multiple interfaces of multiple MAC types. Internet 0 =

even has a MAC-less format.=20
So the result of you proposal, which looks like a great idea in a pure=20
802.15.4 world with short addresses, becomes a nightmare to define in a=20
fully generic fashion.=20

OTOH, a locally significant opaque tag in which the parent could hide a=20
short address of the child - if it cares to do it that way - looks like=20
a way more acceptable approach=20

So it seems to me that you can get what you want as long as we can make=20
the tag big enough for short addresses. When the tag is too small to=20
contain what the parent really needs, then the parent will have to store =

a state with the full information in memory, and then place an index of=20
some sort in the tag.=20

What do you think?=20

Pascal=20

-----Original Message-----=20
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
Sent: Thursday, April 08, 2010 11:40 AM=20
To: ROLL WG=20
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
Subject: RE: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi Pascal, John,=20

Since source routing explicitly gives forwarding instruction to each=20
intermediate node, it can make sense to use only (MAC address based)=20

L2=20

forwarding instead of (IPv6 address based) L3 forwarding.=20

This brings two advantages:=20
- avoid processing each transit packets up to L3.=20
- use MAC addresses that - in ROLL environment - have inherently=20

shorter=20

length than an IPv6 address.=20

Cheers,=20
Daniel=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

Pascal Thubert (pthubert)=20
Sent: jeudi 8 avril 2010 11:15=20
To: JeongGil Ko (John); ROLL WG=20
Subject: Re: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi John:=20

IPv6 already has a number of routing headers, in particular RH0,=20

though it is=20

being deprecated for general use in the Internet.=20
And there are reasons why the fields in RH0/1 are there and we need to=20
make sure we lose none of that. In particular a RH is recoverable, and=20

it is=20

easy to spot the consumed entries.=20

On top of this our new problems are:=20
- make sure the RH stays within the RPL network (since it is used=20

downwards=20

that should be doable)=20
- control the size (that probably means compress)=20

Cheers,=20

Pascal=20

-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

JeongGil Ko (John)=20
Sent: Wednesday, April 07, 2010 10:05 PM=20
To: ROLL WG=20
Subject: [Roll] Proposal for Source Routing Header Format and Source=20
RoutingOperations=20

Hi!=20

Great to see all this discussions on downwards route establishment!=20

To=20

add=20

one more to the conversations here is a proposal for source routing=20

headers.=20

In non-storing mode (where only the root has individual path=20

information)=20

the root will be attaching a source routing header to the data=20

packet=20

that a=20

source node wants to send to a specific destination. We can always=20

make the=20

header super fancy but in my opinion I think we only need two fields=20

in this=20

header and here it is! Feel free to break the stuff and mangle with=20

it=20

so that it=20

looks great in the specs later on. FYI, this is the format that I am=20

using in my=20

implementations so it does work :)=20

1. Source Routing Header Format=20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|   NEntry (8 bits)   |=20

|=20

+-+-+-+-+-+-+-+-+=20

+=20

|                       Source Route Entry (128*NEntry bits)=20

|=20

+=20

+=20

|=20

|=20


     Figure 1. Proposed Source Routing Header Format; each line is=20

32=20

bits:)=20


- NEntry: Indicates the number of 128 bit addresses that the source=20

route=20

entry field is carrying.=20

- Source Route Entry: List of 128 bit address that consist the route=20

to the=20

destination. Here, the address of the node that is one hop away from=20

the=20

*destination* comes first.=20

2. Source Routing Packet Operations=20

When source routing is initiated at a storing node (e.g., root of=20

the=20

DODAG),=20

the header is attached on the data packet for the entire route=20

(i.e.,=20

from=20

next hop node to the destination). This header is positioned in=20

front=20

of the=20

user payload. When the next hop node receives a packet that is not=20

destined=20

to itself AND the network is NOT provisioned to be in 'storing mode'=20

then it=20

checks NEntry to find what the next hop is in the source route=20

entry.=20

Since=20

the 'Source Route Entry' is ordered in 'farthest -> closest' (in=20

terms=20

of hops)=20

order, a node can figure out what the next hop address is with only=20

the=20

NEntry value (since it already knows how big an ipv6 address is).=20

After=20

collecting the next hop node's address, the node erases this address=20
element from the entry and decreases NEntry by one. This assures=20

that=20

we=20

avoid the overhead of carrying the entire source route throughout=20

the=20

data=20

path.=20

The approach itself should be very simple and trivial for everyone=20

to=20

follow.=20

So we can start from here and build on!=20

Thanks.=20

-John=20

------=20
JeongGil Ko (John)=20
Ph.D. Student=20
Department of Computer Science=20
Johns Hopkins University=20
http://www.cs.jhu.edu/~jgko=20

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

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

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


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

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

=20


------=_NextPart_000_00D6_01CAD7B2.46F0B0D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














    


    4e is a ways away from ratification in IEEE.=A0 I would =
not assume
8 bit simple addresses quite yet.=A0 Note that these would only be =
useful in a
subset of deployed networks given the extremely small address range they =
would
provide.
    



    
Don
    


     
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: Friday, April 09, 2010 4:10 AM
    
To: Pascal Thubert (pthubert)
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    Pascal, all, 
    


     
    


    The proposed 4e MAC Amendment for 802.15.4 introduces a =
“8-bit
simple address” in addition to the 16-bit short and 64-bit =
extended addresses,
from 802.15.4-2006.
    


    So, we need 2 bits to signal the size (e.g., 8, 16, 32, =
and 64)
of the “Label Value” Field. 
    


     
    


    Below is the link to the proposed amendment draft (refer =
to
rev6). 
    


    https://mentor.ieee.org/802.15/documents?is_dcn=3D604&is_gr=
oup=3D004e
    


     
    


    Thanks.
    


     
    


    Cheers, 
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: vendredi 9 avril 2010 11:45
    
To: Pascal Thubert (pthubert)
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    Hi Pascal, 
    


     
    


    I have first set of proposals concerning the tag/label =
size
and content:
    


     
    


    -         
Tag/Label =
size:
    


    o   =
As
802.15.4-2006 defines addressing modes with 16-bit short address and =
64-bit
extended address for Src and Dest Addressing Mode, I think we should =
have the
same flexibility for tag/label addressing mode =3D> tag/label should
potentially accommodate values represented on a field with a length up =
to 64
bits. 
    


    o   =
Currently,
there are ongoing activities to amend MAC Layer for 802.15.4-2006 (TG =
4e) that
might alter the aforementioned values for MAC address size. I will try =
have
some further information about MAC Addr Length issue and be back on the =
mailing
list asap.   
    


     
    


    -         
Tag/Label =
contents:
    


     
    


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

    


    | Control fields | Label Value | =

    


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

    


     
    


    o   =
Control
fields
    


    =A7  =
2
bits to signal labeling/tagging mode:  short/extended labels =
 =3D>
the bit-length of the “Label Value (LV)” =
 field 
    


    =B7        
2 bits =3D> 4 modes for LV length : 8, 16, 32 and =
64 bits. 
    


    =A7  =
Eventually,
few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 priority field =
into
label priority).
    


    =A7  =
Eventually,
1 bit for bottom of the stack flag - for source routing;  if =
set to
1 =3D> the current label/tag is last in the =
stack.
    


    =A7  =
1
or 2 bits RFU.
    


    =A7  =
Eventually,
some bits for hop counts (?).
    


    o   =
Label
Value (LV) field
    


    =A7  =
The
value of the label/tag
    


     
    


     
    


    Thanks.
    


     
    


    Cheers,
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert =
(pthubert)
    
Sent: vendredi 9 avril 2010 10:36
    
To: robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations
    


    


    


     
    


    I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


     
    


    There have been plenty iterations/versions of tagging =
since
Frame Relay (pure switching), IBM’s HPR (pure source route), =
Cisco’s tag
switching and MPLS. More often than not, a combination of the 2 models =
is used
so that tags can be both swapped and stacked. 
    


     
    


    -         
In pure switching, there’s only one tag in the =
packet. A tag can
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has =
children
that use it has DAO targets in its subdag.
    


     
    


    -         
In the pure source route model, tags are stacked in an =
ordered
list that forms a strict routing header. A tag can be locally =
significant to the
interpreter and is consumed (marked or removed) as the packet =
progresses. For
RPL, it means that a node uses as many tags as it has children that use =
this
node as DAO parent. 
    


     
    


    It also appears that the 2 tagging models map quite well =
with
the DAO models we have in RPL since the split that we decided with issue =
#26.
The fact that the combination of the 2 models is possible in the real =
world
today gives us a hint that we are not closing the door to the mixed =
model in
the future.
    


     
    


    The next step I wish to agree upon:
    


    -         
Use locally significant tags which implies tag assignment =
by the
node that uses it later and tag swapping for the stateful =
case.
    


    -         
Tag distribution in DAO (there are options there that we =
need to
dig further)
    


    -         
Tag content and size (people have asked for at least 2 =
octets to
fit 15.4 short addresses, do we need some control field as =
well?)
    


    -         
RH format (inherit RH0 fields with labels instead of =
addresses?
What about the tag swapping  case, RH as =
well?)
    


     
    


    Advice?
    


     
    


     
    


     
    


     
    


    


    Pascal
    


    


     
    


    


    


    


    From: =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]
On Behalf Of Robert Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    OK, sounds good. End of topic as far as I am =
concerned. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    


    A couple of questions: 
    
    • I presume the source route header using =
these
tags/labels is an IPv6 extension header. What value for extension header =
type
would this be? Would we need to specify a LOWPAN_NHC value for this so =
we can
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented
it at 6man in Anaheim.  The option is designed to carry =
RPL-specific
information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6
Hop-by-Hop Option header. 
    


        • Can you point to =
where the 'core
ideas have been deployed in traditional IP networks for quite some =
time'? 
    



    
MPLS.  Again, I think the mechanisms will need to be adapted, but =
the core
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach =
over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they =
can be
derived in different ways.  Because the tags/labels have scope =
local to
each node, the mechanism is pretty general already.  For those that =
are
already managing unique 802.15.4 short addresses across a network, I can =
see
that it is attractive to utilize the short address directly and reduce =
state on
devices.  In other cases, it may be best for the node to =
dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more =
flexible
than an approach to compacting a list of IPv6 addresses.  And note =
that
the idea of using tags/labels is nothing new.  Of course we will =
adapt the
basic mechanism a bit (label distribution, headers formats, etc), but =
the core
ideas have been deployed in traditional IP networks for quite some time. =

    

    
I reiterated a lot of what was already stated before by others, but that =
is
what I think. 
    

    
-- 
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =

    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 =

    
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure =

    
802.15.4 world with short addresses, becomes a nightmare to define in a =

    
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a =

    
short address of the child - if it cares to do it that way - looks like =

    
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make =

    
the tag big enough for short addresses. When the tag is too small to =

    
contain what the parent really needs, then the parent will have to store =

    
a state with the full information in memory, and then place an index of =

    
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each =

    
intermediate node, it can make sense to use only (MAC address based) =

    


    L2 
    


    forwarding instead of (IPv6 address based) L3 =
forwarding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently =

    


    shorter =

    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, =

    


    though it is =

    


    being deprecated for general use in the Internet. =

    
And there are reasons why the fields in RH0/1 are there and we need to =

    
make sure we lose none of that. In particular a RH is recoverable, and =

    


    it is =

    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used =

    


    downwards =

    


    that should be =
doable) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    


    -----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source =

    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! =

    


    To 
    


    add 
    


    one more to the conversations here is a proposal =
for source
routing 
    


    headers. =

    


    In non-storing mode (where only the root has =
individual path

    


    information) =

    


    the root will be attaching a source routing header =
to the
data 
    


    packet =

    


    that a =

    


    source node wants to send to a specific =
destination. We can
always 
    


    make the =

    


    header super fancy but in my opinion I think we =
only need
two fields 
    


    in this =

    


    header and here it is! Feel free to break the stuff =
and
mangle with 
    


    it 
    


    so that it =

    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my =

    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|   NEntry (8 bits)   | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |         =
            &=
nbsp;
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
     Figure 1. Proposed Source Routing Header =
Format; each
line is 
    


    32 
    


    bits:) =

    



    
- NEntry: Indicates the number of 128 bit addresses that the source =

    


    route =

    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route =

    


    to the =

    


    destination. Here, the address of the node that is =
one hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of =

    


    the 
    


    DODAG), =

    


    the header is attached on the data packet for the =
entire
route 
    


    (i.e., =

    


    from 
    


    next hop node to the destination). This header is =
positioned
in 
    


    front =

    


    of the =

    


    user payload. When the next hop node receives a =
packet that
is not 
    


    destined =

    


    to itself AND the network is NOT provisioned to be =
in
'storing mode' 
    


    then it =

    


    checks NEntry to find what the next hop is in the =
source
route 
    


    entry. =

    


    Since =

    


    the 'Source Route Entry' is ordered in 'farthest =
->
closest' (in 
    


    terms =

    


    of hops) =

    


    order, a node can figure out what the next hop =
address is
with only 
    


    the 
    


    NEntry value (since it already knows how big an =
ipv6 address
is). 
    


    After =

    


    collecting the next hop node's address, the node =
erases this
address 
    
element from the entry and decreases NEntry by one. This assures =

    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source =
route
throughout 
    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone =

    


    to 
    


    follow. =

    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko =

    

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

    


    _______________________________________________ =

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

    


    _______________________________________________ =

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

    



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

    


    _______________________________________________ =

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

    


     
    


    


    





------=_NextPart_000_00D6_01CAD7B2.46F0B0D0--


From Daniel.Popa@itron.com  Fri Apr  9 07:41:11 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA163A6923 for ; Fri,  9 Apr 2010 07:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TendZXBg9Vzm for ; Fri,  9 Apr 2010 07:40:54 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 087623A68E3 for ; Fri,  9 Apr 2010 07:39:59 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7F2.85C66FBF"
Date: Fri, 9 Apr 2010 10:39:50 -0400
Message-ID: 
In-Reply-To: <00d501cad7ec$f34f88d0$d9ee9a70$@sturek@att.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source	RoutingHeaderFormatand	SourceRoutingOperations
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAJQ/eAABMLP4AAGJZ5wAADm1mA=
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>	  <00d501cad7ec$f34f88d0$d9ee9a70$@sturek@att.net>
From: "Popa, Daniel" 
To: , "Pascal Thubert (pthubert)" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source	RoutingHeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 14:41:11 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAD7F2.85C66FBF
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Maybe, but I think the 8-bit simple address will not be THE issue that =
will stop ratification of the 4e amendment.=20

=20

I assume that a generic labeling approach should not close the door for =
further developments or existing deployments.  So, having variable-size =
labels (e.g., in steps of octets, but no longer than some M octets) can =
better adapt to heterogeneous devices, which will have different =
constraints. One may design shorter labels for some devices and longer =
labels for some other devices.=20

=20

Cheers,=20

Daniel=20

=20

From: Don Sturek [mailto:d.sturek@att.net]=20
Sent: vendredi 9 avril 2010 16:00
To: Popa, Daniel; 'Pascal Thubert (pthubert)'
Cc: roll@ietf.org
Subject: RE: [Roll] Proposal for Source RoutingHeaderFormatand =
SourceRoutingOperations

=20

4e is a ways away from ratification in IEEE.  I would not assume 8 bit =
simple addresses quite yet.  Note that these would only be useful in a =
subset of deployed networks given the extremely small address range they =
would provide.


Don

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Popa, Daniel
Sent: Friday, April 09, 2010 4:10 AM
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand =
SourceRoutingOperations

=20

Pascal, all,=20

=20

The proposed 4e MAC Amendment for 802.15.4 introduces a "8-bit simple =
address" in addition to the 16-bit short and 64-bit extended addresses, =
from 802.15.4-2006.

So, we need 2 bits to signal the size (e.g., 8, 16, 32, and 64) of the =
"Label Value" Field.=20

=20

Below is the link to the proposed amendment draft (refer to rev6).=20

https://mentor.ieee.org/802.15/documents?is_dcn=3D604&is_group=3D004e

=20

Thanks.

=20

Cheers,=20

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Popa, Daniel
Sent: vendredi 9 avril 2010 11:45
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand =
SourceRoutingOperations

=20

Hi Pascal,=20

=20

I have first set of proposals concerning the tag/label size and content:

=20

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address =
and 64-bit extended address for Src and Dest Addressing Mode, I think we =
should have the same flexibility for tag/label addressing mode =3D> =
tag/label should potentially accommodate values represented on a field =
with a length up to 64 bits.=20

o   Currently, there are ongoing activities to amend MAC Layer for =
802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC =
address size. I will try have some further information about MAC Addr =
Length issue and be back on the mailing list asap.  =20

=20

-          Tag/Label contents:

=20

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

| Control fields | Label Value |=20

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

=20

o   Control fields

=A7  2 bits to signal labeling/tagging mode:  short/extended labels  =
=3D> the bit-length of the "Label Value (LV)"  field=20

=B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.=20

=A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 =
priority field into label priority).

=A7  Eventually, 1 bit for bottom of the stack flag - for source =
routing;  if set to 1 =3D> the current label/tag is last in the stack.

=A7  1 or 2 bits RFU.

=A7  Eventually, some bits for hop counts (?).

o   Label Value (LV) field

=A7  The value of the label/tag

=20

=20

Thanks.

=20

Cheers,

Daniel=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Pascal Thubert (pthubert)
Sent: vendredi 9 avril 2010 10:36
To: robert.cragie@gridmerge.com; Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations

=20

I read this as a consensus to use tags J If anyone disagree please speak =
up now!

=20

There have been plenty iterations/versions of tagging since Frame Relay =
(pure switching), IBM's HPR (pure source route), Cisco's tag switching =
and MPLS. More often than not, a combination of the 2 models is used so =
that tags can be both swapped and stacked.=20

=20

-          In pure switching, there's only one tag in the packet. A tag =
can be locally significant, in which case it has to be swapped as the =
packet progresses. For RPL, it means that a node uses as many tags as it =
has children that use it has DAO targets in its subdag.

=20

-          In the pure source route model, tags are stacked in an =
ordered list that forms a strict routing header. A tag can be locally =
significant to the interpreter and is consumed (marked or removed) as =
the packet progresses. For RPL, it means that a node uses as many tags =
as it has children that use this node as DAO parent.=20

=20

It also appears that the 2 tagging models map quite well with the DAO =
models we have in RPL since the split that we decided with issue #26. =
The fact that the combination of the 2 models is possible in the real =
world today gives us a hint that we are not closing the door to the =
mixed model in the future.

=20

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by =
the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need =
to dig further)

-          Tag content and size (people have asked for at least 2 octets =
to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of =
addresses? What about the tag swapping  case, RH as well?)

=20

Advice?

=20

=20

=20

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand =
SourceRoutingOperations

=20

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 10:17 PM, Jonathan Hui wrote:=20


Hi Robert,=20

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:=20

A couple of questions:=20
    * I presume the source route header using these tags/labels is an =
IPv6 extension header. What value for extension header type would this =
be? Would we need to specify a LOWPAN_NHC value for this so we can still =
use LOWPAN_NCH for UDP frames?=20


We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented it at 6man in Anaheim.  The option is designed to carry =
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for =
the IPv6 Hop-by-Hop Option header.=20

    * Can you point to where the 'core ideas have been deployed in =
traditional IP networks for quite some time'?=20


MPLS.  Again, I think the mechanisms will need to be adapted, but the =
core ideas are not new.=20

--=20
Jonathan Hui=20

Thanks=20

Robert=20
Robert Cragie (Pacific Gas & Electric)=20

Gridmerge Ltd.=20
89 Greenfield Crescent,=20
Wakefield, WF4 4WA, UK=20
+44 (0) 1924 910888=20
http://www.gridmerge.com=20


On 08/04/2010 3:57 PM, Jonathan Hui wrote:=20



To make the source route header compact, I favor the tag/label approach =
over some other compaction mechanism that operates directly on a list of =
IPv6 addresses.  Tags/labels can be made general enough such that they =
can be derived in different ways.  Because the tags/labels have scope =
local to each node, the mechanism is pretty general already.  For those =
that are already managing unique 802.15.4 short addresses across a =
network, I can see that it is attractive to utilize the short address =
directly and reduce state on devices.  In other cases, it may be best =
for the node to dynamically assign tags/labels for its neighbors.=20

Either way, while the tag/label mechanism is simple, it is far more =
flexible than an approach to compacting a list of IPv6 addresses.  And =
note that the idea of using tags/labels is nothing new.  Of course we =
will adapt the basic mechanism a bit (label distribution, headers =
formats, etc), but the core ideas have been deployed in traditional IP =
networks for quite some time.=20

I reiterated a lot of what was already stated before by others, but that =
is what I think.=20

--=20
Jonathan Hui=20

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:=20

Hi Daniel:=20

Routers might have multiple interfaces of multiple MAC types. Internet 0 =

even has a MAC-less format.=20
So the result of you proposal, which looks like a great idea in a pure=20
802.15.4 world with short addresses, becomes a nightmare to define in a=20
fully generic fashion.=20

OTOH, a locally significant opaque tag in which the parent could hide a=20
short address of the child - if it cares to do it that way - looks like=20
a way more acceptable approach=20

So it seems to me that you can get what you want as long as we can make=20
the tag big enough for short addresses. When the tag is too small to=20
contain what the parent really needs, then the parent will have to store =

a state with the full information in memory, and then place an index of=20
some sort in the tag.=20

What do you think?=20

Pascal=20

-----Original Message-----=20
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]=20
Sent: Thursday, April 08, 2010 11:40 AM=20
To: ROLL WG=20
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)=20
Subject: RE: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi Pascal, John,=20

Since source routing explicitly gives forwarding instruction to each=20
intermediate node, it can make sense to use only (MAC address based)=20

L2=20

forwarding instead of (IPv6 address based) L3 forwarding.=20

This brings two advantages:=20
- avoid processing each transit packets up to L3.=20
- use MAC addresses that - in ROLL environment - have inherently=20

shorter=20

length than an IPv6 address.=20

Cheers,=20
Daniel=20



-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

Pascal Thubert (pthubert)=20
Sent: jeudi 8 avril 2010 11:15=20
To: JeongGil Ko (John); ROLL WG=20
Subject: Re: [Roll] Proposal for Source Routing Header Format and=20
SourceRoutingOperations=20

Hi John:=20

IPv6 already has a number of routing headers, in particular RH0,=20

though it is=20

being deprecated for general use in the Internet.=20
And there are reasons why the fields in RH0/1 are there and we need to=20
make sure we lose none of that. In particular a RH is recoverable, and=20

it is=20

easy to spot the consumed entries.=20

On top of this our new problems are:=20
- make sure the RH stays within the RPL network (since it is used=20

downwards=20

that should be doable)=20
- control the size (that probably means compress)=20

Cheers,=20

Pascal=20

-----Original Message-----=20
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20

Of=20

JeongGil Ko (John)=20
Sent: Wednesday, April 07, 2010 10:05 PM=20
To: ROLL WG=20
Subject: [Roll] Proposal for Source Routing Header Format and Source=20
RoutingOperations=20

Hi!=20

Great to see all this discussions on downwards route establishment!=20

To=20

add=20

one more to the conversations here is a proposal for source routing=20

headers.=20

In non-storing mode (where only the root has individual path=20

information)=20

the root will be attaching a source routing header to the data=20

packet=20

that a=20

source node wants to send to a specific destination. We can always=20

make the=20

header super fancy but in my opinion I think we only need two fields=20

in this=20

header and here it is! Feel free to break the stuff and mangle with=20

it=20

so that it=20

looks great in the specs later on. FYI, this is the format that I am=20

using in my=20

implementations so it does work :)=20

1. Source Routing Header Format=20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|   NEntry (8 bits)   |=20

|=20

+-+-+-+-+-+-+-+-+=20

+=20

|                       Source Route Entry (128*NEntry bits)=20

|=20

+=20

+=20

|=20

|=20


     Figure 1. Proposed Source Routing Header Format; each line is=20

32=20

bits:)=20


- NEntry: Indicates the number of 128 bit addresses that the source=20

route=20

entry field is carrying.=20

- Source Route Entry: List of 128 bit address that consist the route=20

to the=20

destination. Here, the address of the node that is one hop away from=20

the=20

*destination* comes first.=20

2. Source Routing Packet Operations=20

When source routing is initiated at a storing node (e.g., root of=20

the=20

DODAG),=20

the header is attached on the data packet for the entire route=20

(i.e.,=20

from=20

next hop node to the destination). This header is positioned in=20

front=20

of the=20

user payload. When the next hop node receives a packet that is not=20

destined=20

to itself AND the network is NOT provisioned to be in 'storing mode'=20

then it=20

checks NEntry to find what the next hop is in the source route=20

entry.=20

Since=20

the 'Source Route Entry' is ordered in 'farthest -> closest' (in=20

terms=20

of hops)=20

order, a node can figure out what the next hop address is with only=20

the=20

NEntry value (since it already knows how big an ipv6 address is).=20

After=20

collecting the next hop node's address, the node erases this address=20
element from the entry and decreases NEntry by one. This assures=20

that=20

we=20

avoid the overhead of carrying the entire source route throughout=20

the=20

data=20

path.=20

The approach itself should be very simple and trivial for everyone=20

to=20

follow.=20

So we can start from here and build on!=20

Thanks.=20

-John=20

------=20
JeongGil Ko (John)=20
Ph.D. Student=20
Department of Computer Science=20
Johns Hopkins University=20
http://www.cs.jhu.edu/~jgko=20

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

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

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


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

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

=20


------_=_NextPart_001_01CAD7F2.85C66FBF
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













    


    Maybe, but I think the 8-bit simple address will not be =
THE
issue that will stop ratification of the 4e amendment. =

    


     
    


    I assume that a generic labeling approach should not =
close the
door for further developments or existing deployments. =A0So, having =
variable-size
labels (e.g., in steps of octets, but no longer than some M =
octets) can better
adapt to heterogeneous devices, which will have different constraints. =
One may design
shorter labels for some devices and longer labels for some other =
devices. 
    


     
    


    Cheers, 
    


    Daniel 
    


     
    


    


    


    From: Don Sturek =
[mailto:d.sturek@att.net] 
    
Sent: vendredi 9 avril 2010 16:00
    
To: Popa, Daniel; 'Pascal Thubert (pthubert)'
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    4e is a ways away from ratification in IEEE.  I =
would not
assume 8 bit simple addresses quite yet.  Note that these would =
only be
useful in a subset of deployed networks given the extremely small =
address range
they would provide.
    



    
Don
    


     
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: Friday, April 09, 2010 4:10 AM
    
To: Pascal Thubert (pthubert)
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    Pascal, all, 
    


     
    


    The proposed 4e MAC Amendment for 802.15.4 introduces a
“8-bit simple address” in addition to the 16-bit short and =
64-bit
extended addresses, from 802.15.4-2006.
    


    So, we need 2 bits to signal the size (e.g., 8, 16, 32, =
and 64)
of the “Label Value” Field. 
    


     
    


    Below is the link to the proposed amendment draft (refer =
to
rev6). 
    


    https://mentor.ieee.org/802.15/documents?is_dcn=3D604&is_gr=
oup=3D004e
    


     
    


    Thanks.
    


     
    


    Cheers, 
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Popa, Daniel
    
Sent: vendredi 9 avril 2010 11:45
    
To: Pascal Thubert (pthubert)
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations
    


    


    


     
    


    Hi Pascal, 
    


     
    


    I have first set of proposals concerning the tag/label =
size
and content:
    


     
    


    -         
Tag/Label =
size:
    


    o   =
As
802.15.4-2006 defines addressing modes with 16-bit short address and =
64-bit
extended address for Src and Dest Addressing Mode, I think we should =
have the
same flexibility for tag/label addressing mode =3D> tag/label should
potentially accommodate values represented on a field with a length up =
to 64
bits. 
    


    o   =
Currently,
there are ongoing activities to amend MAC Layer for 802.15.4-2006 (TG =
4e) that
might alter the aforementioned values for MAC address size. I will try =
have
some further information about MAC Addr Length issue and be back on the =
mailing
list asap.   
    


     
    


    -         
Tag/Label =
contents:
    


     
    


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

    


    | Control fields | Label Value | =

    


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

    


     
    


    o   =
Control
fields
    


    =A7  =
2
bits to signal labeling/tagging mode:  short/extended labels =
 =3D>
the bit-length of the “Label Value (LV)” =
 field 
    


    =B7        
2 bits =3D> 4 modes for LV length : 8, 16, 32 and =
64 bits. 
    


    =A7  =
Eventually,
few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 priority field =
into
label priority).
    


    =A7  =
Eventually,
1 bit for bottom of the stack flag - for source routing;  if =
set to
1 =3D> the current label/tag is last in the =
stack.
    


    =A7  =
1
or 2 bits RFU.
    


    =A7  =
Eventually,
some bits for hop counts (?).
    


    o   =
Label
Value (LV) field
    


    =A7  =
The
value of the label/tag
    


     
    


     
    


    Thanks.
    


     
    


    Cheers,
    


    Daniel 
    


     
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert =
(pthubert)
    
Sent: vendredi 9 avril 2010 10:36
    
To: robert.cragie@gridmerge.com; Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations
    


    


    


     
    


    I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


     
    


    There have been plenty iterations/versions of tagging =
since
Frame Relay (pure switching), IBM’s HPR (pure source route),
Cisco’s tag switching and MPLS. More often than not, a combination =
of the
2 models is used so that tags can be both swapped and stacked. =

    


     
    


    -         
In pure switching, there’s only one tag in the =
packet. A
tag can be locally significant, in which case it has to be swapped as =
the
packet progresses. For RPL, it means that a node uses as many tags as it =
has
children that use it has DAO targets in its =
subdag.
    


     
    


    -         
In the pure source route model, tags are stacked in an =
ordered
list that forms a strict routing header. A tag can be locally =
significant to the
interpreter and is consumed (marked or removed) as the packet =
progresses. For
RPL, it means that a node uses as many tags as it has children that use =
this
node as DAO parent. 
    


     
    


    It also appears that the 2 tagging models map quite well =
with the
DAO models we have in RPL since the split that we decided with issue =
#26. The
fact that the combination of the 2 models is possible in the real world =
today
gives us a hint that we are not closing the door to the mixed model in =
the
future.
    


     
    


    The next step I wish to agree upon:
    


    -         
Use locally significant tags which implies tag assignment =
by the
node that uses it later and tag swapping for the stateful =
case.
    


    -         
Tag distribution in DAO (there are options there that we =
need to
dig further)
    


    -         
Tag content and size (people have asked for at least 2 =
octets to
fit 15.4 short addresses, do we need some control field as =
well?)
    


    -         
RH format (inherit RH0 fields with labels instead of =
addresses?
What about the tag swapping  case, RH as =
well?)
    


     
    


    Advice?
    


     
    


     
    


     
    


     
    


    


    Pascal
    


    


     
    


    


    


    


    From: =
roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


     
    


    OK, sounds good. End of topic as far as I am =
concerned. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    


    A couple of questions: 
    
    • I presume the source route header using =
these
tags/labels is an IPv6 extension header. What value for extension header =
type
would this be? Would we need to specify a LOWPAN_NHC value for this so =
we can
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and =
presented
it at 6man in Anaheim.  The option is designed to carry =
RPL-specific
information.  6lowpan-hc already has a LOWPAN_NHC value for the =
IPv6
Hop-by-Hop Option header. 
    


        • Can you point to =
where the
'core ideas have been deployed in traditional IP networks for quite some =
time'?

    



    
MPLS.  Again, I think the mechanisms will need to be adapted, but =
the core
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach =
over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they =
can be
derived in different ways.  Because the tags/labels have scope =
local to
each node, the mechanism is pretty general already.  For those that =
are
already managing unique 802.15.4 short addresses across a network, I can =
see
that it is attractive to utilize the short address directly and reduce =
state on
devices.  In other cases, it may be best for the node to =
dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more =
flexible
than an approach to compacting a list of IPv6 addresses.  And note =
that
the idea of using tags/labels is nothing new.  Of course we will =
adapt the
basic mechanism a bit (label distribution, headers formats, etc), but =
the core ideas
have been deployed in traditional IP networks for quite some time. 
    

    
I reiterated a lot of what was already stated before by others, but that =
is
what I think. 
    

    
-- 
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: =

    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 =

    
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure =

    
802.15.4 world with short addresses, becomes a nightmare to define in a =

    
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a =

    
short address of the child - if it cares to do it that way - looks like =

    
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make =

    
the tag big enough for short addresses. When the tag is too small to =

    
contain what the parent really needs, then the parent will have to store =

    
a state with the full information in memory, and then place an index of =

    
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each =

    
intermediate node, it can make sense to use only (MAC address based) =

    


    L2 
    


    forwarding instead of (IPv6 address based) L3 =
forwarding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently =

    


    shorter =

    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, =

    


    though it is =

    


    being deprecated for general use in the Internet. =

    
And there are reasons why the fields in RH0/1 are there and we need to =

    
make sure we lose none of that. In particular a RH is recoverable, and =

    


    it is =

    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used =

    


    downwards =

    


    that should be =
doable) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    


    -----Original Message----- 
    
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] =
On Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source =

    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! =

    


    To 
    


    add 
    


    one more to the conversations here is a proposal =
for source
routing 
    


    headers. =

    


    In non-storing mode (where only the root has =
individual path

    


    information) =

    


    the root will be attaching a source routing header =
to the
data 
    


    packet =

    


    that a =

    


    source node wants to send to a specific =
destination. We can
always 
    


    make the =

    


    header super fancy but in my opinion I think we =
only need
two fields 
    


    in this =

    


    header and here it is! Feel free to break the stuff =
and
mangle with 
    


    it 
    


    so that it =

    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my =

    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|   NEntry (8 bits)   | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |         =
            &=
nbsp;
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
     Figure 1. Proposed Source Routing Header =
Format; each
line is 
    


    32 
    


    bits:) =

    



    
- NEntry: Indicates the number of 128 bit addresses that the source =

    


    route =

    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route =

    


    to the =

    


    destination. Here, the address of the node that is =
one hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of =

    


    the 
    


    DODAG), =

    


    the header is attached on the data packet for the =
entire
route 
    


    (i.e., =

    


    from 
    


    next hop node to the destination). This header is =
positioned
in 
    


    front =

    


    of the =

    


    user payload. When the next hop node receives a =
packet that
is not 
    


    destined =

    


    to itself AND the network is NOT provisioned to be =
in
'storing mode' 
    


    then it =

    


    checks NEntry to find what the next hop is in the =
source
route 
    


    entry. =

    


    Since =

    


    the 'Source Route Entry' is ordered in 'farthest =
->
closest' (in 
    


    terms =

    


    of hops) =

    


    order, a node can figure out what the next hop =
address is
with only 
    


    the 
    


    NEntry value (since it already knows how big an =
ipv6 address
is). 
    


    After =

    


    collecting the next hop node's address, the node =
erases this
address 
    
element from the entry and decreases NEntry by one. This assures =

    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source =
route
throughout 
    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone =

    


    to 
    


    follow. =

    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko =

    

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

    


    _______________________________________________ =

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

    


    _______________________________________________ =

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

    



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

    


    _______________________________________________ =

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

    


     
    


    


    





------_=_NextPart_001_01CAD7F2.85C66FBF--

From jhui@archrock.com  Fri Apr  9 07:42:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D93E3A68F0 for ; Fri,  9 Apr 2010 07:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level: 
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBCiv-krsm4g for ; Fri,  9 Apr 2010 07:42:53 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A51EA3A6939 for ; Fri,  9 Apr 2010 07:41:49 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 57F57AF81E; Fri,  9 Apr 2010 07:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQfbjo25CGdi; Fri,  9 Apr 2010 07:41:41 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id A8BF3AF991; Fri,  9 Apr 2010 07:41:41 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: Anders Brandt 
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Apr 2010 07:41:40 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>
X-Mailer: Apple Mail (2.936)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 14:42:54 -0000

Hi Anders,

On Apr 9, 2010, at 1:42 AM, Anders Brandt wrote:

> In a non-storing mode, I see no way of storing and/or swapping  
> labels/tags in each node.
> For this kind of nodes we need a complete routing stack in the  
> frame. As mentioned earlier, I am perfectly
> fine with limitations such as max n entries; Compression of  
> addresses to 16 bits and a common subnet.

The issues of tags vs. storing/non-storing are orthogonal.

For non-storing mode, the use of tags does not require any storage  
within the RPL network as long as you can map some locally unique  
identifier to the tag namespace.  For example, assuming a 16-bit tag,  
it is natural to simply use the 802.15.4 short address since those  
must be at least locally unique and in many cases are unique within  
the entire network.  Source routing then becomes source routing on  
tags rather than on IPv6 addresses.  For storing mode, nodes can  
continue to maintain tags for each destination in their sub-DAG.

The difference is that in both cases, nodes route on tags rather than  
IPv6 addresses.  Tags are smaller than IPv6 addresses, so that means  
smaller source route headers for non-storing mode and smaller routing  
tables for storing mode.  Another nice feature with tags is that you  
can maintain multiple tags for the same destination and using tags to  
perform traffic engineering is the primary reason why tags/labels are  
used in IP networks today.

--
Jonathan Hui


From jhui@archrock.com  Fri Apr  9 08:00:31 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7353A6923 for ; Fri,  9 Apr 2010 08:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-fJ9pZPjbHl for ; Fri,  9 Apr 2010 08:00:29 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 746243A67A7 for ; Fri,  9 Apr 2010 08:00:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DCD27AF947; Fri,  9 Apr 2010 08:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAgPCg9ipzYs; Fri,  9 Apr 2010 08:00:22 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id A21E6AF81E; Fri,  9 Apr 2010 08:00:21 -0700 (PDT)
Message-Id: <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
From: Jonathan Hui 
To: "Popa, Daniel" 
In-Reply-To: 
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Apr 2010 08:00:21 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com> 
X-Mailer: Apple Mail (2.936)
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 15:00:31 -0000

Hi Daniel,

Some comments:

- I'm not in favor of having variable sized tags.  It complicates =20
processing and state maintenance.  It makes dealing with RH0-style =20
headers difficult because it causes you to move large portions of the =20=

header around when you simply need to perform a label swap.  We should =20=

pick a fixed size that is reasonable (e.g. 16-bits).  Anything too =20
large diminishes a primary reason for having tags - a compact =20
identifier for the next hop.

- For a source routing header, I'd much rather see something derived =20
from the RH0 format.

- For different levels of service, the nice thing with tags is that =20
the tag itself can identify not only a destination but also how to get =20=

there (path, service level, etc.).  That is the primary reason why =20
labels are used in traditional IP networks today.  Of course, it means =20=

that you will have to maintain multiple tags for the same =20
destination.  And if you're directly mapping the full 802.15.4 short =20
address space into the tag space, then you have to be more careful =20
about managing the mapping (e.g. make sure short addresses can be =20
encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not =20
enough for what you want to do.  In the end, I'm not sure we want to =20
explicitly reserve bits for indicating a service level rather than =20
simply keeping a flat tag namespace.  The use case should define what =20=

to do with the bits.

--
Jonathan Hui

On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:

> Hi Pascal,
>
> I have first set of proposals concerning the tag/label size and =20
> content:
>
> -          Tag/Label size:
> o   As 802.15.4-2006 defines addressing modes with 16-bit short =20
> address and 64-bit extended address for Src and Dest Addressing =20
> Mode, I think we should have the same flexibility for tag/label =20
> addressing mode =3D> tag/label should potentially accommodate values =20=

> represented on a field with a length up to 64 bits.
> o   Currently, there are ongoing activities to amend MAC Layer for =20
> 802.15.4-2006 (TG 4e) that might alter the aforementioned values for =20=

> MAC address size. I will try have some further information about MAC =20=

> Addr Length issue and be back on the mailing list asap.
>
> -          Tag/Label contents:
>
> -------------------------------------
> | Control fields | Label Value |
> -------------------------------------
>
> o   Control fields
> =A7  2 bits to signal labeling/tagging mode:  short/extended labels  =20=

> =3D> the bit-length of the =93Label Value (LV)=94  field
> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.
> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map =20=

> IPv6 priority field into label priority).
> =A7  Eventually, 1 bit for bottom of the stack flag - for source =20
> routing;  if set to 1 =3D> the current label/tag is last in the stack.
> =A7  1 or 2 bits RFU.
> =A7  Eventually, some bits for hop counts (?).
> o   Label Value (LV) field
> =A7  The value of the label/tag
>
>
> Thanks.
>
> Cheers,
> Daniel
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of Pascal Thubert (pthubert)
> Sent: vendredi 9 avril 2010 10:36
> To: robert.cragie@gridmerge.com; Jonathan Hui
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =20
> SourceRoutingOperations
>
> I read this as a consensus to use tags J If anyone disagree please =20
> speak up now!
>
> There have been plenty iterations/versions of tagging since Frame =20
> Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s tag =
=20
> switching and MPLS. More often than not, a combination of the 2 =20
> models is used so that tags can be both swapped and stacked.
>
> -          In pure switching, there=92s only one tag in the packet. A =20=

> tag can be locally significant, in which case it has to be swapped =20
> as the packet progresses. For RPL, it means that a node uses as many =20=

> tags as it has children that use it has DAO targets in its subdag.
>
> -          In the pure source route model, tags are stacked in an =20
> ordered list that forms a strict routing header. A tag can be =20
> locally significant to the interpreter and is consumed (marked or =20
> removed) as the packet progresses. For RPL, it means that a node =20
> uses as many tags as it has children that use this node as DAO parent.
>
> It also appears that the 2 tagging models map quite well with the =20
> DAO models we have in RPL since the split that we decided with issue =20=

> #26. The fact that the combination of the 2 models is possible in =20
> the real world today gives us a hint that we are not closing the =20
> door to the mixed model in the future.
>
> The next step I wish to agree upon:
> -          Use locally significant tags which implies tag assignment =20=

> by the node that uses it later and tag swapping for the stateful case.
> -          Tag distribution in DAO (there are options there that we =20=

> need to dig further)
> -          Tag content and size (people have asked for at least 2 =20
> octets to fit 15.4 short addresses, do we need some control field as =20=

> well?)
> -          RH format (inherit RH0 fields with labels instead of =20
> addresses? What about the tag swapping  case, RH as well?)
>
> Advice?
>
>
>
>
> Pascal
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of Robert Cragie
> Sent: Thursday, April 08, 2010 11:34 PM
> To: Jonathan Hui
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Formatand =20
> SourceRoutingOperations
>
> OK, sounds good. End of topic as far as I am concerned. +1
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>
> Hi Robert,
>
> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>
>
> A couple of questions:
>     =95 I presume the source route header using these tags/labels is =20=

> an IPv6 extension header. What value for extension header type would =20=

> this be? Would we need to specify a LOWPAN_NHC value for this so we =20=

> can still use LOWPAN_NCH for UDP frames?
>
> We already have a draft requesting a new IPv6 Hop-by-Hop Option and =20=

> presented it at 6man in Anaheim.  The option is designed to carry =20
> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value =20=

> for the IPv6 Hop-by-Hop Option header.
>
>
>     =95 Can you point to where the 'core ideas have been deployed in =20=

> traditional IP networks for quite some time'?
>
> MPLS.  Again, I think the mechanisms will need to be adapted, but =20
> the core ideas are not new.
>
> --=20
> Jonathan Hui
>
>
> Thanks
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>
>
>
> To make the source route header compact, I favor the tag/label =20
> approach over some other compaction mechanism that operates directly =20=

> on a list of IPv6 addresses.  Tags/labels can be made general enough =20=

> such that they can be derived in different ways.  Because the tags/=20
> labels have scope local to each node, the mechanism is pretty =20
> general already.  For those that are already managing unique =20
> 802.15.4 short addresses across a network, I can see that it is =20
> attractive to utilize the short address directly and reduce state on =20=

> devices.  In other cases, it may be best for the node to dynamically =20=

> assign tags/labels for its neighbors.
>
> Either way, while the tag/label mechanism is simple, it is far more =20=

> flexible than an approach to compacting a list of IPv6 addresses.  =20
> And note that the idea of using tags/labels is nothing new.  Of =20
> course we will adapt the basic mechanism a bit (label distribution, =20=

> headers formats, etc), but the core ideas have been deployed in =20
> traditional IP networks for quite some time.
>
> I reiterated a lot of what was already stated before by others, but =20=

> that is what I think.
>
> --=20
> Jonathan Hui
>
> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>
>
> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types. =20
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define =20
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could =20
> hide a
> short address of the child - if it cares to do it that way - looks =20
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can =20
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to =20
> store
> a state with the full information in memory, and then place an index =20=

> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>
> -----Original Message-----
> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
> Sent: Thursday, April 08, 2010 11:40 AM
> To: ROLL WG
> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi Pascal, John,
>
> Since source routing explicitly gives forwarding instruction to each
> intermediate node, it can make sense to use only (MAC address based)
> L2
>
> forwarding instead of (IPv6 address based) L3 forwarding.
>
> This brings two advantages:
> - avoid processing each transit packets up to L3.
> - use MAC addresses that - in ROLL environment - have inherently
> shorter
>
> length than an IPv6 address.
>
> Cheers,
> Daniel
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>
> Pascal Thubert (pthubert)
> Sent: jeudi 8 avril 2010 11:15
> To: JeongGil Ko (John); ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi John:
>
> IPv6 already has a number of routing headers, in particular RH0,
> though it is
>
> being deprecated for general use in the Internet.
> And there are reasons why the fields in RH0/1 are there and we need to
> make sure we lose none of that. In particular a RH is recoverable, and
> it is
>
> easy to spot the consumed entries.
>
> On top of this our new problems are:
> - make sure the RH stays within the RPL network (since it is used
> downwards
>
> that should be doable)
> - control the size (that probably means compress)
>
> Cheers,
>
> Pascal
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>
> Hi!
>
> Great to see all this discussions on downwards route establishment!
> To
>
> add
>
> one more to the conversations here is a proposal for source routing
> headers.
>
> In non-storing mode (where only the root has individual path
> information)
>
> the root will be attaching a source routing header to the data
> packet
>
> that a
>
> source node wants to send to a specific destination. We can always
> make the
>
> header super fancy but in my opinion I think we only need two fields
> in this
>
> header and here it is! Feel free to break the stuff and mangle with
> it
>
> so that it
>
> looks great in the specs later on. FYI, this is the format that I am
> using in my
>
> implementations so it does work :)
>
> 1. Source Routing Header Format
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
> |
>
> +-+-+-+-+-+-+-+-+
> +
>
> |                       Source Route Entry (128*NEntry bits)
> |
>
> +
> +
>
> |
> |
>
>
>      Figure 1. Proposed Source Routing Header Format; each line is
> 32
>
> bits:)
>
>
> - NEntry: Indicates the number of 128 bit addresses that the source
> route
>
> entry field is carrying.
>
> - Source Route Entry: List of 128 bit address that consist the route
> to the
>
> destination. Here, the address of the node that is one hop away from
> the
>
> *destination* comes first.
>
> 2. Source Routing Packet Operations
>
> When source routing is initiated at a storing node (e.g., root of
> the
>
> DODAG),
>
> the header is attached on the data packet for the entire route
> (i.e.,
>
> from
>
> next hop node to the destination). This header is positioned in
> front
>
> of the
>
> user payload. When the next hop node receives a packet that is not
> destined
>
> to itself AND the network is NOT provisioned to be in 'storing mode'
> then it
>
> checks NEntry to find what the next hop is in the source route
> entry.
>
> Since
>
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> terms
>
> of hops)
>
> order, a node can figure out what the next hop address is with only
> the
>
> NEntry value (since it already knows how big an ipv6 address is).
> After
>
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures
> that
>
> we
>
> avoid the overhead of carrying the entire source route throughout
> the
>
> data
>
> path.
>
> The approach itself should be very simple and trivial for everyone
> to
>
> follow.
>
> So we can start from here and build on!
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>


From yoav@yitran.com  Fri Apr  9 08:00:36 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEAE3A67A7 for ; Fri,  9 Apr 2010 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.989
X-Spam-Level: 
X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.609,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ki9sC1VTUF8 for ; Fri,  9 Apr 2010 08:00:32 -0700 (PDT)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id 3D34F3A6920 for ; Fri,  9 Apr 2010 08:00:31 -0700 (PDT)
Received: from source ([209.85.220.222]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKS79BC8qr3OGP6UXsILPHyr0GugdkcpSH@postini.com; Fri, 09 Apr 2010 08:00:28 PDT
Received: by mail-fx0-f222.google.com with SMTP id 22so2830748fxm.34 for ; Fri, 09 Apr 2010 08:00:27 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 	 <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>	 <6D9687E95918C04A8B30A7D6DA805A3E0142A011@zensys17.zensys.local>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD78D@XMB-AMS-107.cisco.com>  <6D9687E95918C04A8B30A7D6DA805A3E0142A013@zensys17.zensys.local>  <015301cad7cd$d3046ab0$790d4010$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A014@zensys17.zensys.local>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A014@zensys17.zensys.local>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrXY1+HAcb0Wv7nT/W0KnhPVarJfAAVImWQAAH+OQAAAGJtUAACdZkgAAB8m5AAAHy3kAAJhbvw
Date: Fri, 9 Apr 2010 18:00:26 +0300
Received: by 10.239.183.145 with SMTP id u17mr16011hbg.145.1270825226821; Fri,  09 Apr 2010 08:00:26 -0700 (PDT)
Message-ID: <018001cad7f5$63837780$2a8a6680$@com>
To: Anders Brandt , "Pascal Thubert (pthubert)" , robert.cragie@gridmerge.com, Jonathan Hui 
Content-Type: multipart/alternative; boundary=001485f5cef63761360483cf0e74
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 15:00:36 -0000

--001485f5cef63761360483cf0e74
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I agree freshness counters are problematic (sorry - I thought the question
was about worst case scenario).



Regards,

Yoav





*From:* Anders Brandt [mailto:abr@sdesigns.dk]
*Sent:* Friday, April 09, 2010 1:32 PM
*To:* Yoav Ben-Yehezkel; Pascal Thubert (pthubert);
robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations



Yoav,



>So that=92s two network keys and a set of freshness counters (per priority
per key).



The two network keys may make sense but freshness counters are problematic =
-
in home control at least.

Some targets may be controlled by a high number of controllers. Counters
would require targets to hold many
instances. Since many controllers may be battery operated it is not an
option to keep the counters synchronized.

Challenge-response is also replay-proof and it requires no additional state
in nodes - except for a temporary nonce.



Cheers,

  Anders




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

*From:* Yoav Ben-Yehezkel [mailto:yoav@yitran.com]
*Sent:* Friday, April 09, 2010 12:17
*To:* Anders Brandt; Pascal Thubert (pthubert); robert.cragie@gridmerge.com=
;
Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Small comments on that=85

To be able to re-distribute (update) keys, it is sometimes customary to
maintain two network keys.

One key for regular communication and one in case a node for some reason
didn=92t receive the new network key (for example, wasn=92t online).

Another thing is the freshness counters vs. replay attacks=85

For MAC priorities =96 it is best to maintain freshness counters per priori=
ty
(since packets may replace order of transmissions).

So that=92s two network keys and a set of freshness counters (per priority =
per
key).



Thanks,

Yoav





*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Anders
Brandt
*Sent:* Friday, April 09, 2010 1:04 PM
*To:* Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations



Pascal,



>One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?



Typically a network key is shared among all nodes. A few nodes (e.g.
electronic door locks with extra high security requirements) may have
dedicated link keys.
The link keys work end-to-end and do not require storage in all other nodes=
.
Thus, the most simple nodes need only storage for a network key.



- Anders


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

*From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
*Sent:* Friday, April 09, 2010 10:52
*To:* Anders Brandt; robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Hi Anders:



You did not miss much. But maybe the fact that the tag could be stateless a=
s
long as the node knows how to do that.

For instance a short address could be encoded in there, as long as this is
opaque to the rest of the L3 network.

One question though. In your case, do you / can you maintain any informatio=
n
about neighbors? Like security ?



Pascal



*From:* Anders Brandt [mailto:abr@sdesigns.dk]
*Sent:* Friday, April 09, 2010 10:43 AM
*To:* Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations



Admitted, I have been absent from this thread; trying to catch up on
others...



> I read this as a consensus to use tags J If anyone disagree please speak
up now!

I have to comment respectfully but loudly that this may at best some sort o=
f
rough concensus..



In a non-storing mode, I see no way of storing and/or swapping labels/tags
in each node.

For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to 16
bits and a common subnet.



Just my $0.05






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

*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Pascal
Thubert (pthubert)
*Sent:* Friday, April 09, 2010 10:36
*To:* robert.cragie@gridmerge.com; Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

I read this as a consensus to use tags J If anyone disagree please speak up
now!



There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM=92s HPR (pure source route), Cisco=92s tag switching =
and
MPLS. More often than not, a combination of the 2 models is used so that
tags can be both swapped and stacked.



-          In pure switching, there=92s only one tag in the packet. A tag c=
an
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use it has DAO targets in its subdag.



-          In the pure source route model, tags are stacked in an ordered
list that forms a strict routing header. A tag can be locally significant t=
o
the interpreter and is consumed (marked or removed) as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use this node as DAO parent.



It also appears that the 2 tagging models map quite well with the DAO model=
s
we have in RPL since the split that we decided with issue #26. The fact tha=
t
the combination of the 2 models is possible in the real world today gives u=
s
a hint that we are not closing the door to the mixed model in the future.



The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by the
node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need to
dig further)

-          Tag content and size (people have asked for at least 2 octets to
fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of addresses?
What about the tag swapping  case, RH as well?)



Advice?



Pascal



*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Robert
Cragie
*Sent:* Thursday, April 08, 2010 11:34 PM
*To:* Jonathan Hui
*Cc:* roll@ietf.org
*Subject:* Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations



OK, sounds good. End of topic as far as I am concerned. +1

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 08/04/2010 10:17 PM, Jonathan Hui wrote:


Hi Robert,

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:

A couple of questions:
    =95 I presume the source route header using these tags/labels is an IPv=
6
extension header. What value for extension header type would this be? Would
we need to specify a LOWPAN_NHC value for this so we can still use
LOWPAN_NCH for UDP frames?


We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for th=
e
IPv6 Hop-by-Hop Option header.

    =95 Can you point to where the 'core ideas have been deployed in
traditional IP networks for quite some time'?


MPLS.  Again, I think the mechanisms will need to be adapted, but the core
ideas are not new.

--=20
Jonathan Hui

Thanks

Robert
Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 08/04/2010 3:57 PM, Jonathan Hui wrote:



To make the source route header compact, I favor the tag/label approach ove=
r
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they can be
derived in different ways.  Because the tags/labels have scope local to eac=
h
node, the mechanism is pretty general already.  For those that are already
managing unique 802.15.4 short addresses across a network, I can see that i=
t
is attractive to utilize the short address directly and reduce state on
devices.  In other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more flexibl=
e
than an approach to compacting a list of IPv6 addresses.  And note that the
idea of using tags/labels is nothing new.  Of course we will adapt the basi=
c
mechanism a bit (label distribution, headers formats, etc), but the core
ideas have been deployed in traditional IP networks for quite some time.

I reiterated a lot of what was already stated before by others, but that is
what I think.

--=20
Jonathan Hui

On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:

Hi Daniel:

Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.

OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach

So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.

What do you think?

Pascal

-----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com ]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)

L2

forwarding instead of (IPv6 address based) L3 forwarding.

This brings two advantages:
- avoid processing each transit packets up to L3.
- use MAC addresses that - in ROLL environment - have inherently

shorter

length than an IPv6 address.

Cheers,
Daniel



-----Original Message-----
From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]
On Behalf

Of

Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

IPv6 already has a number of routing headers, in particular RH0,

though it is

being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and

it is

easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used

downwards

that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal

-----Original Message-----
From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]
On Behalf

Of

JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

Great to see all this discussions on downwards route establishment!

To

add

one more to the conversations here is a proposal for source routing

headers.

In non-storing mode (where only the root has individual path

information)

the root will be attaching a source routing header to the data

packet

that a

source node wants to send to a specific destination. We can always

make the

header super fancy but in my opinion I think we only need two fields

in this

header and here it is! Feel free to break the stuff and mangle with

it

so that it

looks great in the specs later on. FYI, this is the format that I am

using in my

implementations so it does work :)

1. Source Routing Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |

|

+-+-+-+-+-+-+-+-+

+

|                       Source Route Entry (128*NEntry bits)

|

+

+

|

|


     Figure 1. Proposed Source Routing Header Format; each line is

32

bits:)


- NEntry: Indicates the number of 128 bit addresses that the source

route

entry field is carrying.

- Source Route Entry: List of 128 bit address that consist the route

to the

destination. Here, the address of the node that is one hop away from

the

*destination* comes first.

2. Source Routing Packet Operations

When source routing is initiated at a storing node (e.g., root of

the

DODAG),

the header is attached on the data packet for the entire route

(i.e.,

from

next hop node to the destination). This header is positioned in

front

of the

user payload. When the next hop node receives a packet that is not

destined

to itself AND the network is NOT provisioned to be in 'storing mode'

then it

checks NEntry to find what the next hop is in the source route

entry.

Since

the 'Source Route Entry' is ordered in 'farthest -> closest' (in

terms

of hops)

order, a node can figure out what the next hop address is with only

the

NEntry value (since it already knows how big an ipv6 address is).

After

collecting the next hop node's address, the node erases this address
element from the entry and decreases NEntry by one. This assures

that

we

avoid the overhead of carrying the entire source route throughout

the

data

path.

The approach itself should be very simple and trivial for everyone

to

follow.

So we can start from here and build on!

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

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

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

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


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

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

--001485f5cef63761360483cf0e74
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable














    


    I agree freshness counters are problematic (sorry - I though=
t
the question was about worst case scenario).
    


    =A0
    


    Regards,
    


    Yoav
    


    =A0
    


    =A0
    


    


    


    From: Anders Brandt =
[mailto:abr@sdesigns.dk]

    
Sent: Friday, April 09, 2010 1:32 PM
    
To: Yoav Ben-Yehezkel; Pascal Thubert (pthubert);
robert.cragie@gridmerge.com<=
/a>; Jonathan Hui
    
Cc:     roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


    =A0
    


    Yoav,
    


    =A0
    


    >So that=92s two network keys and a set of freshness coun=
ters
(per priority per key).
    


    =A0
    


    The two network keys may make sense but freshness counters are
problematic - in home control at least.
    


    Some targets may be controlled by a high number of controllers.
Counters would require targets to hold many
    
instances. Since many controllers may be battery operated it is not an opti=
on
to keep the counters synchronized.    <=
/span>
    


    Challenge-response is also replay-proof and it requires no
additional state in nodes - except for a temporary nonce.
    


    =A0
    


    Cheers,
    


    =A0 Anders
    


    =A0
    


    


    =A0
    


    


    


    


    Fro=
m:
Yoav Ben-Yehezkel [mailto:yoav@yitran.co=
m] 
    
Sent: Friday, April 09, 2010 12:17
    
To: Anders Brandt; Pascal Thubert (pthubert);
robert.cragie@gridmerge.com<=
/a>; Jonathan Hui
    
Cc:     roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    Small comments on that=85
    


    To be able to re-distribute (update) keys, it is sometimes
customary to maintain two network keys.
    


    One key for regular communication and one in case a node for
some reason didn=92t receive the new network key (for example, wasn=92t onl=
ine).
    


    Another thing is the freshness counters vs. replay attacks=
=85
    


    For MAC priorities =96 it is best to maintain freshness coun=
ters
per priority (since packets may replace order of transmissions).
    


    So that=92s two network keys and a set of freshness counters=
 (per
priority per key).
    


    =A0
    


    Thanks,
    


    Yoav
    


    =A0
    


    =A0
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]=
 On
Behalf Of Anders Brandt
    
Sent: Friday, April 09, 2010 1:04 PM
    
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com;
Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


    =A0
    


    Pascal,
    


    =A0
    


    >One question though. In your case, do you / can you main=
tain
any information about neighbors? Like security ?
    


    


    =A0
    


    


    Typically a network key is shared among all nodes. A few nodes
(e.g. electronic door locks with extra high security requirements) may have
dedicated link keys.
    
The link keys work end-to-end and do not require storage in all other nodes=
.
    
Thus, the most simple nodes need only storage for a network key.
    


    =A0
    


    - Anders
    


    


    =A0
    


    


    


    


    Fro=
m:
Pascal Thubert (pthubert) [mailto:pth=
ubert@cisco.com]

    
Sent: Friday, April 09, 2010 10:52
    
To: Anders Brandt; ro=
bert.cragie@gridmerge.com;
Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    Hi Anders:
    


    =A0
    


    You did not miss much. But maybe the fact that the tag could=
 be
stateless as long as the node knows how to do that. 
    


    For instance a short address could be encoded in there, as l=
ong
as this is opaque to the rest of the L3 network.
    


    One question though. In your case, do you / can you maintain=
 any
information about neighbors? Like security ?
    


    =A0
    


    


    Pascal
    


    


    =A0
    


    


    


    


    From: An=
ders Brandt [mailto:abr@sdesigns.dk]=
 
    
Sent: Friday, April 09, 2010 10:43 AM
    
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com;
Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    


    


    =A0
    


    Admitted, I have been absent from this thread; trying to catch =
up
on others...
    


    =A0
    


    > I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


    I have to comment respectfully but loudly that this may at best
some sort of rough concensus..
    


    =A0
    


    In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.
    


    For this kind of nodes we need a complete routing stack in the
frame. As mentioned earlier, I am perfectly
    
fine with limitations such as max n entries; Compression of addresses to 16
bits and a common subnet.
    


    =A0
    


    Just my $0.05
    


    =A0
    


    =A0
    


    


    =A0
    


    


    


    


    Fro=
m: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal
Thubert (pthubert)
    
Sent: Friday, April 09, 2010 10:36
    
To: robert.cragie@gri=
dmerge.com;
Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    


    I read this as a consensus to use tags J If
anyone disagree please speak up now!
    


    =A0
    


    There have been plenty iterations/versions of tagging since
Frame Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s ta=
g
switching and MPLS. More often than not, a combination of the 2 models is u=
sed
so that tags can be both swapped and stacked. 
    


    =A0
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
In pure switching, there=92s only one tag in the packet. A t=
ag can
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has child=
ren
that use it has DAO targets in its subdag.
    


    =A0
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
In the pure source route model, tags are stacked in an order=
ed
list that forms a strict routing header. A tag can be locally significant t=
o
the interpreter and is consumed (marked or removed) as the packet progresse=
s.
For RPL, it means that a node uses as many tags as it has children that use
this node as DAO parent. 
    


    =A0
    


    It also appears that the 2 tagging models map quite well wit=
h
the DAO models we have in RPL since the split that we decided with issue #2=
6.
The fact that the combination of the 2 models is possible in the real world
today gives us a hint that we are not closing the door to the mixed model i=
n
the future.
    


    =A0
    


    The next step I wish to agree upon:
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Use locally significant tags which implies tag assignment by=
 the
node that uses it later and tag swapping for the stateful case.
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Tag distribution in DAO (there are options there that we nee=
d to
dig further)
    


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
Tag content and size (people have asked for at least 2 octet=
s to
fit 15.4 short addresses, do we need some control field as well?)


    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0
RH format (inherit RH0 fields with labels instead of address=
es?
What about the tag swapping=A0 case, RH as well?)
    


    =A0
    


    Advice?
    


    =A0
    


    


    Pascal
    


    


    =A0
    


    


    


    


    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Beh=
alf Of Robert
Cragie
    
Sent: Thursday, April 08, 2010 11:34 PM
    
To: Jonathan Hui
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    


    


    


    =A0
    


    OK, sounds good. End of topic as far as I am concern=
ed. +1
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 08/04/2010 10:17 PM, Jonathan Hui wrote: 
    



    
Hi Robert, 
    

    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote: 
    


    A couple of questions: 
    
=A0=A0=A0=A0=95 I presume the source route header using these
tags/labels is an IPv6 extension header. What value for extension header ty=
pe
would this be? Would we need to specify a LOWPAN_NHC value for this so we c=
an
still use LOWPAN_NCH for UDP frames? 
    



    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and present=
ed
it at 6man in Anaheim.=A0 The option is designed to carry RPL-specific
information.=A0 6lowpan-hc already has a LOWPAN_NHC value for the IPv6
Hop-by-Hop Option header. 
    


    =A0=A0=A0=A0=95 Can you point to where the 'core
ideas have been deployed in traditional IP networks for quite some time'=
;? 
    



    
MPLS.=A0 Again, I think the mechanisms will need to be adapted, but the cor=
e
ideas are not new. 
    

    
-- 
    
Jonathan Hui 
    


    Thanks 
    

    
Robert 
    
Robert Cragie (Pacific Gas & Electric) 
    

    
Gridmerge Ltd. 
    
89 Greenfield Crescent, 
    
Wakefield, WF4 4WA, UK 
    
+44 (0) 1924 910888 
    
http://www.gridmerge.com 
    

    

    
On 08/04/2010 3:57 PM, Jonathan Hui wrote: 
    



    

    
To make the source route header compact, I favor the tag/label approach ove=
r
some other compaction mechanism that operates directly on a list of IPv6
addresses.=A0 Tags/labels can be made general enough such that they can be
derived in different ways.=A0 Because the tags/labels have scope local to
each node, the mechanism is pretty general already.=A0 For those that are
already managing unique 802.15.4 short addresses across a network, I can se=
e
that it is attractive to utilize the short address directly and reduce stat=
e on
devices.=A0 In other cases, it may be best for the node to dynamically
assign tags/labels for its neighbors. 
    

    
Either way, while the tag/label mechanism is simple, it is far more flexibl=
e
than an approach to compacting a list of IPv6 addresses.=A0 And note that
the idea of using tags/labels is nothing new.=A0 Of course we will adapt th=
e
basic mechanism a bit (label distribution, headers formats, etc), but the c=
ore
ideas have been deployed in traditional IP networks for quite some time. 

    
I reiterated a lot of what was already stated before by others, but that is
what I think. 
    

    
--=A0
    
Jonathan Hui 
    

    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi Daniel: 
    

    
Routers might have multiple interfaces of multiple MAC types. Internet 0 
even has a MAC-less format. 
    
So the result of you proposal, which looks like a great idea in a pure 
    
802.15.4 world with short addresses, becomes a nightmare to define in a 
fully generic fashion. 
    

    
OTOH, a locally significant opaque tag in which the parent could hide a 
short address of the child - if it cares to do it that way - looks like 
a way more acceptable approach 
    

    
So it seems to me that you can get what you want as long as we can make 
the tag big enough for short addresses. When the tag is too small to 
    
contain what the parent really needs, then the parent will have to store 
a state with the full information in memory, and then place an index of 
some sort in the tag. 
    

    
What do you think? 
    

    
Pascal 
    


    -----Original Message----- 
    
From: Popa, Daniel [mailto:Daniel.=
Popa@itron.com]

    
Sent: Thursday, April 08, 2010 11:40 AM 
    
To: ROLL WG 
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi Pascal, John, 
    

    
Since source routing explicitly gives forwarding instruction to each 
    
intermediate node, it can make sense to use only (MAC address based) 
    


    L2 
    


    forwarding instead of (IPv6 address based) L3 forwar=
ding. 
    

    
This brings two advantages: 
    
- avoid processing each transit packets up to L3. 
    
- use MAC addresses that - in ROLL environment - have inherently 
    


    shorter 
    


    length than an IPv6 address. 
    

    
Cheers, 
    
Daniel 
    

    

    

    
-----Original Message----- 
    
From: roll-bounces@ietf.org [<=
a href=3D"mailto:roll-bounces@ietf.org">mailto:roll-bounces@ietf.org] O=
n Behalf

    


    Of 
    


    Pascal Thubert (pthubert) 
    
Sent: jeudi 8 avril 2010 11:15 
    
To: JeongGil Ko (John); ROLL WG 
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and 
    
SourceRoutingOperations 
    

    
Hi John: 
    

    
IPv6 already has a number of routing headers, in particular RH0, 
    


    though it is 
    


    being deprecated for general use in the Internet. 
And there are reasons why the fields in RH0/1 are there and we need to 
    
make sure we lose none of that. In particular a RH is recoverable, and 
    


    it is 
    


    easy to spot the consumed entries. 
    

    
On top of this our new problems are: 
    
- make sure the RH stays within the RPL network (since it is used 
    


    downwards 
    


    that should be doable=
) 
    
- control the size (that probably means compress) 
    

    
Cheers, 
    

    
Pascal 
    


    -----Original Message----- 
    
From: roll-bounces@ietf.org [<=
a href=3D"mailto:roll-bounces@ietf.org">mailto:roll-bounces@ietf.org] O=
n Behalf

    


    Of 
    


    JeongGil Ko (John) 
    
Sent: Wednesday, April 07, 2010 10:05 PM 
    
To: ROLL WG 
    
Subject: [Roll] Proposal for Source Routing Header Format and Source 
    
RoutingOperations 
    

    
Hi! 
    

    
Great to see all this discussions on downwards route establishment! 
    


    To 
    


    add 
    


    one more to the conversations here is a proposal for=
 source
routing 
    


    headers. 
    


    In non-storing mode (where only the root has individ=
ual path

    


    information) 
    


    the root will be attaching a source routing header t=
o the
data 
    


    packet 
    


    that a 
    


    source node wants to send to a specific destination.=
 We can
always 
    


    make the 
    


    header super fancy but in my opinion I think we only=
 need
two fields 
    


    in this 
    


    header and here it is! Feel free to break the stuff =
and
mangle with 
    


    it 
    


    so that it 
    


    looks great in the specs later on. FYI, this is the =
format
that I am 
    


    using in my 
    


    implementations so it does work :) 
    

    
1. Source Routing Header Format 
    

    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
|=A0=A0 NEntry (8 bits)=A0=A0 | 
    


    | 
    


    +-+-+-+-+-+-+-+-+ 
    


    + 
    


    |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0
Source Route Entry (128*NEntry bits) 
    


    | 
    


    + 
    


    + 
    


    | 
    


    | 
    



    
=A0=A0=A0=A0 Figure 1. Proposed Source Routing Header Format; each
line is 
    


    32 
    


    bits:) 
    



    
- NEntry: Indicates the number of 128 bit addresses that the source 
    


    route 
    


    entry field is carrying. 
    

    
- Source Route Entry: List of 128 bit address that consist the route 
    


    to the 
    


    destination. Here, the address of the node that is o=
ne hop
away from 
    


    the 
    


    *destination* comes first. 
    

    
2. Source Routing Packet Operations 
    

    
When source routing is initiated at a storing node (e.g., root of 
    


    the 
    


    DODAG), 
    


    the header is attached on the data packet for the en=
tire
route 
    


    (i.e., 
    


    from 
    


    next hop node to the destination). This header is po=
sitioned
in 
    


    front 
    


    of the 
    


    user payload. When the next hop node receives a pack=
et that
is not 
    


    destined 
    


    to itself AND the network is NOT provisioned to be i=
n
'storing mode' 
    


    then it 
    


    checks NEntry to find what the next hop is in the so=
urce
route 
    


    entry. 
    


    Since 
    


    the 'Source Route Entry' is ordered in '=
farthest ->
closest' (in 
    


    terms 
    


    of hops) 
    


    order, a node can figure out what the next hop addre=
ss is
with only 
    


    the 
    


    NEntry value (since it already knows how big an ipv6=
 address
is). 
    


    After 
    


    collecting the next hop node's address, the node=
 erases this
address 
    
element from the entry and decreases NEntry by one. This assures 
    


    that 
    


    we 
    


    avoid the overhead of carrying the entire source rou=
te throughout

    


    the 
    


    data 
    


    path. 
    

    
The approach itself should be very simple and trivial for everyone 
    


    to 
    


    follow. 
    


    So we can start from here and build on! 
    

    
Thanks. 
    

    
-John 
    

    
------ 
    
JeongGil Ko (John) 
    
Ph.D. Student 
    
Department of Computer Science 
    
Johns Hopkins University 
    
http://www.cs.jhu.edu/~jgko 

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

    


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

    


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

    



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

    


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

    


    =A0
    


    


    


    


    


    


    





--001485f5cef63761360483cf0e74--

From jhui@archrock.com  Fri Apr  9 08:19:34 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0D73A6874 for ; Fri,  9 Apr 2010 08:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUjhgqENkSYP for ; Fri,  9 Apr 2010 08:19:29 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 725593A67A3 for ; Fri,  9 Apr 2010 08:19:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id ECBDDAF834; Fri,  9 Apr 2010 08:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZo0ceN0Q6pl; Fri,  9 Apr 2010 08:19:18 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 536ABAF81E; Fri,  9 Apr 2010 08:19:18 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: Pascal Thubert (pthubert) 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Apr 2010 08:19:17 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com> <4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG 
Subject: Re: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 15:19:34 -0000

Hi Pascal,

On Apr 9, 2010, at 1:35 AM, Pascal Thubert (pthubert) wrote:

> I read this as a consensus to use tags J If anyone disagree please =20
> speak up now!
>
> There have been plenty iterations/versions of tagging since Frame =20
> Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s tag =
=20
> switching and MPLS. More often than not, a combination of the 2 =20
> models is used so that tags can be both swapped and stacked.
>
> -          In pure switching, there=92s only one tag in the packet. A =20=

> tag can be locally significant, in which case it has to be swapped =20
> as the packet progresses. For RPL, it means that a node uses as many =20=

> tags as it has children that use it has DAO targets in its subdag.
>
> -          In the pure source route model, tags are stacked in an =20
> ordered list that forms a strict routing header. A tag can be =20
> locally significant to the interpreter and is consumed (marked or =20
> removed) as the packet progresses. For RPL, it means that a node =20
> uses as many tags as it has children that use this node as DAO parent.
>
> It also appears that the 2 tagging models map quite well with the =20
> DAO models we have in RPL since the split that we decided with issue =20=

> #26. The fact that the combination of the 2 models is possible in =20
> the real world today gives us a hint that we are not closing the =20
> door to the mixed model in the future.

Agree with everything here.

>  The next step I wish to agree upon:
> -          Use locally significant tags which implies tag assignment =20=

> by the node that uses it later and tag swapping for the stateful case.

In favor of local tags.  Just to be clear to others, having local tags =20=

is more general than global tags in that you can use global tags as =20
your local tags as well.  So the case where you directly map 802.15.4 =20=

short addresses into the tag would work as long as the tag has enough =20=

bits to do so.

> -          Tag distribution in DAO (there are options there that we =20=

> need to dig further)

The DAO is a natural place to communicate tags.  There are questions =20
of whether a node should know it's own tag, but these are just =20
details.  I also would like to see an option record-route header for =20
quickly establishing a path along the way - I know I've asked for this =20=

many times before :).

> -          Tag content and size (people have asked for at least 2 =20
> octets to fit 15.4 short addresses, do we need some control field as =20=

> well?)

I'd prefer to see the tag fixed in size.  One octet seems to be a bit =20=

small.  When the tag is too small, you have to worry about reusing =20
tags prematurely and it limits how many destinations you can =20
reasonably identify.  Two octets seems to be more appropriate.  Three =20=

or Four octets may be even better if you want to have some extra bits =20=

for service levels.  But I'd want to be extra sure that we *need* =20
every bit because it dictates the source route header and routing =20
table size.

> -          RH format (inherit RH0 fields with labels instead of =20
> addresses? What about the tag swapping  case, RH as well?)

Inheriting RH0 fields for both is fine with me.

--
Jonathan Hui


From Daniel.Popa@itron.com  Fri Apr  9 09:01:29 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F3B3A6862 for ; Fri,  9 Apr 2010 09:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOHtHVz0halJ for ; Fri,  9 Apr 2010 09:01:26 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id E5BD23A6828 for ; Fri,  9 Apr 2010 09:01:24 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Apr 2010 12:01:19 -0400
Message-ID: 
In-Reply-To: <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrX9WZher/vvPDlTQWEdn8SAmcDZQABC8/g
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
From: "Popa, Daniel" 
To: "Jonathan Hui" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 16:01:29 -0000

Hi Jonathan,=20

Thanks for comments.

Some additional comments between your lines.

Cheers,=20
Daniel

-----Original Message-----
From: Jonathan Hui [mailto:jhui@archrock.com]=20
Sent: vendredi 9 avril 2010 17:00
To: Popa, Daniel
Cc: Pascal Thubert (pthubert); roll@ietf.org; =
robert.cragie@gridmerge.com
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =
SourceRoutingOperations


Hi Daniel,

Some comments:

- I'm not in favor of having variable sized tags.  It complicates =20
processing and state maintenance.  It makes dealing with RH0-style =20
headers difficult because it causes you to move large portions of the =20
header around when you simply need to perform a label swap.  We should =20
pick a fixed size that is reasonable (e.g. 16-bits).  Anything too =20
large diminishes a primary reason for having tags - a compact =20
identifier for the next hop.

---
DP1: Let assume we have X bits for control. The problem with a short tag =
is that it burdens the management of mapping Link Layer addresses larger =
16 bits into a (16-X)-bit field.=20
DP2: It will be quite mission impossible to chose the right length for =
the "Tag Value" field. And I agree a too large tag decreases the reason =
of having tags.=20

DP3: I'm not necessarily in favor of having tags with different sizes =
within the same network. I'm rather in favor of having the flexibility =
to chose the size of the label that meets the network design objectives. =
There were discussions about 802.15.4 address space but there can be =
many other scenarios that might adopt ROLL, where the Link Layer =
addressing is different from 802.15.4 MAC addressing. So, having the =
possibility to chose for your network the size of the label is a "nice =
to have" feature.
---


- For a source routing header, I'd much rather see something derived =20
from the RH0 format.

- For different levels of service, the nice thing with tags is that =20
the tag itself can identify not only a destination but also how to get =20
there (path, service level, etc.).  That is the primary reason why =20
labels are used in traditional IP networks today.  Of course, it means =20
that you will have to maintain multiple tags for the same =20
destination. =20

--
DP: For this reason is nice to have 1 or 2 bits for service level within =
the tag, to avoid burdening nodes by maintaining multiple tags for the =
same destination.=20
--=20

And if you're directly mapping the full 802.15.4 short =20
address space into the tag space, then you have to be more careful =20
about managing the mapping (e.g. make sure short addresses can be =20
encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not =20
enough for what you want to do.  In the end, I'm not sure we want to =20
explicitly reserve bits for indicating a service level rather than =20
simply keeping a flat tag namespace.  The use case should define what =20
to do with the bits.

--
Jonathan Hui

On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:

> Hi Pascal,
>
> I have first set of proposals concerning the tag/label size and =20
> content:
>
> -          Tag/Label size:
> o   As 802.15.4-2006 defines addressing modes with 16-bit short =20
> address and 64-bit extended address for Src and Dest Addressing =20
> Mode, I think we should have the same flexibility for tag/label =20
> addressing mode =3D> tag/label should potentially accommodate values =20
> represented on a field with a length up to 64 bits.
> o   Currently, there are ongoing activities to amend MAC Layer for =20
> 802.15.4-2006 (TG 4e) that might alter the aforementioned values for =20
> MAC address size. I will try have some further information about MAC =20
> Addr Length issue and be back on the mailing list asap.
>
> -          Tag/Label contents:
>
> -------------------------------------
> | Control fields | Label Value |
> -------------------------------------
>
> o   Control fields
> =A7  2 bits to signal labeling/tagging mode:  short/extended labels  =20
> =3D> the bit-length of the "Label Value (LV)"  field
> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.
> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map =20
> IPv6 priority field into label priority).
> =A7  Eventually, 1 bit for bottom of the stack flag - for source =20
> routing;  if set to 1 =3D> the current label/tag is last in the stack.
> =A7  1 or 2 bits RFU.
> =A7  Eventually, some bits for hop counts (?).
> o   Label Value (LV) field
> =A7  The value of the label/tag
>
>
> Thanks.
>
> Cheers,
> Daniel
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20
> Of Pascal Thubert (pthubert)
> Sent: vendredi 9 avril 2010 10:36
> To: robert.cragie@gridmerge.com; Jonathan Hui
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =20
> SourceRoutingOperations
>
> I read this as a consensus to use tags J If anyone disagree please =20
> speak up now!
>
> There have been plenty iterations/versions of tagging since Frame =20
> Relay (pure switching), IBM's HPR (pure source route), Cisco's tag =20
> switching and MPLS. More often than not, a combination of the 2 =20
> models is used so that tags can be both swapped and stacked.
>
> -          In pure switching, there's only one tag in the packet. A =20
> tag can be locally significant, in which case it has to be swapped =20
> as the packet progresses. For RPL, it means that a node uses as many =20
> tags as it has children that use it has DAO targets in its subdag.
>
> -          In the pure source route model, tags are stacked in an =20
> ordered list that forms a strict routing header. A tag can be =20
> locally significant to the interpreter and is consumed (marked or =20
> removed) as the packet progresses. For RPL, it means that a node =20
> uses as many tags as it has children that use this node as DAO parent.
>
> It also appears that the 2 tagging models map quite well with the =20
> DAO models we have in RPL since the split that we decided with issue =20
> #26. The fact that the combination of the 2 models is possible in =20
> the real world today gives us a hint that we are not closing the =20
> door to the mixed model in the future.
>
> The next step I wish to agree upon:
> -          Use locally significant tags which implies tag assignment =20
> by the node that uses it later and tag swapping for the stateful case.
> -          Tag distribution in DAO (there are options there that we =20
> need to dig further)
> -          Tag content and size (people have asked for at least 2 =20
> octets to fit 15.4 short addresses, do we need some control field as =20
> well?)
> -          RH format (inherit RH0 fields with labels instead of =20
> addresses? What about the tag swapping  case, RH as well?)
>
> Advice?
>
>
>
>
> Pascal
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20
> Of Robert Cragie
> Sent: Thursday, April 08, 2010 11:34 PM
> To: Jonathan Hui
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Formatand =20
> SourceRoutingOperations
>
> OK, sounds good. End of topic as far as I am concerned. +1
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>
> Hi Robert,
>
> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>
>
> A couple of questions:
>     * I presume the source route header using these tags/labels is =20
> an IPv6 extension header. What value for extension header type would =20
> this be? Would we need to specify a LOWPAN_NHC value for this so we =20
> can still use LOWPAN_NCH for UDP frames?
>
> We already have a draft requesting a new IPv6 Hop-by-Hop Option and =20
> presented it at 6man in Anaheim.  The option is designed to carry =20
> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value =20
> for the IPv6 Hop-by-Hop Option header.
>
>
>     * Can you point to where the 'core ideas have been deployed in =20
> traditional IP networks for quite some time'?
>
> MPLS.  Again, I think the mechanisms will need to be adapted, but =20
> the core ideas are not new.
>
> --=20
> Jonathan Hui
>
>
> Thanks
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>
>
>
> To make the source route header compact, I favor the tag/label =20
> approach over some other compaction mechanism that operates directly =20
> on a list of IPv6 addresses.  Tags/labels can be made general enough =20
> such that they can be derived in different ways.  Because the tags/=20
> labels have scope local to each node, the mechanism is pretty =20
> general already.  For those that are already managing unique =20
> 802.15.4 short addresses across a network, I can see that it is =20
> attractive to utilize the short address directly and reduce state on =20
> devices.  In other cases, it may be best for the node to dynamically =20
> assign tags/labels for its neighbors.
>
> Either way, while the tag/label mechanism is simple, it is far more =20
> flexible than an approach to compacting a list of IPv6 addresses.  =20
> And note that the idea of using tags/labels is nothing new.  Of =20
> course we will adapt the basic mechanism a bit (label distribution, =20
> headers formats, etc), but the core ideas have been deployed in =20
> traditional IP networks for quite some time.
>
> I reiterated a lot of what was already stated before by others, but =20
> that is what I think.
>
> --=20
> Jonathan Hui
>
> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>
>
> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types. =20
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define =20
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could =20
> hide a
> short address of the child - if it cares to do it that way - looks =20
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can =20
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to =20
> store
> a state with the full information in memory, and then place an index =20
> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>
> -----Original Message-----
> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
> Sent: Thursday, April 08, 2010 11:40 AM
> To: ROLL WG
> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi Pascal, John,
>
> Since source routing explicitly gives forwarding instruction to each
> intermediate node, it can make sense to use only (MAC address based)
> L2
>
> forwarding instead of (IPv6 address based) L3 forwarding.
>
> This brings two advantages:
> - avoid processing each transit packets up to L3.
> - use MAC addresses that - in ROLL environment - have inherently
> shorter
>
> length than an IPv6 address.
>
> Cheers,
> Daniel
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>
> Pascal Thubert (pthubert)
> Sent: jeudi 8 avril 2010 11:15
> To: JeongGil Ko (John); ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi John:
>
> IPv6 already has a number of routing headers, in particular RH0,
> though it is
>
> being deprecated for general use in the Internet.
> And there are reasons why the fields in RH0/1 are there and we need to
> make sure we lose none of that. In particular a RH is recoverable, and
> it is
>
> easy to spot the consumed entries.
>
> On top of this our new problems are:
> - make sure the RH stays within the RPL network (since it is used
> downwards
>
> that should be doable)
> - control the size (that probably means compress)
>
> Cheers,
>
> Pascal
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>
> Hi!
>
> Great to see all this discussions on downwards route establishment!
> To
>
> add
>
> one more to the conversations here is a proposal for source routing
> headers.
>
> In non-storing mode (where only the root has individual path
> information)
>
> the root will be attaching a source routing header to the data
> packet
>
> that a
>
> source node wants to send to a specific destination. We can always
> make the
>
> header super fancy but in my opinion I think we only need two fields
> in this
>
> header and here it is! Feel free to break the stuff and mangle with
> it
>
> so that it
>
> looks great in the specs later on. FYI, this is the format that I am
> using in my
>
> implementations so it does work :)
>
> 1. Source Routing Header Format
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
> |
>
> +-+-+-+-+-+-+-+-+
> +
>
> |                       Source Route Entry (128*NEntry bits)
> |
>
> +
> +
>
> |
> |
>
>
>      Figure 1. Proposed Source Routing Header Format; each line is
> 32
>
> bits:)
>
>
> - NEntry: Indicates the number of 128 bit addresses that the source
> route
>
> entry field is carrying.
>
> - Source Route Entry: List of 128 bit address that consist the route
> to the
>
> destination. Here, the address of the node that is one hop away from
> the
>
> *destination* comes first.
>
> 2. Source Routing Packet Operations
>
> When source routing is initiated at a storing node (e.g., root of
> the
>
> DODAG),
>
> the header is attached on the data packet for the entire route
> (i.e.,
>
> from
>
> next hop node to the destination). This header is positioned in
> front
>
> of the
>
> user payload. When the next hop node receives a packet that is not
> destined
>
> to itself AND the network is NOT provisioned to be in 'storing mode'
> then it
>
> checks NEntry to find what the next hop is in the source route
> entry.
>
> Since
>
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> terms
>
> of hops)
>
> order, a node can figure out what the next hop address is with only
> the
>
> NEntry value (since it already knows how big an ipv6 address is).
> After
>
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures
> that
>
> we
>
> avoid the overhead of carrying the entire source route throughout
> the
>
> data
>
> path.
>
> The approach itself should be very simple and trivial for everyone
> to
>
> follow.
>
> So we can start from here and build on!
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>


From robert.cragie@gridmerge.com  Fri Apr  9 09:24:46 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3E328C116 for ; Fri,  9 Apr 2010 09:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.238
X-Spam-Level: 
X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIQZGUWXKjKg for ; Fri,  9 Apr 2010 09:24:41 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8E6E328C11C for ; Fri,  9 Apr 2010 09:24:13 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O0Gzw-0000kz-Uz; Fri, 09 Apr 2010 17:24:02 +0100
Message-ID: <4BBF5499.8030306@gridmerge.com>
Date: Fri, 09 Apr 2010 17:23:53 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jonathan Hui 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
In-Reply-To: <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030006030802030806000904"
Cc: roll@ietf.org, "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Apr 2010 16:24:46 -0000

This is a cryptographically signed message in MIME format.

--------------ms030006030802030806000904
Content-Type: multipart/alternative;
 boundary="------------020600090003060305020206"

This is a multi-part message in MIME format.
--------------020600090003060305020206
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

I thought the idea was to use the hop-by-hop extension header for source =

routing? Isn't that what=20
http://tools.ietf.org/id/draft-hui-6man-rpl-option-00.txt is all about?=20
Or are you suggesting using that just for route repair?

I'm confused - can we have a statement regarding the intention behind=20
the above draft and how you propose to use the extension headers for=20
source routing and whatever else (in the DAO?)?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 09/04/2010 4:00 PM, Jonathan Hui wrote:
>
> Hi Daniel,
>
> Some comments:
>
> - I'm not in favor of having variable sized tags.  It complicates=20
> processing and state maintenance.  It makes dealing with RH0-style=20
> headers difficult because it causes you to move large portions of the=20
> header around when you simply need to perform a label swap.  We should =

> pick a fixed size that is reasonable (e.g. 16-bits).  Anything too=20
> large diminishes a primary reason for having tags - a compact=20
> identifier for the next hop.
>
> - For a source routing header, I'd much rather see something derived=20
> from the RH0 format.
>
> - For different levels of service, the nice thing with tags is that=20
> the tag itself can identify not only a destination but also how to get =

> there (path, service level, etc.).  That is the primary reason why=20
> labels are used in traditional IP networks today.  Of course, it means =

> that you will have to maintain multiple tags for the same=20
> destination.  And if you're directly mapping the full 802.15.4 short=20
> address space into the tag space, then you have to be more careful=20
> about managing the mapping (e.g. make sure short addresses can be=20
> encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not=20
> enough for what you want to do.  In the end, I'm not sure we want to=20
> explicitly reserve bits for indicating a service level rather than=20
> simply keeping a flat tag namespace.  The use case should define what=20
> to do with the bits.
>
> --=20
> Jonathan Hui
>
> On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
>
>> Hi Pascal,
>>
>> I have first set of proposals concerning the tag/label size and conten=
t:
>>
>> -          Tag/Label size:
>> o   As 802.15.4-2006 defines addressing modes with 16-bit short=20
>> address and 64-bit extended address for Src and Dest Addressing Mode, =

>> I think we should have the same flexibility for tag/label addressing=20
>> mode =3D> tag/label should potentially accommodate values represented =

>> on a field with a length up to 64 bits.
>> o   Currently, there are ongoing activities to amend MAC Layer for=20
>> 802.15.4-2006 (TG 4e) that might alter the aforementioned values for=20
>> MAC address size. I will try have some further information about MAC=20
>> Addr Length issue and be back on the mailing list asap.
>>
>> -          Tag/Label contents:
>>
>> -------------------------------------
>> | Control fields | Label Value |
>> -------------------------------------
>>
>> o   Control fields
>> =A7  2 bits to signal labeling/tagging mode:  short/extended labels  =3D=
>=20
>> the bit-length of the =93Label Value (LV)=94  field
>> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 bits.=

>> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map=20
>> IPv6 priority field into label priority).
>> =A7  Eventually, 1 bit for bottom of the stack flag - for source=20
>> routing;  if set to 1 =3D> the current label/tag is last in the stack.=

>> =A7  1 or 2 bits RFU.
>> =A7  Eventually, some bits for hop counts (?).
>> o   Label Value (LV) field
>> =A7  The value of the label/tag
>>
>>
>> Thanks.
>>
>> Cheers,
>> Daniel
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20
>> Of Pascal Thubert (pthubert)
>> Sent: vendredi 9 avril 2010 10:36
>> To: robert.cragie@gridmerge.com; Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand=20
>> SourceRoutingOperations
>>
>> I read this as a consensus to use tags J If anyone disagree please=20
>> speak up now!
>>
>> There have been plenty iterations/versions of tagging since Frame=20
>> Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s tag=
=20
>> switching and MPLS. More often than not, a combination of the 2=20
>> models is used so that tags can be both swapped and stacked.
>>
>> -          In pure switching, there=92s only one tag in the packet. A =

>> tag can be locally significant, in which case it has to be swapped as =

>> the packet progresses. For RPL, it means that a node uses as many=20
>> tags as it has children that use it has DAO targets in its subdag.
>>
>> -          In the pure source route model, tags are stacked in an=20
>> ordered list that forms a strict routing header. A tag can be locally =

>> significant to the interpreter and is consumed (marked or removed) as =

>> the packet progresses. For RPL, it means that a node uses as many=20
>> tags as it has children that use this node as DAO parent.
>>
>> It also appears that the 2 tagging models map quite well with the DAO =

>> models we have in RPL since the split that we decided with issue #26. =

>> The fact that the combination of the 2 models is possible in the real =

>> world today gives us a hint that we are not closing the door to the=20
>> mixed model in the future.
>>
>> The next step I wish to agree upon:
>> -          Use locally significant tags which implies tag assignment=20
>> by the node that uses it later and tag swapping for the stateful case.=

>> -          Tag distribution in DAO (there are options there that we=20
>> need to dig further)
>> -          Tag content and size (people have asked for at least 2=20
>> octets to fit 15.4 short addresses, do we need some control field as=20
>> well?)
>> -          RH format (inherit RH0 fields with labels instead of=20
>> addresses? What about the tag swapping  case, RH as well?)
>>
>> Advice?
>>
>>
>>
>>
>> Pascal
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20
>> Of Robert Cragie
>> Sent: Thursday, April 08, 2010 11:34 PM
>> To: Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing Header Formatand=20
>> SourceRoutingOperations
>>
>> OK, sounds good. End of topic as far as I am concerned. +1
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>>
>> Hi Robert,
>>
>> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>>
>>
>> A couple of questions:
>>     =95 I presume the source route header using these tags/labels is a=
n=20
>> IPv6 extension header. What value for extension header type would=20
>> this be? Would we need to specify a LOWPAN_NHC value for this so we=20
>> can still use LOWPAN_NCH for UDP frames?
>>
>> We already have a draft requesting a new IPv6 Hop-by-Hop Option and=20
>> presented it at 6man in Anaheim.  The option is designed to carry=20
>> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value=20
>> for the IPv6 Hop-by-Hop Option header.
>>
>>
>>     =95 Can you point to where the 'core ideas have been deployed in=20
>> traditional IP networks for quite some time'?
>>
>> MPLS.  Again, I think the mechanisms will need to be adapted, but the =

>> core ideas are not new.
>>
>> --=20
>> Jonathan Hui
>>
>>
>> Thanks
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>
>>
>>
>> To make the source route header compact, I favor the tag/label=20
>> approach over some other compaction mechanism that operates directly=20
>> on a list of IPv6 addresses.  Tags/labels can be made general enough=20
>> such that they can be derived in different ways.  Because the=20
>> tags/labels have scope local to each node, the mechanism is pretty=20
>> general already.  For those that are already managing unique 802.15.4 =

>> short addresses across a network, I can see that it is attractive to=20
>> utilize the short address directly and reduce state on devices.  In=20
>> other cases, it may be best for the node to dynamically assign=20
>> tags/labels for its neighbors.
>>
>> Either way, while the tag/label mechanism is simple, it is far more=20
>> flexible than an approach to compacting a list of IPv6 addresses. =20
>> And note that the idea of using tags/labels is nothing new.  Of=20
>> course we will adapt the basic mechanism a bit (label distribution,=20
>> headers formats, etc), but the core ideas have been deployed in=20
>> traditional IP networks for quite some time.
>>
>> I reiterated a lot of what was already stated before by others, but=20
>> that is what I think.
>>
>> --=20
>> Jonathan Hui
>>
>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. Internet=
 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a pure=

>> 802.15.4 world with short addresses, becomes a nightmare to define in =
a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could hide =
a
>> short address of the child - if it cares to do it that way - looks lik=
e
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can mak=
e
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to sto=
re
>> a state with the full information in memory, and then place an index o=
f
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
>> L2
>>
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
>> shorter
>>
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
>> though it is
>>
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need to=

>> make sure we lose none of that. In particular a RH is recoverable, and=

>> it is
>>
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
>> downwards
>>
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> JeongGil Ko (John)
>> Sent: Wednesday, April 07, 2010 10:05 PM
>> To: ROLL WG
>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>> RoutingOperations
>>
>> Hi!
>>
>> Great to see all this discussions on downwards route establishment!
>> To
>>
>> add
>>
>> one more to the conversations here is a proposal for source routing
>> headers.
>>
>> In non-storing mode (where only the root has individual path
>> information)
>>
>> the root will be attaching a source routing header to the data
>> packet
>>
>> that a
>>
>> source node wants to send to a specific destination. We can always
>> make the
>>
>> header super fancy but in my opinion I think we only need two fields
>> in this
>>
>> header and here it is! Feel free to break the stuff and mangle with
>> it
>>
>> so that it
>>
>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>
>> implementations so it does work :)
>>
>> 1. Source Routing Header Format
>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   NEntry (8 bits)   |
>> |
>>
>> +-+-+-+-+-+-+-+-+
>> +
>>
>> |                       Source Route Entry (128*NEntry bits)
>> |
>>
>> +
>> +
>>
>> |
>> |
>>
>>
>>      Figure 1. Proposed Source Routing Header Format; each line is
>> 32
>>
>> bits:)
>>
>>
>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>
>> entry field is carrying.
>>
>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>
>> destination. Here, the address of the node that is one hop away from
>> the
>>
>> *destination* comes first.
>>
>> 2. Source Routing Packet Operations
>>
>> When source routing is initiated at a storing node (e.g., root of
>> the
>>
>> DODAG),
>>
>> the header is attached on the data packet for the entire route
>> (i.e.,
>>
>> from
>>
>> next hop node to the destination). This header is positioned in
>> front
>>
>> of the
>>
>> user payload. When the next hop node receives a packet that is not
>> destined
>>
>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>
>> checks NEntry to find what the next hop is in the source route
>> entry.
>>
>> Since
>>
>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>> terms
>>
>> of hops)
>>
>> order, a node can figure out what the next hop address is with only
>> the
>>
>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>
>> collecting the next hop node's address, the node erases this address
>> element from the entry and decreases NEntry by one. This assures
>> that
>>
>> we
>>
>> avoid the overhead of carrying the entire source route throughout
>> the
>>
>> data
>>
>> path.
>>
>> The approach itself should be very simple and trivial for everyone
>> to
>>
>> follow.
>>
>> So we can start from here and build on!
>>
>> Thanks.
>>
>> -John
>>
>> ------
>> JeongGil Ko (John)
>> Ph.D. Student
>> Department of Computer Science
>> Johns Hopkins University
>> http://www.cs.jhu.edu/~jgko
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
>

--------------020600090003060305020206
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




  


I thought the idea was to use the hop-by-hop extension header for
source routing? Isn't that what http:=
//tools.ietf.org/id/draft-hui-6man-rpl-option-00.txt
is all about? Or are you suggesting using that just for route repair?
    =


    
I'm confused - can we have a statement regarding the intention behind
the above draft and how you propose to use the extension headers for
source routing and whatever else (in the DAO?)?
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 09/04/2010 4:00 PM, Jonathan Hui wrote:


    
Hi Daniel,
  
    
  
    
Some comments:
  
    
  
    
- I'm not in favor of having variable sized tags.=A0 It complicates
processing and state maintenance.=A0 It makes dealing with RH0-style
headers difficult because it causes you to move large portions of the
header around when you simply need to perform a label swap.=A0 We should
pick a fixed size that is reasonable (e.g. 16-bits).=A0 Anything too
large diminishes a primary reason for having tags - a compact
identifier for the next hop.
  
    
  
    
- For a source routing header, I'd much rather see something derived
from the RH0 format.
  
    
  
    
- For different levels of service, the nice thing with tags is that the
tag itself can identify not only a destination but also how to get
there (path, service level, etc.).=A0 That is the primary reason why
labels are used in traditional IP networks today.=A0 Of course, it means
that you will have to maintain multiple tags for the same destination.=A0=

And if you're directly mapping the full 802.15.4 short address space
into the tag space, then you have to be more careful about managing the
mapping (e.g. make sure short addresses can be encoded within 14 or 15
bits).=A0 Alternatively, maybe 16 bits is not enough for what you want to=

do.=A0 In the end, I'm not sure we want to explicitly reserve bits for
indicating a service level rather than simply keeping a flat tag
namespace.=A0 The use case should define what to do with the bits.
  
    
  
    
--
  
    
Jonathan Hui
  
    
  
    
On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
  
    
  
    
  
    Hi Pascal,
    
    
    
    
I have first set of proposals concerning the tag/label size and
content:
    
    
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tag/Label size:
    
    
o=A0=A0 As 802.15.4-2006 defines addressing modes with 16-bit short addre=
ss
and 64-bit extended address for Src and Dest Addressing Mode, I think
we should have the same flexibility for tag/label addressing mode =3D>=

tag/label should potentially accommodate values represented on a field
with a length up to 64 bits.
    
    
o=A0=A0 Currently, there are ongoing activities to amend MAC Layer for
802.15.4-2006 (TG 4e) that might alter the aforementioned values for
MAC address size. I will try have some further information about MAC
Addr Length issue and be back on the mailing list asap.
    
    
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tag/Label contents:
    
    
    
    
-------------------------------------
    
    
| Control fields | Label Value |
    
    
-------------------------------------
    
    
    
    
o=A0=A0 Control fields
    
    
=A7=A0 2 bits to signal labeling/tagging mode:=A0 short/extended labels=A0=

=3D> the bit-length of the =93Label Value (LV)=94=A0 field
    
    
=B7=A0=A0=A0=A0=A0=A0=A0=A0 2 bits =3D> 4 modes for LV length : 8, 16,=
 32 and 64 bits.
    
    
=A7=A0 Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv=
6
priority field into label priority).
    
    
=A7=A0 Eventually, 1 bit for bottom of the stack flag - for source
routing;=A0 if set to 1 =3D> the current label/tag is last in the stac=
k.
    
    
=A7=A0 1 or 2 bits RFU.
    
    
=A7=A0 Eventually, some bits for hop counts (?).
    
    
o=A0=A0 Label Value (LV) field
    
    
=A7=A0 The value of the label/tag
    
    
    
    
    
    
Thanks.
    
    
    
    
Cheers,
    
    
Daniel
    
    
    
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
Pascal Thubert (pthubert)
    
    
Sent: vendredi 9 avril 2010 10:36
    
    
To: robert.cragie@gridmerge.com; Jonathan Hui
    
    
Cc: r=
oll@ietf.org
    
    
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations
    
    
    
    
I read this as a consensus to use tags J If anyone disagree please
speak up now!
    
    
    
    
There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM=92s HPR (pure source route), Cisco=92s tag switchin=
g
and MPLS. More often than not, a combination of the 2 models is used so
that tags can be both swapped and stacked.
    
    
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 In pure switching, there=92s only one tag in=
 the packet. A tag
can be locally significant, in which case it has to be swapped as the
packet progresses. For RPL, it means that a node uses as many tags as
it has children that use it has DAO targets in its subdag.
    
    
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 In the pure source route model, tags are sta=
cked in an
ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent.
    
    
    
    
It also appears that the 2 tagging models map quite well with the DAO
models we have in RPL since the split that we decided with issue #26.
The fact that the combination of the 2 models is possible in the real
world today gives us a hint that we are not closing the door to the
mixed model in the future.
    
    
    
    
The next step I wish to agree upon:
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Use locally significant tags which implies t=
ag assignment by
the node that uses it later and tag swapping for the stateful case.
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tag distribution in DAO (there are options t=
here that we
need to dig further)
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tag content and size (people have asked for =
at least 2
octets to fit 15.4 short addresses, do we need some control field as
well?)
    
    
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 RH format (inherit RH0 fields with labels in=
stead of
addresses? What about the tag swapping=A0 case, RH as well?)
    
    
    
    
Advice?
    
    
    
    
    
    
    
    
    
    
Pascal
    
    
    
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
Robert Cragie
    
    
Sent: Thursday, April 08, 2010 11:34 PM
    
    
To: Jonathan Hui
    
    
Cc: r=
oll@ietf.org
    
    
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations
    
    
    
    
OK, sounds good. End of topic as far as I am concerned. +1
    
    
    
    
Robert
    
    
Robert Cragie (Pacific Gas & Electric)
    
    
    
    
Gridmerge Ltd.
    
    
89 Greenfield Crescent,
    
    
Wakefield, WF4 4WA, UK
    
    
+44 (0) 1924 910888
    
    
http=
://www.gridmerge.com
    
    
    
    
    
    
On 08/04/2010 10:17 PM, Jonathan Hui wrote:
    
    
    
    
Hi Robert,
    
    
    
    
On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
    
    
    
    
    
    
A couple of questions:
    
    
=A0=A0=A0 =95 I presume the source route header using these tags/labels i=
s an
IPv6 extension header. What value for extension header type would this
be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames?
    
    
    
    
We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.=A0 The option is designed to carry
RPL-specific information.=A0 6lowpan-hc already has a LOWPAN_NHC value
for the IPv6 Hop-by-Hop Option header.
    
    
    
    
    
    
=A0=A0=A0 =95 Can you point to where the 'core ideas have been deployed i=
n
traditional IP networks for quite some time'?
    
    
    
    
MPLS.=A0 Again, I think the mechanisms will need to be adapted, but the
core ideas are not new.
    
    
    
    
--=A0
    
Jonathan Hui
    
    
    
    
    
    
Thanks
    
    
    
    
Robert
    
    
Robert Cragie (Pacific Gas & Electric)
    
    
    
    
Gridmerge Ltd.
    
    
89 Greenfield Crescent,
    
    
Wakefield, WF4 4WA, UK
    
    
+44 (0) 1924 910888
    
    
http=
://www.gridmerge.com
    
    
    
    
    
    
On 08/04/2010 3:57 PM, Jonathan Hui wrote:
    
    
    
    
    
    
    
    
To make the source route header compact, I favor the tag/label approach
over some other compaction mechanism that operates directly on a list
of IPv6 addresses.=A0 Tags/labels can be made general enough such that
they can be derived in different ways.=A0 Because the tags/labels have
scope local to each node, the mechanism is pretty general already.=A0 For=

those that are already managing unique 802.15.4 short addresses across
a network, I can see that it is attractive to utilize the short address
directly and reduce state on devices.=A0 In other cases, it may be best
for the node to dynamically assign tags/labels for its neighbors.
    
    
    
    
Either way, while the tag/label mechanism is simple, it is far more
flexible than an approach to compacting a list of IPv6 addresses.=A0 And
note that the idea of using tags/labels is nothing new.=A0 Of course we
will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time.
    
    
    
    
I reiterated a lot of what was already stated before by others, but
that is what I think.
    
    
    
    
--=A0
    
Jonathan Hui
    
    
    
    
On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
    
    
    
    
    
    
Hi Daniel:
    
    
    
    
Routers might have multiple interfaces of multiple MAC types. Internet
0
    
    
even has a MAC-less format.
    
    
So the result of you proposal, which looks like a great idea in a pure
    
    
802.15.4 world with short addresses, becomes a nightmare to define in a
    
    
fully generic fashion.
    
    
    
    
OTOH, a locally significant opaque tag in which the parent could hide a
    
    
short address of the child - if it cares to do it that way - looks like
    
    
a way more acceptable approach
    
    
    
    
So it seems to me that you can get what you want as long as we can make
    
    
the tag big enough for short addresses. When the tag is too small to
    
    
contain what the parent really needs, then the parent will have to
store
    
    
a state with the full information in memory, and then place an index of
    
    
some sort in the tag.
    
    
    
    
What do you think?
    
    
    
    
Pascal
    
    
    
    
    
    
    
    
-----Original Message-----
    
    
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    
    
Sent: Thursday, April 08, 2010 11:40 AM
    
    
To: ROLL WG
    
    
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
    
    
Subject: RE: [Roll] Proposal for Source Routing Header Format and
    
    
SourceRoutingOperations
    
    
    
    
Hi Pascal, John,
    
    
    
    
Since source routing explicitly gives forwarding instruction to each
    
    
intermediate node, it can make sense to use only (MAC address based)
    
    
L2
    
    
    
    
forwarding instead of (IPv6 address based) L3 forwarding.
    
    
    
    
This brings two advantages:
    
    
- avoid processing each transit packets up to L3.
    
    
- use MAC addresses that - in ROLL environment - have inherently
    
    
shorter
    
    
    
    
length than an IPv6 address.
    
    
    
    
Cheers,
    
    
Daniel
    
    
    
    
    
    
    
    
-----Original Message-----
    
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
    
    
Of
    
    
    
    
Pascal Thubert (pthubert)
    
    
Sent: jeudi 8 avril 2010 11:15
    
    
To: JeongGil Ko (John); ROLL WG
    
    
Subject: Re: [Roll] Proposal for Source Routing Header Format and
    
    
SourceRoutingOperations
    
    
    
    
Hi John:
    
    
    
    
IPv6 already has a number of routing headers, in particular RH0,
    
    
though it is
    
    
    
    
being deprecated for general use in the Internet.
    
    
And there are reasons why the fields in RH0/1 are there and we need to
    
    
make sure we lose none of that. In particular a RH is recoverable, and
    
    
it is
    
    
    
    
easy to spot the consumed entries.
    
    
    
    
On top of this our new problems are:
    
    
- make sure the RH stays within the RPL network (since it is used
    
    
downwards
    
    
    
    
that should be doable)
    
    
- control the size (that probably means compress)
    
    
    
    
Cheers,
    
    
    
    
Pascal
    
    
    
    
    
    
    
    
-----Original Message-----
    
    
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
    
    
Of
    
    
    
    
JeongGil Ko (John)
    
    
Sent: Wednesday, April 07, 2010 10:05 PM
    
    
To: ROLL WG
    
    
Subject: [Roll] Proposal for Source Routing Header Format and Source
    
    
RoutingOperations
    
    
    
    
Hi!
    
    
    
    
Great to see all this discussions on downwards route establishment!
    
    
To
    
    
    
    
add
    
    
    
    
one more to the conversations here is a proposal for source routing
    
    
headers.
    
    
    
    
In non-storing mode (where only the root has individual path
    
    
information)
    
    
    
    
the root will be attaching a source routing header to the data
    
    
packet
    
    
    
    
that a
    
    
    
    
source node wants to send to a specific destination. We can always
    
    
make the
    
    
    
    
header super fancy but in my opinion I think we only need two fields
    
    
in this
    
    
    
    
header and here it is! Feel free to break the stuff and mangle with
    
    
it
    
    
    
    
so that it
    
    
    
    
looks great in the specs later on. FYI, this is the format that I am
    
    
using in my
    
    
    
    
implementations so it does work :)
    
    
    
    
1. Source Routing Header Format
    
    
    
    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    
|=A0=A0 NEntry (8 bits)=A0=A0 |
    
    
|
    
    
    
    
+-+-+-+-+-+-+-+-+
    
    
+
    
    
    
    
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Sourc=
e Route Entry (128*NEntry bits)
    
    
|
    
    
    
    
+
    
    
+
    
    
    
    
|
    
    
|
    
    
    
    
    
    
=A0=A0=A0=A0 Figure 1. Proposed Source Routing Header Format; each line i=
s
    
    
32
    
    
    
    
bits:)
    
    
    
    
    
    
- NEntry: Indicates the number of 128 bit addresses that the source
    
    
route
    
    
    
    
entry field is carrying.
    
    
    
    
- Source Route Entry: List of 128 bit address that consist the route
    
    
to the
    
    
    
    
destination. Here, the address of the node that is one hop away from
    
    
the
    
    
    
    
*destination* comes first.
    
    
    
    
2. Source Routing Packet Operations
    
    
    
    
When source routing is initiated at a storing node (e.g., root of
    
    
the
    
    
    
    
DODAG),
    
    
    
    
the header is attached on the data packet for the entire route
    
    
(i.e.,
    
    
    
    
from
    
    
    
    
next hop node to the destination). This header is positioned in
    
    
front
    
    
    
    
of the
    
    
    
    
user payload. When the next hop node receives a packet that is not
    
    
destined
    
    
    
    
to itself AND the network is NOT provisioned to be in 'storing mode'
    
    
then it
    
    
    
    
checks NEntry to find what the next hop is in the source route
    
    
entry.
    
    
    
    
Since
    
    
    
    
the 'Source Route Entry' is ordered in 'farthest -> closest' (in
    
    
terms
    
    
    
    
of hops)
    
    
    
    
order, a node can figure out what the next hop address is with only
    
    
the
    
    
    
    
NEntry value (since it already knows how big an ipv6 address is).
    
    
After
    
    
    
    
collecting the next hop node's address, the node erases this address
    
    
element from the entry and decreases NEntry by one. This assures
    
    
that
    
    
    
    
we
    
    
    
    
avoid the overhead of carrying the entire source route throughout
    
    
the
    
    
    
    
data
    
    
    
    
path.
    
    
    
    
The approach itself should be very simple and trivial for everyone
    
    
to
    
    
    
    
follow.
    
    
    
    
So we can start from here and build on!
    
    
    
    
Thanks.
    
    
    
    
-John
    
    
    
    
------
    
    
JeongGil Ko (John)
    
    
Ph.D. Student
    
    
Department of Computer Science
    
    
Johns Hopkins University
    
    
h=
ttp://www.cs.jhu.edu/~jgko
    
    
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
    
    
_______________________________________________
    
    
Roll mailing list
    
    
Roll@=
ietf.org
    
    
https://www.ietf.org/mailman/listinfo/roll
    
    
    
    
    
    
  
    
  
    
  
    

    



--------------020600090003060305020206--

--------------ms030006030802030806000904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDkxNjIzNTNaMCMGCSqGSIb3DQEJBDEWBBR5li2GvriZCK7JOxA/aouHAfKpfTBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAHtEaKECPLBxXCYF7yfn+5C4qgk6NgZ/rnQomBDMOBR1aL0Xb2iDLdP0yT/ti4+NkRvY
+AgpUnxHOBvCOJYpvnGcVHpskhi99ggocaq0BrMApkNvJLW9cPgNDBpg3Cf50YOpaF30nbgV
JP/ngI9Iq5yMr58b8nQY8ZxouIFnL3Wkp/IJSsvpAFU0l6askbCwLPhAwaHNqY9m0diBrfeb
Yc48HGyYo5RESfzMvCdhkS6rgHyJXrwOvnEDY2eAc2sSU2s7QhMD8iccOoLxBaHeszwq8rl0
zUJ7QvKGdMvr5RywK+WNqihZJ20iK9El/zzkE81pW/2UFby70C16h0EgQAEAAAAAAAA=
--------------ms030006030802030806000904--

From jhui@archrock.com  Fri Apr  9 09:34:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFFB3A6861 for ; Fri,  9 Apr 2010 09:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0og7e142K0Ak for ; Fri,  9 Apr 2010 09:34:28 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 05B283A6810 for ; Fri,  9 Apr 2010 09:34:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A3D0FAF90F; Fri,  9 Apr 2010 09:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de2LC0GtMW2X; Fri,  9 Apr 2010 09:34:12 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 559C3AF910; Fri,  9 Apr 2010 09:34:12 -0700 (PDT)
Message-Id: <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com>
From: Jonathan Hui 
To: robert.cragie@gridmerge.com
In-Reply-To: <4BBF5499.8030306@gridmerge.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Apr 2010 09:34:11 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com>
X-Mailer: Apple Mail (2.936)
Cc: roll@ietf.org, "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 16:34:30 -0000

Hi Robert,

On Apr 9, 2010, at 9:23 AM, Robert Cragie wrote:

> I thought the idea was to use the hop-by-hop extension header for =20
> source routing? Isn't that =
whathttp://tools.ietf.org/id/draft-hui-6man-rpl-option-00.txt=20
>  is all about? Or are you suggesting using that just for route repair?
>
> I'm confused - can we have a statement regarding the intention =20
> behind the above draft and how you propose to use the extension =20
> headers for source routing and whatever else (in the DAO?)?

The intention with the RPL option is to use it for whatever we need =20
for RPL.  Detecting inconsistencies is one.  Using it to carry source =20=

route headers is another.  The point is that we left the RPL option as =20=

simple container and is flexible in what we put in it.

Note that I said "RH0-style" that doesn't mean using RH0 verbatim.  In =20=

fact, we can't use RH0 because it is deprecated.  What I meant by "RH0-=20=

style" is that the fields and format would be derived from RH0.

--
Jonathan Hui

> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 09/04/2010 4:00 PM, Jonathan Hui wrote:
>>
>>
>> Hi Daniel,
>>
>> Some comments:
>>
>> - I'm not in favor of having variable sized tags.  It complicates =20
>> processing and state maintenance.  It makes dealing with RH0-style =20=

>> headers difficult because it causes you to move large portions of =20
>> the header around when you simply need to perform a label swap.  We =20=

>> should pick a fixed size that is reasonable (e.g. 16-bits).  =20
>> Anything too large diminishes a primary reason for having tags - a =20=

>> compact identifier for the next hop.
>>
>> - For a source routing header, I'd much rather see something =20
>> derived from the RH0 format.
>>
>> - For different levels of service, the nice thing with tags is that =20=

>> the tag itself can identify not only a destination but also how to =20=

>> get there (path, service level, etc.).  That is the primary reason =20=

>> why labels are used in traditional IP networks today.  Of course, =20
>> it means that you will have to maintain multiple tags for the same =20=

>> destination.  And if you're directly mapping the full 802.15.4 =20
>> short address space into the tag space, then you have to be more =20
>> careful about managing the mapping (e.g. make sure short addresses =20=

>> can be encoded within 14 or 15 bits).  Alternatively, maybe 16 bits =20=

>> is not enough for what you want to do.  In the end, I'm not sure we =20=

>> want to explicitly reserve bits for indicating a service level =20
>> rather than simply keeping a flat tag namespace.  The use case =20
>> should define what to do with the bits.
>>
>> --=20
>> Jonathan Hui
>>
>> On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
>>
>>> Hi Pascal,
>>>
>>> I have first set of proposals concerning the tag/label size and =20
>>> content:
>>>
>>> -          Tag/Label size:
>>> o   As 802.15.4-2006 defines addressing modes with 16-bit short =20
>>> address and 64-bit extended address for Src and Dest Addressing =20
>>> Mode, I think we should have the same flexibility for tag/label =20
>>> addressing mode =3D> tag/label should potentially accommodate values =
=20
>>> represented on a field with a length up to 64 bits.
>>> o   Currently, there are ongoing activities to amend MAC Layer for =20=

>>> 802.15.4-2006 (TG 4e) that might alter the aforementioned values =20
>>> for MAC address size. I will try have some further information =20
>>> about MAC Addr Length issue and be back on the mailing list asap.
>>>
>>> -          Tag/Label contents:
>>>
>>> -------------------------------------
>>> | Control fields | Label Value |
>>> -------------------------------------
>>>
>>> o   Control fields
>>> =A7  2 bits to signal labeling/tagging mode:  short/extended labels  =
=20
>>> =3D> the bit-length of the =93Label Value (LV)=94  field
>>> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 =
bits.
>>> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map =20=

>>> IPv6 priority field into label priority).
>>> =A7  Eventually, 1 bit for bottom of the stack flag - for source =20
>>> routing;  if set to 1 =3D> the current label/tag is last in the =
stack.
>>> =A7  1 or 2 bits RFU.
>>> =A7  Eventually, some bits for hop counts (?).
>>> o   Label Value (LV) field
>>> =A7  The value of the label/tag
>>>
>>>
>>> Thanks.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>>> Behalf Of Pascal Thubert (pthubert)
>>> Sent: vendredi 9 avril 2010 10:36
>>> To: robert.cragie@gridmerge.com; Jonathan Hui
>>> Cc: roll@ietf.org
>>> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =20
>>> SourceRoutingOperations
>>>
>>> I read this as a consensus to use tags J If anyone disagree please =20=

>>> speak up now!
>>>
>>> There have been plenty iterations/versions of tagging since Frame =20=

>>> Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s =
tag =20
>>> switching and MPLS. More often than not, a combination of the 2 =20
>>> models is used so that tags can be both swapped and stacked.
>>>
>>> -          In pure switching, there=92s only one tag in the packet. =20=

>>> A tag can be locally significant, in which case it has to be =20
>>> swapped as the packet progresses. For RPL, it means that a node =20
>>> uses as many tags as it has children that use it has DAO targets =20
>>> in its subdag.
>>>
>>> -          In the pure source route model, tags are stacked in an =20=

>>> ordered list that forms a strict routing header. A tag can be =20
>>> locally significant to the interpreter and is consumed (marked or =20=

>>> removed) as the packet progresses. For RPL, it means that a node =20
>>> uses as many tags as it has children that use this node as DAO =20
>>> parent.
>>>
>>> It also appears that the 2 tagging models map quite well with the =20=

>>> DAO models we have in RPL since the split that we decided with =20
>>> issue #26. The fact that the combination of the 2 models is =20
>>> possible in the real world today gives us a hint that we are not =20
>>> closing the door to the mixed model in the future.
>>>
>>> The next step I wish to agree upon:
>>> -          Use locally significant tags which implies tag =20
>>> assignment by the node that uses it later and tag swapping for the =20=

>>> stateful case.
>>> -          Tag distribution in DAO (there are options there that =20
>>> we need to dig further)
>>> -          Tag content and size (people have asked for at least 2 =20=

>>> octets to fit 15.4 short addresses, do we need some control field =20=

>>> as well?)
>>> -          RH format (inherit RH0 fields with labels instead of =20
>>> addresses? What about the tag swapping  case, RH as well?)
>>>
>>> Advice?
>>>
>>>
>>>
>>>
>>> Pascal
>>>
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>>> Behalf Of Robert Cragie
>>> Sent: Thursday, April 08, 2010 11:34 PM
>>> To: Jonathan Hui
>>> Cc: roll@ietf.org
>>> Subject: Re: [Roll] Proposal for Source Routing Header Formatand =20
>>> SourceRoutingOperations
>>>
>>> OK, sounds good. End of topic as far as I am concerned. +1
>>>
>>> Robert
>>> Robert Cragie (Pacific Gas & Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 (0) 1924 910888
>>> http://www.gridmerge.com
>>>
>>>
>>> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>>>
>>> Hi Robert,
>>>
>>> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>>>
>>>
>>> A couple of questions:
>>>     =95 I presume the source route header using these tags/labels is =
=20
>>> an IPv6 extension header. What value for extension header type =20
>>> would this be? Would we need to specify a LOWPAN_NHC value for =20
>>> this so we can still use LOWPAN_NCH for UDP frames?
>>>
>>> We already have a draft requesting a new IPv6 Hop-by-Hop Option =20
>>> and presented it at 6man in Anaheim.  The option is designed to =20
>>> carry RPL-specific information.  6lowpan-hc already has a =20
>>> LOWPAN_NHC value for the IPv6 Hop-by-Hop Option header.
>>>
>>>
>>>     =95 Can you point to where the 'core ideas have been deployed in =
=20
>>> traditional IP networks for quite some time'?
>>>
>>> MPLS.  Again, I think the mechanisms will need to be adapted, but =20=

>>> the core ideas are not new.
>>>
>>> --=20
>>> Jonathan Hui
>>>
>>>
>>> Thanks
>>>
>>> Robert
>>> Robert Cragie (Pacific Gas & Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 (0) 1924 910888
>>> http://www.gridmerge.com
>>>
>>>
>>> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>>
>>>
>>>
>>> To make the source route header compact, I favor the tag/label =20
>>> approach over some other compaction mechanism that operates =20
>>> directly on a list of IPv6 addresses.  Tags/labels can be made =20
>>> general enough such that they can be derived in different ways.  =20
>>> Because the tags/labels have scope local to each node, the =20
>>> mechanism is pretty general already.  For those that are already =20
>>> managing unique 802.15.4 short addresses across a network, I can =20
>>> see that it is attractive to utilize the short address directly =20
>>> and reduce state on devices.  In other cases, it may be best for =20
>>> the node to dynamically assign tags/labels for its neighbors.
>>>
>>> Either way, while the tag/label mechanism is simple, it is far =20
>>> more flexible than an approach to compacting a list of IPv6 =20
>>> addresses.  And note that the idea of using tags/labels is nothing =20=

>>> new.  Of course we will adapt the basic mechanism a bit (label =20
>>> distribution, headers formats, etc), but the core ideas have been =20=

>>> deployed in traditional IP networks for quite some time.
>>>
>>> I reiterated a lot of what was already stated before by others, =20
>>> but that is what I think.
>>>
>>> --=20
>>> Jonathan Hui
>>>
>>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>>
>>>
>>> Hi Daniel:
>>>
>>> Routers might have multiple interfaces of multiple MAC types. =20
>>> Internet 0
>>> even has a MAC-less format.
>>> So the result of you proposal, which looks like a great idea in a =20=

>>> pure
>>> 802.15.4 world with short addresses, becomes a nightmare to define =20=

>>> in a
>>> fully generic fashion.
>>>
>>> OTOH, a locally significant opaque tag in which the parent could =20
>>> hide a
>>> short address of the child - if it cares to do it that way - looks =20=

>>> like
>>> a way more acceptable approach
>>>
>>> So it seems to me that you can get what you want as long as we can =20=

>>> make
>>> the tag big enough for short addresses. When the tag is too small to
>>> contain what the parent really needs, then the parent will have to =20=

>>> store
>>> a state with the full information in memory, and then place an =20
>>> index of
>>> some sort in the tag.
>>>
>>> What do you think?
>>>
>>> Pascal
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>> To: ROLL WG
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi Pascal, John,
>>>
>>> Since source routing explicitly gives forwarding instruction to each
>>> intermediate node, it can make sense to use only (MAC address based)
>>> L2
>>>
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>> This brings two advantages:
>>> - avoid processing each transit packets up to L3.
>>> - use MAC addresses that - in ROLL environment - have inherently
>>> shorter
>>>
>>> length than an IPv6 address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>> Of
>>>
>>> Pascal Thubert (pthubert)
>>> Sent: jeudi 8 avril 2010 11:15
>>> To: JeongGil Ko (John); ROLL WG
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Hi John:
>>>
>>> IPv6 already has a number of routing headers, in particular RH0,
>>> though it is
>>>
>>> being deprecated for general use in the Internet.
>>> And there are reasons why the fields in RH0/1 are there and we =20
>>> need to
>>> make sure we lose none of that. In particular a RH is recoverable, =20=

>>> and
>>> it is
>>>
>>> easy to spot the consumed entries.
>>>
>>> On top of this our new problems are:
>>> - make sure the RH stays within the RPL network (since it is used
>>> downwards
>>>
>>> that should be doable)
>>> - control the size (that probably means compress)
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>> Of
>>>
>>> JeongGil Ko (John)
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>> To: ROLL WG
>>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>>> RoutingOperations
>>>
>>> Hi!
>>>
>>> Great to see all this discussions on downwards route establishment!
>>> To
>>>
>>> add
>>>
>>> one more to the conversations here is a proposal for source routing
>>> headers.
>>>
>>> In non-storing mode (where only the root has individual path
>>> information)
>>>
>>> the root will be attaching a source routing header to the data
>>> packet
>>>
>>> that a
>>>
>>> source node wants to send to a specific destination. We can always
>>> make the
>>>
>>> header super fancy but in my opinion I think we only need two fields
>>> in this
>>>
>>> header and here it is! Feel free to break the stuff and mangle with
>>> it
>>>
>>> so that it
>>>
>>> looks great in the specs later on. FYI, this is the format that I am
>>> using in my
>>>
>>> implementations so it does work :)
>>>
>>> 1. Source Routing Header Format
>>>
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |   NEntry (8 bits)   |
>>> |
>>>
>>> +-+-+-+-+-+-+-+-+
>>> +
>>>
>>> |                       Source Route Entry (128*NEntry bits)
>>> |
>>>
>>> +
>>> +
>>>
>>> |
>>> |
>>>
>>>
>>>      Figure 1. Proposed Source Routing Header Format; each line is
>>> 32
>>>
>>> bits:)
>>>
>>>
>>> - NEntry: Indicates the number of 128 bit addresses that the source
>>> route
>>>
>>> entry field is carrying.
>>>
>>> - Source Route Entry: List of 128 bit address that consist the route
>>> to the
>>>
>>> destination. Here, the address of the node that is one hop away from
>>> the
>>>
>>> *destination* comes first.
>>>
>>> 2. Source Routing Packet Operations
>>>
>>> When source routing is initiated at a storing node (e.g., root of
>>> the
>>>
>>> DODAG),
>>>
>>> the header is attached on the data packet for the entire route
>>> (i.e.,
>>>
>>> from
>>>
>>> next hop node to the destination). This header is positioned in
>>> front
>>>
>>> of the
>>>
>>> user payload. When the next hop node receives a packet that is not
>>> destined
>>>
>>> to itself AND the network is NOT provisioned to be in 'storing mode'
>>> then it
>>>
>>> checks NEntry to find what the next hop is in the source route
>>> entry.
>>>
>>> Since
>>>
>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>> terms
>>>
>>> of hops)
>>>
>>> order, a node can figure out what the next hop address is with only
>>> the
>>>
>>> NEntry value (since it already knows how big an ipv6 address is).
>>> After
>>>
>>> collecting the next hop node's address, the node erases this address
>>> element from the entry and decreases NEntry by one. This assures
>>> that
>>>
>>> we
>>>
>>> avoid the overhead of carrying the entire source route throughout
>>> the
>>>
>>> data
>>>
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
>>> to
>>>
>>> follow.
>>>
>>> So we can start from here and build on!
>>>
>>> Thanks.
>>>
>>> -John
>>>
>>> ------
>>> JeongGil Ko (John)
>>> Ph.D. Student
>>> Department of Computer Science
>>> Johns Hopkins University
>>> http://www.cs.jhu.edu/~jgko
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>
>>


From alexandru.petrescu@gmail.com  Fri Apr  9 10:28:51 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F80A3A688E for ; Fri,  9 Apr 2010 10:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.742
X-Spam-Level: 
X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl0ox3yOPvDi for ; Fri,  9 Apr 2010 10:28:50 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 91F773A685D for ; Fri,  9 Apr 2010 10:28:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o39HSjcX010542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Apr 2010 19:28:45 +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 o39HSjUH024302 for ; Fri, 9 Apr 2010 19:28:45 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o39HSi5I013512 for ; Fri, 9 Apr 2010 19:28:44 +0200
Message-ID: <4BBF63CC.3060101@gmail.com>
Date: Fri, 09 Apr 2010 19:28:44 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 17:28:51 -0000

I have a _very_ hard time grasping the redefinition of the simple word "up":

> Up:   Up refers to the direction from leaf nodes towards DODAG roots,
> following the orientation of the edges within the DODAG.

Redefinition of such a simple word is very dangerous because it easily
leads to misunderstandings, like this one:

> Movement entails changes to the DODAG parent set.  Moving up does not
> present the risk to create a loop but moving down might, so that
> operation is subject to additional constraints.

Moving "up" what?? (I suppose packets to move "up", but not nodes to 
move "up").

> except in the case where it is intended for the packet to change
> from an up to an down flow

Packets shouldn't change whatever we do.  Or maybe I don't understand
"up" and "down".

Alex


From alexandru.petrescu@gmail.com  Fri Apr  9 10:35:31 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46843A699D for ; Fri,  9 Apr 2010 10:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level: 
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_05=-1.11, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YADna4COzOky for ; Fri,  9 Apr 2010 10:35:31 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D389D3A68F6 for ; Fri,  9 Apr 2010 10:35:30 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o39HZQYA015014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Apr 2010 19:35:26 +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 o39HZPTD025080 for ; Fri, 9 Apr 2010 19:35:26 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o39HZPEU014902 for ; Fri, 9 Apr 2010 19:35:25 +0200
Message-ID: <4BBF655D.1020807@gmail.com>
Date: Fri, 09 Apr 2010 19:35:25 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 17:35:31 -0000

>    Down 'O' bit:  1-bit flag indicating whether the packet is expected
>          to progress up or down.  A router sets the 'O' bit when the
>          packet is expect to progress down (using DAO routes), and
>          resets it when forwarding towards the root of the DODAG
>          iteration.  A host MUST set the bit to 0.

Is the DAG Root a Host?  I guess so, because it has no outgoing edge. 
If it's a Host it means it can't send packets "down" (MUST set the O bit 
to 0, up).  If it can't send packets down then there's a problem because 
it can't send queries.

Or am I missing something.

Alex



From jeonggil.ko@gmail.com  Fri Apr  9 10:41:36 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5E13A6810 for ; Fri,  9 Apr 2010 10:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPkgcOMJNlx0 for ; Fri,  9 Apr 2010 10:41:35 -0700 (PDT)
Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 14E3B3A67AD for ; Fri,  9 Apr 2010 10:41:34 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2840596bwz.29 for ; Fri, 09 Apr 2010 10:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nhE49A4KpUtzd60aPepKXOoBswUu2wjsi9ZwVJ/EtWk=; b=e5cS56TV8bjeYRRdRwc1RXm5p0m6ZGollhZgfXydu2VRikeTUrWZ6L9PtgoMhOW3Gi yMbzd1SLDHGoTl10kBSBJ/FXl4wZGfdIBCZzjcKGMJvN99H2D3VREjeeVdYjgD0B8hLC yG/7R0ln4JgfLcVkf0nXl5EBSCprvYyrrGbiU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=N9ktADpTjQ4dlFnWC7kJ73fbdVNDOiv0oJJjJ/iazdOL/y85TG/BI4M+Fa2zSBwhX3 q97EpkKX00q5X0Yyw0Ap1b2R5oN+cXId57kZkFAzAv/d481YThujZocXeW4DR/ftCsA3 tcEu6XYfX009MBUAURceBQFZCVBjROIB7yHlg=
Received: by 10.204.24.9 with SMTP id t9mr385148bkb.150.1270834886705; Fri, 09 Apr 2010 10:41:26 -0700 (PDT)
Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id a11sm11291354bkc.9.2010.04.09.10.41.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 10:41:25 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: "JeongGil Ko (John)" 
In-Reply-To: <4BBF63CC.3060101@gmail.com>
Date: Fri, 9 Apr 2010 10:41:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu>
References: <4BBF63CC.3060101@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 17:41:37 -0000

Hi!

It might not be common but it is understandable.=20

On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:

> I have a _very_ hard time grasping the redefinition of the simple word =
"up":
>=20
>> Up:   Up refers to the direction from leaf nodes towards DODAG roots,
>> following the orientation of the edges within the DODAG.
>=20
> Redefinition of such a simple word is very dangerous because it easily
> leads to misunderstandings, like this one:
>=20
>> Movement entails changes to the DODAG parent set.  Moving up does not
>> present the risk to create a loop but moving down might, so that
>> operation is subject to additional constraints.
>=20
> Moving "up" what?? (I suppose packets to move "up", but not nodes to =
move "up").
>=20

Since 'upwards' is the direction from leaf to root, moving up will =
indicate that a node's rank is decreasing. Obviously this will not cause =
loops.

>> except in the case where it is intended for the packet to change
>> from an up to an down flow
>=20
> Packets shouldn't change whatever we do.  Or maybe I don't understand
> "up" and "down".
>=20

Think of this case you're packets are headed to a node that is in your =
own subtree. However, you are not a storing node so all your point to =
point traffic will first traverse the root (or some other storing node =
if we assume that we still have 'mixed mode which was the case when this =
draft was written). Going 'up' the root is definitely an upwards flow =
but it will have to switch to a 'downwards flow'.

Better?

-John

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

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From alexandru.petrescu@gmail.com  Fri Apr  9 10:49:40 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605C43A68DB for ; Fri,  9 Apr 2010 10:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.404
X-Spam-Level: 
X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_40=-0.185, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl4zx7hxcyeX for ; Fri,  9 Apr 2010 10:49:39 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 6200B3A68C0 for ; Fri,  9 Apr 2010 10:49:39 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o39HnYcb023848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Apr 2010 19:49:34 +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 o39HnYTw026347 for ; Fri, 9 Apr 2010 19:49:34 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o39HnYRY017231 for ; Fri, 9 Apr 2010 19:49:34 +0200
Message-ID: <4BBF68AD.40000@gmail.com>
Date: Fri, 09 Apr 2010 19:49:33 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Roll] What is "topological distance"? And "rank"? And "fixed point number"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Apr 2010 17:49:40 -0000

I am not sure in which order to mention this, but that's how I read it.

Alex

What is "topological distance"?

This pair of words appears precisely once in the draft, as help
explaining another term.

However, "topological distance" as such is not an easy term to
understand.  It could mean "IP hop count" if we knew there existed IP
hops between links but here we don't.

It could also mean "distance in meters".

It could also mean some energy-weighted distance.

Depending on these meanings the original term ("Rank") could have
various meanings ("Rank").

For example:
> The DODAG parent of a node will have a lower rank than the node
> itself

What does "lower" mean?  A smaller figure like in 2 is lower than 3? 
But in my company a "rank 1" means top level above everybody.

> Rank may be thought of as a fixed point number

What's a fixed point number?  A fixed point number between 0 and 1?  OR
a fixed point number between 1 and infinity?  Or did you mean integer
and not fixed point?

> When an objective function computes rank, the objective function
> operates on the entire (i.e. 16-bit) rank quantity.

What's the representation of the 16-bit fixed point number?  On which 
bit is the point?  What's the range of values?  How could it be represented?

Or you meant an "integer"?

Alex


From alexandru.petrescu@gmail.com  Fri Apr  9 10:54:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B993A68E4 for ; Fri,  9 Apr 2010 10:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=0.752,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD4Gzj2zv-eX for ; Fri,  9 Apr 2010 10:54:27 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 129603A6890 for ; Fri,  9 Apr 2010 10:54:26 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o39HsHQV022916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Apr 2010 19:54:17 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o39HsHf7026551; Fri, 9 Apr 2010 19:54:17 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o39HsGUm026481; Fri, 9 Apr 2010 19:54:16 +0200
Message-ID: <4BBF69C8.3010409@gmail.com>
Date: Fri, 09 Apr 2010 19:54:16 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "JeongGil Ko (John)" 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu>
In-Reply-To: <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 17:54:28 -0000

Le 09/04/2010 19:41, JeongGil Ko (John) a écrit :
> Hi!
>
> It might not be common but it is understandable.
>
> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>
>> I have a _very_ hard time grasping the redefinition of the simple
>> word "up":
>>
>>> Up:   Up refers to the direction from leaf nodes towards DODAG
>>> roots, following the orientation of the edges within the DODAG.
>>
>> Redefinition of such a simple word is very dangerous because it
>> easily leads to misunderstandings, like this one:
>>
>>> Movement entails changes to the DODAG parent set.  Moving up does
>>> not present the risk to create a loop but moving down might, so
>>> that operation is subject to additional constraints.
>>
>> Moving "up" what?? (I suppose packets to move "up", but not nodes
>> to move "up").
>>
>
> Since 'upwards' is the direction from leaf to root,

Who moves "up"?  A packet or a node?

What becomes "up" when leaf and root move and substitute each other?

> moving up will indicate that a node's rank is decreasing. Obviously
> this will not cause loops.
>
>>> except in the case where it is intended for the packet to change
>>> from an up to an down flow
>>
>> Packets shouldn't change whatever we do.  Or maybe I don't
>> understand "up" and "down".
>>
>
> Think of this case you're packets are headed to a node that is in
> your own subtree.

Trees?  YEs, please call them trees.  Why explaining in terms of trees
and writing in terms of graphs.

Trees don't have this problem of edges being arrowed.

> However, you are not a storing node so all your point to point

Point to point?  But I thought it was Acyclic?  Which point to which
point?  Or do we tolerate cycles on a single link?

Alex

> traffic will first traverse the root (or some other storing node if
> we assume that we still have 'mixed mode which was the case when this
> draft was written). Going 'up' the root is definitely an upwards flow
> but it will have to switch to a 'downwards flow'.
>
> Better?
>
> -John
>
>> Alex
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>
>
> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>
>



From jeonggil.ko@gmail.com  Fri Apr  9 11:08:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811433A689B for ; Fri,  9 Apr 2010 11:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level: 
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9fZiBMGgUOE for ; Fri,  9 Apr 2010 11:08:06 -0700 (PDT)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id DCC023A692A for ; Fri,  9 Apr 2010 11:07:57 -0700 (PDT)
Received: by ewy24 with SMTP id 24so449724ewy.13 for ; Fri, 09 Apr 2010 11:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=3uf6zq2/MBFKyyZXUuYZNGBYvQJBcBgzWhRdyNLe+W4=; b=HIXTnC4McJtrHzSmFIu7p19c8JENDF4kX/HV3d06lFNEnI3KKSlEAnhuCrJblTYR3M CDH7+n99YXVp9wI9x+jGBvNcWStGHVYFwch9N5GXLLT1MS6GEzYLEknsu0VBljfjhBx9 WxXp4pDk4FSF3tKP+EEoSiItvwUNnFEmXixtg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=DHRApJMhXGicmlR7tN1n7X1ctspybJsjsUhJCT4ckmDS9jIQmtqlrOzD/LRsFQNhjA 6lNphx5Aa/rtUt+g6uZiGuL+1TtxOqFsUnjKwx3fCthW8yMcNl/Mo3dfI0J3WiYw/a+s +wRsnBw/TxepsQtvDqUhVHq1rzDjE5/oXsGbk=
Received: by 10.213.77.203 with SMTP id h11mr208638ebk.51.1270836471198; Fri, 09 Apr 2010 11:07:51 -0700 (PDT)
Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 13sm904532ewy.9.2010.04.09.11.07.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 11:07:50 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: "JeongGil Ko (John)" 
In-Reply-To: <4BBF69C8.3010409@gmail.com>
Date: Fri, 9 Apr 2010 11:07:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 18:08:07 -0000

On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:

> Le 09/04/2010 19:41, JeongGil Ko (John) a =E9crit :
>> Hi!
>>=20
>> It might not be common but it is understandable.
>>=20
>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>=20
>>> I have a _very_ hard time grasping the redefinition of the simple
>>> word "up":
>>>=20
>>>> Up:   Up refers to the direction from leaf nodes towards DODAG
>>>> roots, following the orientation of the edges within the DODAG.
>>>=20
>>> Redefinition of such a simple word is very dangerous because it
>>> easily leads to misunderstandings, like this one:
>>>=20
>>>> Movement entails changes to the DODAG parent set.  Moving up does
>>>> not present the risk to create a loop but moving down might, so
>>>> that operation is subject to additional constraints.
>>>=20
>>> Moving "up" what?? (I suppose packets to move "up", but not nodes
>>> to move "up").
>>>=20
>>=20
>> Since 'upwards' is the direction from leaf to root,
>=20
> Who moves "up"?  A packet or a node?
>=20
> What becomes "up" when leaf and root move and substitute each other?
>=20

'Movement' here should indicate changes in the rank values of a node. =
This can be reflected as a change in topology, thus 'movement' in the =
DODAG :) I think there was some discussion on the list sometime ago on =
clarifying the term movement.=20


>> moving up will indicate that a node's rank is decreasing. Obviously
>> this will not cause loops.
>>=20
>>>> except in the case where it is intended for the packet to change
>>>> from an up to an down flow
>>>=20
>>> Packets shouldn't change whatever we do.  Or maybe I don't
>>> understand "up" and "down".
>>>=20
>>=20
>> Think of this case you're packets are headed to a node that is in
>> your own subtree.
>=20
> Trees?  YEs, please call them trees.  Why explaining in terms of trees
> and writing in terms of graphs.
>=20
> Trees don't have this problem of edges being arrowed.
>=20

I should have used subgraph instead of subtree. Sorry for the =
complication here.=20

>> However, you are not a storing node so all your point to point
>=20
> Point to point?  But I thought it was Acyclic?  Which point to which
> point?  Or do we tolerate cycles on a single link?
>=20

A link can still be bidirectional. Check out the below topology and the =
two cases that I describe below.

            Root
           /     \
         A        B
        /
       C

1) If A tries to send a packet to B then it will go 'up' to the root and =
'down' from the root to B.=20

2) Assuming that A does not have storing capabilities and A wants to =
send a packet to C, one way of reaching C is by sending its packets 'up' =
to the root, let the root figure out that the route to C is =
"root->A->C", then pass the packet 'down' to A then let A pass it to C =
(using source routing). It's not a loop (so it is acyclic) but they are =
bidirectional links. That's why we have bits like the 'O bit' to =
distinguish different types of traffic.=20

John

> Alex
>=20
>> traffic will first traverse the root (or some other storing node if
>> we assume that we still have 'mixed mode which was the case when this
>> draft was written). Going 'up' the root is definitely an upwards flow
>> but it will have to switch to a 'downwards flow'.
>>=20
>> Better?
>>=20
>> -John
>>=20
>>> Alex
>>>=20
>>> _______________________________________________ Roll mailing list
>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>>=20
>>=20
>> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
>> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>>=20
>>=20
>=20
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From robert.cragie@gridmerge.com  Fri Apr  9 11:23:35 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E388B3A6765 for ; Fri,  9 Apr 2010 11:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.341
X-Spam-Level: 
X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQSnSfaQmfOJ for ; Fri,  9 Apr 2010 11:23:33 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 0A1C13A6860 for ; Fri,  9 Apr 2010 11:23:22 -0700 (PDT)
Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O0IrN-0000UM-9k for roll@ietf.org; Fri, 09 Apr 2010 19:23:17 +0100
Message-ID: <4BBF708D.30802@gridmerge.com>
Date: Fri, 09 Apr 2010 19:23:09 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4BBF68AD.40000@gmail.com>
In-Reply-To: <4BBF68AD.40000@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020206000907080207040801"
Subject: Re: [Roll] What is "topological distance"? And "rank"? And "fixed point	number"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Apr 2010 18:23:36 -0000

This is a cryptographically signed message in MIME format.

--------------ms020206000907080207040801
Content-Type: multipart/alternative;
 boundary="------------030305050205060706020208"

This is a multi-part message in MIME format.
--------------030305050205060706020208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Alex,

I agree that ranking does seem perverse, with 'higher' rank meaning=20
further down the tree (an Australian tree, whose root is at the top ;-). =

In terms of superiority, you would think the root was most superior node =

but, well, I guess as long as it is consistent it doesn't really matter=20
- there aren't actually any strict rules on the use of cardinal numbers=20
in ordinality, despite the clear lexical relationship (e.g. third,=20
fourth). On that note, the term 'deeper' is still used in a couple of=20
places and should be changed to 'higher rank'.

I think rank is clearer - it is a fixed point number with an integer and =

fractional part. The integer part is used for the ordinal position and=20
the integer and fractional part are used in rank arithmetic. Where the=20
point sits is dependent on the objective function. Or at least that's=20
how I read it. There are a couple of oddities, such as in OF0,=20
MinHopRankIncrease is set to 256 but this cannot strictly be carried in=20
the DODAG configuration suboption as there is only 1 byte for it.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 09/04/2010 6:49 PM, Alexandru Petrescu wrote:
> I am not sure in which order to mention this, but that's how I read it.=

>
> Alex
>
> What is "topological distance"?
>
> This pair of words appears precisely once in the draft, as help
> explaining another term.
>
> However, "topological distance" as such is not an easy term to
> understand.  It could mean "IP hop count" if we knew there existed IP
> hops between links but here we don't.
>
> It could also mean "distance in meters".
>
> It could also mean some energy-weighted distance.
>
> Depending on these meanings the original term ("Rank") could have
> various meanings ("Rank").
>
> For example:
>> The DODAG parent of a node will have a lower rank than the node
>> itself
>
> What does "lower" mean?  A smaller figure like in 2 is lower than 3?=20
> But in my company a "rank 1" means top level above everybody.
>
>> Rank may be thought of as a fixed point number
>
> What's a fixed point number?  A fixed point number between 0 and 1?  OR=

> a fixed point number between 1 and infinity?  Or did you mean integer
> and not fixed point?
>
>> When an objective function computes rank, the objective function
>> operates on the entire (i.e. 16-bit) rank quantity.
>
> What's the representation of the 16-bit fixed point number?  On which=20
> bit is the point?  What's the range of values?  How could it be=20
> represented?
>
> Or you meant an "integer"?
>
> Alex
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

--------------030305050205060706020208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  
  


Hi Alex,
    

    
I agree that ranking does seem perverse, with 'higher' rank meaning
further down the tree (an Australian tree, whose root is at the top
;-). In terms of superiority, you would think the root was most
superior node but, well, I guess as long as it is consistent it doesn't
really matter - there aren't actually any strict rules on the use of
cardinal numbers in ordinality, despite the clear lexical relationship
(e.g. third, fourth). On that note, the term 'deeper' is still used in
a couple of places and should be changed to 'higher rank'.
    

    
I think rank is clearer - it is a fixed point number with an integer
and fractional part. The integer part is used for the ordinal position
and the integer and fractional part are used in rank arithmetic. Where
the point sits is dependent on the objective function. Or at least
that's how I read it. There are a couple of oddities, such as in OF0,
MinHopRankIncrease is set to 256 but this cannot strictly be carried in
the DODAG configuration suboption as there is only 1 byte for it.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 09/04/2010 6:49 PM, Alexandru Petrescu wrote:

    I am not
sure in which order to mention this, but that's how I read it.
  
    
  
    
Alex
  
    
  
    
What is "topological distance"?
  
    
  
    
This pair of words appears precisely once in the draft, as help
  
    
explaining another term.
  
    
  
    
However, "topological distance" as such is not an easy term to
  
    
understand.  It could mean "IP hop count" if we knew there existed I=
P
  
    
hops between links but here we don't.
  
    
  
    
It could also mean "distance in meters".
  
    
  
    
It could also mean some energy-weighted distance.
  
    
  
    
Depending on these meanings the original term ("Rank") could have
  
    
various meanings ("Rank").
  
    
  
    
For example:
  
    
  
    The DODAG parent of a node will have a lower
rank than the node
    
    
itself
    
    
  
    
  
    
What does "lower" mean?  A smaller figure like in 2 is lower than 3?=

But in my company a "rank 1" means top level above everybody.
  
    
  
    
  
    Rank may be thought of as a fixed point
number
    
    
  
    
  
    
What's a fixed point number?  A fixed point number between 0 and 1?&=
nbsp; OR
  
    
a fixed point number between 1 and infinity?  Or did you mean intege=
r
  
    
and not fixed point?
  
    
  
    
  
    When an objective function computes rank, the=

objective function
    
    
operates on the entire (i.e. 16-bit) rank quantity.
    
    
  
    
  
    
What's the representation of the 16-bit fixed point number?  On whic=
h
bit is the point?  What's the range of values?  How could it be=

represented?
  
    
  
    
Or you meant an "integer"?
  
    
  
    
Alex
  
    
  
    
_______________________________________________
  
    
Roll mailing list
  
    
Roll@=
ietf.org
  
    
https://www.ietf.org/mailman/listinfo/roll
  
    
  
    

    



--------------030305050205060706020208--

--------------ms020206000907080207040801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MDkxODIzMDlaMCMGCSqGSIb3DQEJBDEWBBSol1+SHY52TI3UdFSHvp1lYgDZpjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBABjCjkrZk2Kz+MCtQj4moPOYwVN6W/N7NvCYaXQex3KsLGL1VDsdGm8lieFMEYSURFdD
IPvayLVQksqQzu5EULfkGhFYRmE8jCeGC5rus95hEtAe5CqQb9MEV4Td3Hze82HYMc2dn4pJ
vqGUXazILYuM7bF+e0+3WXMs/QAlszZSUgn55aGv5AvKzyQhhbKV3M6YOnJzBX7kVr+1Q1IV
8OOVRRuRYtu16pbyOYviQX3qPP+7I/TpFtux7sztGUxcntJm1B2TCaMfZwm+3mhApI28CFew
CKgoMTC7EH/zv32OZ15XvFk08p2jxZWMuEt2I2XsMRD50L95onvWpZ1fyfEAAAAAAAA=
--------------ms020206000907080207040801--

From cabo@tzi.org  Fri Apr  9 13:54:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D363A695F for ; Fri,  9 Apr 2010 13:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.506
X-Spam-Level: 
X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=0.743,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22akO0yH4jur for ; Fri,  9 Apr 2010 13:54:37 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AD65D3A6949 for ; Fri,  9 Apr 2010 13:54:36 -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 o39KsJfT009682; Fri, 9 Apr 2010 22:54:19 +0200 (CEST)
Received: from [192.168.217.101] (p5489AE62.dip.t-dialin.net [84.137.174.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 27F3AEC3C;  Fri,  9 Apr 2010 22:54:19 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com>
Date: Fri, 9 Apr 2010 22:54:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org>
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com> <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com>
To: Jonathan Hui 
X-Mailer: Apple Mail (2.1078)
Cc: roll@ietf.org, "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 20:54:37 -0000

On Apr 9, 2010, at 18:34, Jonathan Hui wrote:

> the RPL option as simple container and is flexible in what we put in =
it

One comment in 6man (was that by Erik?) was that this is not the only =
place to put it -- we might as well insert a header in front of the IPv6 =
header like MPLS does.  Now all this talk about forwarding by tags =
instead of IP addresses puts a pretty eerie ring on that...

Gruesse, Carsten


From alexandru.petrescu@gmail.com  Fri Apr  9 14:47:57 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34843A6A12 for ; Fri,  9 Apr 2010 14:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4IkWEyfO20j for ; Fri,  9 Apr 2010 14:47:56 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 00A013A6928 for ; Fri,  9 Apr 2010 14:47:54 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B4BD8D480CB for ; Fri,  9 Apr 2010 23:47:47 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7D210D4800D for ; Fri,  9 Apr 2010 23:47:44 +0200 (CEST)
Message-ID: <4BBFA077.4030102@gmail.com>
Date: Fri, 09 Apr 2010 23:47:35 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4BBF68AD.40000@gmail.com> <4BBF708D.30802@gridmerge.com>
In-Reply-To: <4BBF708D.30802@gridmerge.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [Roll] What is "topological distance"? And "rank"? And "fixed point	number"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Apr 2010 21:47:57 -0000

Le 09/04/2010 20:23, Robert Cragie a écrit :
> Hi Alex,
>
> I agree that ranking does seem perverse, with 'higher' rank meaning
> further down the tree (an Australian tree, whose root is at the top
> ;-). In terms of superiority, you would think the root was most
> superior node but, well, I guess as long as it is consistent it
> doesn't really matter - there aren't actually any strict rules on the
> use of cardinal numbers in ordinality, despite the clear lexical
> relationship (e.g. third, fourth). On that note, the term 'deeper' is
> still used in a couple of places and should be changed to 'higher
> rank'.

To me it is unnecessary complication.  BEtter use standard things 
wherever available.

> I think rank is clearer - it is a fixed point number with an integer
> and fractional part.

How is a fixed point on 16bit represented in practice please?  NEver
programmed it before... I don't personally know I may be fully ignorant.

In C is it like an "fint16_t" (like the standard uint_t, or fpfloat or 
similar?)

How can one compare these meaningfully if the spec doesn't say?

What does "/" mean in:
>              DAGRank(rank) = floor(rank/MinHopRankIncrease)

Is it an integer divide?  A real divide?

What does "floor" mean?  It's not standard C.  Is it C++?  Does one 
_have_ to use C++ to implement this?  (knowing C compilers generate 
faster less memory code...)

In C I am afraid never seen a fixed point on 16bit.

Alex

> The integer part is used for the ordinal position and the integer and
> fractional part are used in rank arithmetic. Where the point sits is
> dependent on the objective function. Or at least that's how I read
> it. There are a couple of oddities, such as in OF0,
> MinHopRankIncrease is set to 256 but this cannot strictly be carried
> in the DODAG configuration suboption as there is only 1 byte for it.
>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0)
> 1924 910888 http://www.gridmerge.com 
>
>
> On 09/04/2010 6:49 PM, Alexandru Petrescu wrote:
>> I am not sure in which order to mention this, but that's how I read
>> it.
>>
>> Alex
>>
>> What is "topological distance"?
>>
>> This pair of words appears precisely once in the draft, as help
>> explaining another term.
>>
>> However, "topological distance" as such is not an easy term to
>> understand. It could mean "IP hop count" if we knew there existed
>> IP hops between links but here we don't.
>>
>> It could also mean "distance in meters".
>>
>> It could also mean some energy-weighted distance.
>>
>> Depending on these meanings the original term ("Rank") could have
>> various meanings ("Rank").
>>
>> For example:
>>> The DODAG parent of a node will have a lower rank than the node
>>> itself
>>
>> What does "lower" mean? A smaller figure like in 2 is lower than 3?
>>  But in my company a "rank 1" means top level above everybody.
>>
>>> Rank may be thought of as a fixed point number
>>
>> What's a fixed point number? A fixed point number between 0 and 1?
>> OR a fixed point number between 1 and infinity? Or did you mean
>> integer and not fixed point?
>>
>>> When an objective function computes rank, the objective function
>>> operates on the entire (i.e. 16-bit) rank quantity.
>>
>> What's the representation of the 16-bit fixed point number? On
>> which bit is the point? What's the range of values? How could it be
>>  represented?
>>
>> Or you meant an "integer"?
>>
>> Alex
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>
>
>
> _______________________________________________ Roll mailing list
> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll


From alexandru.petrescu@gmail.com  Fri Apr  9 15:22:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0489D3A67AE for ; Fri,  9 Apr 2010 15:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph8QVEguWSD9 for ; Fri,  9 Apr 2010 15:22:27 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DE7983A6943 for ; Fri,  9 Apr 2010 15:22:14 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8B7B8D4808F; Sat, 10 Apr 2010 00:22:06 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 68CDDD4801C; Sat, 10 Apr 2010 00:22:04 +0200 (CEST)
Message-ID: <4BBFA883.2040505@gmail.com>
Date: Sat, 10 Apr 2010 00:21:55 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "JeongGil Ko (John)" 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 22:22:30 -0000

Le 09/04/2010 20:07, JeongGil Ko (John) a écrit :
>

> On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:
>
>> Le 09/04/2010 19:41, JeongGil Ko (John) a écrit :
>>> Hi!
>>>
>>> It might not be common but it is understandable.
>>>
>>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>>
>>>> I have a _very_ hard time grasping the redefinition of the
>>>> simple word "up":
>>>>
>>>>> Up:   Up refers to the direction from leaf nodes towards
>>>>> DODAG roots, following the orientation of the edges within
>>>>> the DODAG.
>>>>
>>>> Redefinition of such a simple word is very dangerous because it
>>>> easily leads to misunderstandings, like this one:
>>>>
>>>>> Movement entails changes to the DODAG parent set.  Moving up
>>>>> does not present the risk to create a loop but moving down
>>>>> might, so that operation is subject to additional
>>>>> constraints.
>>>>
>>>> Moving "up" what?? (I suppose packets to move "up", but not
>>>> nodes to move "up").
>>>>
>>>
>>> Since 'upwards' is the direction from leaf to root,
>>
>> Who moves "up"?  A packet or a node?
>>
>> What becomes "up" when leaf and root move and substitute each
>> other?
>>
>
> 'Movement' here should indicate changes in the rank values of a
> node. This can be reflected as a change in topology, thus 'movement'
> in the DODAG :) I think there was some discussion on the list
> sometime ago on clarifying the term movement.

I think the draft uses the term "move" to indicate various things
which some times are _node_ movement other times _packet_ movement.

e.g. node movement:
> Movement entails changes to the DODAG parent set.
[...]
> When a node moves to improve its position

e.g. packet movement:
> o A DODAG parent forwards a packet intended to move up,

Additionally, whenever text tries to control physical movement on the
node I think the Author had a difficult to understand mindset:

[...]
> In order to limit erratic movements, and all metrics being equal,
> nodes SHOULD keep their previous selection.

One can't limit erratic movements, nodes move as they please.

> movement within the DODAG are restricted in favor of loop avoidance.

Again, knowing one can't restrict node movement - this reads as if
Author wished to restrict movement of a data structure - is it a
representation of a node in that data structure which moves?

> 5.3.3.4. Rank and Movement within a DODAG Iteration
>
> 1.  A node MUST NOT advertise a rank less than or equal to any
> member of its parent set within the DODAG Iteration.

Does Author intend to limit the contents of the packet the node sends?
(and not the node movement?).

> o  Move down within the DODAG iteration (i.e. increase its rank)

...i.e. sending a _packet_ with an increased rank?

> If a node is allowed to be greedy and attempts to move deeper

(greedier would read as move higher, closer to the Parent, smaller
  Rank, and not deeper bigger Rank).

> If a node needs to move down a DODAG that it is attached to, causing
> the rank to increase, then it MAY poison its routes and delay before
> moving as described in Section 5.3.3.5.

Again, can't tell a node to delay its physical movement. It may delay
sending packets, but not its physical movement. Spec can't pupetteer
nodes if I can say so.

>>> moving up will indicate that a node's rank is decreasing.
>>> Obviously this will not cause loops.
>>>
>>>>> except in the case where it is intended for the packet to
>>>>> change from an up to an down flow
>>>>
>>>> Packets shouldn't change whatever we do.  Or maybe I don't
>>>> understand "up" and "down".
>>>>
>>>
>>> Think of this case you're packets are headed to a node that is in
>>> your own subtree.
>>
>> Trees?  YEs, please call them trees.  Why explaining in terms of
>> trees and writing in terms of graphs.
>>
>> Trees don't have this problem of edges being arrowed.
>>
>
> I should have used subgraph instead of subtree. Sorry for the
> complication here.

What's a subgraph? I think we have a clear view of a tree but a subgraph
not...

>>> However, you are not a storing node so all your point to point
>>
>> Point to point?  But I thought it was Acyclic?  Which point to
>> which point?  Or do we tolerate cycles on a single link?
>>
>
> A link can still be bidirectional. Check out the below topology and
> the two cases that I describe below.
>
>             Root
>            /     \
>          A        B
>         /
>        C

Ok, but this has nothing of a DAG, it's a pure rectilinear topology,
which, additionally - has 2 interfaces per node! (limited features per 
node right?).

DAGs have arrows on their edges. These arrows must mean something.  If I
want to translate such an arrow in terms of entries in the routing table
then I imply there must be arrows in both directions (there are
routes both ways).  And if I put both arrows on every link then I 
obviously no longer talk DAG...

I don't understand the use of this DAG term overall. I find it an
unnecessary complication.

> 1) If A tries to send a packet to B then it will go 'up' to the root
> and 'down' from the root to B.

I agree, but where else could it go?

Did Author intend to talk about Default routes instead of "Up"? If yes
then why don't we talk Default route throughout? It would be much more
meaningful to me.

> 2) Assuming that A does not have storing capabilities and A wants to
> send a packet to C, one way of reaching C is by sending its packets
> 'up' to the root, let the root figure out that the route to C is
> "root->A->C", then pass the packet 'down' to A then let A pass it to
> C (using source routing). It's not a loop (so it is acyclic) but
> they are bidirectional links. That's why we have bits like the 'O
> bit' to distinguish different types of traffic.

John - loops may form in an acyclic graph painted as above. Suffices it
for Root to forward packets back to A because it had the wrong route.

The image that each node has about the network could be qualified as a
DAG (if one absolutely wishes) but the topology of the nodes is an
arbitrary graph with arbitrary physical node movements.  Mixind the two 
is little understandable.

I think the mindset of designing the protocol should change from one 
where a God-like all-knowing central point dictates node behaviour to a 
mindset where limits are reckoned and well defined, if I can say so.

Respectfully,

Alex

From jeonggil.ko@gmail.com  Fri Apr  9 15:51:13 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8DB3A6A43 for ; Fri,  9 Apr 2010 15:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.09
X-Spam-Level: 
X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.905,  BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4WIzW9yG40J for ; Fri,  9 Apr 2010 15:51:11 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 56A463A6980 for ; Fri,  9 Apr 2010 15:51:11 -0700 (PDT)
Received: by yxe9 with SMTP id 9so1952560yxe.29 for ; Fri, 09 Apr 2010 15:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=+LNCD04F86gSawrE/36A4CtuhXK38QLFszncU1pVAUM=; b=lxKgb0xAB02jPenriXuIvwj7K5KueyKq5CyMNmfvW7hDO2Q5/NNzrY+cshaWJkCzdh mx8LLZPUh8zeMDeRG+Wuamm5ezfFfTYZMuexTGBOWbIf52HQmdolmMPcYRYweQKFOu8Y UKwNTRgyMOZmJPWNkci1d+SRvt/GwP2Gp7op8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=K70IRyNYNVWnqpGM2MCxvyDUKVholeZLxGq/bugt7pFoAd8/M7EK/wJMIBssNj3NZ2 ba6fwaBxmzTMXCmuJzy53EMzhBEYLOEnPoYOXjFnfTi0y73OSGP3Qiwmqk7Qho1k+uwR oXTWLfrjBqOjBOivZqG0HxnFg0NMq6B8pn/X8=
Received: by 10.151.21.3 with SMTP id y3mr20932ybi.61.1270853463991; Fri, 09 Apr 2010 15:51:03 -0700 (PDT)
Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 9sm443533ywe.52.2010.04.09.15.51.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 15:51:03 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: "JeongGil Ko (John)" 
In-Reply-To: <4BBFA883.2040505@gmail.com>
Date: Fri, 9 Apr 2010 15:51:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu>
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 22:51:13 -0000

A lot of points here so let me just try to summarize instead of putting =
things in line.

1. The authors of the draft can better answer this but I don't think the =
RPL draft even considers physical movements of nodes. This (as far as I =
know) is out of the scope of what RPL is trying to do. We are dealing =
with a physically stationary network (no node mobility) and the =
movements of nodes just indicate the changes in the rank values. So no =
'restriction' of physical movement here.

2. I agree with you that some parts use 'move' for node level rank =
changes and some parts use 'move' for packet exchanges and you pointed =
out the parts correctly. But I don't think this is so complex that one =
cannot understand what the draft is trying to say. Still, this is a room =
for improvement in the draft.

3. For point to point traffic all the discussions until now have shown =
that we can EITHER have a 'God-like all knowing' central node (as you =
put it) OR nodes can separately save prefixes in their sub-graphs. No =
need to change mindsets since here we just support different modes.

4. If you assure that packets with the 'O bit' set to 0 will travel 'up' =
(to lower rank nodes) and packets with 'O bit' set to 1 will travel =
'down' (to higher rank nodes) there should not be a loop formed (at =
least theoretically). For the cases that the theory fails (crazy things =
can happen), packets being forwarded must be checked if the forwarding =
of the packet is valid or not (specs explicitly give you things to check =
before forwarding a packet). There are also cases where the packets can =
travel to siblings that can cause loops but RPL limits the number of =
hops in such cases so that the hop limit exceeds its threshold or an =
inconsistency is detected if more than two siblings are used for packet =
forwarding consecutively.=20

5. To my understanding (authors can correct me if I am wrong), the DODAG =
(yes, the DAG) is 'directed' towards the root. So you are definitely =
right about that. The links that make up the DODAG are selected via DIO =
exchanges and the rank computation process. RPL just uses the =
bi-directional connectivity of wireless links (that nodes get anyway) to =
perform other operations such as point to multipoint and point to point. =
How do we select the links that are 'directed' to individual nodes =
(other than the root)? Now that's a totally new story that is still =
under discussion on the list ;) My example below was a single case where =
source routing is used and the network has a 'God-like all knowing' root =
node :)

-John

On Apr 9, 2010, at 3:21 PM, Alexandru Petrescu wrote:

> Le 09/04/2010 20:07, JeongGil Ko (John) a =E9crit :
>>=20
>=20
>> On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:
>>=20
>>> Le 09/04/2010 19:41, JeongGil Ko (John) a =E9crit :
>>>> Hi!
>>>>=20
>>>> It might not be common but it is understandable.
>>>>=20
>>>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>>>=20
>>>>> I have a _very_ hard time grasping the redefinition of the
>>>>> simple word "up":
>>>>>=20
>>>>>> Up:   Up refers to the direction from leaf nodes towards
>>>>>> DODAG roots, following the orientation of the edges within
>>>>>> the DODAG.
>>>>>=20
>>>>> Redefinition of such a simple word is very dangerous because it
>>>>> easily leads to misunderstandings, like this one:
>>>>>=20
>>>>>> Movement entails changes to the DODAG parent set.  Moving up
>>>>>> does not present the risk to create a loop but moving down
>>>>>> might, so that operation is subject to additional
>>>>>> constraints.
>>>>>=20
>>>>> Moving "up" what?? (I suppose packets to move "up", but not
>>>>> nodes to move "up").
>>>>>=20
>>>>=20
>>>> Since 'upwards' is the direction from leaf to root,
>>>=20
>>> Who moves "up"?  A packet or a node?
>>>=20
>>> What becomes "up" when leaf and root move and substitute each
>>> other?
>>>=20
>>=20
>> 'Movement' here should indicate changes in the rank values of a
>> node. This can be reflected as a change in topology, thus 'movement'
>> in the DODAG :) I think there was some discussion on the list
>> sometime ago on clarifying the term movement.
>=20
> I think the draft uses the term "move" to indicate various things
> which some times are _node_ movement other times _packet_ movement.
>=20
> e.g. node movement:
>> Movement entails changes to the DODAG parent set.
> [...]
>> When a node moves to improve its position
>=20
> e.g. packet movement:
>> o A DODAG parent forwards a packet intended to move up,
>=20
> Additionally, whenever text tries to control physical movement on the
> node I think the Author had a difficult to understand mindset:
>=20
> [...]
>> In order to limit erratic movements, and all metrics being equal,
>> nodes SHOULD keep their previous selection.
>=20
> One can't limit erratic movements, nodes move as they please.
>=20
>> movement within the DODAG are restricted in favor of loop avoidance.
>=20
> Again, knowing one can't restrict node movement - this reads as if
> Author wished to restrict movement of a data structure - is it a
> representation of a node in that data structure which moves?
>=20
>> 5.3.3.4. Rank and Movement within a DODAG Iteration
>>=20
>> 1.  A node MUST NOT advertise a rank less than or equal to any
>> member of its parent set within the DODAG Iteration.
>=20
> Does Author intend to limit the contents of the packet the node sends?
> (and not the node movement?).
>=20
>> o  Move down within the DODAG iteration (i.e. increase its rank)
>=20
> ...i.e. sending a _packet_ with an increased rank?
>=20
>> If a node is allowed to be greedy and attempts to move deeper
>=20
> (greedier would read as move higher, closer to the Parent, smaller
> Rank, and not deeper bigger Rank).
>=20
>> If a node needs to move down a DODAG that it is attached to, causing
>> the rank to increase, then it MAY poison its routes and delay before
>> moving as described in Section 5.3.3.5.
>=20
> Again, can't tell a node to delay its physical movement. It may delay
> sending packets, but not its physical movement. Spec can't pupetteer
> nodes if I can say so.
>=20
>>>> moving up will indicate that a node's rank is decreasing.
>>>> Obviously this will not cause loops.
>>>>=20
>>>>>> except in the case where it is intended for the packet to
>>>>>> change from an up to an down flow
>>>>>=20
>>>>> Packets shouldn't change whatever we do.  Or maybe I don't
>>>>> understand "up" and "down".
>>>>>=20
>>>>=20
>>>> Think of this case you're packets are headed to a node that is in
>>>> your own subtree.
>>>=20
>>> Trees?  YEs, please call them trees.  Why explaining in terms of
>>> trees and writing in terms of graphs.
>>>=20
>>> Trees don't have this problem of edges being arrowed.
>>>=20
>>=20
>> I should have used subgraph instead of subtree. Sorry for the
>> complication here.
>=20
> What's a subgraph? I think we have a clear view of a tree but a =
subgraph
> not...
>=20
>>>> However, you are not a storing node so all your point to point
>>>=20
>>> Point to point?  But I thought it was Acyclic?  Which point to
>>> which point?  Or do we tolerate cycles on a single link?
>>>=20
>>=20
>> A link can still be bidirectional. Check out the below topology and
>> the two cases that I describe below.
>>=20
>>            Root
>>           /     \
>>         A        B
>>        /
>>       C
>=20
> Ok, but this has nothing of a DAG, it's a pure rectilinear topology,
> which, additionally - has 2 interfaces per node! (limited features per =
node right?).
>=20
> DAGs have arrows on their edges. These arrows must mean something.  If =
I
> want to translate such an arrow in terms of entries in the routing =
table
> then I imply there must be arrows in both directions (there are
> routes both ways).  And if I put both arrows on every link then I =
obviously no longer talk DAG...
>=20
> I don't understand the use of this DAG term overall. I find it an
> unnecessary complication.
>=20
>> 1) If A tries to send a packet to B then it will go 'up' to the root
>> and 'down' from the root to B.
>=20
> I agree, but where else could it go?
>=20
> Did Author intend to talk about Default routes instead of "Up"? If yes
> then why don't we talk Default route throughout? It would be much more
> meaningful to me.
>=20
>> 2) Assuming that A does not have storing capabilities and A wants to
>> send a packet to C, one way of reaching C is by sending its packets
>> 'up' to the root, let the root figure out that the route to C is
>> "root->A->C", then pass the packet 'down' to A then let A pass it to
>> C (using source routing). It's not a loop (so it is acyclic) but
>> they are bidirectional links. That's why we have bits like the 'O
>> bit' to distinguish different types of traffic.
>=20
> John - loops may form in an acyclic graph painted as above. Suffices =
it
> for Root to forward packets back to A because it had the wrong route.
>=20
> The image that each node has about the network could be qualified as a
> DAG (if one absolutely wishes) but the topology of the nodes is an
> arbitrary graph with arbitrary physical node movements.  Mixind the =
two is little understandable.
>=20
> I think the mindset of designing the protocol should change from one =
where a God-like all-knowing central point dictates node behaviour to a =
mindset where limits are reckoned and well defined, if I can say so.
>=20
> Respectfully,
>=20
> Alex
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From alexandru.petrescu@gmail.com  Fri Apr  9 16:11:45 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC3E3A694D for ; Fri,  9 Apr 2010 16:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSF+sZ5D2Fbb for ; Fri,  9 Apr 2010 16:11:43 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 48BD53A68CC for ; Fri,  9 Apr 2010 16:11:39 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 96A9AD48050 for ; Sat, 10 Apr 2010 01:11:33 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9DF78D4806E for ; Sat, 10 Apr 2010 01:11:30 +0200 (CEST)
Message-ID: <4BBFB419.10905@gmail.com>
Date: Sat, 10 Apr 2010 01:11:21 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Subject: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 23:11:46 -0000

Flow Labels are wrongly used.

First they're wrongly represented:

>   RPL loop detection uses information that is placed into the packet in
>    the IPv6 flow label.  The IPv6 flow label is defined in [RFC2460] and
>    its operation is further specified in [RFC3697].  For the purpose of
>    RPL operations, the flow label is constructed as follows:
>
>
>         0                   1                   2
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                |O|S|R|F|  SenderRank   | RPLInstanceID |
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What are the first 4 bits? The diagram in rfc2460 shows 32bit wide with
the rightmost 20bits as the flow label, whereas the above diagram shows
24bit wide.

Second, the flow label MUST NOT be modified en-route by any router. Or,
RPL says:
> A router sets the 'O' bit when the packet is expect to progress down
> (using DAO routes), and resets it when forwarding towards the root of
> the DODAG iteration.   A host MUST set the bit to 0.

If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
intermediary Routers must not modify it, RFC3697:
> The Flow Label value set by the source MUST be delivered unchanged
> to the destination node(s).

The risk of not doing so is obvious: the communication between a Host in
the RoLL network and a host in the Internet and relying on Flow Labels
as RFC3697 - will be broken.

I like Flow Labels as Appendix A of rfc2460 I like it. It's not intended
to establish routing paths IMHO.

If one needs intermediary routers to modify stuff going through them
then better encapsulate, or at an extreme write new packets (like when
using RSVP, or when triggering route setup like Triggered RIP, or DYMO)
- but don't modify RFC2460 headers of packets not intended to self!
(other than exceptions like RH, or decrement the Hop Limit obviously).
The mutation of fields in the IPv6 headers is very dangerous breaks
things. Smiley.

Alex



From alexandru.petrescu@gmail.com  Fri Apr  9 16:26:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5B73A6A6C for ; Fri,  9 Apr 2010 16:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level: 
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_20=-0.74, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNNEirhyrpyB for ; Fri,  9 Apr 2010 16:26:26 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id AFE533A6A33 for ; Fri,  9 Apr 2010 16:26:24 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 62464D48031; Sat, 10 Apr 2010 01:26:16 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3FD76D4805C; Sat, 10 Apr 2010 01:26:14 +0200 (CEST)
Message-ID: <4BBFB78D.4080801@gmail.com>
Date: Sat, 10 Apr 2010 01:26:05 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "JeongGil Ko (John)" 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu>
In-Reply-To: <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 23:26:27 -0000

Le 10/04/2010 00:51, JeongGil Ko (John) a écrit :
> A lot of points here so let me just try to summarize instead of
> putting things in line.
>
> 1. The authors of the draft can better answer this but I don't think
> the RPL draft even considers physical movements of nodes.

Physical movements of nodes is in the RoLL requirements!

> This (as far as I know) is out of the scope of what RPL is trying to
> do. We are dealing with a physically stationary network (no node
> mobility) and the movements of nodes just indicate the changes in the
> rank values. So no 'restriction' of physical movement here.

This is a complete misunderstanding.  I am not sure on whom part.
Smiley.  RFC5826 to cite one has a section on mobility.

If the nodes are fixed and don't move then why does the RPL say at 
several points prevent "movements"?  Is this a spec about moving data 
structures in graphs?  IF so then it's wrong, the spec should specify 
how the routers build their loop-free data structures.  No other routing 
protocol does.

> 2. I agree with you that some parts use 'move' for node level rank
> changes and some parts use 'move' for packet exchanges and you
> pointed out the parts correctly. But I don't think this is so
> complex that one cannot understand what the draft is trying to say.
> Still, this is a room for improvement in the draft.
>
> 3. For point to point traffic all the discussions until now have
> shown that we can EITHER have a 'God-like all knowing' central node
> (as you put it) OR nodes can separately save prefixes in their
> sub-graphs. No need to change mindsets since here we just support
> different modes.
>
> 4. If you assure that packets with the 'O bit' set to 0 will travel
> 'up' (to lower rank nodes) and packets with 'O bit' set to 1 will
> travel 'down' (to higher rank nodes) there should not be a loop
> formed (at least theoretically).

This is a wrong mindset on somebody's part.  Smiley.

Loops can form up-down-up-down.

> For the cases that the theory fails (crazy things can happen),
> packets being forwarded must be checked if the forwarding of the
> packet is valid or not (specs explicitly give you things to check
> before forwarding a packet).

I am not in synch with you about what it means to forward a packet.  To
me the only thing a router must check before forwarding a packet are
actually three: the dst field, the Hop Limit and the size.  No more no 
less, shouldn't modify that rule otherwise node can't connect to the 
Internet.

The RPL spec should not check more than these.  If anything wrong in 
these fields then Router should use ICMP to inform the owner of the src 
field about wrong stuff, or hold on for a while and generate new packets 
for establishing routes.  It's as simple as that.

> There are also cases where the packets can travel to siblings that
> can cause loops but RPL limits the number of hops in such cases so
> that the hop limit exceeds its threshold or an inconsistency is
> detected if more than two siblings are used for packet forwarding
> consecutively.

How?  By modifying the Flow Label?  That shouldn't be done.

> 5. To my understanding (authors can correct me if I am wrong), the
> DODAG (yes, the DAG) is 'directed' towards the root. So you are
> definitely right about that. The links that make up the DODAG are
> selected via DIO exchanges and the rank computation process.

That computation process should be left out of this document.

Why don't Authors use the existing methods for this?  Bellman-Ford 
Dijkstra guaranteed bullet-proof Internet scale.

Alex

  RPL
> just uses the bi-directional connectivity of wireless links (that
> nodes get anyway) to perform other operations such as point to
> multipoint and point to point. How do we select the links that are
> 'directed' to individual nodes (other than the root)? Now that's a
> totally new story that is still under discussion on the list ;) My
> example below was a single case where source routing is used and the
> network has a 'God-like all knowing' root node :)

>
> -John
>
> On Apr 9, 2010, at 3:21 PM, Alexandru Petrescu wrote:
>
>> Le 09/04/2010 20:07, JeongGil Ko (John) a écrit :
>>>
>>
>>> On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:
>>>
>>>> Le 09/04/2010 19:41, JeongGil Ko (John) a écrit :
>>>>> Hi!
>>>>>
>>>>> It might not be common but it is understandable.
>>>>>
>>>>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>>>>
>>>>>> I have a _very_ hard time grasping the redefinition of the
>>>>>>  simple word "up":
>>>>>>
>>>>>>> Up:   Up refers to the direction from leaf nodes towards
>>>>>>>  DODAG roots, following the orientation of the edges
>>>>>>> within the DODAG.
>>>>>>
>>>>>> Redefinition of such a simple word is very dangerous
>>>>>> because it easily leads to misunderstandings, like this
>>>>>> one:
>>>>>>
>>>>>>> Movement entails changes to the DODAG parent set.
>>>>>>> Moving up does not present the risk to create a loop but
>>>>>>> moving down might, so that operation is subject to
>>>>>>> additional constraints.
>>>>>>
>>>>>> Moving "up" what?? (I suppose packets to move "up", but not
>>>>>> nodes to move "up").
>>>>>>
>>>>>
>>>>> Since 'upwards' is the direction from leaf to root,
>>>>
>>>> Who moves "up"?  A packet or a node?
>>>>
>>>> What becomes "up" when leaf and root move and substitute each
>>>> other?
>>>>
>>>
>>> 'Movement' here should indicate changes in the rank values of a
>>> node. This can be reflected as a change in topology, thus
>>> 'movement' in the DODAG :) I think there was some discussion on
>>> the list sometime ago on clarifying the term movement.
>>
>> I think the draft uses the term "move" to indicate various things
>> which some times are _node_ movement other times _packet_
>> movement.
>>
>> e.g. node movement:
>>> Movement entails changes to the DODAG parent set.
>> [...]
>>> When a node moves to improve its position
>>
>> e.g. packet movement:
>>> o A DODAG parent forwards a packet intended to move up,
>>
>> Additionally, whenever text tries to control physical movement on
>> the node I think the Author had a difficult to understand mindset:
>>
>> [...]
>>> In order to limit erratic movements, and all metrics being equal,
>>> nodes SHOULD keep their previous selection.
>>
>> One can't limit erratic movements, nodes move as they please.
>>
>>> movement within the DODAG are restricted in favor of loop
>>> avoidance.
>>
>> Again, knowing one can't restrict node movement - this reads as if
>>  Author wished to restrict movement of a data structure - is it a
>> representation of a node in that data structure which moves?
>>
>>> 5.3.3.4. Rank and Movement within a DODAG Iteration
>>>
>>> 1.  A node MUST NOT advertise a rank less than or equal to any
>>> member of its parent set within the DODAG Iteration.
>>
>> Does Author intend to limit the contents of the packet the node
>> sends? (and not the node movement?).
>>
>>> o  Move down within the DODAG iteration (i.e. increase its rank)
>>
>> ...i.e. sending a _packet_ with an increased rank?
>>
>>> If a node is allowed to be greedy and attempts to move deeper
>>
>> (greedier would read as move higher, closer to the Parent, smaller
>>  Rank, and not deeper bigger Rank).
>>
>>> If a node needs to move down a DODAG that it is attached to,
>>> causing the rank to increase, then it MAY poison its routes and
>>> delay before moving as described in Section 5.3.3.5.
>>
>> Again, can't tell a node to delay its physical movement. It may
>> delay sending packets, but not its physical movement. Spec can't
>> pupetteer nodes if I can say so.
>>
>>>>> moving up will indicate that a node's rank is decreasing.
>>>>> Obviously this will not cause loops.
>>>>>
>>>>>>> except in the case where it is intended for the packet to
>>>>>>> change from an up to an down flow
>>>>>>
>>>>>> Packets shouldn't change whatever we do.  Or maybe I don't
>>>>>>  understand "up" and "down".
>>>>>>
>>>>>
>>>>> Think of this case you're packets are headed to a node that
>>>>> is in your own subtree.
>>>>
>>>> Trees?  YEs, please call them trees.  Why explaining in terms
>>>> of trees and writing in terms of graphs.
>>>>
>>>> Trees don't have this problem of edges being arrowed.
>>>>
>>>
>>> I should have used subgraph instead of subtree. Sorry for the
>>> complication here.
>>
>> What's a subgraph? I think we have a clear view of a tree but a
>> subgraph not...
>>
>>>>> However, you are not a storing node so all your point to
>>>>> point
>>>>
>>>> Point to point?  But I thought it was Acyclic?  Which point to
>>>>  which point?  Or do we tolerate cycles on a single link?
>>>>
>>>
>>> A link can still be bidirectional. Check out the below topology
>>> and the two cases that I describe below.
>>>
>>> Root /     \ A        B / C
>>
>> Ok, but this has nothing of a DAG, it's a pure rectilinear
>> topology, which, additionally - has 2 interfaces per node!
>> (limited features per node right?).
>>
>> DAGs have arrows on their edges. These arrows must mean something.
>> If I want to translate such an arrow in terms of entries in the
>> routing table then I imply there must be arrows in both directions
>> (there are routes both ways).  And if I put both arrows on every
>> link then I obviously no longer talk DAG...
>>
>> I don't understand the use of this DAG term overall. I find it an
>> unnecessary complication.
>>
>>> 1) If A tries to send a packet to B then it will go 'up' to the
>>> root and 'down' from the root to B.
>>
>> I agree, but where else could it go?
>>
>> Did Author intend to talk about Default routes instead of "Up"? If
>> yes then why don't we talk Default route throughout? It would be
>> much more meaningful to me.
>>
>>> 2) Assuming that A does not have storing capabilities and A
>>> wants to send a packet to C, one way of reaching C is by sending
>>> its packets 'up' to the root, let the root figure out that the
>>> route to C is "root->A->C", then pass the packet 'down' to A then
>>> let A pass it to C (using source routing). It's not a loop (so it
>>> is acyclic) but they are bidirectional links. That's why we have
>>> bits like the 'O bit' to distinguish different types of traffic.
>>
>> John - loops may form in an acyclic graph painted as above.
>> Suffices it for Root to forward packets back to A because it had
>> the wrong route.
>>
>> The image that each node has about the network could be qualified
>> as a DAG (if one absolutely wishes) but the topology of the nodes
>> is an arbitrary graph with arbitrary physical node movements.
>> Mixind the two is little understandable.
>>
>> I think the mindset of designing the protocol should change from
>> one where a God-like all-knowing central point dictates node
>> behaviour to a mindset where limits are reckoned and well defined,
>> if I can say so.
>>
>> Respectfully,
>>
>> Alex
>>
>
> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>
>


From jeonggil.ko@gmail.com  Fri Apr  9 16:58:22 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EE53A6A80 for ; Fri,  9 Apr 2010 16:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level: 
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhdAHUnjoPka for ; Fri,  9 Apr 2010 16:58:20 -0700 (PDT)
Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id D03383A69E3 for ; Fri,  9 Apr 2010 16:58:18 -0700 (PDT)
Received: by ywh38 with SMTP id 38so1909942ywh.29 for ; Fri, 09 Apr 2010 16:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=HJSjYa60HwQSQiHTLRusRsxHmE5yzDd9oW48C3QTYLU=; b=JDI0YqjyoDfp2HT5A8EfZoa4YxoVUMfr4NEeclQgRQEaIenN9w+TobOlgATEM7jqHV QReq9FCgvTf+p5/sCAr1/IMEodSJxQSyGBZdPmDDHp70ukOX2PYZS9kk4w3/SBcvqC4z Tkh4Q23+2eU8Bv/luLga1VqHN5Gtmsu/hurX0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=HUqOA/OWPT6J6D3pWmn4zOdXs0AxpRCzi4qSISaT29pTzPDxsCEtYasS5CFVXbEjc8 V0BuhMT/JZ+nInXDozeePJ5HtPoBbPm1EokD0DJC4P68MDhL/McsXx72ftITO/AY6zSn 9wmZNSKdQySoDpdRv7ZMxn1rv5I3I450+ZKKg=
Received: by 10.101.180.26 with SMTP id h26mr1248699anp.45.1270857492154; Fri, 09 Apr 2010 16:58:12 -0700 (PDT)
Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 22sm463407ywh.16.2010.04.09.16.58.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 16:58:11 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: "JeongGil Ko (John)" 
In-Reply-To: <4BBFB78D.4080801@gmail.com>
Date: Fri, 9 Apr 2010 16:58:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 09 Apr 2010 23:58:22 -0000

On Apr 9, 2010, at 4:26 PM, Alexandru Petrescu wrote:

> Le 10/04/2010 00:51, JeongGil Ko (John) a =E9crit :
>> A lot of points here so let me just try to summarize instead of
>> putting things in line.
>>=20
>> 1. The authors of the draft can better answer this but I don't think
>> the RPL draft even considers physical movements of nodes.
>=20
> Physical movements of nodes is in the RoLL requirements!
>=20
>> This (as far as I know) is out of the scope of what RPL is trying to
>> do. We are dealing with a physically stationary network (no node
>> mobility) and the movements of nodes just indicate the changes in the
>> rank values. So no 'restriction' of physical movement here.
>=20
> This is a complete misunderstanding.  I am not sure on whom part.
> Smiley.  RFC5826 to cite one has a section on mobility.
>=20
> If the nodes are fixed and don't move then why does the RPL say at =
several points prevent "movements"?  Is this a spec about moving data =
structures in graphs?  IF so then it's wrong, the spec should specify =
how the routers build their loop-free data structures.  No other routing =
protocol does.
>=20

You got me! Maybe I was misunderstanding the scope of RPL. But I still =
think that the "movements" that the draft talks about is only DAG =
connectivity changes (node changing to lower/higher ranks wrt the =
connectivity conditions or maybe this implies the physical movements as =
well?). Now you got me confused as well :) The authors should be the =
ones that can provide answers without any fuss. You and I arguing over =
what the draft is trying to mean is meaningless at this point without =
the help of the authors.

>> 2. I agree with you that some parts use 'move' for node level rank
>> changes and some parts use 'move' for packet exchanges and you
>> pointed out the parts correctly. But I don't think this is so
>> complex that one cannot understand what the draft is trying to say.
>> Still, this is a room for improvement in the draft.
>>=20
>> 3. For point to point traffic all the discussions until now have
>> shown that we can EITHER have a 'God-like all knowing' central node
>> (as you put it) OR nodes can separately save prefixes in their
>> sub-graphs. No need to change mindsets since here we just support
>> different modes.
>>=20
>> 4. If you assure that packets with the 'O bit' set to 0 will travel
>> 'up' (to lower rank nodes) and packets with 'O bit' set to 1 will
>> travel 'down' (to higher rank nodes) there should not be a loop
>> formed (at least theoretically).
>=20
> This is a wrong mindset on somebody's part.  Smiley.
>=20
> Loops can form up-down-up-down.
>=20
>> For the cases that the theory fails (crazy things can happen),
>> packets being forwarded must be checked if the forwarding of the
>> packet is valid or not (specs explicitly give you things to check
>> before forwarding a packet).
>=20
> I am not in synch with you about what it means to forward a packet.  =
To
> me the only thing a router must check before forwarding a packet are
> actually three: the dst field, the Hop Limit and the size.  No more no =
less, shouldn't modify that rule otherwise node can't connect to the =
Internet.
>=20
> The RPL spec should not check more than these.  If anything wrong in =
these fields then Router should use ICMP to inform the owner of the src =
field about wrong stuff, or hold on for a while and generate new packets =
for establishing routes.  It's as simple as that.
>=20
>> There are also cases where the packets can travel to siblings that
>> can cause loops but RPL limits the number of hops in such cases so
>> that the hop limit exceeds its threshold or an inconsistency is
>> detected if more than two siblings are used for packet forwarding
>> consecutively.
>=20
> How?  By modifying the Flow Label?  That shouldn't be done.
>=20

Yes. I was talking about the flow label modification. I sent out a =
question on the mailing list sometime ago about the issues of using the =
flow label and at that point this issue was still under discussion. I =
think the authors are already aware of the RFCs that these flow label =
modifications can violate.

John

>> 5. To my understanding (authors can correct me if I am wrong), the
>> DODAG (yes, the DAG) is 'directed' towards the root. So you are
>> definitely right about that. The links that make up the DODAG are
>> selected via DIO exchanges and the rank computation process.
>=20
> That computation process should be left out of this document.
>=20
> Why don't Authors use the existing methods for this?  Bellman-Ford =
Dijkstra guaranteed bullet-proof Internet scale.
>=20
> Alex
>=20
> RPL
>> just uses the bi-directional connectivity of wireless links (that
>> nodes get anyway) to perform other operations such as point to
>> multipoint and point to point. How do we select the links that are
>> 'directed' to individual nodes (other than the root)? Now that's a
>> totally new story that is still under discussion on the list ;) My
>> example below was a single case where source routing is used and the
>> network has a 'God-like all knowing' root node :)
>=20
>>=20
>> -John
>>=20
>> On Apr 9, 2010, at 3:21 PM, Alexandru Petrescu wrote:
>>=20
>>> Le 09/04/2010 20:07, JeongGil Ko (John) a =E9crit :
>>>>=20
>>>=20
>>>> On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:
>>>>=20
>>>>> Le 09/04/2010 19:41, JeongGil Ko (John) a =E9crit :
>>>>>> Hi!
>>>>>>=20
>>>>>> It might not be common but it is understandable.
>>>>>>=20
>>>>>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>>>>>=20
>>>>>>> I have a _very_ hard time grasping the redefinition of the
>>>>>>> simple word "up":
>>>>>>>=20
>>>>>>>> Up:   Up refers to the direction from leaf nodes towards
>>>>>>>> DODAG roots, following the orientation of the edges
>>>>>>>> within the DODAG.
>>>>>>>=20
>>>>>>> Redefinition of such a simple word is very dangerous
>>>>>>> because it easily leads to misunderstandings, like this
>>>>>>> one:
>>>>>>>=20
>>>>>>>> Movement entails changes to the DODAG parent set.
>>>>>>>> Moving up does not present the risk to create a loop but
>>>>>>>> moving down might, so that operation is subject to
>>>>>>>> additional constraints.
>>>>>>>=20
>>>>>>> Moving "up" what?? (I suppose packets to move "up", but not
>>>>>>> nodes to move "up").
>>>>>>>=20
>>>>>>=20
>>>>>> Since 'upwards' is the direction from leaf to root,
>>>>>=20
>>>>> Who moves "up"?  A packet or a node?
>>>>>=20
>>>>> What becomes "up" when leaf and root move and substitute each
>>>>> other?
>>>>>=20
>>>>=20
>>>> 'Movement' here should indicate changes in the rank values of a
>>>> node. This can be reflected as a change in topology, thus
>>>> 'movement' in the DODAG :) I think there was some discussion on
>>>> the list sometime ago on clarifying the term movement.
>>>=20
>>> I think the draft uses the term "move" to indicate various things
>>> which some times are _node_ movement other times _packet_
>>> movement.
>>>=20
>>> e.g. node movement:
>>>> Movement entails changes to the DODAG parent set.
>>> [...]
>>>> When a node moves to improve its position
>>>=20
>>> e.g. packet movement:
>>>> o A DODAG parent forwards a packet intended to move up,
>>>=20
>>> Additionally, whenever text tries to control physical movement on
>>> the node I think the Author had a difficult to understand mindset:
>>>=20
>>> [...]
>>>> In order to limit erratic movements, and all metrics being equal,
>>>> nodes SHOULD keep their previous selection.
>>>=20
>>> One can't limit erratic movements, nodes move as they please.
>>>=20
>>>> movement within the DODAG are restricted in favor of loop
>>>> avoidance.
>>>=20
>>> Again, knowing one can't restrict node movement - this reads as if
>>> Author wished to restrict movement of a data structure - is it a
>>> representation of a node in that data structure which moves?
>>>=20
>>>> 5.3.3.4. Rank and Movement within a DODAG Iteration
>>>>=20
>>>> 1.  A node MUST NOT advertise a rank less than or equal to any
>>>> member of its parent set within the DODAG Iteration.
>>>=20
>>> Does Author intend to limit the contents of the packet the node
>>> sends? (and not the node movement?).
>>>=20
>>>> o  Move down within the DODAG iteration (i.e. increase its rank)
>>>=20
>>> ...i.e. sending a _packet_ with an increased rank?
>>>=20
>>>> If a node is allowed to be greedy and attempts to move deeper
>>>=20
>>> (greedier would read as move higher, closer to the Parent, smaller
>>> Rank, and not deeper bigger Rank).
>>>=20
>>>> If a node needs to move down a DODAG that it is attached to,
>>>> causing the rank to increase, then it MAY poison its routes and
>>>> delay before moving as described in Section 5.3.3.5.
>>>=20
>>> Again, can't tell a node to delay its physical movement. It may
>>> delay sending packets, but not its physical movement. Spec can't
>>> pupetteer nodes if I can say so.
>>>=20
>>>>>> moving up will indicate that a node's rank is decreasing.
>>>>>> Obviously this will not cause loops.
>>>>>>=20
>>>>>>>> except in the case where it is intended for the packet to
>>>>>>>> change from an up to an down flow
>>>>>>>=20
>>>>>>> Packets shouldn't change whatever we do.  Or maybe I don't
>>>>>>> understand "up" and "down".
>>>>>>>=20
>>>>>>=20
>>>>>> Think of this case you're packets are headed to a node that
>>>>>> is in your own subtree.
>>>>>=20
>>>>> Trees?  YEs, please call them trees.  Why explaining in terms
>>>>> of trees and writing in terms of graphs.
>>>>>=20
>>>>> Trees don't have this problem of edges being arrowed.
>>>>>=20
>>>>=20
>>>> I should have used subgraph instead of subtree. Sorry for the
>>>> complication here.
>>>=20
>>> What's a subgraph? I think we have a clear view of a tree but a
>>> subgraph not...
>>>=20
>>>>>> However, you are not a storing node so all your point to
>>>>>> point
>>>>>=20
>>>>> Point to point?  But I thought it was Acyclic?  Which point to
>>>>> which point?  Or do we tolerate cycles on a single link?
>>>>>=20
>>>>=20
>>>> A link can still be bidirectional. Check out the below topology
>>>> and the two cases that I describe below.
>>>>=20
>>>> Root /     \ A        B / C
>>>=20
>>> Ok, but this has nothing of a DAG, it's a pure rectilinear
>>> topology, which, additionally - has 2 interfaces per node!
>>> (limited features per node right?).
>>>=20
>>> DAGs have arrows on their edges. These arrows must mean something.
>>> If I want to translate such an arrow in terms of entries in the
>>> routing table then I imply there must be arrows in both directions
>>> (there are routes both ways).  And if I put both arrows on every
>>> link then I obviously no longer talk DAG...
>>>=20
>>> I don't understand the use of this DAG term overall. I find it an
>>> unnecessary complication.
>>>=20
>>>> 1) If A tries to send a packet to B then it will go 'up' to the
>>>> root and 'down' from the root to B.
>>>=20
>>> I agree, but where else could it go?
>>>=20
>>> Did Author intend to talk about Default routes instead of "Up"? If
>>> yes then why don't we talk Default route throughout? It would be
>>> much more meaningful to me.
>>>=20
>>>> 2) Assuming that A does not have storing capabilities and A
>>>> wants to send a packet to C, one way of reaching C is by sending
>>>> its packets 'up' to the root, let the root figure out that the
>>>> route to C is "root->A->C", then pass the packet 'down' to A then
>>>> let A pass it to C (using source routing). It's not a loop (so it
>>>> is acyclic) but they are bidirectional links. That's why we have
>>>> bits like the 'O bit' to distinguish different types of traffic.
>>>=20
>>> John - loops may form in an acyclic graph painted as above.
>>> Suffices it for Root to forward packets back to A because it had
>>> the wrong route.
>>>=20
>>> The image that each node has about the network could be qualified
>>> as a DAG (if one absolutely wishes) but the topology of the nodes
>>> is an arbitrary graph with arbitrary physical node movements.
>>> Mixind the two is little understandable.
>>>=20
>>> I think the mindset of designing the protocol should change from
>>> one where a God-like all-knowing central point dictates node
>>> behaviour to a mindset where limits are reckoned and well defined,
>>> if I can say so.
>>>=20
>>> Respectfully,
>>>=20
>>> Alex
>>>=20
>>=20
>> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
>> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>>=20
>>=20
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From dat@exegin.com  Fri Apr  9 17:03:25 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF2528C0D6 for ; Fri,  9 Apr 2010 17:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofb3FQ48HqI1 for ; Fri,  9 Apr 2010 17:03:24 -0700 (PDT)
Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id BE2ED28C0D0 for ; Fri,  9 Apr 2010 17:03:24 -0700 (PDT)
Received: by pzk29 with SMTP id 29so3374431pzk.29 for ; Fri, 09 Apr 2010 17:03:18 -0700 (PDT)
Received: by 10.114.33.9 with SMTP id g9mr1365891wag.34.1270857798388; Fri, 09 Apr 2010 17:03:18 -0700 (PDT)
Received: from [172.16.1.52] (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 21sm1389506pzk.4.2010.04.09.17.03.17 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 17:03:17 -0700 (PDT)
Message-ID: <4BBFC036.1050208@exegin.com>
Date: Fri, 09 Apr 2010 17:03:02 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Roll] Sub-option Alignment
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 00:03:25 -0000

The [length] field in the first sub-option in a DIO message will not be 
aligned properly (as per IPv6 convention), unless a PAD1 is inserted 
after DAGID. Was this the original intention or an oversight?

One alternative to this, would be to change the DIO base header format 
to always include the OCP as a one byte field instead of having OCP as a 
sub-option. Of coarse, this won't fix alignment in subsequent options 
(due to [type] plus [length] being 3 bytes long), but at least we 
replace some padding with useful information.

I apologize if this has already been discussed. I've only found one 
archived thread on the matter, and it appears unresolved.
http://www.ietf.org/mail-archive/web/roll/current/msg02769.html

Regards
Dario Tedeschi

From alexandru.petrescu@gmail.com  Fri Apr  9 17:11:48 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A893A69E3 for ; Fri,  9 Apr 2010 17:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.023
X-Spam-Level: 
X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=1.226,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8zGfFeGPB4k for ; Fri,  9 Apr 2010 17:11:45 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A29D53A69CA for ; Fri,  9 Apr 2010 17:11:42 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 346ACD4805F; Sat, 10 Apr 2010 02:11:35 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 00274D48052; Sat, 10 Apr 2010 02:11:32 +0200 (CEST)
Message-ID: <4BBFC22C.4060407@gmail.com>
Date: Sat, 10 Apr 2010 02:11:24 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "JeongGil Ko (John)" 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 00:11:48 -0000

Le 10/04/2010 01:58, JeongGil Ko (John) a écrit :
>
> On Apr 9, 2010, at 4:26 PM, Alexandru Petrescu wrote:
>
>> Le 10/04/2010 00:51, JeongGil Ko (John) a écrit :
>>> A lot of points here so let me just try to summarize instead of
>>> putting things in line.
>>>
>>> 1. The authors of the draft can better answer this but I don't
>>> think the RPL draft even considers physical movements of nodes.
>>
>> Physical movements of nodes is in the RoLL requirements!
>>
>>> This (as far as I know) is out of the scope of what RPL is trying
>>> to do. We are dealing with a physically stationary network (no
>>> node mobility) and the movements of nodes just indicate the
>>> changes in the rank values. So no 'restriction' of physical
>>> movement here.
>>
>> This is a complete misunderstanding.  I am not sure on whom part.
>> Smiley.  RFC5826 to cite one has a section on mobility.
>>
>> If the nodes are fixed and don't move then why does the RPL say at
>> several points prevent "movements"?  Is this a spec about moving
>> data structures in graphs?  IF so then it's wrong, the spec should
>> specify how the routers build their loop-free data structures.  No
>> other routing protocol does.
>>
>
> You got me! Maybe I was misunderstanding the scope of RPL. But I
> still think that the "movements" that the draft talks about is only
> DAG connectivity changes (node changing to lower/higher ranks wrt the
> connectivity conditions or maybe this implies the physical movements
> as well?). Now you got me confused as well :) The authors should be
> the ones that can provide answers without any fuss. You and I arguing
> over what the draft is trying to mean is meaningless at this point
> without the help of the authors.

Yours and mine interpretations of the draft are needed, because this 
mirrors what people think about it.  The draft does not belong to 
authors it is for everyone else interested in it.  It is a WG item. 
Thanks for your remarks.

>>> 2. I agree with you that some parts use 'move' for node level
>>> rank changes and some parts use 'move' for packet exchanges and
>>> you pointed out the parts correctly. But I don't think this is
>>> so complex that one cannot understand what the draft is trying to
>>> say. Still, this is a room for improvement in the draft.
>>>
>>> 3. For point to point traffic all the discussions until now have
>>> shown that we can EITHER have a 'God-like all knowing' central
>>> node (as you put it) OR nodes can separately save prefixes in
>>> their sub-graphs. No need to change mindsets since here we just
>>> support different modes.
>>>
>>> 4. If you assure that packets with the 'O bit' set to 0 will
>>> travel 'up' (to lower rank nodes) and packets with 'O bit' set to
>>> 1 will travel 'down' (to higher rank nodes) there should not be a
>>> loop formed (at least theoretically).
>>
>> This is a wrong mindset on somebody's part.  Smiley.
>>
>> Loops can form up-down-up-down.
>>
>>> For the cases that the theory fails (crazy things can happen),
>>> packets being forwarded must be checked if the forwarding of the
>>> packet is valid or not (specs explicitly give you things to
>>> check before forwarding a packet).
>>
>> I am not in synch with you about what it means to forward a packet.
>> To me the only thing a router must check before forwarding a packet
>> are actually three: the dst field, the Hop Limit and the size.  No
>> more no less, shouldn't modify that rule otherwise node can't
>> connect to the Internet.
>>
>> The RPL spec should not check more than these.  If anything wrong
>> in these fields then Router should use ICMP to inform the owner of
>> the src field about wrong stuff, or hold on for a while and
>> generate new packets for establishing routes.  It's as simple as
>> that.
>>
>>> There are also cases where the packets can travel to siblings
>>> that can cause loops but RPL limits the number of hops in such
>>> cases so that the hop limit exceeds its threshold or an
>>> inconsistency is detected if more than two siblings are used for
>>> packet forwarding consecutively.
>>
>> How?  By modifying the Flow Label?  That shouldn't be done.
>>
>
> Yes. I was talking about the flow label modification. I sent out a
> question on the mailing list sometime ago about the issues of using
> the flow label and at that point this issue was still under
> discussion. I think the authors are already aware of the RFCs that
> these flow label modifications can violate.

Well that's good then.  Let's hope for the best.  I will wait and see 
how this evolves.

Alex

>
> John
>
>>> 5. To my understanding (authors can correct me if I am wrong),
>>> the DODAG (yes, the DAG) is 'directed' towards the root. So you
>>> are definitely right about that. The links that make up the DODAG
>>> are selected via DIO exchanges and the rank computation process.
>>
>> That computation process should be left out of this document.
>>
>> Why don't Authors use the existing methods for this?  Bellman-Ford
>> Dijkstra guaranteed bullet-proof Internet scale.
>>
>> Alex
>>
>> RPL
>>> just uses the bi-directional connectivity of wireless links
>>> (that nodes get anyway) to perform other operations such as point
>>> to multipoint and point to point. How do we select the links that
>>> are 'directed' to individual nodes (other than the root)? Now
>>> that's a totally new story that is still under discussion on the
>>> list ;) My example below was a single case where source routing
>>> is used and the network has a 'God-like all knowing' root node
>>> :)
>>
>>>
>>> -John
>>>
>>> On Apr 9, 2010, at 3:21 PM, Alexandru Petrescu wrote:
>>>
>>>> Le 09/04/2010 20:07, JeongGil Ko (John) a écrit :
>>>>>
>>>>
>>>>> On Apr 9, 2010, at 10:54 AM, Alexandru Petrescu wrote:
>>>>>
>>>>>> Le 09/04/2010 19:41, JeongGil Ko (John) a écrit :
>>>>>>> Hi!
>>>>>>>
>>>>>>> It might not be common but it is understandable.
>>>>>>>
>>>>>>> On Apr 9, 2010, at 10:28 AM, Alexandru Petrescu wrote:
>>>>>>>
>>>>>>>> I have a _very_ hard time grasping the redefinition of
>>>>>>>> the simple word "up":
>>>>>>>>
>>>>>>>>> Up:   Up refers to the direction from leaf nodes
>>>>>>>>> towards DODAG roots, following the orientation of the
>>>>>>>>> edges within the DODAG.
>>>>>>>>
>>>>>>>> Redefinition of such a simple word is very dangerous
>>>>>>>> because it easily leads to misunderstandings, like
>>>>>>>> this one:
>>>>>>>>
>>>>>>>>> Movement entails changes to the DODAG parent set.
>>>>>>>>> Moving up does not present the risk to create a loop
>>>>>>>>> but moving down might, so that operation is subject
>>>>>>>>> to additional constraints.
>>>>>>>>
>>>>>>>> Moving "up" what?? (I suppose packets to move "up", but
>>>>>>>> not nodes to move "up").
>>>>>>>>
>>>>>>>
>>>>>>> Since 'upwards' is the direction from leaf to root,
>>>>>>
>>>>>> Who moves "up"?  A packet or a node?
>>>>>>
>>>>>> What becomes "up" when leaf and root move and substitute
>>>>>> each other?
>>>>>>
>>>>>
>>>>> 'Movement' here should indicate changes in the rank values of
>>>>> a node. This can be reflected as a change in topology, thus
>>>>> 'movement' in the DODAG :) I think there was some discussion
>>>>> on the list sometime ago on clarifying the term movement.
>>>>
>>>> I think the draft uses the term "move" to indicate various
>>>> things which some times are _node_ movement other times
>>>> _packet_ movement.
>>>>
>>>> e.g. node movement:
>>>>> Movement entails changes to the DODAG parent set.
>>>> [...]
>>>>> When a node moves to improve its position
>>>>
>>>> e.g. packet movement:
>>>>> o A DODAG parent forwards a packet intended to move up,
>>>>
>>>> Additionally, whenever text tries to control physical movement
>>>> on the node I think the Author had a difficult to understand
>>>> mindset:
>>>>
>>>> [...]
>>>>> In order to limit erratic movements, and all metrics being
>>>>> equal, nodes SHOULD keep their previous selection.
>>>>
>>>> One can't limit erratic movements, nodes move as they please.
>>>>
>>>>> movement within the DODAG are restricted in favor of loop
>>>>> avoidance.
>>>>
>>>> Again, knowing one can't restrict node movement - this reads as
>>>> if Author wished to restrict movement of a data structure - is
>>>> it a representation of a node in that data structure which
>>>> moves?
>>>>
>>>>> 5.3.3.4. Rank and Movement within a DODAG Iteration
>>>>>
>>>>> 1.  A node MUST NOT advertise a rank less than or equal to
>>>>> any member of its parent set within the DODAG Iteration.
>>>>
>>>> Does Author intend to limit the contents of the packet the
>>>> node sends? (and not the node movement?).
>>>>
>>>>> o  Move down within the DODAG iteration (i.e. increase its
>>>>> rank)
>>>>
>>>> ...i.e. sending a _packet_ with an increased rank?
>>>>
>>>>> If a node is allowed to be greedy and attempts to move
>>>>> deeper
>>>>
>>>> (greedier would read as move higher, closer to the Parent,
>>>> smaller Rank, and not deeper bigger Rank).
>>>>
>>>>> If a node needs to move down a DODAG that it is attached to,
>>>>> causing the rank to increase, then it MAY poison its routes
>>>>> and delay before moving as described in Section 5.3.3.5.
>>>>
>>>> Again, can't tell a node to delay its physical movement. It
>>>> may delay sending packets, but not its physical movement. Spec
>>>> can't pupetteer nodes if I can say so.
>>>>
>>>>>>> moving up will indicate that a node's rank is
>>>>>>> decreasing. Obviously this will not cause loops.
>>>>>>>
>>>>>>>>> except in the case where it is intended for the
>>>>>>>>> packet to change from an up to an down flow
>>>>>>>>
>>>>>>>> Packets shouldn't change whatever we do.  Or maybe I
>>>>>>>> don't understand "up" and "down".
>>>>>>>>
>>>>>>>
>>>>>>> Think of this case you're packets are headed to a node
>>>>>>> that is in your own subtree.
>>>>>>
>>>>>> Trees?  YEs, please call them trees.  Why explaining in
>>>>>> terms of trees and writing in terms of graphs.
>>>>>>
>>>>>> Trees don't have this problem of edges being arrowed.
>>>>>>
>>>>>
>>>>> I should have used subgraph instead of subtree. Sorry for
>>>>> the complication here.
>>>>
>>>> What's a subgraph? I think we have a clear view of a tree but
>>>> a subgraph not...
>>>>
>>>>>>> However, you are not a storing node so all your point to
>>>>>>> point
>>>>>>
>>>>>> Point to point?  But I thought it was Acyclic?  Which point
>>>>>> to which point?  Or do we tolerate cycles on a single
>>>>>> link?
>>>>>>
>>>>>
>>>>> A link can still be bidirectional. Check out the below
>>>>> topology and the two cases that I describe below.
>>>>>
>>>>> Root /     \ A        B / C
>>>>
>>>> Ok, but this has nothing of a DAG, it's a pure rectilinear
>>>> topology, which, additionally - has 2 interfaces per node!
>>>> (limited features per node right?).
>>>>
>>>> DAGs have arrows on their edges. These arrows must mean
>>>> something. If I want to translate such an arrow in terms of
>>>> entries in the routing table then I imply there must be arrows
>>>> in both directions (there are routes both ways).  And if I put
>>>> both arrows on every link then I obviously no longer talk
>>>> DAG...
>>>>
>>>> I don't understand the use of this DAG term overall. I find it
>>>> an unnecessary complication.
>>>>
>>>>> 1) If A tries to send a packet to B then it will go 'up' to
>>>>> the root and 'down' from the root to B.
>>>>
>>>> I agree, but where else could it go?
>>>>
>>>> Did Author intend to talk about Default routes instead of "Up"?
>>>> If yes then why don't we talk Default route throughout? It
>>>> would be much more meaningful to me.
>>>>
>>>>> 2) Assuming that A does not have storing capabilities and A
>>>>> wants to send a packet to C, one way of reaching C is by
>>>>> sending its packets 'up' to the root, let the root figure out
>>>>> that the route to C is "root->A->C", then pass the packet
>>>>> 'down' to A then let A pass it to C (using source routing).
>>>>> It's not a loop (so it is acyclic) but they are bidirectional
>>>>> links. That's why we have bits like the 'O bit' to
>>>>> distinguish different types of traffic.
>>>>
>>>> John - loops may form in an acyclic graph painted as above.
>>>> Suffices it for Root to forward packets back to A because it
>>>> had the wrong route.
>>>>
>>>> The image that each node has about the network could be
>>>> qualified as a DAG (if one absolutely wishes) but the topology
>>>> of the nodes is an arbitrary graph with arbitrary physical node
>>>> movements. Mixind the two is little understandable.
>>>>
>>>> I think the mindset of designing the protocol should change
>>>> from one where a God-like all-knowing central point dictates
>>>> node behaviour to a mindset where limits are reckoned and well
>>>> defined, if I can say so.
>>>>
>>>> Respectfully,
>>>>
>>>> Alex
>>>>
>>>
>>> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
>>> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>>>
>>>
>>
>
> ------ JeongGil Ko (John) Ph.D. Student Department of Computer
> Science Johns Hopkins University http://www.cs.jhu.edu/~jgko
>
>


From pal@cs.stanford.edu  Fri Apr  9 17:16:49 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96FD3A6A82 for ; Fri,  9 Apr 2010 17:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.449,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0AHU0LrZKCd for ; Fri,  9 Apr 2010 17:16:47 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A4D103A69E3 for ; Fri,  9 Apr 2010 17:16:46 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O0ONO-0004i7-H6; Fri, 09 Apr 2010 17:16:42 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-493626058
From: Philip Levis 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
Date: Fri, 9 Apr 2010 17:16:42 -0700
Message-Id: <7D65A3EB-4011-405A-9B4E-4C49C55CC186@cs.stanford.edu>
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com> <4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>
To: Pascal Thubert (pthubert) 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: 1620fcb02ed1792cf65161168a9fe1e9
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Formatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 00:16:50 -0000

--Apple-Mail-1-493626058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 9, 2010, at 1:35 AM, Pascal Thubert (pthubert) wrote:

> I read this as a consensus to use tags J If anyone disagree please =
speak up now!
> =20
> There have been plenty iterations/versions of tagging since Frame =
Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s tag =
switching and MPLS. More often than not, a combination of the 2 models =
is used so that tags can be both swapped and stacked.

I think it is very dangerous to start from examples in the wired domain. =
The long history of wireless research has shown that doing so typically =
leads to big problems. We should start from the deployed, working =
examples in the wireless domain.

Phil=

--Apple-Mail-1-493626058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


    On Apr 9, 2010, at 1:35 AM, Pascal =
Thubert (pthubert) wrote:

    I read this as a consensus to use tags J If anyone disagree please =
speak up now!
     
    There have been plenty =
iterations/versions of tagging since Frame Relay (pure switching), IBM=92s=
 HPR (pure source route), Cisco=92s tag switching and MPLS. More often =
than not, a combination of the 2 models is used so that tags can be both =
swapped and =
stacked.

    =

    I think it is very dangerous to start from examples in the wired =
domain. The long history of wireless research has shown that doing so =
typically leads to big problems. We should start from the deployed, =
working examples in the wireless =
domain.

    Phil
    =

--Apple-Mail-1-493626058--

From pal@cs.stanford.edu  Fri Apr  9 17:21:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F3C3A6A50 for ; Fri,  9 Apr 2010 17:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level: 
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ld8wlAuZv5 for ; Fri,  9 Apr 2010 17:20:56 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D57E13A69CA for ; Fri,  9 Apr 2010 17:20:54 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O0ORP-0008I2-3J; Fri, 09 Apr 2010 17:20:51 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <4BBFB419.10905@gmail.com>
Date: Fri, 9 Apr 2010 17:20:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4BBFB419.10905@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 00:21:03 -0000

On Apr 9, 2010, at 4:11 PM, Alexandru Petrescu wrote:

> Flow Labels are wrongly used.
>=20
> First they're wrongly represented:
>=20
>>  RPL loop detection uses information that is placed into the packet =
in
>>   the IPv6 flow label.  The IPv6 flow label is defined in [RFC2460] =
and
>>   its operation is further specified in [RFC3697].  For the purpose =
of
>>   RPL operations, the flow label is constructed as follows:
>>=20
>>=20
>>        0                   1                   2
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>               |O|S|R|F|  SenderRank   | RPLInstanceID |
>>               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> What are the first 4 bits? The diagram in rfc2460 shows 32bit wide =
with
> the rightmost 20bits as the flow label, whereas the above diagram =
shows
> 24bit wide.
>=20
> Second, the flow label MUST NOT be modified en-route by any router. =
Or,
> RPL says:
>> A router sets the 'O' bit when the packet is expect to progress down
>> (using DAO routes), and resets it when forwarding towards the root of
>> the DODAG iteration.   A host MUST set the bit to 0.
>=20
> If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
> intermediary Routers must not modify it, RFC3697:
>> The Flow Label value set by the source MUST be delivered unchanged
>> to the destination node(s).
>=20
> The risk of not doing so is obvious: the communication between a Host =
in
> the RoLL network and a host in the Internet and relying on Flow Labels
> as RFC3697 - will be broken.
>=20
> I like Flow Labels as Appendix A of rfc2460 I like it. It's not =
intended
> to establish routing paths IMHO.
>=20
> If one needs intermediary routers to modify stuff going through them
> then better encapsulate, or at an extreme write new packets (like when
> using RSVP, or when triggering route setup like Triggered RIP, or =
DYMO)
> - but don't modify RFC2460 headers of packets not intended to self!
> (other than exceptions like RH, or decrement the Hop Limit obviously).
> The mutation of fields in the IPv6 headers is very dangerous breaks
> things. Smiley.
>=20

Alex,

As has been discussed many times on the list recently, the flow label =
approach is being replaced with a hop-by-hop header. Packets originating =
from within a RPL network MAY encode the instance ID within the flow =
label, but if they do not the instance ID will be in the proposed RPL =
hop-by-hop header.

Phil=

From Matteo.Paris@ember.com  Fri Apr  9 17:29:25 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108F93A68FC for ; Fri,  9 Apr 2010 17:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRFhy1+gKg48 for ; Fri,  9 Apr 2010 17:29:24 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1BA6F3A67D7 for ; Fri,  9 Apr 2010 17:29:24 -0700 (PDT)
Received: from [192.168.1.106] ([192.168.90.85]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 20:32:20 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4BBFC036.1050208@exegin.com>
References: <4BBFC036.1050208@exegin.com>
Date: Fri, 9 Apr 2010 20:29:18 -0400
To: roll@ietf.org
From: Matteo Paris 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-OriginalArrivalTime: 10 Apr 2010 00:32:20.0875 (UTC) FILETIME=[482D45B0:01CAD845]
Subject: Re: [Roll] Sub-option Alignment
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 00:29:25 -0000

I believe it has been observed before that the length field should be 
one byte, which would address your alignment concerns.  If RPL 
requires suboptions longer than 255 bytes, we are in trouble.  Does 
anybody object to changing this in the next rpl draft?

Matteo


At 5:03 PM -0700 4/9/10, Dario Tedeschi wrote:
>The [length] field in the first sub-option in a DIO message will not 
>be aligned properly (as per IPv6 convention), unless a PAD1 is 
>inserted after DAGID. Was this the original intention or an 
>oversight?
>
>One alternative to this, would be to change the DIO base header 
>format to always include the OCP as a one byte field instead of 
>having OCP as a sub-option. Of coarse, this won't fix alignment in 
>subsequent options (due to [type] plus [length] being 3 bytes long), 
>but at least we replace some padding with useful information.
>
>I apologize if this has already been discussed. I've only found one 
>archived thread on the matter, and it appears unresolved.
>http://www.ietf.org/mail-archive/web/roll/current/msg02769.html
>
>Regards
>Dario Tedeschi
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


From jhui@archrock.com  Fri Apr  9 18:49:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4893A681C for ; Fri,  9 Apr 2010 18:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwfMcd8BzqxU for ; Fri,  9 Apr 2010 18:49:25 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4D9053A67C2 for ; Fri,  9 Apr 2010 18:49:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8BF1FAF834; Fri,  9 Apr 2010 18:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyt9U7bYkC8S; Fri,  9 Apr 2010 18:49:17 -0700 (PDT)
Received: from [10.0.1.5] (adsl-71-142-75-17.dsl.pltn13.pacbell.net [71.142.75.17]) by mail.sf.archrock.com (Postfix) with ESMTP id 70CF2AF81E; Fri,  9 Apr 2010 18:49:17 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: Alexandru Petrescu 
In-Reply-To: <4BBFB419.10905@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Apr 2010 18:49:15 -0700
References: <4BBFB419.10905@gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 01:49:26 -0000

Hi Alex,

This issue was document months ago as Ticket #21.  We are working on  
moving the information into a IPv6 Hop-by-Hop Option.  A draft that  
requests and documents the RPL option was posted and presented at the  
6man WG meeting in Anaheim.

--
Jonathan Hui


On Apr 9, 2010, at 4:11 PM, Alexandru Petrescu wrote:

> Flow Labels are wrongly used.
>
> First they're wrongly represented:
>
>>  RPL loop detection uses information that is placed into the packet  
>> in
>>   the IPv6 flow label.  The IPv6 flow label is defined in [RFC2460]  
>> and
>>   its operation is further specified in [RFC3697].  For the purpose  
>> of
>>   RPL operations, the flow label is constructed as follows:
>>
>>
>>        0                   1                   2
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>               |O|S|R|F|  SenderRank   | RPLInstanceID |
>>               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> What are the first 4 bits? The diagram in rfc2460 shows 32bit wide  
> with
> the rightmost 20bits as the flow label, whereas the above diagram  
> shows
> 24bit wide.
>
> Second, the flow label MUST NOT be modified en-route by any router.  
> Or,
> RPL says:
>> A router sets the 'O' bit when the packet is expect to progress down
>> (using DAO routes), and resets it when forwarding towards the root of
>> the DODAG iteration.   A host MUST set the bit to 0.
>
> If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
> intermediary Routers must not modify it, RFC3697:
>> The Flow Label value set by the source MUST be delivered unchanged
>> to the destination node(s).
>
> The risk of not doing so is obvious: the communication between a  
> Host in
> the RoLL network and a host in the Internet and relying on Flow Labels
> as RFC3697 - will be broken.
>
> I like Flow Labels as Appendix A of rfc2460 I like it. It's not  
> intended
> to establish routing paths IMHO.
>
> If one needs intermediary routers to modify stuff going through them
> then better encapsulate, or at an extreme write new packets (like when
> using RSVP, or when triggering route setup like Triggered RIP, or  
> DYMO)
> - but don't modify RFC2460 headers of packets not intended to self!
> (other than exceptions like RH, or decrement the Hop Limit obviously).
> The mutation of fields in the IPv6 headers is very dangerous breaks
> things. Smiley.
>
> Alex
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From pthubert@cisco.com  Sat Apr 10 02:58:32 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE693A67FB for ; Sat, 10 Apr 2010 02:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.34
X-Spam-Level: 
X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=-2.741,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M236DbMzNN1x for ; Sat, 10 Apr 2010 02:58:32 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A2F513A67A5 for ; Sat, 10 Apr 2010 02:58:31 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsBAMPov0uQ/uCWe2dsb2JhbACbQxUBAQsLIgYcn0eZIYUKBA
X-IronPort-AV: E=Sophos;i="4.52,181,1270425600";  d="scan'208";a="5409741"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2010 09:22:54 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3A9wQj8006468; Sat, 10 Apr 2010 09:58:26 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 10 Apr 2010 11:58:25 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 10 Apr 2010 11:58:20 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com>
In-Reply-To: <4BBF655D.1020807@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
Thread-Index: AcrYCxJWNivjK0GHS02OybJFMyBaMgAiMWLA
References: <4BBF655D.1020807@gmail.com>
From: "Pascal Thubert (pthubert)" 
To: "Alexandru Petrescu" , "ROLL WG" 
X-OriginalArrivalTime: 10 Apr 2010 09:58:25.0878 (UTC) FILETIME=[5CE56F60:01CAD894]
Subject: Re: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 09:58:32 -0000

Alex,

the root has no edge in such instance where it is root. Yet it might
participate to other instances where it is not root, other routing
protocols, or simply have a static default route towards an access
router.
Redistribution rules such as strict ordering of instances and protocols
avoid loops.

Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Alexandru Petrescu
> Sent: Friday, April 09, 2010 7:35 PM
> To: ROLL WG
> Subject: [Roll] Is the DAG Root a Host? Can it send packets "down"?
>=20
> >    Down 'O' bit:  1-bit flag indicating whether the packet is
expected
> >          to progress up or down.  A router sets the 'O' bit when the
> >          packet is expect to progress down (using DAO routes), and
> >          resets it when forwarding towards the root of the DODAG
> >          iteration.  A host MUST set the bit to 0.
>=20
> Is the DAG Root a Host?  I guess so, because it has no outgoing edge.
> If it's a Host it means it can't send packets "down" (MUST set the O
bit to 0,
> up).  If it can't send packets down then there's a problem because it
can't
> send queries.
>=20
> Or am I missing something.
>=20
> Alex
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From alexandru.petrescu@gmail.com  Sat Apr 10 04:12:06 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F973A6A1F for ; Sat, 10 Apr 2010 04:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_20=-0.74, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVPr7NwLOWCc for ; Sat, 10 Apr 2010 04:12:05 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 635C63A6A1A for ; Sat, 10 Apr 2010 04:11:26 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 1DFADD48129; Sat, 10 Apr 2010 13:11:18 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id E5FB8D4814A; Sat, 10 Apr 2010 13:11:15 +0200 (CEST)
Message-ID: <4BC05CCB.5040009@gmail.com>
Date: Sat, 10 Apr 2010 13:11:07 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Philip Levis 
References: <4BBFB419.10905@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 11:12:08 -0000

Le 10/04/2010 02:20, Philip Levis a écrit :
>
> On Apr 9, 2010, at 4:11 PM, Alexandru Petrescu wrote:
>
>> Flow Labels are wrongly used.
>>
>> First they're wrongly represented:
>>
>>> RPL loop detection uses information that is placed into the
>>> packet in the IPv6 flow label.  The IPv6 flow label is defined
>>> in [RFC2460] and its operation is further specified in
>>> [RFC3697]. For the purpose of RPL operations, the flow label is
>>> constructed as follows:
>>>
>>>
>>> 0                   1                   2 0 1 2 3 4 5 6 7 8 9 0
>>> 1 2 3 4 5 6 7 8 9 0 1 2 3
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|S|R|F|
>>> SenderRank   | RPLInstanceID |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> What are the first 4 bits? The diagram in rfc2460 shows 32bit wide
>> with the rightmost 20bits as the flow label, whereas the above
>> diagram shows 24bit wide.
>>
>> Second, the flow label MUST NOT be modified en-route by any
>> router. Or, RPL says:
>>> A router sets the 'O' bit when the packet is expect to progress
>>> down (using DAO routes), and resets it when forwarding towards
>>> the root of the DODAG iteration.   A host MUST set the bit to 0.
>>
>> If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
>>  intermediary Routers must not modify it, RFC3697:
>>> The Flow Label value set by the source MUST be delivered
>>> unchanged to the destination node(s).
>>
>> The risk of not doing so is obvious: the communication between a
>> Host in the RoLL network and a host in the Internet and relying on
>> Flow Labels as RFC3697 - will be broken.
>>
>> I like Flow Labels as Appendix A of rfc2460 I like it. It's not
>> intended to establish routing paths IMHO.
>>
>> If one needs intermediary routers to modify stuff going through
>> them then better encapsulate, or at an extreme write new packets
>> (like when using RSVP, or when triggering route setup like
>> Triggered RIP, or DYMO) - but don't modify RFC2460 headers of
>> packets not intended to self! (other than exceptions like RH, or
>> decrement the Hop Limit obviously). The mutation of fields in the
>> IPv6 headers is very dangerous breaks things. Smiley.
>>
>
> Alex,
>
> As has been discussed many times on the list recently,

Phil - I can't seem to find that discussion.  I have archives only since
january 2010... I consider that recent enough.

> the flow label approach is being replaced with a hop-by-hop header.

The HbH (Hop-by-Hop) header can't be modified en-route either.  I hope 
Authors don't either.

> Packets originating from within a RPL network MAY encode the instance
> ID within the flow label, but if they do not the instance ID will be
> in the proposed RPL hop-by-hop header.

The important thing is to not require the intermediary RPL routers to 
modify these fields.

I am afraid one can't simply substitute the use of HbH for Flow Labels 
because the semantics described in the draft involve modifying the 
fields (e.g. the 'O' oh bit) by the routers forwarding packets, which is 
wrong.

The HbH use I know is in the Router Alert option RFC2711 and used in 
MLDv2 RFC3810.  These don't modify en route any field in the HbH.

Alex

>
> Phil


From alexandru.petrescu@gmail.com  Sat Apr 10 04:32:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011433A6817 for ; Sat, 10 Apr 2010 04:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Level: 
X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=0.264,  BAYES_05=-1.11, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNrdzg1lYIUL for ; Sat, 10 Apr 2010 04:32:07 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4A3D73A6994 for ; Sat, 10 Apr 2010 04:31:58 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id BA770D48054; Sat, 10 Apr 2010 13:31:51 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id AA591D480CC; Sat, 10 Apr 2010 13:31:48 +0200 (CEST)
Message-ID: <4BC0619C.90506@gmail.com>
Date: Sat, 10 Apr 2010 13:31:40 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jonathan Hui 
References: <4BBFB419.10905@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 11:32:08 -0000

Le 10/04/2010 03:49, Jonathan Hui a écrit :
>
> Hi Alex,
>
> This issue was document months ago as Ticket #21.

Jonathan, Ticket #21 simpy says "RPL control Bits in flow Label[...] A
decision has to be made on whether the control bits of RPL currently
specified in the Flow Label should be moved to a newly defined IPv6
extended header."

This doesn't say what the issue is.

It doesn't say HbH header.

I am not happy with this Ticket #21.

> We are working on moving the information into a IPv6 Hop-by-Hop
> Option. A draft that requests and documents the RPL option was posted
> and presented at the 6man WG meeting in Anaheim.

Ok, I read the slides and the jabber log.

Nobody seemed to ask about you modifying the HbH option en-route.  I
hope you don't, I haven't seen it elsewhere before, requires additional
per-packet processing by intermediary routers.

If your (author's) problem is to update the routing state upon arrival
of a packet which you don't have a route for then consider a use similar
to what Triggered RIP does, or similar to what DYMO and MANET
"on-demand" semantics do: hold the packet and generate new packets for
route update.

Moving encoding from Flow Label to HbH doesn't solve your fundamental
problem - which btw we haven't discussed.

The slide at
http://www.ietf.org/proceedings/10mar/slides/6man-7.pdf
says the problem is "How to manage control overhead with reactivity to
link state changes?".  The answer to that is simple: use link-state
protocols like OSPF.

slide says solution is:
> Slow proactive process - allow routing inconsistencies

Link-state protocols propagate route updates immediately upon change of
link states (hence the name) - that is as fast as it could get.

> Include routing info in data-plane packets to detect inconsistencies

No, please don't modify data-plane packets on the fly("data-plane" is
payload I believe).  Besides, if a packet arrives at a router which
doesn't know where to forward then no amount of additional data in the
packet will help find a way.

> React to inconsistencies when routes are used

This I don't understand.  Routes are always used aren't they.

Reacting to inconsistencies in the internal routing database happens
whenever a new route update is received, not when an application data is
received.  Each time a route update is received a new computation on the
table is performed and eventually send new updates.  Reacting to updates
is easy.  What's difficult is convergence time, but that doesn't depend
on the piggybacked data - it depends mostly on the number of nodes and
the number of links.

For some reason I dislike this approach of piggybacking routing
information in data packets, makes not much sense to me.  IMHO and a smiley.

Alex

>
> -- Jonathan Hui
>
>
> On Apr 9, 2010, at 4:11 PM, Alexandru Petrescu wrote:
>
>> Flow Labels are wrongly used.
>>
>> First they're wrongly represented:
>>
>>> RPL loop detection uses information that is placed into the
>>> packet in the IPv6 flow label. The IPv6 flow label is defined in
>>>  [RFC2460] and its operation is further specified in [RFC3697].
>>> For the purpose of RPL operations, the flow label is constructed
>>>  as follows:
>>>
>>>
>>> 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|S|R|F|
>>> SenderRank | RPLInstanceID |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> What are the first 4 bits? The diagram in rfc2460 shows 32bit wide
>>  with the rightmost 20bits as the flow label, whereas the above
>> diagram shows 24bit wide.
>>
>> Second, the flow label MUST NOT be modified en-route by any router.
>> Or, RPL says:
>>> A router sets the 'O' bit when the packet is expect to progress
>>> down (using DAO routes), and resets it when forwarding towards
>>> the root of the DODAG iteration. A host MUST set the bit to 0.
>>
>> If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
>> intermediary Routers must not modify it, RFC3697:
>>> The Flow Label value set by the source MUST be delivered
>>> unchanged to the destination node(s).
>>
>> The risk of not doing so is obvious: the communication between a
>> Host in the RoLL network and a host in the Internet and relying on
>>  Flow Labels as RFC3697 - will be broken.
>>
>> I like Flow Labels as Appendix A of rfc2460 I like it. It's not
>> intended to establish routing paths IMHO.
>>
>> If one needs intermediary routers to modify stuff going through
>> them then better encapsulate, or at an extreme write new packets
>> (like when using RSVP, or when triggering route setup like
>> Triggered RIP, or DYMO) - but don't modify RFC2460 headers of
>> packets not intended to self! (other than exceptions like RH, or
>> decrement the Hop Limit obviously). The mutation of fields in the
>> IPv6 headers is very dangerous breaks things. Smiley.
>>
>> Alex
>>
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>


From alexandru.petrescu@gmail.com  Sat Apr 10 04:35:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F7D3A6817 for ; Sat, 10 Apr 2010 04:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.344
X-Spam-Level: 
X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_20=-0.74, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAGUev9khn-L for ; Sat, 10 Apr 2010 04:35:26 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id C42723A6982 for ; Sat, 10 Apr 2010 04:35:23 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4185AD4801C; Sat, 10 Apr 2010 13:35:15 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id ED0B9D480B9; Sat, 10 Apr 2010 13:35:12 +0200 (CEST)
Message-ID: <4BC06268.5090501@gmail.com>
Date: Sat, 10 Apr 2010 13:35:04 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
References: <4BBF655D.1020807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 11:35:27 -0000

Le 10/04/2010 11:58, Pascal Thubert (pthubert) a écrit :
> Alex,
>
> the root has no edge in such instance where it is root. Yet it might
> participate to other instances where it is not root, other routing
> protocols, or simply have a static default route towards an access
> router. Redistribution rules such as strict ordering of instances and
> protocols avoid loops.

Pascal - I have a hard time trying to understand what you mean.

A root has no edge?  It has no link?  No interface?

Protocols avoid loops?  I don't think so.  It's not the communication 
protocol which avoid loop creation, but the local computation of the 
route database (within each node) which makes sure that the view of the 
network at each node is loop-free.  PRotocols simply exchange data.

We have such different views on this...

Alex

>
> Pascal
>
>> -----Original Message----- From: roll-bounces@ietf.org
>> [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> Alexandru Petrescu Sent: Friday, April 09, 2010 7:35 PM To: ROLL
>> WG Subject: [Roll] Is the DAG Root a Host? Can it send packets
>> "down"?
>>
>>> Down 'O' bit:  1-bit flag indicating whether the packet is
> expected
>>> to progress up or down.  A router sets the 'O' bit when the
>>> packet is expect to progress down (using DAO routes), and resets
>>> it when forwarding towards the root of the DODAG iteration.  A
>>> host MUST set the bit to 0.
>>
>> Is the DAG Root a Host?  I guess so, because it has no outgoing
>> edge. If it's a Host it means it can't send packets "down" (MUST
>> set the O
> bit to 0,
>> up).  If it can't send packets down then there's a problem because
>> it
> can't
>> send queries.
>>
>> Or am I missing something.
>>
>> Alex
>>
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>


From alexandru.petrescu@gmail.com  Sat Apr 10 04:38:29 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6143A69AA for ; Sat, 10 Apr 2010 04:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Level: 
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[AWL=-0.330,  BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWcVNFE6Qz4S for ; Sat, 10 Apr 2010 04:38:28 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5EF023A6817 for ; Sat, 10 Apr 2010 04:38:26 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 62E4BD48106 for ; Sat, 10 Apr 2010 13:38:19 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 6CD74D48070 for ; Sat, 10 Apr 2010 13:38:17 +0200 (CEST)
Message-ID: <4BC06320.70700@gmail.com>
Date: Sat, 10 Apr 2010 13:38:08 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4BBFC036.1050208@exegin.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [Roll] Sub-option Alignment
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 11:38:29 -0000

Le 10/04/2010 02:29, Matteo Paris a écrit :
>
> I believe it has been observed before that the length field should be
> one byte, which would address your alignment concerns. If RPL requires
> suboptions longer than 255 bytes, we are in trouble. Does anybody object
> to changing this in the next rpl draft?

I strongly support using padding as usual is used for IPv6 - it helps 
implementer a lot.

Alex

>
> Matteo
>
>
> At 5:03 PM -0700 4/9/10, Dario Tedeschi wrote:
>> The [length] field in the first sub-option in a DIO message will not
>> be aligned properly (as per IPv6 convention), unless a PAD1 is
>> inserted after DAGID. Was this the original intention or an oversight?
>>
>> One alternative to this, would be to change the DIO base header format
>> to always include the OCP as a one byte field instead of having OCP as
>> a sub-option. Of coarse, this won't fix alignment in subsequent
>> options (due to [type] plus [length] being 3 bytes long), but at least
>> we replace some padding with useful information.
>>
>> I apologize if this has already been discussed. I've only found one
>> archived thread on the matter, and it appears unresolved.
>> http://www.ietf.org/mail-archive/web/roll/current/msg02769.html
>>
>> Regards
>> Dario Tedeschi
>> _______________________________________________
>> 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 cabo@tzi.org  Sat Apr 10 04:40:41 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6B43A688B for ; Sat, 10 Apr 2010 04:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.692
X-Spam-Level: 
X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.557,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJiDgWeR3UVU for ; Sat, 10 Apr 2010 04:40:39 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D954D3A6817 for ; Sat, 10 Apr 2010 04:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o3ABeOAY004700; Sat, 10 Apr 2010 13:40:24 +0200 (CEST)
Received: from [192.168.217.101] (p5489CF74.dip.t-dialin.net [84.137.207.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 249BFECCF;  Sat, 10 Apr 2010 13:40:24 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <4BC05CCB.5040009@gmail.com>
Date: Sat, 10 Apr 2010 13:40:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 11:40:41 -0000

On Apr 10, 2010, at 13:11, Alexandru Petrescu wrote:

> The HbH (Hop-by-Hop) header can't be modified en-route either.

Why do you think so?

E.g., section 4.2 of RFC 2460 provides a bit for the option number to =
indicate one of:

      0 - Option Data does not change en-route
      1 - Option Data may change en-route

Jonathan's draft correctly sets this bit by suggesting this option =
value:

   HEX         act  chg  rest
   ---         ---  ---  -----
     1          00    1  01011

(See also RFC 4302 on the interaction of mutable fields with AH =
headers.)

Gruesse, Carsten


From alexandru.petrescu@gmail.com  Sat Apr 10 05:06:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C923A67D2 for ; Sat, 10 Apr 2010 05:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.054
X-Spam-Level: 
X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=-0.297,  BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBWcyxgIPH74 for ; Sat, 10 Apr 2010 05:06:06 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 90E683A683E for ; Sat, 10 Apr 2010 05:06:02 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 21E5BD4805C; Sat, 10 Apr 2010 14:05:54 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id BFC63D480D9; Sat, 10 Apr 2010 14:05:51 +0200 (CEST)
Message-ID: <4BC06997.8010703@gmail.com>
Date: Sat, 10 Apr 2010 14:05:43 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Carsten Bormann 
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100409-1, 09/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 12:06:07 -0000

Le 10/04/2010 13:40, Carsten Bormann a écrit :
> On Apr 10, 2010, at 13:11, Alexandru Petrescu wrote:
>
>> The HbH (Hop-by-Hop) header can't be modified en-route either.
>
> Why do you think so?

Because I've never seen it - this is the first time.  MLDv2 employs HbH 
with immutable options.

MIPv6 uses DO headers - also immutable.

I don't understand why you want to use another header than the ICMP 
already defined in RPL.

> E.g., section 4.2 of RFC 2460 provides a bit for the option number to indicate one of:
>
>        0 - Option Data does not change en-route
>        1 - Option Data may change en-route

Ah!  Is there some other RFC where a HbH uses an option changed en-route?

> Jonathan's draft correctly sets this bit by suggesting this option value:
>
>     HEX         act  chg  rest
>     ---         ---  ---  -----
>       1          00    1  01011
>
> (See also RFC 4302 on the interaction of mutable fields with AH headers.)

Right... AH will ignore the mutable fields.  Which means the heart of 
the RPL protocol is insecure...  should say that upfront somewhere.

Alex

>
> Gruesse, Carsten
>
>


From cabo@tzi.org  Sat Apr 10 07:18:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACBB3A6853 for ; Sat, 10 Apr 2010 07:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.803
X-Spam-Level: 
X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.446,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMzMNc0SGgWP for ; Sat, 10 Apr 2010 07:18:07 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 47FB73A67A6 for ; Sat, 10 Apr 2010 07:18:02 -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 o3AEHnaf000869; Sat, 10 Apr 2010 16:17:49 +0200 (CEST)
Received: from [192.168.217.101] (p5489CF74.dip.t-dialin.net [84.137.207.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C7D44ECF2;  Sat, 10 Apr 2010 16:17:48 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <4BC06997.8010703@gmail.com>
Date: Sat, 10 Apr 2010 16:17:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>  <4BC06997.8010703@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 14:18:10 -0000

On Apr 10, 2010, at 14:05, Alexandru Petrescu wrote:

> Right... AH will ignore the mutable fields.  Which means the heart of =
the RPL protocol is insecure...  should say that upfront somewhere.

No, that is not at all what that means.

I cited AH to provide more evidence the fact that mutable hbh headers =
are part of the IPv6 architecture.

But let's talk about security.

AH, like all of IPsec, is end-to-end.
Routers are not supposed to act on it.
(Even if they wanted, they couldn't, as they are not privy to the SA =
governing the AH header.)

So how would an RPL hbh option interact with AH?
AH is generated at the origin of the packet and evaluated at its =
destination.
The RPL hbh option is inserted at the ingress of the RPL routing domain =
and removed (latest) at the egress.
(Obviously, if RPL needs hbh security, that will have to be added in a =
way that is independent of any IPsec headers present.)

Since a node outside the RPL domain cannot divine that the routing =
system will use RPL hbh options, it will generate/evaluate AH without =
the presence of that option.
The processing rules should make sure that this works correctly.

Jonathan, how about adding the following clarification to =
draft-hui-6man-rpl-option:

     As explained in section 1, RPL options, if present, are inserted
     inside an RPL routing domain and are removed (at least) at the
     boundaries of that domain.  Source and destination nodes of a
     packet have no control over when this happens; the presence or
     absence of the option MUST therefore be without effect on the
     security posture of the packet itself.  For example, any
     generation or evaluation of AH headers [RFC4302], if colocated
     with the addition/removal of RPL options, MUST be performed
     before the RPL option is added and after it is removed,
     respectively.  Removing an RPL option that is the only hop-by-hop
     option MUST be performed by removing the hop-by-hop option
     altogether.  [Add processing rules for when there *is* a HBH
     option already.  This could get ugly quickly because it will be
     hard to reliably restore padding if the SHOULD in section 4.2 of
     RFC 2460 "If more than one octet of padding is required, the PadN
     option, described next, should be used, rather than multiple Pad1
     options." is not heeded, or if there is more than one HBH option.]

(In other words, the RPL option is layered *under* the end-to-end =
delivery function of IP.  Unlike other hbh options, it is not part of =
the end-to-end semantics of the packet.  The fact that sticking it into =
the same data structure with other, possibly end-to-end hbh options, can =
lead to padding issues, makes Erik's comment in 6man even more =
interesting.)

Gruesse, Carsten


From alexandru.petrescu@gmail.com  Sat Apr 10 08:21:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4033A69DE for ; Sat, 10 Apr 2010 08:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_40=-0.185, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c35Jvj332ji for ; Sat, 10 Apr 2010 08:21:55 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E4B813A68B8 for ; Sat, 10 Apr 2010 08:21:47 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 27208D48096; Sat, 10 Apr 2010 17:21:39 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id DDB8BD48110; Sat, 10 Apr 2010 17:21:36 +0200 (CEST)
Message-ID: <4BC09778.1070405@gmail.com>
Date: Sat, 10 Apr 2010 17:21:28 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Carsten Bormann 
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>  <4BC06997.8010703@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100410-0, 10/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 15:21:56 -0000

Le 10/04/2010 16:17, Carsten Bormann a écrit :
> On Apr 10, 2010, at 14:05, Alexandru Petrescu wrote:
>
>> Right... AH will ignore the mutable fields.  Which means the heart of the RPL protocol is insecure...  should say that upfront somewhere.
>
> No, that is not at all what that means.
>
> I cited AH to provide more evidence the fact that mutable hbh headers are part of the IPv6 architecture.
>
> But let's talk about security.
>
> AH, like all of IPsec, is end-to-end.
> Routers are not supposed to act on it.
> (Even if they wanted, they couldn't, as they are not privy to the SA governing the AH header.)
>
> So how would an RPL hbh option interact with AH?
> AH is generated at the origin of the packet and evaluated at its destination.
> The RPL hbh option is inserted at the ingress of the RPL routing domain and removed (latest) at the egress.

Carsten - what is then a Host in RPL speak (when Host MUST reset the 'O' 
oh bit)?  Is such a Host part of the RPL routing domain you mention 
above?  Or is it _outside_ this routing domain.

> (Obviously, if RPL needs hbh security, that will have to be added in a way that is independent of any IPsec headers present.)
>
> Since a node outside the RPL domain cannot divine that the routing system will use RPL hbh options, it will generate/evaluate AH without the presence of that option.
> The processing rules should make sure that this works correctly.
>
> Jonathan, how about adding the following clarification to draft-hui-6man-rpl-option:
>
>       As explained in section 1, RPL options, if present, are inserted
>       inside an RPL routing domain and are removed (at least) at the
>       boundaries of that domain.

Carsten - I doubt any other protocol makes the intermediary routers to 
insert extension headers between the base header and the payload (of the 
originating packets).  To me it's very simple: if the dst address is not 
me then I don't touch the packet, just pass it on and decrement its Hop 
Limit.  I could create another packet by encapsulating the original 
untouched one, or remove an address from the routing header, of course. 
  I don't know of any other exception.

When inserting an additional header the overall packet Length field will 
have to change too, and then set back to the original value.  Draft-hui 
is silent about this.  I don't necessarily want it to talk about it but 
there are many aspects which need to be treated when changing packets 
enroute.

Why all this work?  Why approaching so much that NAT-like evil which 
changes packets enroute?

(YOu may know otherwise, curious about examples)

Alex

   Source and destination nodes of a
>       packet have no control over when this happens; the presence or
>       absence of the option MUST therefore be without effect on the
>       security posture of the packet itself.  For example, any
>       generation or evaluation of AH headers [RFC4302], if colocated
>       with the addition/removal of RPL options, MUST be performed
>       before the RPL option is added and after it is removed,
>       respectively.  Removing an RPL option that is the only hop-by-hop
>       option MUST be performed by removing the hop-by-hop option
>       altogether.  [Add processing rules for when there *is* a HBH
>       option already.  This could get ugly quickly because it will be
>       hard to reliably restore padding if the SHOULD in section 4.2 of
>       RFC 2460 "If more than one octet of padding is required, the PadN
>       option, described next, should be used, rather than multiple Pad1
>       options." is not heeded, or if there is more than one HBH option.]
>
> (In other words, the RPL option is layered *under* the end-to-end delivery function of IP.  Unlike other hbh options, it is not part of the end-to-end semantics of the packet.  The fact that sticking it into the same data structure with other, possibly end-to-end hbh options, can lead to padding issues, makes Erik's comment in 6man even more interesting.)
>
> Gruesse, Carsten
>
>


From jhui@archrock.com  Sat Apr 10 09:26:51 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BFB3A67D1 for ; Sat, 10 Apr 2010 09:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-hBAbwBNQs3 for ; Sat, 10 Apr 2010 09:26:50 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 19F7C3A67CC for ; Sat, 10 Apr 2010 09:26:50 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 43A31AF936; Sat, 10 Apr 2010 09:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-OX-bKmjE99; Sat, 10 Apr 2010 09:26:42 -0700 (PDT)
Received: from [10.0.1.5] (adsl-71-142-75-17.dsl.pltn13.pacbell.net [71.142.75.17]) by mail.sf.archrock.com (Postfix) with ESMTP id 1C3DFAF845; Sat, 10 Apr 2010 09:26:42 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: Alexandru Petrescu 
In-Reply-To: <4BC0619C.90506@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 10 Apr 2010 09:26:41 -0700
References: <4BBFB419.10905@gmail.com>  <4BC0619C.90506@gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 16:26:51 -0000

Hi Alex,

On Apr 10, 2010, at 4:31 AM, Alexandru Petrescu wrote:

> Le 10/04/2010 03:49, Jonathan Hui a =E9crit :
>>
>> This issue was document months ago as Ticket #21.
>
> Jonathan, Ticket #21 simpy says "RPL control Bits in flow Label[...] A
> decision has to be made on whether the control bits of RPL currently
> specified in the Flow Label should be moved to a newly defined IPv6
> extended header."
>
> This doesn't say what the issue is.

It raises the question of whether we should be using the IPv6 Flow =20
Label, the *exact* same question you initially raised but 4 months =20
earlier.

> It doesn't say HbH header.

The HbH header is one possible solution we are pursuing at this time.

> I am not happy with this Ticket #21.
>
>> We are working on moving the information into a IPv6 Hop-by-Hop
>> Option. A draft that requests and documents the RPL option was posted
>> and presented at the 6man WG meeting in Anaheim.
>
> Ok, I read the slides and the jabber log.
>
> Nobody seemed to ask about you modifying the HbH option en-route.  I
> hope you don't, I haven't seen it elsewhere before, requires =20
> additional
> per-packet processing by intermediary routers.

Because no one had an issue with it.  In fact, there were some =20
comments indicating that this may be the best use case for a HbH =20
option that they've seen.

> If your (author's) problem is to update the routing state upon arrival
> of a packet which you don't have a route for then consider a use =20
> similar
> to what Triggered RIP does, or similar to what DYMO and MANET
> "on-demand" semantics do: hold the packet and generate new packets for
> route update.

The problem isn't when you don't have a route - data-path validation =20
doesn't work in that case because you have nowhere to send the data.  =20=

The problem is when you have a route but the routing information is =20
stale and inconsistent.  The only way to know is by exchanging =20
information either in control packets or data packets.  See below why =20=

we prefer data packets.

> Moving encoding from Flow Label to HbH doesn't solve your fundamental
> problem - which btw we haven't discussed.
>
> The slide at
> http://www.ietf.org/proceedings/10mar/slides/6man-7.pdf
> says the problem is "How to manage control overhead with reactivity to
> link state changes?".  The answer to that is simple: use link-state
> protocols like OSPF.

The notion hear is to operate at the time scales of your data plane.  =20=

The intuition is simple - if you don't use a path, why spend resources =20=

(energy, channel capacity, etc.) fixing it?  Wireless links change all =20=

the time, in many cases much faster than the rate at which you use =20
them for data.

> slide says solution is:
>> Slow proactive process - allow routing inconsistencies
>
> Link-state protocols propagate route updates immediately upon change =20=

> of
> link states (hence the name) - that is as fast as it could get.

That is exactly the behavior we do not want in LLNs.  Again, link-=20
state changes often happen at much smaller time scales than the data =20
plane.

>> Include routing info in data-plane packets to detect inconsistencies
>
> No, please don't modify data-plane packets on the fly("data-plane" is
> payload I believe).  Besides, if a packet arrives at a router which
> doesn't know where to forward then no amount of additional data in the
> packet will help find a way.

Again, the case where no route exists is not the problem we are trying =20=

to solve.

>> React to inconsistencies when routes are used
>
> This I don't understand.  Routes are always used aren't they.
>
> Reacting to inconsistencies in the internal routing database happens
> whenever a new route update is received, not when an application =20
> data is
> received.  Each time a route update is received a new computation on =20=

> the
> table is performed and eventually send new updates.  Reacting to =20
> updates
> is easy.  What's difficult is convergence time, but that doesn't =20
> depend
> on the piggybacked data - it depends mostly on the number of nodes and
> the number of links.

It depends on how often you exchange routing information.  Again, you =20=

want that to happen on data-plane time scales.

> For some reason I dislike this approach of piggybacking routing
> information in data packets, makes not much sense to me.  IMHO and a =20=

> smiley.

This mechanism has been in the draft since 04.  It was presented in =20
Hiroshima.  You are the first to have a serious objection.

--
Jonathan Hui


From jhui@archrock.com  Sat Apr 10 09:45:21 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3A93A67D1 for ; Sat, 10 Apr 2010 09:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09xA1t3caDDs for ; Sat, 10 Apr 2010 09:45:20 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8F1453A67CC for ; Sat, 10 Apr 2010 09:45:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 71CC9AF946; Sat, 10 Apr 2010 09:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOWDWMFkIX2J; Sat, 10 Apr 2010 09:45:11 -0700 (PDT)
Received: from [10.0.1.5] (adsl-71-142-75-17.dsl.pltn13.pacbell.net [71.142.75.17]) by mail.sf.archrock.com (Postfix) with ESMTP id 94164AF845; Sat, 10 Apr 2010 09:45:11 -0700 (PDT)
Message-Id: <51F1DDDB-9F00-4EBE-A5BA-05BDA55260EE@archrock.com>
From: Jonathan Hui 
To: Carsten Bormann 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 10 Apr 2010 09:45:10 -0700
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>  <4BC06997.8010703@gmail.com> 
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 16:45:21 -0000

Hi Carsten,

On Apr 10, 2010, at 7:17 AM, Carsten Bormann wrote:

> So how would an RPL hbh option interact with AH?
> AH is generated at the origin of the packet and evaluated at its  
> destination.
> The RPL hbh option is inserted at the ingress of the RPL routing  
> domain and removed (latest) at the egress.
> (Obviously, if RPL needs hbh security, that will have to be added in  
> a way that is independent of any IPsec headers present.)
>
> Since a node outside the RPL domain cannot divine that the routing  
> system will use RPL hbh options, it will generate/evaluate AH  
> without the presence of that option.
> The processing rules should make sure that this works correctly.
>
> Jonathan, how about adding the following clarification to draft- 
> hui-6man-rpl-option:
>
>     As explained in section 1, RPL options, if present, are inserted
>     inside an RPL routing domain and are removed (at least) at the
>     boundaries of that domain.  Source and destination nodes of a
>     packet have no control over when this happens; the presence or
>     absence of the option MUST therefore be without effect on the
>     security posture of the packet itself.  For example, any
>     generation or evaluation of AH headers [RFC4302], if colocated
>     with the addition/removal of RPL options, MUST be performed
>     before the RPL option is added and after it is removed,
>     respectively.  Removing an RPL option that is the only hop-by-hop
>     option MUST be performed by removing the hop-by-hop option
>     altogether.  [Add processing rules for when there *is* a HBH
>     option already.  This could get ugly quickly because it will be
>     hard to reliably restore padding if the SHOULD in section 4.2 of
>     RFC 2460 "If more than one octet of padding is required, the PadN
>     option, described next, should be used, rather than multiple Pad1
>     options." is not heeded, or if there is more than one HBH option.]

Thanks, Carsten.  This is a good clarification to bring out.

> (In other words, the RPL option is layered *under* the end-to-end  
> delivery function of IP.  Unlike other hbh options, it is not part  
> of the end-to-end semantics of the packet.  The fact that sticking  
> it into the same data structure with other, possibly end-to-end hbh  
> options, can lead to padding issues, makes Erik's comment in 6man  
> even more interesting.)

One possibility to maintain alignment is to require the RPL option to  
be sized such that it maintains the alignment of any existing options  
(e.g. require a size of always 6+8n if inserting at the beginning or  
simply 8n if inserting at the end).  We could also be conservative  
with the PadN vs. Pad1 issue by saying that all existing options  
(including PadN and Pad1) cannot be removed when inserting a RPL  
option.  Of course, this assumes that options will never need to be  
aligned on larger boundaries (e.g. 16n), but is there a case for that?

--
Jonathan Hui


From alexandru.petrescu@gmail.com  Sat Apr 10 12:50:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDF23A68E4 for ; Sat, 10 Apr 2010 12:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level: 
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=1.045,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXJ9AMwNurEj for ; Sat, 10 Apr 2010 12:50:41 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id F05DE3A6823 for ; Sat, 10 Apr 2010 12:50:39 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 161C0D4809D; Sat, 10 Apr 2010 21:50:31 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id EBC62D4805F; Sat, 10 Apr 2010 21:50:28 +0200 (CEST)
Message-ID: <4BC0D67C.8070205@gmail.com>
Date: Sat, 10 Apr 2010 21:50:20 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jonathan Hui 
References: <4BBFB419.10905@gmail.com>  <4BC0619C.90506@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100410-0, 10/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Other than Flow Lables, non-modified enroute packets, data vs control, more (was:  Flow Labels are wrongly used)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 10 Apr 2010 19:50:42 -0000

Hi Jonathan,

Le 10/04/2010 18:26, Jonathan Hui a écrit :
>
> Hi Alex,
>
> On Apr 10, 2010, at 4:31 AM, Alexandru Petrescu wrote:
>
>> Le 10/04/2010 03:49, Jonathan Hui a écrit :
>>>
>>> This issue was document months ago as Ticket #21.
>>
>> Jonathan, Ticket #21 simpy says "RPL control Bits in flow
>> Label[...] A decision has to be made on whether the control bits
>> of RPL currently specified in the Flow Label should be moved to a
>> newly defined IPv6 extended header."
>>
>> This doesn't say what the issue is.
>
> It raises the question of whether we should be using the IPv6 Flow
> Label, the *exact* same question you initially raised but 4 months
> earlier.
>
>> It doesn't say HbH header.
>
> The HbH header is one possible solution we are pursuing at this
> time.
>
>> I am not happy with this Ticket #21.
>>
>>> We are working on moving the information into a IPv6 Hop-by-Hop
>>> Option. A draft that requests and documents the RPL option was
>>> posted and presented at the 6man WG meeting in Anaheim.
>>
>> Ok, I read the slides and the jabber log.
>>
>> Nobody seemed to ask about you modifying the HbH option en-route. I
>> hope you don't, I haven't seen it elsewhere before, requires
>> additional per-packet processing by intermediary routers.
>
> Because no one had an issue with it. In fact, there were some
> comments indicating that this may be the best use case for a HbH
> option that they've seen.
>
>> If your (author's) problem is to update the routing state upon
>> arrival of a packet which you don't have a route for then consider
>> a use similar to what Triggered RIP does, or similar to what DYMO
>> and MANET "on-demand" semantics do: hold the packet and generate
>> new packets for route update.
>
> The problem isn't when you don't have a route - data-path validation
> doesn't work in that case because you have nowhere to send the data.
> The problem is when you have a route but the routing information is
> stale and inconsistent. The only way to know is by exchanging
> information either in control packets or data packets. See below why
> we prefer data packets.
>
>> Moving encoding from Flow Label to HbH doesn't solve your
>> fundamental problem - which btw we haven't discussed.
>>
>> The slide at
>> http://www.ietf.org/proceedings/10mar/slides/6man-7.pdf says the
>> problem is "How to manage control overhead with reactivity to link
>> state changes?". The answer to that is simple: use link-state
>> protocols like OSPF.
>
> The notion hear is to operate at the time scales of your data plane.
> The intuition is simple - if you don't use a path, why spend
> resources (energy, channel capacity, etc.) fixing it? Wireless links
> change all the time, in many cases much faster than the rate at which
> you use them for data.
>
>> slide says solution is:
>>> Slow proactive process - allow routing inconsistencies
>>
>> Link-state protocols propagate route updates immediately upon
>> change of link states (hence the name) - that is as fast as it
>> could get.
>
> That is exactly the behavior we do not want in LLNs. Again,
> link-state changes often happen at much smaller time scales than the
> data plane.

Hmm... interesting to hear that.  Do we have some quantification or
example of this statement - what does it look like?  What application is
used?  Periodic querying of sensor data - which app protocol?  What link
layer is used which is so often unstable?  Any thoughts along this line.

This qualifying of links going down more often than data being sent
(smaller time scales) makes think one needs to send heartbeat control
packets right before sending data packets.

>>> Include routing info in data-plane packets to detect
>>> inconsistencies
>>
>> No, please don't modify data-plane packets on the fly("data-plane"
>> is payload I believe). Besides, if a packet arrives at a router
>> which doesn't know where to forward then no amount of additional
>> data in the packet will help find a way.
>
> Again, the case where no route exists is not the problem we are
> trying to solve.

But absence of route is equivalent to a route being stale or incosistent.

>>> React to inconsistencies when routes are used
>>
>> This I don't understand. Routes are always used aren't they.
>>
>> Reacting to inconsistencies in the internal routing database
>> happens whenever a new route update is received, not when an
>> application data is received. Each time a route update is received
>> a new computation on the table is performed and eventually send new
>> updates. Reacting to updates is easy. What's difficult is
>> convergence time, but that doesn't depend on the piggybacked data
>> - it depends mostly on the number of nodes and the number of
>> links.
>
> It depends on how often you exchange routing information. Again, you
> want that to happen on data-plane time scales.

You may want it on a certain time-scale - ok.  How about the Host (leaf,
end-node, Client) sending heartbeat control packets right before sending
its data, just to make sure a path exists.

>> For some reason I dislike this approach of piggybacking routing
>> information in data packets, makes not much sense to me. IMHO and
>> a smiley.
>
> This mechanism has been in the draft since 04. It was presented in
> Hiroshima. You are the first to have a serious objection.

Well thanks for making me a first... I believe these things
(paging for power-save, piggybacking, heartbeats, on-demand, triggering,
data vs control) have been discussed many times on other protocols.

Heartbeat could be Router Alert (Option Data does not change en-route).
  MLDv2 uses it piggybacked on data packets.  RPL Host could piggyback it
in the same way.  But I see that as an optimization.  One can't request
every app on RPL node to piggyback it.

Better have first the RPL control (ICMP) first separated completely from
data packets.  And see later for HbH optimization.

I would like to make sure that any application works ok unmodified on a
Host in the RPL network (e.g. httpd), and not only those which
piggyback, or which send control packets before sending their data.

Not sure how to explain but really deserves discussion.  Should have 
been in requirements actually... don't modify apps, don't change packets 
enroute, talk to Internet nodes, etc.

Alex

>
> -- Jonathan Hui
>
>


From root@core3.amsl.com  Sat Apr 10 15:45:01 2010
Return-Path: 
X-Original-To: roll@ietf.org
Delivered-To: roll@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id E10CD3A68DD; Sat, 10 Apr 2010 15:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100410224501.E10CD3A68DD@core3.amsl.com>
Date: Sat, 10 Apr 2010 15:45:01 -0700 (PDT)
Cc: roll@ietf.org
Subject: [Roll] I-D Action:draft-ietf-roll-trickle-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Apr 2010 22:45: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 Trickle Algorithm
	Author(s)       : P. Levis, et al.
	Filename        : draft-ietf-roll-trickle-01.txt
	Pages           : 8
	Date            : 2010-04-10

The Trickle algorithm allows wireless nodes to exchange information
in a highly robust, energy efficient, simple, and scalable manner.
Dynamically adjusting transmission windows allows Trickle to spread
new information on the scale of link-layer transmission times while
sending only a few messages per hour when information does not
change.  A simple suppression nechanism and transmission point
selection allows Trickle's communication rate to scale
logarithmically with density.  This document describes Trickle and
considerations in its use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-01.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-trickle-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-10154132.I-D@ietf.org>


--NextPart--

From pal@cs.stanford.edu  Sat Apr 10 16:13:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B323A6838 for ; Sat, 10 Apr 2010 16:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdvSyRecgscV for ; Sat, 10 Apr 2010 16:13:02 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 297AD3A6810 for ; Sat, 10 Apr 2010 16:13:02 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O0jrF-00027U-LE for roll@ietf.org; Sat, 10 Apr 2010 16:12:58 -0700
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <20100410224501.E10CD3A68DD@core3.amsl.com>
References: <20100410224501.E10CD3A68DD@core3.amsl.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <75BA5A7C-5D94-47D6-9220-C0DCB56705B5@cs.stanford.edu>
Content-Transfer-Encoding: 7bit
From: Philip Levis 
Date: Sat, 10 Apr 2010 16:11:02 -0700
To: roll WG 
X-Mailer: Apple Mail (2.753.1)
X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621
Subject: Re: [Roll] I-D Action:draft-ietf-roll-trickle-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Apr 2010 23:13:07 -0000

On Apr 10, 2010, at 3:45 PM, 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 Trickle Algorithm
> 	Author(s)       : P. Levis, et al.
> 	Filename        : draft-ietf-roll-trickle-01.txt
> 	Pages           : 8
> 	Date            : 2010-04-10
>
> The Trickle algorithm allows wireless nodes to exchange information
> in a highly robust, energy efficient, simple, and scalable manner.
> Dynamically adjusting transmission windows allows Trickle to spread
> new information on the scale of link-layer transmission times while
> sending only a few messages per hour when information does not
> change.  A simple suppression nechanism and transmission point
> selection allows Trickle's communication rate to scale
> logarithmically with density.  This document describes Trickle and
> considerations in its use.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-01.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.
> Content-Type: text/plain
> Content-ID: <2010-04-10154132.I-D@ietf.org>

This version incorporates comments from the WG and adds Jonathan Hui  
and John Ko as co-authors.

Phil

From navagar@cisco.com  Sat Apr 10 22:26:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892773A6988 for ; Sat, 10 Apr 2010 22:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level: 
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sDjRBIIp0fj for ; Sat, 10 Apr 2010 22:25:55 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 481A33A697C for ; Sat, 10 Apr 2010 22:22:04 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,184,1270425600"; d="scan'208";a="181289907"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2010 05:21:38 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3B5Lbsm001171; Sun, 11 Apr 2010 05:21:37 GMT
Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 11 Apr 2010 10:51:37 +0530
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: Sun, 11 Apr 2010 10:51:36 +0530
Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com>
In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8A=
References:  <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>
From: "Navneet Agarwal (navagar)" 
To: "ROLL WG" 
X-OriginalArrivalTime: 11 Apr 2010 05:21:37.0449 (UTC) FILETIME=[DBEA0990:01CAD936]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 11 Apr 2010 05:26:03 -0000

Hi:
I have two feedbacks from the router testing perspective.

Feedback-I:
DAO rank: It seems there very couple of different interpretations for
setting this value.=20
A. Several implementations were setting the DAO rank to be equal to the
node rank (value sent in DIO rank). Each node relays this info in the
DAO towards the root. However this does not convey any differentiating
info to the receiving nodes when the DAOs are received thru multiple
paths in order to install the best route.
B. The other implementation was to set the value to 0 (or 1) by the node
and have the intermediate nodes increment it as the DAO rides up to the
root. The DAO rank in this case is more of a hop count and the receiving
nodes can make a decision based on the lowest value received when
installing the DAO route.
Pros: Decision is optimized based on hopcount. Relatively simple.
Cons: Hopcount does not take link cost into account.
C. A third proposal was to set the DAO rank equal to the node rank and a
link cost in the metric container as each nodes propagates the DAO. The
receiving nodes would make a decision based on the link cost.
Pros: Decision is optimized based on link cost
Cons: The DAOs would need to carry additional info in the packet (bigger
DAOs) and more processing needed in the nodes to parse and process.

I think we need some more details the spec for describing the value to
be set in DAO rank.


Feedback-II:
DIO Sequence number: The issue was what should be the initial value of
this field. The spec is not clear on what should be the initial value
set by the root. This has implications at the LBR in reload/reboot
conditions. For example, if the initial value is set to 1 and is
incremented to say 10. When the LBR reloads/reboots, it would start the
sequence number with 1 but its DIOs will be rejected by the nodes as
having stale sequence number. The LBR can store the sequence in
persistent memory. An easier option could be use 255 as the starting
sequence number. Using this value will make sure that the sequence
number is always valid.

Comments?

Thanks

Regards,
Navneet

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20
> Behalf Of Mathilde Durvy (mdurvy)
> Sent: Thursday, April 08, 2010 1:46 PM
> To: JP Vasseur
> Cc: ROLL WG
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>=20
> Dear All,
>=20
> Following the discussion on the mailing list I just wanted to=20
> clarify a few things so that we can find the best way to=20
> interact in the future.
>=20
> - We were proposed a slot to announce this first interop=20
> event during the ROLL WG meeting, future events may be=20
> advertised only on an IPSO web-site if this is preferred by the WG.
> - IPSO is not defining standards. It is organizing interop=20
> events to ensure that different implementations of the same=20
> standard do work together. The current status is that you=20
> have to pay a membership fee to participate in these events=20
> (and indeed these events take work, prior preparation, and=20
> money to organize).=20
> - We understand (at least) some people are still interested=20
> in interop event feedback. This will be given on individual,=20
> voluntary, basis by the participants of the interop event.=20
>=20
> Best,
> Mathilde
> =20
>=20
> -----Original Message-----
> From: JP Vasseur [mailto:jpv@cisco.com]
> Sent: vendredi, 26. mars 2010 03:55
> To: Mathilde Durvy (mdurvy)
> Cc: ROLL WG
> Subject: IPSO Interop event - Feed-back welcome
>=20
> Hi,
>=20
> Just re-enforcing my comments during the ROLL WG meeting ...=20
> any feed- back from the IPSO interop about any issues that=20
> you may have found would be extremely useful to continue to=20
> improve our spec. Feel free to also share good news.
>=20
> Thanks.
>=20
> JP.
>=20

From pthubert@cisco.com  Sun Apr 11 08:40:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2C63A67FA for ; Sun, 11 Apr 2010 08:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.179
X-Spam-Level: 
X-Spam-Status: No, score=-5.179 tagged_above=-999 required=5 tests=[AWL=-2.580, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaGFayK7sAaZ for ; Sun, 11 Apr 2010 08:40:36 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 60D9F3A63EB for ; Sun, 11 Apr 2010 08:40:35 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8CAC6KwUuQ/uCWe2dsb2JhbACbRRUBAQsLIgYcnX6XeoJsCIIYBA
X-IronPort-AV: E=Sophos;i="4.52,185,1270425600";  d="scan'208";a="5431884"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2010 15:04:52 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3BFeTKY017227 for ; Sun, 11 Apr 2010 15:40:29 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 11 Apr 2010 17:40:29 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 11 Apr 2010 17:40:26 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com>
In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAFjH7kA==
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com>
From: "Pascal Thubert (pthubert)" 
To: "Navneet Agarwal (navagar)" , "ROLL WG" 
X-OriginalArrivalTime: 11 Apr 2010 15:40:29.0509 (UTC) FILETIME=[5058BF50:01CAD98D]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 11 Apr 2010 15:40:38 -0000

Hi Navneet:

For issue 1), the most recent discussion tends to remove the DAO rank
and metrics completely. The reason is that with RPL, the node selects
its DAO parent and thus decides of the routing.
Passing a simple preference provides a better indication that the
parents (or the root in source route mode) can only root along the most
preferred path as the nodes have decided it.

Regarding issue 2) I think we should use a traditional lollipop and then
Serial Number Arithmetic as defined in RFC 1982. The straight part of
the lollipop could use sequence 0 to 15, and then the number would
increment skipping those values as it wraps, what do you think?

Cheers;

Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Navneet Agarwal (navagar)
> Sent: Sunday, April 11, 2010 7:22 AM
> To: ROLL WG
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>=20
> Hi:
> I have two feedbacks from the router testing perspective.
>=20
> Feedback-I:
> DAO rank: It seems there very couple of different interpretations for
setting
> this value.
> A. Several implementations were setting the DAO rank to be equal to
the
> node rank (value sent in DIO rank). Each node relays this info in the
DAO
> towards the root. However this does not convey any differentiating
info to
> the receiving nodes when the DAOs are received thru multiple paths in
order
> to install the best route.
> B. The other implementation was to set the value to 0 (or 1) by the
node and
> have the intermediate nodes increment it as the DAO rides up to the
root.
> The DAO rank in this case is more of a hop count and the receiving
nodes can
> make a decision based on the lowest value received when installing the
DAO
> route.
> Pros: Decision is optimized based on hopcount. Relatively simple.
> Cons: Hopcount does not take link cost into account.
> C. A third proposal was to set the DAO rank equal to the node rank and
a link
> cost in the metric container as each nodes propagates the DAO. The
receiving
> nodes would make a decision based on the link cost.
> Pros: Decision is optimized based on link cost
> Cons: The DAOs would need to carry additional info in the packet
(bigger
> DAOs) and more processing needed in the nodes to parse and process.
>=20
> I think we need some more details the spec for describing the value to
be set
> in DAO rank.
>=20
>=20
> Feedback-II:
> DIO Sequence number: The issue was what should be the initial value of
this
> field. The spec is not clear on what should be the initial value set
by the root.
> This has implications at the LBR in reload/reboot conditions. For
example, if
> the initial value is set to 1 and is incremented to say 10. When the
LBR
> reloads/reboots, it would start the sequence number with 1 but its
DIOs will
> be rejected by the nodes as having stale sequence number. The LBR can
> store the sequence in persistent memory. An easier option could be use
255
> as the starting sequence number. Using this value will make sure that
the
> sequence number is always valid.
>=20
> Comments?
>=20
> Thanks
>=20
> Regards,
> Navneet
>=20
> > -----Original Message-----
> > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> > Of Mathilde Durvy (mdurvy)
> > Sent: Thursday, April 08, 2010 1:46 PM
> > To: JP Vasseur
> > Cc: ROLL WG
> > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Dear All,
> >
> > Following the discussion on the mailing list I just wanted to
clarify
> > a few things so that we can find the best way to interact in the
> > future.
> >
> > - We were proposed a slot to announce this first interop event
during
> > the ROLL WG meeting, future events may be advertised only on an IPSO
> > web-site if this is preferred by the WG.
> > - IPSO is not defining standards. It is organizing interop events to
> > ensure that different implementations of the same standard do work
> > together. The current status is that you have to pay a membership
fee
> > to participate in these events (and indeed these events take work,
> > prior preparation, and money to organize).
> > - We understand (at least) some people are still interested in
interop
> > event feedback. This will be given on individual, voluntary, basis
by
> > the participants of the interop event.
> >
> > Best,
> > Mathilde
> >
> >
> > -----Original Message-----
> > From: JP Vasseur [mailto:jpv@cisco.com]
> > Sent: vendredi, 26. mars 2010 03:55
> > To: Mathilde Durvy (mdurvy)
> > Cc: ROLL WG
> > Subject: IPSO Interop event - Feed-back welcome
> >
> > Hi,
> >
> > Just re-enforcing my comments during the ROLL WG meeting ...
> > any feed- back from the IPSO interop about any issues that you may
> > have found would be extremely useful to continue to improve our
spec.
> > Feel free to also share good news.
> >
> > Thanks.
> >
> > JP.
> >
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From pthubert@cisco.com  Sun Apr 11 08:47:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068B83A67FA for ; Sun, 11 Apr 2010 08:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.035
X-Spam-Level: 
X-Spam-Status: No, score=-9.035 tagged_above=-999 required=5 tests=[AWL=1.564,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHSCpgoMFpVf for ; Sun, 11 Apr 2010 08:47:09 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B828E3A63EB for ; Sun, 11 Apr 2010 08:47:08 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8CAFqLwUuQ/uCWe2dsb2JhbACbRRUBAQsLIgYcnXyXe4UMBA
X-IronPort-AV: E=Sophos;i="4.52,185,1270425600"; d="scan'208";a="59248158"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2010 15:47:03 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3BFl3jX018075; Sun, 11 Apr 2010 15:47:03 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 11 Apr 2010 17:47:02 +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: Sun, 11 Apr 2010 17:46:58 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38576@XMB-AMS-107.cisco.com>
In-Reply-To: <4BC06268.5090501@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
Thread-Index: AcrYoenSJtZSMrK3SVmSDiALTnplpQA66yxw
References: <4BBF655D.1020807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com> <4BC06268.5090501@gmail.com>
From: "Pascal Thubert (pthubert)" 
To: "Alexandru Petrescu" 
X-OriginalArrivalTime: 11 Apr 2010 15:47:02.0853 (UTC) FILETIME=[3ACC4750:01CAD98E]
Cc: ROLL WG 
Subject: Re: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 11 Apr 2010 15:47:10 -0000

> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> Sent: Saturday, April 10, 2010 1:35 PM
> To: Pascal Thubert (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] Is the DAG Root a Host? Can it send packets =
"down"?
>=20
> Le 10/04/2010 11:58, Pascal Thubert (pthubert) a =E9crit :
> > Alex,
> >
> > the root has no edge in such instance where it is root. Yet it might
> > participate to other instances where it is not root, other routing
> > protocols, or simply have a static default route towards an access
> > router. Redistribution rules such as strict ordering of instances =
and
> > protocols avoid loops.
>=20
> Pascal - I have a hard time trying to understand what you mean.
>=20
> A root has no edge?  It has no link?  No interface?

[Pascal] Those were your words that I was echoing.=20

>=20
> Protocols avoid loops?  I don't think so.  It's not the communication =
protocol
> which avoid loop creation, but the local computation of the route =
database
> (within each node) which makes sure that the view of the network at =
each
> node is loop-free.  PRotocols simply exchange data.
>=20

[Pascal] I said that the redistribution rules avoid the loops between =
the protocols or the instances of a protocols.

Let me suggest test to make this clearer in the spec:
"
RPL defines how a packet is routed within a given instance.  The
   precedence and redistribution of routes between different RPL
   instances and between RPL and other routing protocols is out of
   scope.

   The decision to use a given instance for a given packet belongs to
   the end points.  The endpoints signal the instance in the flow label
   of the IPv6 header for use by the RPL routers that forward the
   packet.  The mechanism for provisioning instance identifiers to the
   end points and the routers is out of scope.
"

Does that sound clearer?

Pascal
>=20
> Alex
>=20
> >
> > Pascal
> >
> >> -----Original Message----- From: roll-bounces@ietf.org
> >> [mailto:roll-bounces@ietf.org] On Behalf
> > Of
> >> Alexandru Petrescu Sent: Friday, April 09, 2010 7:35 PM To: ROLL WG
> >> Subject: [Roll] Is the DAG Root a Host? Can it send packets "down"?
> >>
> >>> Down 'O' bit:  1-bit flag indicating whether the packet is
> > expected
> >>> to progress up or down.  A router sets the 'O' bit when the packet
> >>> is expect to progress down (using DAO routes), and resets it when
> >>> forwarding towards the root of the DODAG iteration.  A host MUST =
set
> >>> the bit to 0.
> >>
> >> Is the DAG Root a Host?  I guess so, because it has no outgoing =
edge.
> >> If it's a Host it means it can't send packets "down" (MUST set the =
O
> > bit to 0,
> >> up).  If it can't send packets down then there's a problem because =
it
> > can't
> >> send queries.
> >>
> >> Or am I missing something.
> >>
> >> Alex
> >>
> >>
> >> _______________________________________________ Roll mailing
> list
> >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
> >


From jpv@cisco.com  Sun Apr 11 10:42:43 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2113C3A683A for ; Sun, 11 Apr 2010 10:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.667
X-Spam-Level: 
X-Spam-Status: No, score=-9.667 tagged_above=-999 required=5 tests=[AWL=0.932,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHgyK4wZ-NqN for ; Sun, 11 Apr 2010 10:42:42 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 26DA93A67DA for ; Sun, 11 Apr 2010 10:42:42 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJWmwUurRN+J/2dsb2JhbACbSXGeGJgAgmwIghgE
X-IronPort-AV: E=Sophos;i="4.52,185,1270425600"; d="scan'208";a="512951144"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2010 17:42:37 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3BHgaxp015422 for ; Sun, 11 Apr 2010 17:42:37 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 11 Apr 2010 19:42:36 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 11 Apr 2010 19:42:35 +0200
Message-Id: 
From: JP Vasseur 
To: Pascal Thubert (pthubert) 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 11 Apr 2010 19:42:35 +0200
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 11 Apr 2010 17:42:36.0025 (UTC) FILETIME=[5F4A5E90:01CAD99E]
Cc: ROLL WG 
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 11 Apr 2010 17:42:43 -0000

On Apr 11, 2010, at 5:40 PM, Pascal Thubert (pthubert) wrote:

> Hi Navneet:
>
> For issue 1), the most recent discussion tends to remove the DAO rank
> and metrics completely. The reason is that with RPL, the node selects
> its DAO parent and thus decides of the routing.

Let's still discuss on having the metric in DAO as an option though.

> Passing a simple preference provides a better indication that the
> parents (or the root in source route mode) can only root along the  
> most
> preferred path as the nodes have decided it.
>
> Regarding issue 2) I think we should use a traditional lollipop and  
> then
> Serial Number Arithmetic as defined in RFC 1982. The straight part of
> the lollipop could use sequence 0 to 15, and then the number would
> increment skipping those values as it wraps, what do you think?
>
> Cheers;
>
> Pascal
>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
>> Navneet Agarwal (navagar)
>> Sent: Sunday, April 11, 2010 7:22 AM
>> To: ROLL WG
>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>>
>> Hi:
>> I have two feedbacks from the router testing perspective.
>>
>> Feedback-I:
>> DAO rank: It seems there very couple of different interpretations for
> setting
>> this value.
>> A. Several implementations were setting the DAO rank to be equal to
> the
>> node rank (value sent in DIO rank). Each node relays this info in the
> DAO
>> towards the root. However this does not convey any differentiating
> info to
>> the receiving nodes when the DAOs are received thru multiple paths in
> order
>> to install the best route.
>> B. The other implementation was to set the value to 0 (or 1) by the
> node and
>> have the intermediate nodes increment it as the DAO rides up to the
> root.
>> The DAO rank in this case is more of a hop count and the receiving
> nodes can
>> make a decision based on the lowest value received when installing  
>> the
> DAO
>> route.
>> Pros: Decision is optimized based on hopcount. Relatively simple.
>> Cons: Hopcount does not take link cost into account.
>> C. A third proposal was to set the DAO rank equal to the node rank  
>> and
> a link
>> cost in the metric container as each nodes propagates the DAO. The
> receiving
>> nodes would make a decision based on the link cost.
>> Pros: Decision is optimized based on link cost
>> Cons: The DAOs would need to carry additional info in the packet
> (bigger
>> DAOs) and more processing needed in the nodes to parse and process.
>>
>> I think we need some more details the spec for describing the value  
>> to
> be set
>> in DAO rank.
>>
>>
>> Feedback-II:
>> DIO Sequence number: The issue was what should be the initial value  
>> of
> this
>> field. The spec is not clear on what should be the initial value set
> by the root.
>> This has implications at the LBR in reload/reboot conditions. For
> example, if
>> the initial value is set to 1 and is incremented to say 10. When the
> LBR
>> reloads/reboots, it would start the sequence number with 1 but its
> DIOs will
>> be rejected by the nodes as having stale sequence number. The LBR can
>> store the sequence in persistent memory. An easier option could be  
>> use
> 255
>> as the starting sequence number. Using this value will make sure that
> the
>> sequence number is always valid.
>>
>> Comments?
>>
>> Thanks
>>
>> Regards,
>> Navneet
>>
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>>> Of Mathilde Durvy (mdurvy)
>>> Sent: Thursday, April 08, 2010 1:46 PM
>>> To: JP Vasseur
>>> Cc: ROLL WG
>>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>>>
>>> Dear All,
>>>
>>> Following the discussion on the mailing list I just wanted to
> clarify
>>> a few things so that we can find the best way to interact in the
>>> future.
>>>
>>> - We were proposed a slot to announce this first interop event
> during
>>> the ROLL WG meeting, future events may be advertised only on an IPSO
>>> web-site if this is preferred by the WG.
>>> - IPSO is not defining standards. It is organizing interop events to
>>> ensure that different implementations of the same standard do work
>>> together. The current status is that you have to pay a membership
> fee
>>> to participate in these events (and indeed these events take work,
>>> prior preparation, and money to organize).
>>> - We understand (at least) some people are still interested in
> interop
>>> event feedback. This will be given on individual, voluntary, basis
> by
>>> the participants of the interop event.
>>>
>>> Best,
>>> Mathilde
>>>
>>>
>>> -----Original Message-----
>>> From: JP Vasseur [mailto:jpv@cisco.com]
>>> Sent: vendredi, 26. mars 2010 03:55
>>> To: Mathilde Durvy (mdurvy)
>>> Cc: ROLL WG
>>> Subject: IPSO Interop event - Feed-back welcome
>>>
>>> Hi,
>>>
>>> Just re-enforcing my comments during the ROLL WG meeting ...
>>> any feed- back from the IPSO interop about any issues that you may
>>> have found would be extremely useful to continue to improve our
> spec.
>>> Feel free to also share good news.
>>>
>>> Thanks.
>>>
>>> JP.
>>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From navagar@cisco.com  Mon Apr 12 01:15:49 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500A63A67CF for ; Mon, 12 Apr 2010 01:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.299
X-Spam-Level: 
X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CRKrUJqaWYI for ; Mon, 12 Apr 2010 01:15:46 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 945963A6A03 for ; Mon, 12 Apr 2010 01:15:46 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,189,1270425600"; d="scan'208";a="113772588"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 12 Apr 2010 08:15:41 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3C8FT03007900; Mon, 12 Apr 2010 08:15:40 GMT
Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 13:45:37 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 13:45:36 +0530
Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01184D3E@XMB-BGL-41C.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrZnmDwgra6zJoCSw+bdqRiYthRqAAd8msw
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com> 
From: "Navneet Agarwal (navagar)" 
To: "JP Vasseur" , "Pascal Thubert (pthubert)" 
X-OriginalArrivalTime: 12 Apr 2010 08:15:37.0257 (UTC) FILETIME=[54F01190:01CADA18]
Cc: ROLL WG 
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 08:15:49 -0000

Hi:=20

> -----Original Message-----
> From: JP Vasseur [mailto:jpv@cisco.com]=20
> Sent: Sunday, April 11, 2010 11:13 PM
> To: Pascal Thubert (pthubert)
> Cc: Navneet Agarwal (navagar); ROLL WG
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>=20
>=20
> On Apr 11, 2010, at 5:40 PM, Pascal Thubert (pthubert) wrote:
>=20
> > Hi Navneet:
> >
> > For issue 1), the most recent discussion tends to remove=20
> the DAO rank=20
> > and metrics completely. The reason is that with RPL, the=20
> node selects=20
> > its DAO parent and thus decides of the routing.
>=20
> Let's still discuss on having the metric in DAO as an option though.
>=20
> > Passing a simple preference provides a better indication that the=20
> > parents (or the root in source route mode) can only root along the=20
> > most preferred path as the nodes have decided it.
NAV> How would the node decide the preference value?. I was thinking
that if a metric is explicitly defined in the DAO it may be more
transparent for decision making in a mixed environment...imo. What do
you think?



> >
> > Regarding issue 2) I think we should use a traditional lollipop and=20
> > then Serial Number Arithmetic as defined in RFC 1982. The straight=20
> > part of the lollipop could use sequence 0 to 15, and then=20
> the number=20
> > would increment skipping those values as it wraps, what do=20
> you think?
NAV> Is using 255 as the starting sequence number simpler than using the
above logic?

Thx

Regards,
Navneet
> >
> > Cheers;
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20
> On Behalf
> > Of
> >> Navneet Agarwal (navagar)
> >> Sent: Sunday, April 11, 2010 7:22 AM
> >> To: ROLL WG
> >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >>
> >> Hi:
> >> I have two feedbacks from the router testing perspective.
> >>
> >> Feedback-I:
> >> DAO rank: It seems there very couple of different=20
> interpretations for
> > setting
> >> this value.
> >> A. Several implementations were setting the DAO rank to be equal to
> > the
> >> node rank (value sent in DIO rank). Each node relays this=20
> info in the
> > DAO
> >> towards the root. However this does not convey any differentiating
> > info to
> >> the receiving nodes when the DAOs are received thru=20
> multiple paths in
> > order
> >> to install the best route.
> >> B. The other implementation was to set the value to 0 (or 1) by the
> > node and
> >> have the intermediate nodes increment it as the DAO rides up to the
> > root.
> >> The DAO rank in this case is more of a hop count and the receiving
> > nodes can
> >> make a decision based on the lowest value received when installing=20
> >> the
> > DAO
> >> route.
> >> Pros: Decision is optimized based on hopcount. Relatively simple.
> >> Cons: Hopcount does not take link cost into account.
> >> C. A third proposal was to set the DAO rank equal to the node rank=20
> >> and
> > a link
> >> cost in the metric container as each nodes propagates the DAO. The
> > receiving
> >> nodes would make a decision based on the link cost.
> >> Pros: Decision is optimized based on link cost
> >> Cons: The DAOs would need to carry additional info in the packet
> > (bigger
> >> DAOs) and more processing needed in the nodes to parse and process.
> >>
> >> I think we need some more details the spec for describing=20
> the value=20
> >> to
> > be set
> >> in DAO rank.
> >>
> >>
> >> Feedback-II:
> >> DIO Sequence number: The issue was what should be the=20
> initial value=20
> >> of
> > this
> >> field. The spec is not clear on what should be the initial=20
> value set
> > by the root.
> >> This has implications at the LBR in reload/reboot conditions. For
> > example, if
> >> the initial value is set to 1 and is incremented to say=20
> 10. When the
> > LBR
> >> reloads/reboots, it would start the sequence number with 1 but its
> > DIOs will
> >> be rejected by the nodes as having stale sequence number.=20
> The LBR can=20
> >> store the sequence in persistent memory. An easier option could be=20
> >> use
> > 255
> >> as the starting sequence number. Using this value will=20
> make sure that
> > the
> >> sequence number is always valid.
> >>
> >> Comments?
> >>
> >> Thanks
> >>
> >> Regards,
> >> Navneet
> >>
> >>> -----Original Message-----
> >>> From: roll-bounces@ietf.org=20
> [mailto:roll-bounces@ietf.org] On Behalf=20
> >>> Of Mathilde Durvy (mdurvy)
> >>> Sent: Thursday, April 08, 2010 1:46 PM
> >>> To: JP Vasseur
> >>> Cc: ROLL WG
> >>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >>>
> >>> Dear All,
> >>>
> >>> Following the discussion on the mailing list I just wanted to
> > clarify
> >>> a few things so that we can find the best way to interact in the=20
> >>> future.
> >>>
> >>> - We were proposed a slot to announce this first interop event
> > during
> >>> the ROLL WG meeting, future events may be advertised only=20
> on an IPSO=20
> >>> web-site if this is preferred by the WG.
> >>> - IPSO is not defining standards. It is organizing=20
> interop events to=20
> >>> ensure that different implementations of the same=20
> standard do work=20
> >>> together. The current status is that you have to pay a membership
> > fee
> >>> to participate in these events (and indeed these events=20
> take work,=20
> >>> prior preparation, and money to organize).
> >>> - We understand (at least) some people are still interested in
> > interop
> >>> event feedback. This will be given on individual, voluntary, basis
> > by
> >>> the participants of the interop event.
> >>>
> >>> Best,
> >>> Mathilde
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: JP Vasseur [mailto:jpv@cisco.com]
> >>> Sent: vendredi, 26. mars 2010 03:55
> >>> To: Mathilde Durvy (mdurvy)
> >>> Cc: ROLL WG
> >>> Subject: IPSO Interop event - Feed-back welcome
> >>>
> >>> Hi,
> >>>
> >>> Just re-enforcing my comments during the ROLL WG meeting ...
> >>> any feed- back from the IPSO interop about any issues=20
> that you may=20
> >>> have found would be extremely useful to continue to improve our
> > spec.
> >>> Feel free to also share good news.
> >>>
> >>> Thanks.
> >>>
> >>> JP.
> >>>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
>=20
>=20

From mdurvy@cisco.com  Mon Apr 12 01:15:52 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905613A6A06 for ; Mon, 12 Apr 2010 01:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.134
X-Spam-Level: 
X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWeRe5i2681q for ; Mon, 12 Apr 2010 01:15:50 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D78203A67CF for ; Mon, 12 Apr 2010 01:15:49 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: smime.p7s : 4235
X-IronPort-AV: E=Sophos;i="4.52,189,1270425600";  d="p7s'?scan'208";a="181562605"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2010 08:15:45 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3C8FccA006405; Mon, 12 Apr 2010 08:15:44 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 10:15:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Apr 2010 10:15:39 +0200
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0D14_01CADA29.19F9B530"; protocol="application/x-pkcs7-signature"
Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com>
In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAOMtcQA==
References:  <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com>
From: "Mathilde Durvy (mdurvy)" 
To: "Navneet Agarwal (navagar)" , "ROLL WG" 
X-OriginalArrivalTime: 12 Apr 2010 08:15:40.0795 (UTC) FILETIME=[570BECB0:01CADA18]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 08:15:52 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0D14_01CADA29.19F9B530
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Navneet,

Thanks for your feedback. I fully agree with the issues you described. I
just wanted to mention that our interop event was based on revision 05 of
the RPL draft.

My general impression is that the "DIO part" of RPL is stable, working well,
and it's probably a good time to freeze the specs there. Concerning the "DAO
part", we could only test the "fully storing" mode. What I observed was that
except for the "DAO rank" issue below, there was no interop problems but the
scalability of the solution needs to be improved  (the first think to do
would be to agree on a way to include several prefixes in a DAO packet).
Also I think RPL is currently at the right level of complexity for the
platforms it's targeting however we should be careful not to add to much
extra features.

Best,
Mathilde

-----Original Message-----
From: Navneet Agarwal (navagar) 
Sent: dimanche, 11. avril 2010 07:22
To: ROLL WG
Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal (navagar)
Subject: RE: [Roll] IPSO Interop event - Feed-back welcome

Hi:
I have two feedbacks from the router testing perspective.

Feedback-I:
DAO rank: It seems there very couple of different interpretations for
setting this value. 
A. Several implementations were setting the DAO rank to be equal to the node
rank (value sent in DIO rank). Each node relays this info in the DAO towards
the root. However this does not convey any differentiating info to the
receiving nodes when the DAOs are received thru multiple paths in order to
install the best route.
B. The other implementation was to set the value to 0 (or 1) by the node and
have the intermediate nodes increment it as the DAO rides up to the root.
The DAO rank in this case is more of a hop count and the receiving nodes can
make a decision based on the lowest value received when installing the DAO
route.
Pros: Decision is optimized based on hopcount. Relatively simple.
Cons: Hopcount does not take link cost into account.
C. A third proposal was to set the DAO rank equal to the node rank and a
link cost in the metric container as each nodes propagates the DAO. The
receiving nodes would make a decision based on the link cost.
Pros: Decision is optimized based on link cost
Cons: The DAOs would need to carry additional info in the packet (bigger
DAOs) and more processing needed in the nodes to parse and process.

I think we need some more details the spec for describing the value to be
set in DAO rank.


Feedback-II:
DIO Sequence number: The issue was what should be the initial value of this
field. The spec is not clear on what should be the initial value set by the
root. This has implications at the LBR in reload/reboot conditions. For
example, if the initial value is set to 1 and is incremented to say 10. When
the LBR reloads/reboots, it would start the sequence number with 1 but its
DIOs will be rejected by the nodes as having stale sequence number. The LBR
can store the sequence in persistent memory. An easier option could be use
255 as the starting sequence number. Using this value will make sure that
the sequence number is always valid.

Comments?

Thanks

Regards,
Navneet

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 
> Of Mathilde Durvy (mdurvy)
> Sent: Thursday, April 08, 2010 1:46 PM
> To: JP Vasseur
> Cc: ROLL WG
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> 
> Dear All,
> 
> Following the discussion on the mailing list I just wanted to clarify 
> a few things so that we can find the best way to interact in the 
> future.
> 
> - We were proposed a slot to announce this first interop event during 
> the ROLL WG meeting, future events may be advertised only on an IPSO 
> web-site if this is preferred by the WG.
> - IPSO is not defining standards. It is organizing interop events to 
> ensure that different implementations of the same standard do work 
> together. The current status is that you have to pay a membership fee 
> to participate in these events (and indeed these events take work, 
> prior preparation, and money to organize).
> - We understand (at least) some people are still interested in interop 
> event feedback. This will be given on individual, voluntary, basis by 
> the participants of the interop event.
> 
> Best,
> Mathilde
>  
> 
> -----Original Message-----
> From: JP Vasseur [mailto:jpv@cisco.com]
> Sent: vendredi, 26. mars 2010 03:55
> To: Mathilde Durvy (mdurvy)
> Cc: ROLL WG
> Subject: IPSO Interop event - Feed-back welcome
> 
> Hi,
> 
> Just re-enforcing my comments during the ROLL WG meeting ... 
> any feed- back from the IPSO interop about any issues that you may 
> have found would be extremely useful to continue to improve our spec. 
> Feel free to also share good news.
> 
> Thanks.
> 
> JP.
> 

------=_NextPart_000_0D14_01CADA29.19F9B530
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD
VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl
cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw
MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy
dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp
aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa
c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID
AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh
bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB
AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT
zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b
Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x
jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB
FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa
dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe
MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx
IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH
TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N
VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5
1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN
E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/
BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu
BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU
EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln
bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS
ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz
M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG
49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDQxMjA4MTUzOVowIwYJKoZI
hvcNAQkEMRYEFAjH5BE080r9AhfWd8UObxI3Ay9uMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu
IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w
ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAz/2X
CA39TzVNYfUgFjTj17qul02y7ZA04O3P777OLUR4x1M7mYeB9+q15xE7VKEQ1vHx6blpCRl3lx60
0W7xI6vjj1hCOPGhASxD9FOL25KPdrkZlDUF2akJO8oXcoi9s4ruVN+6DBz+h0aQj2Zojn4Doc7y
t9PunvZlLfxYBo0AAAAAAAA=

------=_NextPart_000_0D14_01CADA29.19F9B530--

From pthubert@cisco.com  Mon Apr 12 01:58:19 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A5D28C0E5 for ; Mon, 12 Apr 2010 01:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.118
X-Spam-Level: 
X-Spam-Status: No, score=-9.118 tagged_above=-999 required=5 tests=[AWL=1.481,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMFZlcZx+dMA for ; Mon, 12 Apr 2010 01:58:18 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9B6C93A68B6 for ; Mon, 12 Apr 2010 01:58:16 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,189,1270425600"; d="scan'208";a="513233879"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 Apr 2010 08:58:12 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3C8w8xR028589; Mon, 12 Apr 2010 08:58:11 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 10:58:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 10:58:02 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38707@XMB-AMS-107.cisco.com>
In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01184D3E@XMB-BGL-41C.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrZnmDwgra6zJoCSw+bdqRiYthRqAAd8mswAADpsjA=
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com>  <3EF472F4AD7D824EA24D3197C56B61DB01184D3E@XMB-BGL-41C.cisco.com>
From: "Pascal Thubert (pthubert)" 
To: "Navneet Agarwal (navagar)" , "JP Vasseur" , "Roger Alexander" 
X-OriginalArrivalTime: 12 Apr 2010 08:58:09.0702 (UTC) FILETIME=[46504460:01CADA1E]
Cc: ROLL WG 
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 08:58:19 -0000

Hi Navneet:

Please reread the thread with Roger and others.
http://www.ietf.org/mail-archive/web/roll/current/msg03426.html=20

A Node selects its parents based on the metrics it gets from them and
from whatever L2 trigger info it has about the link to those parents.
Once the node has selected its parents and in particular the subset that
are DAO parents, the reverse DAG to reach the node is decided.
All the rest, and in particular the DAO flooding back, is about
informing the parent(s) and the root of that decision.=20
This is true in both stateful and stateless modes.

Now, it might happen that in the interest of getting multipath, the DAO
to a destination is fanned out, that is passed to multiple parents.
In that case, it is good to be able to track the preferred parent path
for a number of reasons:
- prefer that path
- minimize stretch
- control fan out within acceptable stretch

With the current spec, we give the impression that the routing can be
done again by the parents, because we give them metrics.=20
It is particularly harmful in stateful mode when we give the impression
that we are doing some form of Link State operation at the root.
In fact all the root needs is to recursively follow the track of
preferred parent, and limit the stretch when that cannot be done.

All the information we need to do this is the usual preference that we
inherited from RFC 4191 and use in a number of places in RPL already.

The metrics, OF, etc... is only needed in DIO processing when the DAG is
built. The rest of RPL can be and should be completely generic.
If we want to control the complexity, I strongly suggest we leave it at
that.


Pascal


> -----Original Message-----
> From: Navneet Agarwal (navagar)
> Sent: Monday, April 12, 2010 10:16 AM
> To: JP Vasseur; Pascal Thubert (pthubert)
> Cc: ROLL WG
> Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
>=20
> Hi:
>=20
> > -----Original Message-----
> > From: JP Vasseur [mailto:jpv@cisco.com]
> > Sent: Sunday, April 11, 2010 11:13 PM
> > To: Pascal Thubert (pthubert)
> > Cc: Navneet Agarwal (navagar); ROLL WG
> > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >
> >
> > On Apr 11, 2010, at 5:40 PM, Pascal Thubert (pthubert) wrote:
> >
> > > Hi Navneet:
> > >
> > > For issue 1), the most recent discussion tends to remove
> > the DAO rank
> > > and metrics completely. The reason is that with RPL, the
> > node selects
> > > its DAO parent and thus decides of the routing.
> >
> > Let's still discuss on having the metric in DAO as an option though.
> >
> > > Passing a simple preference provides a better indication that the
> > > parents (or the root in source route mode) can only root along the
> > > most preferred path as the nodes have decided it.
> NAV> How would the node decide the preference value?. I was thinking
that
> if a metric is explicitly defined in the DAO it may be more
transparent for
> decision making in a mixed environment...imo. What do you think?
>=20
>=20
>=20
> > >
> > > Regarding issue 2) I think we should use a traditional lollipop
and
> > > then Serial Number Arithmetic as defined in RFC 1982. The straight
> > > part of the lollipop could use sequence 0 to 15, and then
> > the number
> > > would increment skipping those values as it wraps, what do
> > you think?
> NAV> Is using 255 as the starting sequence number simpler than using
the
> above logic?
>=20
> Thx
>=20
> Regards,
> Navneet
> > >
> > > Cheers;
> > >
> > > Pascal
> > >
> > >> -----Original Message-----
> > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]
> > On Behalf
> > > Of
> > >> Navneet Agarwal (navagar)
> > >> Sent: Sunday, April 11, 2010 7:22 AM
> > >> To: ROLL WG
> > >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >>
> > >> Hi:
> > >> I have two feedbacks from the router testing perspective.
> > >>
> > >> Feedback-I:
> > >> DAO rank: It seems there very couple of different
> > interpretations for
> > > setting
> > >> this value.
> > >> A. Several implementations were setting the DAO rank to be equal
to
> > > the
> > >> node rank (value sent in DIO rank). Each node relays this
> > info in the
> > > DAO
> > >> towards the root. However this does not convey any
differentiating
> > > info to
> > >> the receiving nodes when the DAOs are received thru
> > multiple paths in
> > > order
> > >> to install the best route.
> > >> B. The other implementation was to set the value to 0 (or 1) by
the
> > > node and
> > >> have the intermediate nodes increment it as the DAO rides up to
the
> > > root.
> > >> The DAO rank in this case is more of a hop count and the
receiving
> > > nodes can
> > >> make a decision based on the lowest value received when
installing
> > >> the
> > > DAO
> > >> route.
> > >> Pros: Decision is optimized based on hopcount. Relatively simple.
> > >> Cons: Hopcount does not take link cost into account.
> > >> C. A third proposal was to set the DAO rank equal to the node
rank
> > >> and
> > > a link
> > >> cost in the metric container as each nodes propagates the DAO.
The
> > > receiving
> > >> nodes would make a decision based on the link cost.
> > >> Pros: Decision is optimized based on link cost
> > >> Cons: The DAOs would need to carry additional info in the packet
> > > (bigger
> > >> DAOs) and more processing needed in the nodes to parse and
process.
> > >>
> > >> I think we need some more details the spec for describing
> > the value
> > >> to
> > > be set
> > >> in DAO rank.
> > >>
> > >>
> > >> Feedback-II:
> > >> DIO Sequence number: The issue was what should be the
> > initial value
> > >> of
> > > this
> > >> field. The spec is not clear on what should be the initial
> > value set
> > > by the root.
> > >> This has implications at the LBR in reload/reboot conditions. For
> > > example, if
> > >> the initial value is set to 1 and is incremented to say
> > 10. When the
> > > LBR
> > >> reloads/reboots, it would start the sequence number with 1 but
its
> > > DIOs will
> > >> be rejected by the nodes as having stale sequence number.
> > The LBR can
> > >> store the sequence in persistent memory. An easier option could
be
> > >> use
> > > 255
> > >> as the starting sequence number. Using this value will
> > make sure that
> > > the
> > >> sequence number is always valid.
> > >>
> > >> Comments?
> > >>
> > >> Thanks
> > >>
> > >> Regards,
> > >> Navneet
> > >>
> > >>> -----Original Message-----
> > >>> From: roll-bounces@ietf.org
> > [mailto:roll-bounces@ietf.org] On Behalf
> > >>> Of Mathilde Durvy (mdurvy)
> > >>> Sent: Thursday, April 08, 2010 1:46 PM
> > >>> To: JP Vasseur
> > >>> Cc: ROLL WG
> > >>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >>>
> > >>> Dear All,
> > >>>
> > >>> Following the discussion on the mailing list I just wanted to
> > > clarify
> > >>> a few things so that we can find the best way to interact in the
> > >>> future.
> > >>>
> > >>> - We were proposed a slot to announce this first interop event
> > > during
> > >>> the ROLL WG meeting, future events may be advertised only
> > on an IPSO
> > >>> web-site if this is preferred by the WG.
> > >>> - IPSO is not defining standards. It is organizing
> > interop events to
> > >>> ensure that different implementations of the same
> > standard do work
> > >>> together. The current status is that you have to pay a
membership
> > > fee
> > >>> to participate in these events (and indeed these events
> > take work,
> > >>> prior preparation, and money to organize).
> > >>> - We understand (at least) some people are still interested in
> > > interop
> > >>> event feedback. This will be given on individual, voluntary,
basis
> > > by
> > >>> the participants of the interop event.
> > >>>
> > >>> Best,
> > >>> Mathilde
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: JP Vasseur [mailto:jpv@cisco.com]
> > >>> Sent: vendredi, 26. mars 2010 03:55
> > >>> To: Mathilde Durvy (mdurvy)
> > >>> Cc: ROLL WG
> > >>> Subject: IPSO Interop event - Feed-back welcome
> > >>>
> > >>> Hi,
> > >>>
> > >>> Just re-enforcing my comments during the ROLL WG meeting ...
> > >>> any feed- back from the IPSO interop about any issues
> > that you may
> > >>> have found would be extremely useful to continue to improve our
> > > spec.
> > >>> Feel free to also share good news.
> > >>>
> > >>> Thanks.
> > >>>
> > >>> JP.
> > >>>
> > >> _______________________________________________
> > >> Roll mailing list
> > >> Roll@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/roll
> > > _______________________________________________
> > > Roll mailing list
> > > Roll@ietf.org
> > > https://www.ietf.org/mailman/listinfo/roll
> >
> >

From pthubert@cisco.com  Mon Apr 12 06:39:17 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C95B3A6A3E for ; Mon, 12 Apr 2010 06:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.192
X-Spam-Level: 
X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=-2.593, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YQE5ojOgl5W for ; Mon, 12 Apr 2010 06:39:16 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2B5AE3A6A3C for ; Mon, 12 Apr 2010 06:39:16 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIBAMu/wkuQ/uCWe2dsb2JhbACbMhUBAQsLIgYcojOYS4UMBA
X-IronPort-AV: E=Sophos;i="4.52,190,1270425600";  d="scan'208";a="5469594"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2010 13:03:28 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CDdAAg016168; Mon, 12 Apr 2010 13:39:10 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 15:39:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 15:39:05 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A3894D@XMB-AMS-107.cisco.com>
In-Reply-To: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs
Thread-Index: AcrOvPnqIqbF7Tl1Q6m+mpR6f6JN6ALh5Qcw
References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com>
From: "Pascal Thubert (pthubert)" 
To: "Richard Kelsey" , "Jonathan Hui" 
X-OriginalArrivalTime: 12 Apr 2010 13:39:09.0844 (UTC) FILETIME=[87BDC540:01CADA45]
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 13:39:17 -0000

Hi Richard:

Following up on this proposal and Jonathan's answers, I've been trying
to formulate how the parents up the DAG know that they need to
participate to the source route and send their own DAO indicating their
own parents.

As discussed earlier, one option is that all routers in the network do
send DAOs with their parents, so we're all set. But that falls short in
a number of cases, including P2P where we only want to trace back the
path between A and B.=20

Or, we ask the destination to send uncast a DAO to each of its DAO
parent. So each parent knows that it has to send its own DAO and so on
recursively; as soon as a router has at least one child that is a source
route destination then it must send its own DAO information.

What do you think?

Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Richard Kelsey
> Sent: Sunday, March 28, 2010 11:21 PM
> To: roll@ietf.org
> Subject: [Roll] proposal for DAOs in non-caching DODAGs
>=20
> Pascal and I had a discussion on how to simplify DAOs if the group
confirms
> the decision to not explicitly support DAGs with mixed caching and
non-
> caching routers.  The obvious simplification is that the DIO 'S' flag
is either on
> or off throughout a DODAG, eliminating the need to do anything when it
> changes.
>=20
> More interestingly, the reverse route stack is no longer needed.  It
is not
> used if all nodes cache DAOs.  If only the root does so, including
intermediate
> hops when forwarding DAOs only duplicates information that the root
will
> receive from others.
>=20
> Our proposal is to replace the reverse route stack with a set of
parents that is
> forwarded up the DAG to the root.
> The DAO format stays the same, except that the reverse route stack is
now a
> set of parents and is not changed when forwarded.
>=20
> The root can then reconstruct the DAG and compute downwards routes as
> needed.  This is not as big a change as it may
> seem: in the current draft the root may have to compute the paths to
nodes
> whose S bit is not set.  Path computation is simpler than for a full
link-state
> protocol, as the DIOs have preselected the better up/down links in
forming
> the DAG and other links are not reported.
>=20
> The advantages of using a parent set rather than a reverse route stack
are:
>   - downward path diversity while only sending DAOs
>     to the preferred parent
>   - DAOs do not grow with DAG depth
>   - DAO forwarding is simpler
>=20
> What do people think?
>                                   -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From richard.kelsey@ember.com  Mon Apr 12 06:47:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465653A69B6 for ; Mon, 12 Apr 2010 06:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.742
X-Spam-Level: 
X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N3uouPqmoOh for ; Mon, 12 Apr 2010 06:47:43 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5DA003A68A9 for ; Mon, 12 Apr 2010 06:47:43 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 09:50:40 -0400
Date: Mon, 12 Apr 2010 09:46:14 -0400
Message-Id: <87eiik3hsp.fsf@kelsey-ws.hq.ember.com>
To: Carsten Bormann 
In-reply-to: <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org> (message from Carsten Bormann on Fri, 9 Apr 2010 22:54:17 +0200)
From: Richard Kelsey 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com> <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com> <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org>
X-OriginalArrivalTime: 12 Apr 2010 13:50:40.0612 (UTC) FILETIME=[23789A40:01CADA47]
Cc: roll@ietf.org, Daniel.Popa@itron.com
Subject: Re: [Roll] Proposal for Source Routing	HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 13:47:44 -0000

> From: Carsten Bormann 
> Date: Fri, 9 Apr 2010 22:54:17 +0200
> Cc: roll@ietf.org, "Popa, Daniel" 
> 
> On Apr 9, 2010, at 18:34, Jonathan Hui wrote:
> 
> > the RPL option as simple container and is flexible in what we put in it
> 
> One comment in 6man (was that by Erik?) was that this is not the only
> place to put it -- we might as well insert a header in front of the
> IPv6 header like MPLS does.  Now all this talk about forwarding by
> tags instead of IP addresses puts a pretty eerie ring on that...

Why aren't we inserting a header in front of the IPv6
header like MPLS does?  Especially as the hop-by-hop
option seems to be getting more complicated (alignment,
maximum size)?  I am not advocating doing so, just
wondering why we don't.
                             -Richard Kelsey

From mcr@sandelman.ca  Mon Apr 12 06:50:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAF03A69B6 for ; Mon, 12 Apr 2010 06:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zciTYT+c-Li8 for ; Mon, 12 Apr 2010 06:50:36 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id F29B03A68A9 for ; Mon, 12 Apr 2010 06:50:33 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id 8661934715 for ; Mon, 12 Apr 2010 09:50:28 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 98C454E7B9 for ; Mon, 12 Apr 2010 09:50:26 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-Reply-To: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu>
References: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 09:50:26 -0400
Message-ID: <14765.1271080226@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 13:50:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


    notsure1> I'm not sure I understand the concern. Is it that if this
    notsure1> isn't stated explicitly, then an implementation might put a
    notsure1> neighbor in the parent set for which it cannot compute
    notsure1> DAGRank from the OF? How would it ever compute its own
    notsure1> DAGRank? Can you explain the failure condition? 

    notsure2> Consider the situation where node A receives a DIO from
    notsure2> node B and knows the cost of link B->A (either it already
    notsure2> knew this cost or DIO carries this cost or it assumes a
    notsure2> value for this cost) but not that of link A->B. Then, node
    notsure2> A may be able to compute its DAG rank via node B and thus
    notsure2> possibly select node B as a DIO parent. But, even if B
    notsure2> becomes a DIO parent, A should not consider B as a
    notsure2> candidate for DAO parenthood because A does not know the
    notsure2> cost of link A->B.     

    Phil> So a node A MUST NOT select node B as a parent if the OF
    Phil> cannot compute the DAGRank of the resulting route? 

>>>>> "Mukul" == Mukul Goyal  writes:
    Mukul> Node A may have sufficient information to calculate its DAG
    Mukul> rank via B but still may not have the information to
    Mukul> calculate B's suitability as a DAO parent (e.g. if OF just
    Mukul> considers the upwards costs in calculating the DAG rank and
    Mukul> such costs are known to A but requires knowledge of downwards
    Mukul> costs for a parent's selection as DAO parent and these
    Mukul> downwards costs (from B to A) are not known to A). 

Naively, if the A->B link is never used, then you'd never know what the
cost of the link is.   

But Jonathan has said:

>>>>> "Jonathan" == Jonathan Hui  writes:
    Jonathan> It's obvious that if A's link cost estimation information
    Jonathan> about the  path from A -> B, then whatever mechanism is
    Jonathan> used to generate that  link cost metric needs to be
    Jonathan> communicated to be resident at A.  It's  not obvious to me
    Jonathan> that the routing protocol should be responsible for  make
    Jonathan> sure this happens. I'd actually prefer that the link
    Jonathan> estimation  mechanism handle the necessary propagation of
    Jonathan> information. 

So this suggests to me that there is some possibly-out-of-scope,
possibly-layer-2-specific, mechanism that calculates the costs.

Is this correct?

I would rather do all the work with as few transmissions as possible.
I would think that the A->B cost includes such things as the transmit
power required for B to hear A, and reducing that extends battery life.

I would imagine B transmitting their DIO messages with increasing power
until it gets an ack from A.  (We haven't defined such an ACK yet)

I would want to use the A->B link, if it can be used, until such time as
another link appears with a lower cost.  

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8MlHICLcPvd0N1lAQIUfgf+LyQST5Q/X+AVjm3VrrQFFnNZHWYZHqY6
sqQ5Obxu8qnLqLnGsBuuLw7zJqnGsHgOUsQGrAJxJFziSa/SFtGmJkoQijwsJP76
2BItsNWQqKQ35KGc4jDlOvZqN5Sfk/GvZ+4ggUDC9xWydBLmmhV4frHCEm7KBBJA
AfLNuZnf0EO5qHU8RbXZlpQe0VOo4tAauXKwDq0J40QeCwV44S1mMrt1+/JEyK8y
yh3l9JdTaE+81qtRf6yvcsulfCgUZ6QcX09uduacyrW1sOshPO2BUrPXPgzy2Eus
m196rQrI7MMBidU3TGj1IIdlAwKh0yxUkK0Zr7nB4954nC8fBaowFw==
=feYo
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 06:51:55 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E573A6A41 for ; Mon, 12 Apr 2010 06:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIq-PY-c-Rsh for ; Mon, 12 Apr 2010 06:51:54 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 57DB63A67E3 for ; Mon, 12 Apr 2010 06:51:54 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id 9240434715; Mon, 12 Apr 2010 09:51:49 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 1EBF14E7B9; Mon, 12 Apr 2010 09:51:48 -0400 (EDT)
From: Michael Richardson 
To: Richard Kelsey 
In-Reply-To: <87wrwror7o.fsf@kelsey-ws.hq.ember.com> 
References: <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> <87wrwror7o.fsf@kelsey-ws.hq.ember.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 09:51:48 -0400
Message-ID: <14884.1271080308@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 13:51:55 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Richard" == Richard Kelsey  writes:
    >> On Mar 31, 2010, at 2:23 PM, Richard Kelsey wrote:
    >> 
    >> > For me there is one big difference, which is that using two
    >> > instances does not require any changes to the RPL draft.  We
    >> > need to support multiple instances in any case, so using two
    >> > instances for separate up/down routes does not add any new
    >> > complications.
    >> 
    >> I am not sure about the comparative overhead of 2 RPL instances versus
    >> 1 instance. Are you sure this is not going to be an issue for
    >> extreme-RAM limited devices that can afford to join 1 DAG but not 2?

    Richard> I was thinking more of complications in the spec and in
    Richard> implementations than of RAM usage.  If we are really
    Richard> concerned about devices having enough RAM for only a single
    Richard> instance, then we should work harder on simplifying the
    Richard> basic protocol.

If we can simplify the base protocol by seperating up/down, and that
reduces timers, code and the like, then is having a minimum of 2
acceptable? 

    Richard> In practice, I would expect severly limited devices to be
    Richard> used in constrained situations such that they would not
    Richard> need to implement the full generality of RPL.  In such a
    Richard> situation I do not think that there would be any significant
    Richard> difference in RAM usage between having two instances versus
    Richard> a single instance with multiple ranks, parent sets, and so
    Richard> forth.

Exactly.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8MlcYCLcPvd0N1lAQLUWQf/YNpu6DHDAJIQT2h5S1jjo86fG+fX/Rm8
gzTRnA0CE4hpdL63qfg6edG/4OdBbMWocyB4C/4CCUyk4jg79nJ39kmvmWOKX4Hm
VDqhMIlTUniqt/HANs6aG/XrumPUPckJXb/KSK7sc4u7nSN4q/bFk3KPxdO8bdMx
7P7cYcjS6+7c3Y02nH93LmqEqiawJTFfOIHDDJqOfKIB9pmj7d2TMyf/Duz4ZPXV
zFCW3aFsKvOOKB6Bz1ONbJf6FDnpQg/ihfuIOLTj5Wo8uTjzXfEx81g0sJf+LY+X
wG6fFeuapUWytipuCZvyiZkBR4R0wg9aPyC4u3pj8CIO0pHn9FCygQ==
=lUWO
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 07:02:47 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7E73A68A9 for ; Mon, 12 Apr 2010 07:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiE+D1OyP6GP for ; Mon, 12 Apr 2010 07:02:43 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E34F93A67E3 for ; Mon, 12 Apr 2010 07:02:35 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id E2FF034715; Mon, 12 Apr 2010 10:02:30 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 663504E7B9; Mon, 12 Apr 2010 10:02:28 -0400 (EDT)
From: Michael Richardson 
To: robert.cragie@gridmerge.com
In-Reply-To: <4BBCE201.2020206@gridmerge.com> 
References: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> <56FAF6DE-2204-48FE-8E29-3533BEC7BE4A@cs.stanford.edu> <4BBCE201.2020206@gridmerge.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 10:02:28 -0400
Message-ID: <15578.1271080948@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 14:02:48 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Robert, thanks for the great write up.
{Like you, I don't try to keep on top of the threads as they occur.}

My understanding is that *some* L2s already know the cost values due to
layer-2 activity.  I still think that this information should be
transmitted again at Layer-3, and that some Layer-2 won't be able to
calculate cost, or that cost won't be visible to layer-3!

I agree with your analysis of DIO/DAO confusion.
It's clear we need ACKs in this protocol.  

I think that some of the ACKs were implicit when we started as being
inside the ND payloads, because the NDs were themselves already
bi-directional. 

- -- 
]       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. 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8Mn8ICLcPvd0N1lAQJfugf6AmljArcebIIo/eR38oRUhVeV/yeFPnmE
gaFxRGh4toTVkTCXxSUGN2EEuiNcFaMs1tywFd94CH/YxpM7VcKjK/gAmd9PHdVr
b8kg9+Mq+fEMBsK3twZfb1Lv7c14xqBv/89s5lvLdtNjU6Zl+pKgrmuVA+UyzCOw
8zlp+by/KLVfRrKIPigwqZS9laFUx3/GGZfl3LLbMXNJX8vyN7VGVt5DNQ9SvT7o
yB8KWjVkhLH3CRH9moNQ1xaz5j0NAiR6tCjBsMP5U+04/cuQ1i4QA5l/ajf9gcOH
M+8fgBQ48f0H5Qfltx1xc0fuuDOGvKcmVQ4ToHVQaN4wvZKWApvcKw==
=PUJd
-----END PGP SIGNATURE-----

From roger.alexander@ekasystems.com  Mon Apr 12 09:04:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914453A6959 for ; Mon, 12 Apr 2010 09:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.874
X-Spam-Level: 
X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-6btP2fa98k for ; Mon, 12 Apr 2010 09:04:43 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id B078C3A6845 for ; Mon, 12 Apr 2010 09:04:42 -0700 (PDT)
Received: (qmail 21855 invoked from network); 12 Apr 2010 16:04:34 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 09:04:34 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: U3qOYn0VM1lAxE8PwkAZ.DHF.20.ljqc_XfSbBr2MKIC.2fA2.xQzxJGeLS60isAaWKQ2mPjjU2HL1ZHBJQXUmTmAVDVxTS0uFkZiec8XEPMKa.imKuU3jBPmaP_LVhLBd1c0XS5H7hbwTo2qou.NEHM7uzL02eOYus5mUXmyVfiTuToFH6.6enI7OnXF1_SSX1Qi6EcHUiWd13Tg0jdLMzhnJtpFre8ylrzgFNSvBWeqYDn5HvdmveTEGL8qiMS56KpkINVsVvMTPX2H7gkq.6SDPPt5zyqgH3qWnOxCQOZLw9M.zgjfaEK.BX1jShJDGBjAStd_pHKfxMS8HU.nPYU_meBim4hfEO5oG6hlAcogJK1KPDj8boJvrgeRXGq
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Mathilde Durvy \(mdurvy\)'" , "'Navneet Agarwal \(navagar\)'" , "'ROLL WG'" 
References: 	<8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>	<3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com>
In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com>
Date: Mon, 12 Apr 2010 12:03:01 -0400
Message-ID: <027601cada59$a0c46350$e24d29f0$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAOMtcQAAN2GfA
Content-Language: en-us
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 16:04:44 -0000

Hi Navneet, Mathilde,

Thanks for the feedback on the interop event.

Roger

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Mathilde Durvy (mdurvy)
> Sent: Monday, April 12, 2010 4:16 AM
> To: Navneet Agarwal (navagar); ROLL WG
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> 
> Hi Navneet,
> 
> Thanks for your feedback. I fully agree with the issues you described.
> I just wanted to mention that our interop event was based on revision
> 05 of the RPL draft.
> 
> My general impression is that the "DIO part" of RPL is stable, working
> well, and it's probably a good time to freeze the specs there.
> Concerning the "DAO part", we could only test the "fully storing" mode.
> What I observed was that except for the "DAO rank" issue below, there
> was no interop problems but the scalability of the solution needs to be
> improved  (the first think to do would be to agree on a way to include
> several prefixes in a DAO packet).

I would very strongly endorse this direction of multiple prefixes (the
option to carry full or partial sub-DAG stack) within the DAO message. This
capability together with the ability to support incremental update of
changes between a node and its DAO parents will greatly improve the
scalability of the solution for networks with storing nodes where nodes can
take advantage of acknowledged/cached information to limit repetitive DAO
transmissions.

 
> Also I think RPL is currently at the right level of complexity for the
> platforms it's targeting however we should be careful not to add to
> much extra features.
> 
> Best,
> Mathilde
> 
> -----Original Message-----
> From: Navneet Agarwal (navagar)
> Sent: dimanche, 11. avril 2010 07:22
> To: ROLL WG
> Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal (navagar)
> Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> 
> Hi:
> I have two feedbacks from the router testing perspective.
> 
> Feedback-I:
> DAO rank: It seems there very couple of different interpretations for
> setting this value.
> A. Several implementations were setting the DAO rank to be equal to the
> node rank (value sent in DIO rank). Each node relays this info in the
> DAO towards the root. However this does not convey any differentiating
> info to the receiving nodes when the DAOs are received thru multiple
> paths in order to install the best route.
> B. The other implementation was to set the value to 0 (or 1) by the
> node and have the intermediate nodes increment it as the DAO rides up
> to the root.
> The DAO rank in this case is more of a hop count and the receiving
> nodes can make a decision based on the lowest value received when
> installing the DAO route.
> Pros: Decision is optimized based on hopcount. Relatively simple.
> Cons: Hopcount does not take link cost into account.
> C. A third proposal was to set the DAO rank equal to the node rank and
> a link cost in the metric container as each nodes propagates the DAO.
> The receiving nodes would make a decision based on the link cost.
> Pros: Decision is optimized based on link cost
> Cons: The DAOs would need to carry additional info in the packet
> (bigger
> DAOs) and more processing needed in the nodes to parse and process.
> 
> I think we need some more details the spec for describing the value to
> be set in DAO rank.
> 
> 
> Feedback-II:
> DIO Sequence number: The issue was what should be the initial value of
> this field. The spec is not clear on what should be the initial value
> set by the root. This has implications at the LBR in reload/reboot
> conditions. For example, if the initial value is set to 1 and is
> incremented to say 10. When the LBR reloads/reboots, it would start the
> sequence number with 1 but its DIOs will be rejected by the nodes as
> having stale sequence number. The LBR can store the sequence in
> persistent memory. An easier option could be use
> 255 as the starting sequence number. Using this value will make sure
> that the sequence number is always valid.
> 
> Comments?
> 
> Thanks
> 
> Regards,
> Navneet
> 
> > -----Original Message-----
> > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> > Of Mathilde Durvy (mdurvy)
> > Sent: Thursday, April 08, 2010 1:46 PM
> > To: JP Vasseur
> > Cc: ROLL WG
> > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Dear All,
> >
> > Following the discussion on the mailing list I just wanted to clarify
> > a few things so that we can find the best way to interact in the
> > future.
> >
> > - We were proposed a slot to announce this first interop event during
> > the ROLL WG meeting, future events may be advertised only on an IPSO
> > web-site if this is preferred by the WG.
> > - IPSO is not defining standards. It is organizing interop events to
> > ensure that different implementations of the same standard do work
> > together. The current status is that you have to pay a membership fee
> > to participate in these events (and indeed these events take work,
> > prior preparation, and money to organize).
> > - We understand (at least) some people are still interested in
> interop
> > event feedback. This will be given on individual, voluntary, basis by
> > the participants of the interop event.
> >
> > Best,
> > Mathilde
> >
> >
> > -----Original Message-----
> > From: JP Vasseur [mailto:jpv@cisco.com]
> > Sent: vendredi, 26. mars 2010 03:55
> > To: Mathilde Durvy (mdurvy)
> > Cc: ROLL WG
> > Subject: IPSO Interop event - Feed-back welcome
> >
> > Hi,
> >
> > Just re-enforcing my comments during the ROLL WG meeting ...
> > any feed- back from the IPSO interop about any issues that you may
> > have found would be extremely useful to continue to improve our spec.
> > Feel free to also share good news.
> >
> > Thanks.
> >
> > JP.
> >


From pthubert@cisco.com  Mon Apr 12 09:27:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09E528C15D for ; Mon, 12 Apr 2010 09:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.068
X-Spam-Level: 
X-Spam-Status: No, score=-5.068 tagged_above=-999 required=5 tests=[AWL=-2.469, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00k9ag985R1B for ; Mon, 12 Apr 2010 09:27:55 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 53E9A28C113 for ; Mon, 12 Apr 2010 09:23:37 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIBAHbmwkuQ/uCWe2dsb2JhbACbNRUBAQsLIgYco2iYcIJsCIIYBA
X-IronPort-AV: E=Sophos;i="4.52,191,1270425600";  d="scan'208";a="5478733"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2010 15:47:36 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CGNIbk000354; Mon, 12 Apr 2010 16:23:18 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 18:23:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 18:23:10 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38AD8@XMB-AMS-107.cisco.com>
In-Reply-To: <027601cada59$a0c46350$e24d29f0$@alexander@ekasystems.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAOMtcQAAN2GfAAAOwoyA=
References: 	<8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>	<3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com> <027601cada59$a0c46350$e24d29f0$@alexander@ekasystems.com>
From: "Pascal Thubert (pthubert)" 
To: "Roger Alexander" , "Mathilde Durvy (mdurvy)" , "Navneet Agarwal (navagar)" , "ROLL WG" 
X-OriginalArrivalTime: 12 Apr 2010 16:23:18.0438 (UTC) FILETIME=[75F5F460:01CADA5C]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 16:27:56 -0000

Hi Roger:

I do believe like you do that incremental updates will be a nice feature
and I'll support it in due time. I'm unsure we can fit that in the
current RPL version though, because even if it works better in a large
scale stable network, it has probably a less generic applicability than
the simple repeat over and over method that RPL uses today. But that's
just my vote.

For the steps that will make it possible (ask the DAO and multiple
targets in a DAO) I think they make sense in the current RPL for merits
of their own. My suggestion here is to have a target option that would
be valid in both DIO and DAO. In the DIO, the use would be the targeted
DIO that we discussed for P2P and so on, and in the DAO, that would be
advertising that target (eventually as a response to the DIO above).

What do you think?


Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Roger Alexander
> Sent: Monday, April 12, 2010 6:03 PM
> To: Mathilde Durvy (mdurvy); Navneet Agarwal (navagar); 'ROLL WG'
> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>=20
> Hi Navneet, Mathilde,
>=20
> Thanks for the feedback on the interop event.
>=20
> Roger
>=20
> > -----Original Message-----
> > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> > Of Mathilde Durvy (mdurvy)
> > Sent: Monday, April 12, 2010 4:16 AM
> > To: Navneet Agarwal (navagar); ROLL WG
> > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Hi Navneet,
> >
> > Thanks for your feedback. I fully agree with the issues you
described.
> > I just wanted to mention that our interop event was based on
revision
> > 05 of the RPL draft.
> >
> > My general impression is that the "DIO part" of RPL is stable,
working
> > well, and it's probably a good time to freeze the specs there.
> > Concerning the "DAO part", we could only test the "fully storing"
mode.
> > What I observed was that except for the "DAO rank" issue below,
there
> > was no interop problems but the scalability of the solution needs to
> > be improved  (the first think to do would be to agree on a way to
> > include several prefixes in a DAO packet).
>=20
> I would very strongly endorse this direction of multiple prefixes (the
option
> to carry full or partial sub-DAG stack) within the DAO message. This
capability
> together with the ability to support incremental update of changes
between
> a node and its DAO parents will greatly improve the scalability of the
solution
> for networks with storing nodes where nodes can take advantage of
> acknowledged/cached information to limit repetitive DAO transmissions.
>=20
>=20
> > Also I think RPL is currently at the right level of complexity for
the
> > platforms it's targeting however we should be careful not to add to
> > much extra features.
> >
> > Best,
> > Mathilde
> >
> > -----Original Message-----
> > From: Navneet Agarwal (navagar)
> > Sent: dimanche, 11. avril 2010 07:22
> > To: ROLL WG
> > Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal (navagar)
> > Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Hi:
> > I have two feedbacks from the router testing perspective.
> >
> > Feedback-I:
> > DAO rank: It seems there very couple of different interpretations
for
> > setting this value.
> > A. Several implementations were setting the DAO rank to be equal to
> > the node rank (value sent in DIO rank). Each node relays this info
in
> > the DAO towards the root. However this does not convey any
> > differentiating info to the receiving nodes when the DAOs are
received
> > thru multiple paths in order to install the best route.
> > B. The other implementation was to set the value to 0 (or 1) by the
> > node and have the intermediate nodes increment it as the DAO rides
up
> > to the root.
> > The DAO rank in this case is more of a hop count and the receiving
> > nodes can make a decision based on the lowest value received when
> > installing the DAO route.
> > Pros: Decision is optimized based on hopcount. Relatively simple.
> > Cons: Hopcount does not take link cost into account.
> > C. A third proposal was to set the DAO rank equal to the node rank
and
> > a link cost in the metric container as each nodes propagates the
DAO.
> > The receiving nodes would make a decision based on the link cost.
> > Pros: Decision is optimized based on link cost
> > Cons: The DAOs would need to carry additional info in the packet
> > (bigger
> > DAOs) and more processing needed in the nodes to parse and process.
> >
> > I think we need some more details the spec for describing the value
to
> > be set in DAO rank.
> >
> >
> > Feedback-II:
> > DIO Sequence number: The issue was what should be the initial value
of
> > this field. The spec is not clear on what should be the initial
value
> > set by the root. This has implications at the LBR in reload/reboot
> > conditions. For example, if the initial value is set to 1 and is
> > incremented to say 10. When the LBR reloads/reboots, it would start
> > the sequence number with 1 but its DIOs will be rejected by the
nodes
> > as having stale sequence number. The LBR can store the sequence in
> > persistent memory. An easier option could be use
> > 255 as the starting sequence number. Using this value will make sure
> > that the sequence number is always valid.
> >
> > Comments?
> >
> > Thanks
> >
> > Regards,
> > Navneet
> >
> > > -----Original Message-----
> > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf
> > > Of Mathilde Durvy (mdurvy)
> > > Sent: Thursday, April 08, 2010 1:46 PM
> > > To: JP Vasseur
> > > Cc: ROLL WG
> > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >
> > > Dear All,
> > >
> > > Following the discussion on the mailing list I just wanted to
> > > clarify a few things so that we can find the best way to interact
in
> > > the future.
> > >
> > > - We were proposed a slot to announce this first interop event
> > > during the ROLL WG meeting, future events may be advertised only
on
> > > an IPSO web-site if this is preferred by the WG.
> > > - IPSO is not defining standards. It is organizing interop events
to
> > > ensure that different implementations of the same standard do work
> > > together. The current status is that you have to pay a membership
> > > fee to participate in these events (and indeed these events take
> > > work, prior preparation, and money to organize).
> > > - We understand (at least) some people are still interested in
> > interop
> > > event feedback. This will be given on individual, voluntary, basis
> > > by the participants of the interop event.
> > >
> > > Best,
> > > Mathilde
> > >
> > >
> > > -----Original Message-----
> > > From: JP Vasseur [mailto:jpv@cisco.com]
> > > Sent: vendredi, 26. mars 2010 03:55
> > > To: Mathilde Durvy (mdurvy)
> > > Cc: ROLL WG
> > > Subject: IPSO Interop event - Feed-back welcome
> > >
> > > Hi,
> > >
> > > Just re-enforcing my comments during the ROLL WG meeting ...
> > > any feed- back from the IPSO interop about any issues that you may
> > > have found would be extremely useful to continue to improve our
spec.
> > > Feel free to also share good news.
> > >
> > > Thanks.
> > >
> > > JP.
> > >
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From alexandru.petrescu@gmail.com  Mon Apr 12 09:31:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E9D3A67EB for ; Mon, 12 Apr 2010 09:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level: 
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.626,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RhsFNgPBvCY for ; Mon, 12 Apr 2010 09:31:54 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C49093A688A for ; Mon, 12 Apr 2010 09:28:33 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3CGSOkq006194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2010 18:28:24 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3CGSOGu006505; Mon, 12 Apr 2010 18:28:24 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3CGSOIv027152; Mon, 12 Apr 2010 18:28:24 +0200
Message-ID: <4BC34A27.7010505@gmail.com>
Date: Mon, 12 Apr 2010 18:28:23 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
References: <4BBF655D.1020807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com> <4BC06268.5090501@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38576@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38576@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: ROLL WG 
Subject: Re: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 16:31:54 -0000

Pascal,

Le 11/04/2010 17:46, Pascal Thubert (pthubert) a écrit :
>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
>> Sent: Saturday, April 10, 2010 1:35 PM To: Pascal Thubert
>> (pthubert) Cc: ROLL WG Subject: Re: [Roll] Is the DAG Root a Host?
>> Can it send packets "down"?
>>
>> Le 10/04/2010 11:58, Pascal Thubert (pthubert) a écrit :
>>> Alex,
>>>
>>> the root has no edge in such instance where it is root. Yet it
>>> might participate to other instances where it is not root, other
>>> routing protocols, or simply have a static default route towards
>>> an access router. Redistribution rules such as strict ordering of
>>> instances and protocols avoid loops.
>>
>> Pascal - I have a hard time trying to understand what you mean.
>>
>> A root has no edge?  It has no link?  No interface?
>
> [Pascal] Those were your words that I was echoing.
>
>>
>> Protocols avoid loops?  I don't think so.  It's not the
>> communication protocol which avoid loop creation, but the local
>> computation of the route database (within each node) which makes
>> sure that the view of the network at each node is loop-free.
>> PRotocols simply exchange data.
>>
>
> [Pascal] I said that the redistribution rules avoid the loops between
> the protocols or the instances of a protocols.
>
> Let me suggest test to make this clearer in the spec: " RPL defines
> how a packet is routed within a given instance.  The precedence and
> redistribution of routes between different RPL instances and between
> RPL and other routing protocols is out of scope.
>
> The decision to use a given instance for a given packet belongs to
> the end points.  The endpoints signal the instance in the flow label
> of the IPv6 header for use by the RPL routers that forward the
> packet.  The mechanism for provisioning instance identifiers to the
> end points and the routers is out of scope. "
>
> Does that sound clearer?

No, sorry, I did not request new clarifying text.  I'd rather suggest
removal of existing text.

My suggestion is that the mindset changes.  Acknowledge that _every_
single movement referred to in the draft is a movement of a data
structure in the computer's memory.  And that there is no physical
mobility of nodes.

For the word "instance": I do not understand what you mean by instance.
  The draft currently says "Each such instance may serve different and
potentially antagonistic constraints or performance criteria."  I do not
see how this could work, sorry.  A routing protocol would set up a
single path not several.  App packets have a single dst address, not
several.

For the word "flow label": I disagree with the mutable Flow Label this
draft uses, because it is broken (flow labels should not change 
enroute).  I explained that 2 days ago.  I see you propose new text 
re-using Flow Labels.  Anything changed?

Alex


>
> Pascal
>>
>> Alex
>>
>>>
>>> Pascal
>>>
>>>> -----Original Message----- From: roll-bounces@ietf.org
>>>> [mailto:roll-bounces@ietf.org] On Behalf
>>> Of
>>>> Alexandru Petrescu Sent: Friday, April 09, 2010 7:35 PM To:
>>>> ROLL WG Subject: [Roll] Is the DAG Root a Host? Can it send
>>>> packets "down"?
>>>>
>>>>> Down 'O' bit:  1-bit flag indicating whether the packet is
>>> expected
>>>>> to progress up or down.  A router sets the 'O' bit when the
>>>>> packet is expect to progress down (using DAO routes), and
>>>>> resets it when forwarding towards the root of the DODAG
>>>>> iteration.  A host MUST set the bit to 0.
>>>>
>>>> Is the DAG Root a Host?  I guess so, because it has no outgoing
>>>> edge. If it's a Host it means it can't send packets "down"
>>>> (MUST set the O
>>> bit to 0,
>>>> up).  If it can't send packets down then there's a problem
>>>> because it
>>> can't
>>>> send queries.
>>>>
>>>> Or am I missing something.
>>>>
>>>> Alex
>>>>
>>>>
>>>> _______________________________________________ Roll mailing
>> list
>>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>>
>
>



From jeonggil.ko@gmail.com  Tue Mar 30 19:51:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4393A6810 for ; Tue, 30 Mar 2010 19:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-7Z3QQrbTHG for ; Tue, 30 Mar 2010 19:51:06 -0700 (PDT)
Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id 12D0D3A63EC for ; Tue, 30 Mar 2010 19:51:06 -0700 (PDT)
Received: by pzk17 with SMTP id 17so5165927pzk.5 for ; Tue, 30 Mar 2010 19:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=IOnINxDy3zuzU5zQlwhRv51nVVAmltmkB4Qz07L/dUk=; b=uzfyygGhnTRI8Y+DHPEgSXSst8G7WhyRPsw0b/wsbo5ImGGnoKDLIh8g9SaHmsET4+ Be7mKpacU90v2guVBu7ah7dpssBHcF3L3ek0P+M++y4jyNZ0xfJkHNclZ93LLxpZi/Ix oMQ1U3tnnvRKCHLWlxMV8PvTyxBtcEHhyjwHU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=bUlvN0wLxaL58n9I373YorEVzAVi0gNGhqYrerzgJyih/N4CUN3HRRzJQnySIoUrHv 3cmekrJWeQeydUqnYIILQiuPk+K+6jlU/G5KV+n8NsfybyR+ZkljTYv3DSwDxIe7R/4R 4h5lxvKos2SB1nUBfuUMnUQ8wwZlAQY/nj/ho=
Received: by 10.143.154.28 with SMTP id g28mr3158856wfo.70.1270003891259; Tue, 30 Mar 2010 19:51:31 -0700 (PDT)
Received: from [10.73.194.113] ([166.205.138.104]) by mx.google.com with ESMTPS id 23sm5524579pzk.10.2010.03.30.19.51.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 19:51:30 -0700 (PDT)
References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AAE9@XMB-AMS-107.cisco.com> <68E6C8D6-65C6-4ED7-9927-1DEEB078A404@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AAFB@XMB-AMS-107.cisco.com> <006f01cacf87$273db310$75b91930$@alexander@ekasystems.com> <5A5438DD-F6D3-4E09-A3E4-A269319F8EEC@cs.jhu.edu> <007201cacf8b$00817b90$018472b0$@alexander@ekasystems.com> <207C6B80-B20B-4553-B04C-CC88841E1002@cs.jhu.edu> <009201cacf8f$95d779c0$c1866d40$@alexander@ekasystems.com> <0146F5F5-5D51-443D-A18F-F0333759BC83@cs.jhu.edu>  <010301cad059$b8017350$280459f0$@alexander@ekasystems.com> <322B249E-6EE0-4FC8-8AC2-9AC227E4B66C@archrock.com>
Message-Id: 
From: "JeongGil Ko (John)" 
To: Jonathan Hui 
In-Reply-To: <322B249E-6EE0-4FC8-8AC2-9AC227E4B66C@archrock.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7E18)
Mime-Version: 1.0 (iPhone Mail 7E18)
Date: Tue, 30 Mar 2010 19:51:18 -0700
X-Mailman-Approved-At: Mon, 12 Apr 2010 09:47:03 -0700
Cc: "roll@ietf.org" 
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Mar 2010 02:51:07 -0000

On Mar 30, 2010, at 7:18 PM, Jonathan Hui  wrote:

>
> On Mar 30, 2010, at 3:38 PM, Roger Alexander wrote:
>> I should be a bit more precise... the Rank is used in the selection  
>> of the
>> parents but the aggregated metric advertised by the Parents plus  
>> that of the
>> local link is what determines the total aggregated path cost. With  
>> the
>> ability of the DIO to carry a Metric Container for either direction  
>> (this
>> may need further specification in the current draft) then even if the
>> metrics are drastically different a node can still determine  
>> aggregate
>> upward and downward path costs and make a choice of Preferred and DAO
>> Parents.
>>
>> Note: With multiple parents the aggregated metric advertised by a  
>> node in
>> its DIO, for either direction, may reflect some average across  
>> parents. I do
>> not believe this is currently defined.
>
>
> I agree with Roger.  Accounting for asymmetric link properties is  
> best done by representing the path cost of each direction separately  
> within the DIO and not by including some path cost in the DAO.  Like  
> building optimal paths to the root, building optimal paths from the  
> root needs to originate from the root itself so that nodes can make  
> more informed decisions when picking DAO parents.  Without any cost  
> information for paths away from the root, a node is blind in  
> choosing its DAO parents.  Utilizing the cost towards the root isn't  
> useful since the reverse cost may have no relation to it.
>

So let me see if I got it correctly. A DIO will contain rank info for  
both down and upwards paths. Right? A node can define it's preferred  
parent list (for both directions) wrt this DIO's rank information? If  
this is the case then I can see how this can work out. I see packet  
formats changing for both DIOs and DAOs here :)

John

> What I like about keeping all path cost information in the DIO is  
> that it allows a choice in whether you utilize separate path cost  
> values for the forward and reverse path or the same path cost value  
> for both directions.  The former case allows paths to optimize for  
> asymmetric link properties but comes at the price of maintaining and  
> communicate more state.  The latter is useful if you want to reduce  
> the cost of maintaining separate cost metrics at the price of  
> selecting the same route for both directions.
>
> --
> Jonathan Hui
>

From wwwrun@rfc-editor.org  Tue Apr  6 15:14:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2136A28C130; Tue,  6 Apr 2010 15:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level: 
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XRqxp3ml8Qg; Tue,  6 Apr 2010 15:14:06 -0700 (PDT)
Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id 429333A6A3B; Tue,  6 Apr 2010 15:13:42 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id EF233130001; Tue,  6 Apr 2010 15:13:40 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20100406221340.EF233130001@rfc-editor.org>
Date: Tue,  6 Apr 2010 15:13:40 -0700 (PDT)
X-Mailman-Approved-At: Mon, 12 Apr 2010 09:47:52 -0700
Cc: roll@ietf.org, rfc-editor@rfc-editor.org
Subject: [Roll] RFC 5826 on Home Automation Routing Requirements in Low-Power and Lossy Networks
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 06 Apr 2010 22:14:08 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5826

        Title:      Home Automation Routing Requirements in 
                    Low-Power and Lossy Networks 
        Author:     A. Brandt, J. Buron,
                    G. Porcu
        Status:     Informational
        Stream:     IETF
        Date:       April 2010
        Mailbox:    abr@sdesigns.dk, 
                    jbu@sdesigns.dk, 
                    gporcu@gmail.com
        Pages:      17
        Characters: 38751
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-roll-home-routing-reqs-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5826.txt

This document presents requirements specific to home control and
automation applications for Routing Over Low
power and Lossy (ROLL) networks.  In the near future, many homes will
contain high numbers of wireless devices for a wide set of
purposes.  Examples include actuators (relay, light dimmer, heating
valve), sensors (wall switch, water leak, blood pressure), and
advanced controllers (radio-frequency-based AV remote control, central
server for light and heat control).  Because such devices only cover a
limited radio range, routing is often required.  The aim of this
document is to specify the routing requirements for networks
comprising such constrained devices in a home-control and automation
environment.  This document is not an Internet Standards Track 
specification; it is published for informational purposes.

This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Wed Apr  7 06:54:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBFB3A690A for ; Wed,  7 Apr 2010 06:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kYFLFMXCHzV for ; Wed,  7 Apr 2010 06:54:27 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 0032B3A6909 for ; Wed,  7 Apr 2010 06:54:26 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id BA014130001; Wed,  7 Apr 2010 06:54:24 -0700 (PDT)
To: abr@sdesigns.dk, jbu@sdesigns.dk, gporcu@gmail.com, stbryant@cisco.com, adrian.farrel@huawei.com, jpv@cisco.com, culler@eecs.berkeley.edu
From: RFC Errata System 
Message-Id: <20100407135424.BA014130001@rfc-editor.org>
Date: Wed,  7 Apr 2010 06:54:24 -0700 (PDT)
X-Mailman-Approved-At: Mon, 12 Apr 2010 09:47:52 -0700
Cc: ah@TR-Sys.de, roll@ietf.org, rfc-editor@rfc-editor.org
Subject: [Roll] [Editorial Errata Reported] RFC5826 (2132)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 07 Apr 2010 13:54:28 -0000

The following errata report has been submitted for RFC5826,
"Home Automation Routing Requirements in Low-Power and Lossy Networks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5826&eid=2132

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes 

Section: 5, pg.15

Original Text
-------------
[[ bottom lines of page 15: ]]

                     [...].  The routing protocol(s) MUST deny service
|  to any node that has not clearly established trust with the HC-LLN.


Corrected Text
--------------
                     [...].  The routing protocol(s) MUST deny service
|  to any node that has not clearly established trust with the LLN.


Notes
-----
Rationale: The abbreviation "HC-LLN" is not defined in the document.
  (Editorial oversight; keep for update!)

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5826 (draft-ietf-roll-home-routing-reqs-11)
--------------------------------------
Title               : Home Automation Routing Requirements in Low-Power and Lossy Networks
Publication Date    : April 2010
Author(s)           : A. Brandt, J. Buron, G. Porcu
Category            : INFORMATIONAL
Source              : Routing Over Low power and Lossy networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From pthubert@cisco.com  Mon Apr 12 09:57:33 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E413A6A9D for ; Mon, 12 Apr 2010 09:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.956
X-Spam-Level: 
X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnZKGmHnhkSr for ; Mon, 12 Apr 2010 09:57:32 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 95CEC3A6AA0 for ; Mon, 12 Apr 2010 09:51:33 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsYBAFLswkuQ/uCWe2dsb2JhbACbOhUBAQsLIgYco1aYcIUMBA
X-IronPort-AV: E=Sophos;i="4.52,191,1270425600";  d="scan'208";a="5479667"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2010 16:15:45 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CGpRhl005932; Mon, 12 Apr 2010 16:51:27 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Apr 2010 18:51: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: Mon, 12 Apr 2010 18:51:22 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38AFB@XMB-AMS-107.cisco.com>
In-Reply-To: <4BC34A27.7010505@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
Thread-Index: AcraXX9pMJ9a6x5fS1S/UMgXbdhulAAAWRgA
References: <4BBF655D.1020807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com> <4BC06268.5090501@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38576@XMB-AMS-107.cisco.com> <4BC34A27.7010505@gmail.com>
From: "Pascal Thubert (pthubert)" 
To: "Alexandru Petrescu" 
X-OriginalArrivalTime: 12 Apr 2010 16:51:27.0141 (UTC) FILETIME=[64819550:01CADA60]
Cc: ROLL WG 
Subject: Re: [Roll] Is the DAG Root a Host?  Can it send packets "down"?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 16:57:33 -0000

Hi Alex

> My suggestion is that the mindset changes.  Acknowledge that _every_
> single movement referred to in the draft is a movement of a data
structure in
> the computer's memory.  And that there is no physical mobility of
nodes.

[Pascal] You're correct in that RPL should define the words it is using.
There used to be text and maybe some was lost in the editorial churn.
Move normally refers to changing the parent set within a DODAG
iteration. There is still text about that somewhere though maybe move is
used with a wider scope now.
Jump refers to changing DODAG within an instance. Migrate refers to
switching to the next iteration of a DODAG.
Whether that coincides with a physical movement is not specified and
difficult to assess. We are not precluding physical movement though.

>=20
> For the word "instance": I do not understand what you mean by
instance.
[Pascal] Maybe if you look at OSPFv3 that will help you?

>   The draft currently says "Each such instance may serve different and
> potentially antagonistic constraints or performance criteria."  I do
not see
> how this could work, sorry.  A routing protocol would set up a single
path not
> several.  App packets have a single dst address, not several.
>=20
> For the word "flow label": I disagree with the mutable Flow Label this
draft
> uses, because it is broken (flow labels should not change enroute).  I
> explained that 2 days ago.  I see you propose new text re-using Flow
Labels.

[Pascal] I've read that. You were wrong. We can change the flow label as
long as we restore it for delivery.
 Anyway the instance itself is not mutable, so in any fashion your
comment does not apply to that field.

> Anything changed?

[Pascal] ?

Pascal
>=20
>=20
> >
> > Pascal
> >>
> >> Alex
> >>
> >>>
> >>> Pascal
> >>>
> >>>> -----Original Message----- From: roll-bounces@ietf.org
> >>>> [mailto:roll-bounces@ietf.org] On Behalf
> >>> Of
> >>>> Alexandru Petrescu Sent: Friday, April 09, 2010 7:35 PM To:
> >>>> ROLL WG Subject: [Roll] Is the DAG Root a Host? Can it send
packets
> >>>> "down"?
> >>>>
> >>>>> Down 'O' bit:  1-bit flag indicating whether the packet is
> >>> expected
> >>>>> to progress up or down.  A router sets the 'O' bit when the
packet
> >>>>> is expect to progress down (using DAO routes), and resets it
when
> >>>>> forwarding towards the root of the DODAG iteration.  A host MUST
> >>>>> set the bit to 0.
> >>>>
> >>>> Is the DAG Root a Host?  I guess so, because it has no outgoing
> >>>> edge. If it's a Host it means it can't send packets "down"
> >>>> (MUST set the O
> >>> bit to 0,
> >>>> up).  If it can't send packets down then there's a problem
because
> >>>> it
> >>> can't
> >>>> send queries.
> >>>>
> >>>> Or am I missing something.
> >>>>
> >>>> Alex
> >>>>
> >>>>
> >>>> _______________________________________________ Roll
> mailing
> >> list
> >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
> >>>
> >
> >
>=20


From roger.alexander@ekasystems.com  Mon Apr 12 11:10:29 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC093A69F7 for ; Mon, 12 Apr 2010 11:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level: 
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxg0+GCWK5Nv for ; Mon, 12 Apr 2010 11:10:24 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id E90F83A68C8 for ; Mon, 12 Apr 2010 11:10:16 -0700 (PDT)
Received: (qmail 94149 invoked from network); 12 Apr 2010 18:10:08 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 11:10:08 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: fQxCovIVM1lMatTIqw3KfOE6De1ATEanfL5xrJr67t99uMzpWFEDWH4B9YNgVODsNHABuk6jAVkAaiIw09YvQGSAsvF8goQpYUVdEyo7ePBpqqPDfSfnjs53m9h8NHnlNokLWxAoWv.v3oH1czuv_93pBTPjWBzQCq2BC3CXTFcBd2QuUoZsTzQH5DCNT12DdJkmJbfIISkn6lReDP1DqzaD.b3V31F4lVUfSy4myDLQWKXRszq28KOBjdwBVPS7H8C.yiVH9WvaS8mVU6LwbvBs0WlR_Gw3aCwMWHP4MVgUj1cQh0Chmw6GME6pYKZP1eNaV2aVa4GuUa2AQprjWCmpPFBdREqlNUesJdm_z3mZLWraUPhJttVzRlD9q8TP
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Pascal Thubert \(pthubert\)'" , "'Navneet Agarwal \(navagar\)'" , "'JP Vasseur'" 
References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38575@XMB-AMS-107.cisco.com>  <3EF472F4AD7D824EA24D3197C56B61DB01184D3E@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38707@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38707@XMB-AMS-107.cisco.com>
Date: Mon, 12 Apr 2010 14:08:34 -0400
Message-ID: <028c01cada6b$2b2f81d0$818e8570$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrZnmDwgra6zJoCSw+bdqRiYthRqAAd8mswAADpsjAACfE8oA==
Content-Language: en-us
Cc: 'ROLL WG' 
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 18:10:29 -0000

Hi Navneet, Pascal,

Thanks again for the feedback on the interop and the issues highlighted.

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Monday, April 12, 2010 4:58 AM
> To: Navneet Agarwal (navagar); JP Vasseur; Roger Alexander
> Cc: ROLL WG
> Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> 
> Hi Navneet:
> 
> Please reread the thread with Roger and others.
> http://www.ietf.org/mail-archive/web/roll/current/msg03426.html
> 
> A Node selects its parents based on the metrics it gets from them and
> from whatever L2 trigger info it has about the link to those parents.
> Once the node has selected its parents and in particular the subset
> that
> are DAO parents, the reverse DAG to reach the node is decided.
> All the rest, and in particular the DAO flooding back, is about
> informing the parent(s) and the root of that decision.
> This is true in both stateful and stateless modes.
> 

Indeed, by selecting its DAO Parents, nodes are dictating the final hop of
the downward path and influencing the overall downward path selection.


> Now, it might happen that in the interest of getting multipath, the DAO
> to a destination is fanned out, that is passed to multiple parents.
> In that case, it is good to be able to track the preferred parent path
> for a number of reasons:
> - prefer that path
> - minimize stretch
> - control fan out within acceptable stretch
> 

One consequence of maintaining multiple DAO parents is the potential fan out
of routing paths. With path fan out a node may have multiple downward next
hop addresses for a given target destination address. Without some path
preference indication there is no information available if a storing node
(including the root) wishes to limit the number of downward next hops
maintained for a given address. It is thus desirable to have some means of
path control to limit fan out as well as a preference indication that can
work in conjunction with the hop-by-hop DAO exchanges. 

See the Figure below for an example in which nodes maintain two DAO Parents
each, where in the worst case the fan out that occurs after three hops
results in eight next hop downward paths from the DODAG root (LBR) to a
target node (41). Even with the hop-by-hop DAO mechanism it would be
desirable to be able to limit fan out as well as to identify path preference
and diversity at the root or other intermediate storing node. 

                    (------------LBR------------)
                    /    /   / |     | \    \   \ 
                   /    /   /  |     |  \    \   \
                  /    /   /   |     |   \    \   \
                 /    /   /    |     |    \    \   \
              (11) (12) (13) (14)   (15) (16) (17) (18)
                 \   |    |    /     \    |    |   /
                  \  |    |   /       \   |    |  /
                   \ |    |  /         \  |    | /
                  (21)   (22)           (23)  (24)
                      \    |            |    /
                       \   |            |   /
                        \  |            |  /
                         (31)          (32)
                             \        /  
                              \      /    
                               \    /      
                                (41) 

A simple path control bitmap associated with the advertised Destination
Address can be included within the DAO to address the issue of path
preference as well as control of fan out. For a network of 'non-storing'
nodes the preference indication would be processed only at the root.

With the path control byte associated with each DAO destination address, a
node will be able to specify preference among DAO parent paths and can
convey limits on the number of downward paths. This is an opportunity for
nodes to further influence the downward paths that are established and
maintained. Consistent with the DV-based RPL operation this DAO path control
mechanism must operate hop-by-hop avoiding any requirement for end-to-end
path coordination. To avoid overloading this email thread I will initiate a
separate discussion on how a path control element may be included within the
DAO. 
 

> With the current spec, we give the impression that the routing can be
> done again by the parents, because we give them metrics.
> It is particularly harmful in stateful mode when we give the impression
> that we are doing some form of Link State operation at the root.
> In fact all the root needs is to recursively follow the track of
> preferred parent, and limit the stretch when that cannot be done.
> 

I do agree entirely and would reiterate that from the perspective of a
network with storing nodes there is no requirement for metric or Rank
information to be included in the DAO. Rank information is not required in
conjunction with routing table entries and if included at all within the DAO
would satisfy only a local need to reconfirm the Parent-Child relationship
to account for changes that may have occurred between the time of sending of
a DIO and the receipt of a new DAO (potentially as part of the acknowledged
DAO exchange).
 
> All the information we need to do this is the usual preference that we
> inherited from RFC 4191 and use in a number of places in RPL already.
> 
> The metrics, OF, etc... is only needed in DIO processing when the DAG
> is
> built. The rest of RPL can be and should be completely generic.
> If we want to control the complexity, I strongly suggest we leave it at
> that.

+1 on maintaining metrics, OF, and other items of general protocol
configuration within the DIO only.
 
> 
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: Navneet Agarwal (navagar)
> > Sent: Monday, April 12, 2010 10:16 AM
> > To: JP Vasseur; Pascal Thubert (pthubert)
> > Cc: ROLL WG
> > Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Hi:
> >
> > > -----Original Message-----
> > > From: JP Vasseur [mailto:jpv@cisco.com]
> > > Sent: Sunday, April 11, 2010 11:13 PM
> > > To: Pascal Thubert (pthubert)
> > > Cc: Navneet Agarwal (navagar); ROLL WG
> > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >
> > >
> > > On Apr 11, 2010, at 5:40 PM, Pascal Thubert (pthubert) wrote:
> > >
> > > > Hi Navneet:
> > > >
> > > > For issue 1), the most recent discussion tends to remove
> > > the DAO rank
> > > > and metrics completely. The reason is that with RPL, the
> > > node selects
> > > > its DAO parent and thus decides of the routing.
> > >
> > > Let's still discuss on having the metric in DAO as an option
> though.
> > >
> > > > Passing a simple preference provides a better indication that the
> > > > parents (or the root in source route mode) can only root along
> the
> > > > most preferred path as the nodes have decided it.
> > NAV> How would the node decide the preference value?. I was thinking
> that
> > if a metric is explicitly defined in the DAO it may be more
> transparent for
> > decision making in a mixed environment...imo. What do you think?
> >
> >
> >
> > > >
> > > > Regarding issue 2) I think we should use a traditional lollipop
> and
> > > > then Serial Number Arithmetic as defined in RFC 1982. The
> straight
> > > > part of the lollipop could use sequence 0 to 15, and then
> > > the number
> > > > would increment skipping those values as it wraps, what do
> > > you think?
> > NAV> Is using 255 as the starting sequence number simpler than using
> the
> > above logic?
> >
> > Thx
> >
> > Regards,
> > Navneet
> > > >
> > > > Cheers;
> > > >
> > > > Pascal
> > > >
> > > >> -----Original Message-----
> > > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]
> > > On Behalf
> > > > Of
> > > >> Navneet Agarwal (navagar)
> > > >> Sent: Sunday, April 11, 2010 7:22 AM
> > > >> To: ROLL WG
> > > >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > > >>
> > > >> Hi:
> > > >> I have two feedbacks from the router testing perspective.
> > > >>
> > > >> Feedback-I:
> > > >> DAO rank: It seems there very couple of different
> > > interpretations for
> > > > setting
> > > >> this value.
> > > >> A. Several implementations were setting the DAO rank to be equal
> to
> > > > the
> > > >> node rank (value sent in DIO rank). Each node relays this
> > > info in the
> > > > DAO
> > > >> towards the root. However this does not convey any
> differentiating
> > > > info to
> > > >> the receiving nodes when the DAOs are received thru
> > > multiple paths in
> > > > order
> > > >> to install the best route.
> > > >> B. The other implementation was to set the value to 0 (or 1) by
> the
> > > > node and
> > > >> have the intermediate nodes increment it as the DAO rides up to
> the
> > > > root.
> > > >> The DAO rank in this case is more of a hop count and the
> receiving
> > > > nodes can
> > > >> make a decision based on the lowest value received when
> installing
> > > >> the
> > > > DAO
> > > >> route.
> > > >> Pros: Decision is optimized based on hopcount. Relatively
> simple.
> > > >> Cons: Hopcount does not take link cost into account.
> > > >> C. A third proposal was to set the DAO rank equal to the node
> rank
> > > >> and
> > > > a link
> > > >> cost in the metric container as each nodes propagates the DAO.
> The
> > > > receiving
> > > >> nodes would make a decision based on the link cost.
> > > >> Pros: Decision is optimized based on link cost
> > > >> Cons: The DAOs would need to carry additional info in the packet
> > > > (bigger
> > > >> DAOs) and more processing needed in the nodes to parse and
> process.
> > > >>
> > > >> I think we need some more details the spec for describing
> > > the value
> > > >> to
> > > > be set
> > > >> in DAO rank.
> > > >>
> > > >>
> > > >> Feedback-II:
> > > >> DIO Sequence number: The issue was what should be the
> > > initial value
> > > >> of
> > > > this
> > > >> field. The spec is not clear on what should be the initial
> > > value set
> > > > by the root.
> > > >> This has implications at the LBR in reload/reboot conditions.
> For
> > > > example, if
> > > >> the initial value is set to 1 and is incremented to say
> > > 10. When the
> > > > LBR
> > > >> reloads/reboots, it would start the sequence number with 1 but
> its
> > > > DIOs will
> > > >> be rejected by the nodes as having stale sequence number.
> > > The LBR can
> > > >> store the sequence in persistent memory. An easier option could
> be
> > > >> use
> > > > 255
> > > >> as the starting sequence number. Using this value will
> > > make sure that
> > > > the
> > > >> sequence number is always valid.
> > > >>
> > > >> Comments?
> > > >>
> > > >> Thanks
> > > >>
> > > >> Regards,
> > > >> Navneet
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: roll-bounces@ietf.org
> > > [mailto:roll-bounces@ietf.org] On Behalf
> > > >>> Of Mathilde Durvy (mdurvy)
> > > >>> Sent: Thursday, April 08, 2010 1:46 PM
> > > >>> To: JP Vasseur
> > > >>> Cc: ROLL WG
> > > >>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > > >>>
> > > >>> Dear All,
> > > >>>
> > > >>> Following the discussion on the mailing list I just wanted to
> > > > clarify
> > > >>> a few things so that we can find the best way to interact in
> the
> > > >>> future.
> > > >>>
> > > >>> - We were proposed a slot to announce this first interop event
> > > > during
> > > >>> the ROLL WG meeting, future events may be advertised only
> > > on an IPSO
> > > >>> web-site if this is preferred by the WG.
> > > >>> - IPSO is not defining standards. It is organizing
> > > interop events to
> > > >>> ensure that different implementations of the same
> > > standard do work
> > > >>> together. The current status is that you have to pay a
> membership
> > > > fee
> > > >>> to participate in these events (and indeed these events
> > > take work,
> > > >>> prior preparation, and money to organize).
> > > >>> - We understand (at least) some people are still interested in
> > > > interop
> > > >>> event feedback. This will be given on individual, voluntary,
> basis
> > > > by
> > > >>> the participants of the interop event.
> > > >>>
> > > >>> Best,
> > > >>> Mathilde
> > > >>>
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: JP Vasseur [mailto:jpv@cisco.com]
> > > >>> Sent: vendredi, 26. mars 2010 03:55
> > > >>> To: Mathilde Durvy (mdurvy)
> > > >>> Cc: ROLL WG
> > > >>> Subject: IPSO Interop event - Feed-back welcome
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Just re-enforcing my comments during the ROLL WG meeting ...
> > > >>> any feed- back from the IPSO interop about any issues
> > > that you may
> > > >>> have found would be extremely useful to continue to improve our
> > > > spec.
> > > >>> Feel free to also share good news.
> > > >>>
> > > >>> Thanks.
> > > >>>
> > > >>> JP.
> > > >>>
> > > >> _______________________________________________
> > > >> Roll mailing list
> > > >> Roll@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/roll
> > > > _______________________________________________
> > > > Roll mailing list
> > > > Roll@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/roll
> > >
> > >


From roger.alexander@ekasystems.com  Mon Apr 12 11:31:16 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4DF3A6AA9 for ; Mon, 12 Apr 2010 11:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level: 
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvMztD9Fpant for ; Mon, 12 Apr 2010 11:31:15 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id BAD5F28C187 for ; Mon, 12 Apr 2010 11:30:00 -0700 (PDT)
Received: (qmail 25903 invoked from network); 12 Apr 2010 18:29:55 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp112.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 11:29:54 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: sDIiTzAVM1khLRAgwZqPT5ciQROosRxtMbUlCyXgsWyU6CaS9dN6LeFDUvgaTI6Vigjh_X55tCkePXwyljUwO.4FmIubYinel4ZiqJnBVJHPDwQyMZCcwXSdwklXkZRDPNfAZb07K6G1WTr2R8AHmqOeoK9tjl.1HeHibnfY8oowxp1zGhJNNDfC7ng6g1Ojnb6ueRVKg_ZEKxpwtVViwI74CMkTEouuovWdFM8ytDCi0KB1XBBOOfsk0opGgbLUcAF0TeKcyTg3.bGIoJKLdDOE8EprisZQdIE5T_BZdgt1msL3MWFztRhLIgH_q8DJwf7Uyf02tLFXbu4SlAF2iRJm.Bzk4nAztMMzEhr0hcKaue2fclTMxq8k5IHjYmav
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Pascal Thubert \(pthubert\)'" , "'Mathilde Durvy \(mdurvy\)'" , "'Navneet Agarwal \(navagar\)'" , "'ROLL WG'" 
References: 	<8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>	<3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com> <027601cada59$a0c46350$e24d29f0$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38AD8@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38AD8@XMB-AMS-107.cisco.com>
Date: Mon, 12 Apr 2010 14:28:19 -0400
Message-ID: <029001cada6d$ee7a8de0$cb6fa9a0$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAOMtcQAAN2GfAAAOwoyAAAPs/oA==
Content-Language: en-us
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 18:31:16 -0000

Hi Pascal,

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Monday, April 12, 2010 12:23 PM
> To: Roger Alexander; Mathilde Durvy (mdurvy); Navneet Agarwal
> (navagar); ROLL WG
> Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> 
> Hi Roger:
> 
> I do believe like you do that incremental updates will be a nice
> feature
> and I'll support it in due time. I'm unsure we can fit that in the
> current RPL version though, because even if it works better in a large
> scale stable network, it has probably a less generic applicability than
> the simple repeat over and over method that RPL uses today. But that's
> just my vote.

In the interest of continued movement on the core spec. this item can be
addressed as part of a specific domain applicability provided there are
elements in the base DAO/DIO structure that will permit later inclusion.

> 
> For the steps that will make it possible (ask the DAO and multiple
> targets in a DAO) I think they make sense in the current RPL for merits
> of their own. 

I certainly support the DAO Acknowledgment and the option to include
multiple targets in a DAO message as capabilities that can have general
applicability.

My suggestion here is to have a target option that would
> be valid in both DIO and DAO. In the DIO, the use would be the targeted
> DIO that we discussed for P2P and so on, and in the DAO, that would be
> advertising that target (eventually as a response to the DIO above).
> 
> What do you think?
>

Sure. To the extent that these measures can be defined in ways to address
requirements across the multiple RPL domain constituents that would indeed
be the preferred way to proceed.
 
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
> > Roger Alexander
> > Sent: Monday, April 12, 2010 6:03 PM
> > To: Mathilde Durvy (mdurvy); Navneet Agarwal (navagar); 'ROLL WG'
> > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Hi Navneet, Mathilde,
> >
> > Thanks for the feedback on the interop event.
> >
> > Roger
> >
> > > -----Original Message-----
> > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> Behalf
> > > Of Mathilde Durvy (mdurvy)
> > > Sent: Monday, April 12, 2010 4:16 AM
> > > To: Navneet Agarwal (navagar); ROLL WG
> > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >
> > > Hi Navneet,
> > >
> > > Thanks for your feedback. I fully agree with the issues you
> described.
> > > I just wanted to mention that our interop event was based on
> revision
> > > 05 of the RPL draft.
> > >
> > > My general impression is that the "DIO part" of RPL is stable,
> working
> > > well, and it's probably a good time to freeze the specs there.
> > > Concerning the "DAO part", we could only test the "fully storing"
> mode.
> > > What I observed was that except for the "DAO rank" issue below,
> there
> > > was no interop problems but the scalability of the solution needs
> to
> > > be improved  (the first think to do would be to agree on a way to
> > > include several prefixes in a DAO packet).
> >
> > I would very strongly endorse this direction of multiple prefixes
> (the
> option
> > to carry full or partial sub-DAG stack) within the DAO message. This
> capability
> > together with the ability to support incremental update of changes
> between
> > a node and its DAO parents will greatly improve the scalability of
> the
> solution
> > for networks with storing nodes where nodes can take advantage of
> > acknowledged/cached information to limit repetitive DAO
> transmissions.
> >
> >
> > > Also I think RPL is currently at the right level of complexity for
> the
> > > platforms it's targeting however we should be careful not to add to
> > > much extra features.
> > >
> > > Best,
> > > Mathilde
> > >
> > > -----Original Message-----
> > > From: Navneet Agarwal (navagar)
> > > Sent: dimanche, 11. avril 2010 07:22
> > > To: ROLL WG
> > > Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal (navagar)
> > > Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> > >
> > > Hi:
> > > I have two feedbacks from the router testing perspective.
> > >
> > > Feedback-I:
> > > DAO rank: It seems there very couple of different interpretations
> for
> > > setting this value.
> > > A. Several implementations were setting the DAO rank to be equal to
> > > the node rank (value sent in DIO rank). Each node relays this info
> in
> > > the DAO towards the root. However this does not convey any
> > > differentiating info to the receiving nodes when the DAOs are
> received
> > > thru multiple paths in order to install the best route.
> > > B. The other implementation was to set the value to 0 (or 1) by the
> > > node and have the intermediate nodes increment it as the DAO rides
> up
> > > to the root.
> > > The DAO rank in this case is more of a hop count and the receiving
> > > nodes can make a decision based on the lowest value received when
> > > installing the DAO route.
> > > Pros: Decision is optimized based on hopcount. Relatively simple.
> > > Cons: Hopcount does not take link cost into account.
> > > C. A third proposal was to set the DAO rank equal to the node rank
> and
> > > a link cost in the metric container as each nodes propagates the
> DAO.
> > > The receiving nodes would make a decision based on the link cost.
> > > Pros: Decision is optimized based on link cost
> > > Cons: The DAOs would need to carry additional info in the packet
> > > (bigger
> > > DAOs) and more processing needed in the nodes to parse and process.
> > >
> > > I think we need some more details the spec for describing the value
> to
> > > be set in DAO rank.
> > >
> > >
> > > Feedback-II:
> > > DIO Sequence number: The issue was what should be the initial value
> of
> > > this field. The spec is not clear on what should be the initial
> value
> > > set by the root. This has implications at the LBR in reload/reboot
> > > conditions. For example, if the initial value is set to 1 and is
> > > incremented to say 10. When the LBR reloads/reboots, it would start
> > > the sequence number with 1 but its DIOs will be rejected by the
> nodes
> > > as having stale sequence number. The LBR can store the sequence in
> > > persistent memory. An easier option could be use
> > > 255 as the starting sequence number. Using this value will make
> sure
> > > that the sequence number is always valid.
> > >
> > > Comments?
> > >
> > > Thanks
> > >
> > > Regards,
> > > Navneet
> > >
> > > > -----Original Message-----
> > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> Behalf
> > > > Of Mathilde Durvy (mdurvy)
> > > > Sent: Thursday, April 08, 2010 1:46 PM
> > > > To: JP Vasseur
> > > > Cc: ROLL WG
> > > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > > >
> > > > Dear All,
> > > >
> > > > Following the discussion on the mailing list I just wanted to
> > > > clarify a few things so that we can find the best way to interact
> in
> > > > the future.
> > > >
> > > > - We were proposed a slot to announce this first interop event
> > > > during the ROLL WG meeting, future events may be advertised only
> on
> > > > an IPSO web-site if this is preferred by the WG.
> > > > - IPSO is not defining standards. It is organizing interop events
> to
> > > > ensure that different implementations of the same standard do
> work
> > > > together. The current status is that you have to pay a membership
> > > > fee to participate in these events (and indeed these events take
> > > > work, prior preparation, and money to organize).
> > > > - We understand (at least) some people are still interested in
> > > interop
> > > > event feedback. This will be given on individual, voluntary,
> basis
> > > > by the participants of the interop event.
> > > >
> > > > Best,
> > > > Mathilde
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: JP Vasseur [mailto:jpv@cisco.com]
> > > > Sent: vendredi, 26. mars 2010 03:55
> > > > To: Mathilde Durvy (mdurvy)
> > > > Cc: ROLL WG
> > > > Subject: IPSO Interop event - Feed-back welcome
> > > >
> > > > Hi,
> > > >
> > > > Just re-enforcing my comments during the ROLL WG meeting ...
> > > > any feed- back from the IPSO interop about any issues that you
> may
> > > > have found would be extremely useful to continue to improve our
> spec.
> > > > Feel free to also share good news.
> > > >
> > > > Thanks.
> > > >
> > > > JP.
> > > >
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll


From jhui@archrock.com  Mon Apr 12 12:58:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE56628C1A1 for ; Mon, 12 Apr 2010 12:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUK0KUEJ4na3 for ; Mon, 12 Apr 2010 12:58:41 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 466E128C19E for ; Mon, 12 Apr 2010 12:58:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B83E0AF95D; Mon, 12 Apr 2010 08:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcGynR-Wr5fI; Mon, 12 Apr 2010 08:08:56 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 0E0FEAF91E; Mon, 12 Apr 2010 08:08:56 -0700 (PDT)
Message-Id: <08F93B98-062A-4CE2-A3C2-5E82FEDB77F2@archrock.com>
From: Jonathan Hui 
To: Richard Kelsey 
In-Reply-To: <87eiik3hsp.fsf@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 12 Apr 2010 08:08:56 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com> <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com> <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org> <87eiik3hsp.fsf@kelsey-ws.hq.ember.com>
X-Mailer: Apple Mail (2.936)
Cc: roll@ietf.org, Daniel.Popa@itron.com
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 19:58:44 -0000

On Apr 12, 2010, at 6:46 AM, Richard Kelsey wrote:

>> From: Carsten Bormann 
>> Date: Fri, 9 Apr 2010 22:54:17 +0200
>> Cc: roll@ietf.org, "Popa, Daniel" 
>>
>> On Apr 9, 2010, at 18:34, Jonathan Hui wrote:
>>
>>> the RPL option as simple container and is flexible in what we put  
>>> in it
>>
>> One comment in 6man (was that by Erik?) was that this is not the only
>> place to put it -- we might as well insert a header in front of the
>> IPv6 header like MPLS does.  Now all this talk about forwarding by
>> tags instead of IP addresses puts a pretty eerie ring on that...
>
> Why aren't we inserting a header in front of the IPv6
> header like MPLS does?  Especially as the hop-by-hop
> option seems to be getting more complicated (alignment,
> maximum size)?  I am not advocating doing so, just
> wondering why we don't.

It was argued to me that we also need to consider the case of source  
routing on full IPv6 addresses for "completeness" or as a "base".  Is  
that no longer the case?  I'm all for simplicity and limiting options...

As for use of an MPLS-like header, here are the arguments I see.   
Inserting a layer below IPv6 means no changes are made to the IPv6  
packet for forwarding within the RPL domain, forwarding is potentially  
simpler if the header is easier to process than the IPv6 + Extension  
header, and convenient if the IPv6 header fields are mostly  
unnecessary for forwarding within the RPL domain.  On the other hand,  
keeping one layer means you can continue to utilize fields in the IPv6  
header (flow label, hop limit, etc.), re-use whatever hop-by-hop  
options we define, and use ICMPv6 directly (e.g. traceroute just  
works).  On the last point, if we decide to go with an MPLS-like  
header, it might be nice to have something like RFC 4950 as well.   
Also, is there precedent on how record-route would work with labels?

My main concern is going down a path where we have to define two  
different ways of implementing the same mechanisms (loop detection,  
source routing, error reporting, etc.).  I don't have a particular  
view at this point on which way to go, but I would prefer limiting it  
to one branch if at all possible.

--
Jonathan Hui


From jhui@archrock.com  Mon Apr 12 13:13:49 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF813A6AC5 for ; Mon, 12 Apr 2010 13:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45xkFCCB7CHr for ; Mon, 12 Apr 2010 13:13:47 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 900793A6AC2 for ; Mon, 12 Apr 2010 13:13:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 91A51AF9AC; Mon, 12 Apr 2010 09:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkVrWMmXRpAq; Mon, 12 Apr 2010 09:38:12 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id D990CAF99C; Mon, 12 Apr 2010 09:38:11 -0700 (PDT)
Message-Id: 
From: Jonathan Hui 
To: Richard Kelsey 
In-Reply-To: <87eiik3hsp.fsf@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 12 Apr 2010 09:31:39 -0700
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com> <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com> <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org> <87eiik3hsp.fsf@kelsey-ws.hq.ember.com>
X-Mailer: Apple Mail (2.936)
Cc: ROLL WG 
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 20:13:49 -0000

On Apr 12, 2010, at 6:46 AM, Richard Kelsey wrote:

> Why aren't we inserting a header in front of the IPv6
> header like MPLS does?  Especially as the hop-by-hop
> option seems to be getting more complicated (alignment,
> maximum size)?  I am not advocating doing so, just
> wondering why we don't.
>                             -Richard Kelsey


It was argued to me that we also need to consider the case of source  
routing on full IPv6 addresses for "completeness" or as a "base".  Is  
that no longer the case?  I'm all for simplicity and limiting options...

As for use of an MPLS-like header, here are the arguments I see.   
Inserting a layer below IPv6 means no changes are made to the IPv6  
packet for forwarding within the RPL domain, forwarding is potentially  
simpler if the header is easier to process than the IPv6 + Extension  
header, and convenient if the IPv6 header fields are mostly  
unnecessary for forwarding within the RPL domain. On the other hand,  
keeping one layer means you can continue to utilize fields in the IPv6  
header (flow label, hop limit, etc.), re-use whatever hop-by-hop  
options we define, and use ICMPv6 directly (e.g. traceroute just  
works).  On the last point, if we decide to go with an MPLS-like  
header, it might be nice to have something like RFC 4950 as well.   
Also, is there precedent on how record-route would work with labels?

My main concern is going down a path where we have to define two  
different ways of implementing the same mechanisms (loop detection,  
source routing, error reporting, etc.).  I don't have a particular  
view at this point on which way to go, but I would prefer limiting it  
to one branch if at all possible.

--
Jonathan Hui


From cabo@tzi.org  Mon Apr 12 13:18:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D48C3A6AB2 for ; Mon, 12 Apr 2010 13:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.877
X-Spam-Level: 
X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifcoTfViI5Ke for ; Mon, 12 Apr 2010 13:18:24 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7F6703A6830 for ; Mon, 12 Apr 2010 13:18:23 -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 o3CKHd6G016748; Mon, 12 Apr 2010 22:17:39 +0200 (CEST)
Received: from [192.168.217.101] (p5489B116.dip.t-dialin.net [84.137.177.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 54CE1C16B;  Mon, 12 Apr 2010 22:17:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <08F93B98-062A-4CE2-A3C2-5E82FEDB77F2@archrock.com>
Date: Mon, 12 Apr 2010 22:17:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AE60700-0C8F-4BA6-947E-A0C299F7CC0B@tzi.org>
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> <4BBF5499.8030306@gridmerge.com> <65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com> <35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org> <87eiik3hsp.fsf@kelsey-ws.hq.ember.com> <08F93B98-062A-4CE2-A3C2-5E82FEDB77F2@archrock.com>
To: Jonathan Hui 
X-Mailer: Apple Mail (2.1078)
Cc: roll@ietf.org, Daniel.Popa@itron.com
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 20:18:26 -0000

On Apr 12, 2010, at 17:08, Jonathan Hui wrote:

> Inserting a layer below IPv6

Does it have to be a whole layer?  (We might as well do a real meshing =
protocol then...)
The prepended shim header might work together with the IPv6 header, =
e.g., use its hop limit, and possibly even other IPv6 fields (including =
hop-by-hop options that are closer to the usual IPv6 ones, even though I =
don't know what those would be).

Another way to think about this: as a way to "header-compress" the IPv6 =
hbh option...

The disadvantage is that we need a stack of "Y over X" documents, where =
Y is this new shim thing and X are the L2s we want to use.

Gruesse, Carsten


From d.sturek@att.net  Mon Apr 12 13:23:39 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614BF28C13F for ; Mon, 12 Apr 2010 13:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.804
X-Spam-Level: 
X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 125nZbxuv1MK for ; Mon, 12 Apr 2010 13:23:38 -0700 (PDT)
Received: from smtp128-mob.biz.mail.mud.yahoo.com (smtp128-mob.biz.mail.mud.yahoo.com [209.191.85.15]) by core3.amsl.com (Postfix) with SMTP id 1B97E28C1A1 for ; Mon, 12 Apr 2010 13:22:53 -0700 (PDT)
Received: (qmail 16957 invoked from network); 12 Apr 2010 20:22:41 -0000
Received: from bda-67-223-67-25.bise.na.blackberry.com (d.sturek@67.223.67.25 with xymcookie) by smtp128-mob.biz.mail.mud.yahoo.com with SMTP; 12 Apr 2010 13:22:41 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: _OJrlagVM1l4ReNaMp5iPde7KML44Oy5EjterkqZC_zoSBNbSW90s7arbC.yxSMBrEC8jamDkOkeVQA8j.9aWvkt5sI8lU.XYLH_VYM_ww2hj.GD3jn6rZqsK7O92VBUeHDMZV0BfV4mnIX6HuFzB5KcfMQx0U8iNjGjE1hqh74acmk5Nn4Rr6OeXvdHl9AZFRk5J1Er3rOydkTefK06T06F28bIa.P3NjuhjKQhCA98zCV5bzfEstXZOAQEKnKtJiXpOxYnlnPu9qg.J8u0UvDAqIJRpNIMQ0kdyARVTldEg1PCp04-
X-Yahoo-Newman-Property: ymail-3
X-rim-org-msg-ref-id: 1032461003
Message-ID: <1032461003-1271103759-cardhu_decombobulator_blackberry.rim.net-2007365716-@bda054.bisx.prod.on.blackberry>
Content-Transfer-Encoding: base64
X-Priority: Normal
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>	 <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com><88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com><4BBF5499.8030306@gridmerge.com><65BE36FC-A9ED-476C-A94D-57C4CD9D7CD2@archrock.com><35C9E6C0-3EDF-4F58-AE26-6A09A429EB20@tzi.org><87eiik3hsp.fsf@kelsey-ws.hq.ember.com><08F93B98-062A-4CE2-A3C2-5E82FEDB77F2@archrock.com><4AE60700-0C8F-4BA6-947E-A0C299F7CC0B@tzi.org>
In-Reply-To: <4AE60700-0C8F-4BA6-947E-A0C299F7CC0B@tzi.org>
Sensitivity: Normal
Importance: Normal
To: "Carsten Bormann" , roll-bounces@ietf.org, "Jonathan Hui" 
From: d.sturek@att.net
Date: Mon, 12 Apr 2010 20:26:35 +0000
Content-Type: text/plain
MIME-Version: 1.0
Cc: roll@ietf.org, Daniel.Popa@itron.com
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Apr 2010 20:23:39 -0000

TGV0cyB0cnkgdHJ5IG5vdCB0byBjcmVhdGUgc3RhY2tzIG9mIHkgb3ZlciB4IGRvY3VtZW50cy4g
IA0KDQpEb24NClNlbnQgdmlhIEJsYWNrQmVycnkgZnJvbSBULU1vYmlsZQ0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpE
YXRlOiBNb24sIDEyIEFwciAyMDEwIDIyOjE3OjM2IA0KVG86IEpvbmF0aGFuIEh1aTxqaHVpQGFy
Y2hyb2NrLmNvbT4NCkNjOiA8cm9sbEBpZXRmLm9yZz47IDxEYW5pZWwuUG9wYUBpdHJvbi5jb20+
DQpTdWJqZWN0OiBSZTogW1JvbGxdIFByb3Bvc2FsIGZvciBTb3VyY2UgUm91dGluZw0KCUhlYWRl
ckZvcm1hdGFuZAlTb3VyY2VSb3V0aW5nT3BlcmF0aW9ucw0KDQpPbiBBcHIgMTIsIDIwMTAsIGF0
IDE3OjA4LCBKb25hdGhhbiBIdWkgd3JvdGU6DQoNCj4gSW5zZXJ0aW5nIGEgbGF5ZXIgYmVsb3cg
SVB2Ng0KDQpEb2VzIGl0IGhhdmUgdG8gYmUgYSB3aG9sZSBsYXllcj8gIChXZSBtaWdodCBhcyB3
ZWxsIGRvIGEgcmVhbCBtZXNoaW5nIHByb3RvY29sIHRoZW4uLi4pDQpUaGUgcHJlcGVuZGVkIHNo
aW0gaGVhZGVyIG1pZ2h0IHdvcmsgdG9nZXRoZXIgd2l0aCB0aGUgSVB2NiBoZWFkZXIsIGUuZy4s
IHVzZSBpdHMgaG9wIGxpbWl0LCBhbmQgcG9zc2libHkgZXZlbiBvdGhlciBJUHY2IGZpZWxkcyAo
aW5jbHVkaW5nIGhvcC1ieS1ob3Agb3B0aW9ucyB0aGF0IGFyZSBjbG9zZXIgdG8gdGhlIHVzdWFs
IElQdjYgb25lcywgZXZlbiB0aG91Z2ggSSBkb24ndCBrbm93IHdoYXQgdGhvc2Ugd291bGQgYmUp
Lg0KDQpBbm90aGVyIHdheSB0byB0aGluayBhYm91dCB0aGlzOiBhcyBhIHdheSB0byAiaGVhZGVy
LWNvbXByZXNzIiB0aGUgSVB2NiBoYmggb3B0aW9uLi4uDQoNClRoZSBkaXNhZHZhbnRhZ2UgaXMg
dGhhdCB3ZSBuZWVkIGEgc3RhY2sgb2YgIlkgb3ZlciBYIiBkb2N1bWVudHMsIHdoZXJlIFkgaXMg
dGhpcyBuZXcgc2hpbSB0aGluZyBhbmQgWCBhcmUgdGhlIEwycyB3ZSB3YW50IHRvIHVzZS4NCg0K
R3J1ZXNzZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K



From jreddy@ti.com  Mon Apr 12 14:22:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF6228C1BE for ; Mon, 12 Apr 2010 14:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Tei-ySLDTZ for ; Mon, 12 Apr 2010 14:22:09 -0700 (PDT)
Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by core3.amsl.com (Postfix) with ESMTP id 54C193A6828 for ; Mon, 12 Apr 2010 14:20:30 -0700 (PDT)
Received: from dlep34.itg.ti.com ([157.170.170.115]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id o3CLKOmQ025373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Apr 2010 16:20:24 -0500
Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep34.itg.ti.com (8.13.7/8.13.7) with ESMTP id o3CLKOar014621 for ; Mon, 12 Apr 2010 16:20:24 -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 o3CLKOLj016271 for ; Mon, 12 Apr 2010 16:20:24 -0500 (CDT)
Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Mon, 12 Apr 2010 16:20:24 -0500
From: "Reddy, Joseph" 
To: "roll@ietf.org" 
Date: Mon, 12 Apr 2010 16:20:23 -0500
Thread-Topic: Feedback from ZigBee interop event
Thread-Index: AcrahfZOKJ7+L8GhT0K9axsh+V7e5Q==
Message-ID: 
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_DE92901D19672647B9ADB0CB4994986504C9435778dlee02enttico_"
MIME-Version: 1.0
Subject: [Roll] Feedback from ZigBee interop event
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 21:22:15 -0000

--_000_DE92901D19672647B9ADB0CB4994986504C9435778dlee02enttico_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,

I would like to share some feedback from the recent interop event held by t=
he ZigBee Alliance that was attended by several 802.15.4 platform vendors. =
At this event, the main focus was on testing TCP, RPL and 6lowpan protocols=
.

For the RPL protocol, the DAG formation and data transmission "up" towards =
the root were tested successfully among the various platforms. In addition =
to the feedback on the exiting spec ( see below ), the main request is to e=
nsure the spec is quickly updated with the routing/forwarding for "downward=
s" paths so we can move forward with our testing.

-Regards, Joseph


1. Need clarification on the Rank and DagRank. The root rank has value of 1=
 but not clear if that is just the integer part or not.

2. In OF0, the values for minRankIncrease and maxRankIncrease take value of=
 256 which cannot be represented in the DoDAG config suboption ( which allo=
ws only 1 byte ). This needs to be fixed in the spec. Also, re-consider if =
we really need fractional part in the rank, it doesn't seem to be very usef=
ul.

3. Clarify the IP source address for DIS/DAO packets - should this be the l=
ink local or global address ( or either ) ?

4. Need clarification on flowlabel. Currently it is not possible to impleme=
nt as defined ( without layer violations ) since a node will need to know i=
f the next hop is the final destination and if the previous hop was the ori=
ginator of the packet.....current implementations have removed flow label v=
alidation

5. Need clarification on the use of the destination prefix. How many of the=
m can be included in a DIO ? Is this intended to be the prefix of the 6lowp=
an or is this a prefix that can be reached by the root node ( on the wired =
side ) ?

6. Does RPL intend to define messages to allow neighboring nodes to exchang=
e bidirectional link quality estimates between themselves ?






--_000_DE92901D19672647B9ADB0CB4994986504C9435778dlee02enttico_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











     
    

    Hi,
    

     
    

    I would like to share some feedback from the recent i=
nterop event held by the ZigBee Alliance that was attended by several 802.1=
5.4 platform vendors. At this event, the main focus was on testing TCP, RPL=
 and 6lowpan protocols. 
    

     
    

    For the RPL protocol, the DAG formation and data tran=
smission "up" towards the root were tested successfully among the=
 various platforms. In addition to the feedback on the exiting spec ( see b=
elow ), the main request is to ensure the spec
is quickly updated with the routing/forwarding for "downwards" pa=
ths so we can move forward with our testing. 
    

     
    

    -Regards, Joseph
    

     
    

     
    

    1. Need clarification on the Ran=
k and DagRank. The root rank has value of 1 but not clear if that is just t=
he integer part or not. 
    

     
    

    2. In OF0, the va=
lues for minRankIncrease and maxRankIncrease take value of 256 which cannot=
 be represented in the DoDAG config suboption ( which allows only 1 byte ).=
 This needs to be fixed in the spec. Also,
re-consider if we really need fractional part i=
n the rank, it doesn’t seem to be very useful.
    

     
    

    3. Clarify the IP=
 source address for DIS/DAO packets - should this be the link local or glob=
al address ( or either ) ?
    

     
    

    4. Need clarifica=
tion on flowlabel. Currently it is not possible to implement as defi=
ned ( without layer violations ) since a node will nee=
d to know if the next hop is the
final destination and if the previous hop was the originator of the packet…..current implementations have =
removed flow label validation 
    

     
    

    5. Need clarifica=
tion on the use of the destination prefix. How many of them can be included in a DIO ? =
Is this intended to be the prefix of the 6lowpan
or is this a prefix that can be reached by the root node ( on the wired sid=
e ) ?
    

     
    

    6. Does RPL intend to define messages to allow neighb=
oring nodes to exchange bidirectional link quality estimates between themse=
lves ?
    

     
    

     
    

     
    

     
    

     
    
    



--_000_DE92901D19672647B9ADB0CB4994986504C9435778dlee02enttico_--

From alexandru.petrescu@gmail.com  Mon Apr 12 15:15:09 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A543A67B7 for ; Mon, 12 Apr 2010 15:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.284
X-Spam-Level: 
X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=0.965,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DopfLvplVm+5 for ; Mon, 12 Apr 2010 15:14:53 -0700 (PDT)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 98EAE3A6948 for ; Mon, 12 Apr 2010 15:14:08 -0700 (PDT)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 25D89D480CF; Tue, 13 Apr 2010 00:13:59 +0200 (CEST)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id DEC9CD480A9; Tue, 13 Apr 2010 00:13:56 +0200 (CEST)
Message-ID: <4BC39B24.3010801@gmail.com>
Date: Tue, 13 Apr 2010 00:13:56 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
References: <4BBF655D.1020807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38510@XMB-AMS-107.cisco.com> <4BC06268.5090501@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38576@XMB-AMS-107.cisco.com> <4BC34A27.7010505@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38AFB@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38AFB@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100412-1, 12/04/2010), Outbound message
X-Antivirus-Status: Clean
Cc: ROLL WG 
Subject: Re: [Roll] Node vs data movement, mutable vs immutable flow labels (was: Is the DAG Root a Host? Can it send packets "down"?)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 22:15:12 -0000

Le 12/04/2010 18:51, Pascal Thubert (pthubert) a écrit :
> Hi Alex
>
>> My suggestion is that the mindset changes.  Acknowledge that
>> _every_ single movement referred to in the draft is a movement of a
>> data
> structure in
>> the computer's memory.  And that there is no physical mobility of
> nodes.
>
> [Pascal] You're correct in that RPL should define the words it is
> using. There used to be text and maybe some was lost in the editorial
> churn. Move normally refers to changing the parent set within a DODAG
> iteration. There is still text about that somewhere though maybe move
> is used with a wider scope now. Jump refers to changing DODAG within
> an instance. Migrate refers to switching to the next iteration of a
> DODAG.

Ok.

> Whether that coincides with a physical movement is not specified and
> difficult to assess. We are not precluding physical movement though.

It's difficult to understand whether the physical movement provoked a
movement of the data structures within the DAG.

Other reader indicated understanding that nodes are mostly
fixed.  Which coincides to my oppinion too.  Yet the draft differs - it
allows for physical movement of nodes.

>> For the word "instance": I do not understand what you mean by
> instance. [Pascal] Maybe if you look at OSPFv3 that will help you?

Ok...

>> The draft currently says "Each such instance may serve different
>> and potentially antagonistic constraints or performance criteria."
>>  I do
> not see
>> how this could work, sorry.  A routing protocol would set up a
>> single
> path not
>> several.  App packets have a single dst address, not several.
>>
>> For the word "flow label": I disagree with the mutable Flow Label
>> this
> draft
>> uses, because it is broken (flow labels should not change enroute).
>> I explained that 2 days ago.  I see you propose new text re-using
>> Flow
> Labels.
>
> [Pascal] I've read that. You were wrong. We can change the flow label
> as long as we restore it for delivery.

I will not CAPITALIZE - but I disagree: do not design a system where you
change the flow label enroute.  Imagine what happens when the
RPL intermediary system ("best effort") forgets to restore it at the
outgoing router.

The whole RPL system is hard to understand i.e. hard to make sure
mistakes are avoided.

> Anyway the instance itself is not mutable, so in any fashion your
> comment does not apply to that field.

It's not what I read in this list recently.

For the sake of bandwidth I will stop posting on this topic.

Alex

>
>> Anything changed?
>
> [Pascal] ?
>
> Pascal
>>
>>
>>>
>>> Pascal
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Pascal
>>>>>
>>>>>> -----Original Message----- From: roll-bounces@ietf.org
>>>>>> [mailto:roll-bounces@ietf.org] On Behalf
>>>>> Of
>>>>>> Alexandru Petrescu Sent: Friday, April 09, 2010 7:35 PM
>>>>>> To: ROLL WG Subject: [Roll] Is the DAG Root a Host? Can it
>>>>>>  send
> packets
>>>>>> "down"?
>>>>>>
>>>>>>> Down 'O' bit:  1-bit flag indicating whether the packet
>>>>>>> is
>>>>> expected
>>>>>>> to progress up or down.  A router sets the 'O' bit when
>>>>>>> the
> packet
>>>>>>> is expect to progress down (using DAO routes), and resets
>>>>>>> it
> when
>>>>>>> forwarding towards the root of the DODAG iteration.  A
>>>>>>> host MUST set the bit to 0.
>>>>>>
>>>>>> Is the DAG Root a Host?  I guess so, because it has no
>>>>>> outgoing edge. If it's a Host it means it can't send
>>>>>> packets "down" (MUST set the O
>>>>> bit to 0,
>>>>>> up).  If it can't send packets down then there's a problem
> because
>>>>>> it
>>>>> can't
>>>>>> send queries.
>>>>>>
>>>>>> Or am I missing something.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> _______________________________________________ Roll
>> mailing
>>>> list
>>>>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>>>>
>>>
>>>
>>
>
>


From mcr@sandelman.ca  Mon Apr 12 16:02:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E463A685D for ; Mon, 12 Apr 2010 16:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijRYhx7SRPXL for ; Mon, 12 Apr 2010 16:02:26 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 516C73A6868 for ; Mon, 12 Apr 2010 16:02:26 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.104.169.194]) by relay.sandelman.ca (Postfix) with ESMTPS id D589B3471C; Mon, 12 Apr 2010 19:02:20 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 24B834E7B9; Mon, 12 Apr 2010 19:02:20 -0400 (EDT)
From: Michael Richardson 
To: Tim Winter 
In-Reply-To: <4BB77631.20503@acm.org> 
References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> <4BB77631.20503@acm.org> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 19:02:20 -0400
Message-ID: <10379.1271113340@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 12 Apr 2010 23:02:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Tim" == Tim Winter  writes:
    Tim> From Anaheim and the list it seems that there is support to
    Tim> proceed on RPL with storing and non-storing modes of operation,
    Tim> and not to elaborate mixed mode operation at this time (while
    Tim> allowing room for future specification of mixed mode). 

    Tim> The summary approach would be to signal the mode of operation
    Tim> through the DIO, that all nodes MUST be capable to support a
    Tim> non-storing mode of operation, and that nodes who are incapable
    Tim> of acting as routers in a storing mode may participate in the
    Tim> DODAG as hosts (leaves).  (The suitable behavior when a routing
    Tim> table in a storing node becomes saturated is still under
    Tim> consideration). 

Tim, 

My instinct is that dealing properly with this saturation issue likely
returns us to the mixed-mode operation.   As such, the only interim
solution I see is to declare solving the problem of saturation
out-of-scope. i.e: 

Patient: "Doctor, Doctor, it hurts when I fill up my routing table!"
Doctor:  "well, then don't do that."

Having said that, I would like us to declare a standard response for what
happens when the node is full:
        1) ignore subsequent additions (early bird wins)
        2) drop oldest additions (newest info wins)
        3) drop all contents, and become a leaf (become non-storing)

My goal in having a standard response is so that, in event that the
network is mis-provisioned, that it reacts in a predictable way.  I
suspect that #1 is the best, but I think the modelers should have a go
at this.

    Tim> Would you please confirm this approach to the list?  Then we
    Tim> may proceed to refine RPL accordingly for the next revision,
    Tim> -08, and to take this into account when working the other
    Tim> tickets.

+1

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8Omd4CLcPvd0N1lAQJpKAf/cKNrWV7mQQWi+8u8grY6y8gbX9WYyEop
gPOawbvznxKf/VFJ+0FDANnt7xLKPDcQhKOC2fTOlgX1vWxOUiUcHWtKKzYei/Rm
G18ErfOaI9nJY1p0XKCVbzWg9ThuyOdzFsJQ8VU9SK0xKY8ceSF9GtnaTLkGW5uj
DB9ZsHpMrXPZx2lyrWNA5LenRvPGttn7AjkzmA/1Vb01rY3+pD0YDf044GgkVbuC
F+jHkU63ydcQ7ivXB1HqI8UVTNlxN6xC64GfKrKfmGvx+L+cyfuGliADr78JGvTd
KzjYPG8r+yOC7Im5ClqZ+6Eq3hjXHgzUTKNNL4qeTcRGKcSQZWrLOw==
=DRMu
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 17:18:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B1728C130 for ; Mon, 12 Apr 2010 17:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EffUajmZwEHI for ; Mon, 12 Apr 2010 17:18:52 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8CABA28C0DE for ; Mon, 12 Apr 2010 17:18:52 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.104.169.194]) by relay.sandelman.ca (Postfix) with ESMTPS id 9034B3477F; Mon, 12 Apr 2010 20:18:46 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id B13594E7B9; Mon, 12 Apr 2010 20:18:16 -0400 (EDT)
From: Michael Richardson 
To: Philip Levis 
In-Reply-To:  
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 20:18:16 -0400
Message-ID: <15281.1271117896@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: 'roll' 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 00:18:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Philip" == Philip Levis  writes:
    Philip> Yes.
 
    >> If C hears a DIO from P, then there is a lot of context in that
    >> message.  The mechanisms that we're proposing to use to protect
    >> DIOs will contain a nonce.   

    >> If C is worried about the authenticity and timeliness of the DIO,
    >> then C can send a unicast DIS after hearing the DIO and make sure
    >> that the response has an incremented nonce.  

    Philip> I don't think this is sufficient. I am an attacker. I hear
    Philip> and record DIOs n....n+k. I repeat DIO n. Another node sends
    Philip> DIS, I send DIO n+1. 

So, at this point there is an assumption that layer-2 will protect the
network from malicious outsiders.   (It's not an assumption that I
believe will apply in many situations, but not all, so I will not
challenge it).

Thus we are safe from attackers that can see inside packets.
Attackers can do traffic analysis,  and record and replay packets.
Some layer-2s have built-in replay protection, but we need to understand
what the effect of replays are on RPL.

    >> Assuming that the MIC is calculated over the headers (which
    >> include both P and C addresses) then we should be OK, yes?  

    Philip> Only if the DIO is sent as a unicast (uniquely tied to the DIS).

    >> Or are you suggesting the need for a random number/challenge in
    >> the DIS that is also a part of the MIC calculation?  

    Philip> Yes, something like that. Could be something such that
    Philip> multicast DIOs have an incrementing sequence number,
    Philip> responds to unicast DISes are unicast and use the nonce in
    Philip> the DIS. Otherwise it becomes tricky, there are DoS attacks
    Philip> (node C sends a DIS with a nonce, I immediately send a DIS
    Philip> with another nonce, which nonce will P use). 

    >> I guess if I were really paranoid I could make up a random
    >> address to put in the DIS. 
    >> So I think that we have the (proposed) *mechanisms* that we need
    >> to do what you want, and it will be up to implementers to decide
    >> on policy. 

    Philip> I'm just worried about the basic case of an adversary
    Philip> replaying DIOs. 

As am I.

I want to see good layer-2/layer-3 binding, and one of the things that
well designed security can do is protect against egrevious
misconfiguration.   In many networks (particularly home networks), there
will be nodes which are connected to many networks, and which contain
security flaws that permit an adversary to get in at layer3. (I'm
thinking windows PCs in people's homes, and other insecure junk)

I'd like it if RPL would be resistant against a malicious insider:
obviously, an insider can wreck havoc, but the question is, can we
at least detect this (it often looks like misconfiguration... and vv)?

- -- 
]       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. 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O4R4CLcPvd0N1lAQIldgf/bRKMQj7YNtAtxcQqinvmFZ1sKGy8cvT8
Sszr1+pMZhFdW7hi6SqBzxEn3Luq+BhLXpnKMwwyvLkXZm0LcJHLDShYmMoU47PN
F72raqGpiefOP+TyiVg7DCBxeNZ5lb4xgEy4GJf3qu40c/ZeMlcSfOUoWkCncvvp
hOoqCzYRGlAVTFzWNCM7ytpkgmDJ5oFBIOzBk6SbHZKvKVhpAJD7eJKMzP399+jC
d0WkEpUsdRuF9l0Jb9grq8vwapMthi6VZKS4ODp8BVC7bZzko7G2pTx50M11GPB/
6OpB+kL+WPFUKs8axeBK3hxe1NIqW0XAwHDb+AG52e1y9b2ccIHfgA==
=v7q1
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 17:22:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14ACC3A6AD3 for ; Mon, 12 Apr 2010 17:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex5CAogwoMKV for ; Mon, 12 Apr 2010 17:22:03 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 1B2143A6A5D for ; Mon, 12 Apr 2010 17:22:03 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.104.169.194]) by relay.sandelman.ca (Postfix) with ESMTPS id C3B1C34642; Mon, 12 Apr 2010 20:21:57 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id AE6904E7B9; Mon, 12 Apr 2010 20:20:42 -0400 (EDT)
From: Michael Richardson 
To: Philip Levis 
In-Reply-To: <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu> 
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>  <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net> <20100.1269887835@marajade.sandelman.ca> <00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net> <7375.1269904161@marajade.sandelman.ca> <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> <17256.1269912377@marajade.sandelman.ca> <4BB38ECC.5050604@eecs.berkeley.edu> <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu> <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> <6643.1270774314@marajade.sandelman.ca> <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 20:20:42 -0400
Message-ID: <15465.1271118042@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll WG 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 00:22:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Philip" =3D=3D Philip Levis  writes:
    Yoav> mmm=E2=88=91. I actually thought that the unicast DIO response is
    Yoav> immediate, and that on top of that the next (unreset) trickle
    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
    Yoav> send out a DIS and that will cause DIOs from all surrounding
    Yoav> nodes to be unicast, i.e. not reach any other nodes=E2=88=91i.e. =
no
    Yoav> DODAG

    >> The threat model that you describe, where an attacker has access to =
send
    >> original data into the link appears to be out of scope from what I h=
ave
    >> read.
    >>=20
    >> It seems that we will assume the layer-2 has sufficient protection t=
hat
    >> an external attacker can not do what you describe.=20=20

    Philip> Michael,

    Philip> Unfortunately, we can't assume that layer-2 has any
    Philip> protection. This is the operating assumption behind all of
    Philip> the security work. Note that the possible presence of layer
    Philip> 2 mechanisms are why RPL's mechanisms are intended to be
    Philip> options: in networks with sufficient layer 2 protection they
    Philip> can be left out, but they can be used in those that need
    Philip> it.=20

First, let's get things working right on the assumption of some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)

That's my take.

- --=20
]       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.=20


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O42ICLcPvd0N1lAQJ1LwgAwEnjjQV9ZIb7khGDHA1z/eYtOSqGUx+p
td/q+YkFuqjG9S6ZhuPpiGExjERTxMgDeG/eknD/Xs7DjujG7dINEMFGhaLLIUaC
qmoJcsOLBbyHdrbpYQxM0o0yGyd27Ret5iFJr4b7+S9qHQfUXUMuRPRAhXySKzit
NBcdEXN2yNEDtWSY/gnX3C8m0V7GfaOmoXG0QnUkWEKrFFaHVdCfUj8k5o/rB2Ge
LcH5chfB/HmDIRuW6WXBdbEv/hTqGZP0wO4J4QBkYnXf3s8dCQQ7P4Gl/ZCTxvti
qbLYeoOVnMi1M1OE8sTyJV71xs1TiKIajzSv9JNSIe9mYPD63Ai78w=3D=3D
=3Dj7BY
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 17:32:33 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F2F3A67B5 for ; Mon, 12 Apr 2010 17:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN9Pn-JhDzO7 for ; Mon, 12 Apr 2010 17:32:32 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 81F613A68CB for ; Mon, 12 Apr 2010 17:32:30 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.104.169.194]) by relay.sandelman.ca (Postfix) with ESMTPS id 781F734642 for ; Mon, 12 Apr 2010 20:32:02 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4AB564E7B9 for ; Mon, 12 Apr 2010 20:31:58 -0400 (EDT)
From: Michael Richardson 
To: ROLL WG 
In-Reply-To: <4BBFB78D.4080801@gmail.com> 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Apr 2010 20:31:58 -0400
Message-ID: <16320.1271118718@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 00:32:33 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Alexandru" =3D=3D Alexandru Petrescu  =
writes:
    Alexandru> Le 10/04/2010 00:51, JeongGil Ko (John) a =E9crit :
    >> A lot of points here so let me just try to summarize instead of
    >> putting things in line.
    >>=20
    >> 1. The authors of the draft can better answer this but I don't think
    >> the RPL draft even considers physical movements of nodes.

    Alexandru> Physical movements of nodes is in the RoLL requirements!

And, even it it wasn't, the nodes do not need to move for the
connectivity to change.=20=20


Apparently some of the domiciles in which ROLL will given homes are
infested with walking bags of RF-opaque water! And sometimes, the
annoying "users" manipulate things like doors and windows made out of
special RF-opaque low-e glass!!


I suggest that we might want to come up with a different term than
"move" to describe topology changes.

- --=20
]       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.=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O7dICLcPvd0N1lAQICEggAkFlCzPEQAwmMDo6BnNQp9/28fwrSc2k2
cb9Hd1fgHcgZTQ/1sgGkFH/g0PFGZiUrHuTWS0ham+Bz1NS2p/BZpBjFgg+XGMPw
rbo1ZqwFikTtTDrc5tXwlyHVn3suarbtmByC0Ssm07PbmBnAu+eOZ4BqRDFNaWaw
HnF9o9afxC+R1/1qjQ/MBIv18pZe2DgzEtk1Votc7BwDpUOMgzhF/KMI/Swy2qDK
tq4FbJb6ItOCADU9bdkV/QIs7vWcN79CJIv1UmF4k1Z+NJqbWVrZzf1NCROA9Unp
9JJiLd3kke8uIhck6mRB5Yu8BO/WT/hduFM3SP0EzfDhSC2DUf9Ymg=3D=3D
=3DrQyN
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 12 17:39:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472443A698C for ; Mon, 12 Apr 2010 17:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.646
X-Spam-Level: 
X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HShrgmMs5Adh for ; Mon, 12 Apr 2010 17:39:43 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 387413A63EC for ; Mon, 12 Apr 2010 17:39:43 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.104.169.194]) by relay.sandelman.ca (Postfix) with ESMTPS id 0ED3B34739 for ; Mon, 12 Apr 2010 20:39:16 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 0F9584E7B9 for ; Mon, 12 Apr 2010 20:39:14 -0400 (EDT)
From: Michael Richardson 
To: ROLL WG 
In-Reply-To:  
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>  <4BC06997.8010703@gmail.com>  
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 12 Apr 2010 20:39:13 -0400
Message-ID: <16772.1271119153@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 00:39:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Carsten" == Carsten Bormann  writes:
    Carsten> On Apr 10, 2010, at 14:05, Alexandru Petrescu wrote:

    >> Right... AH will ignore the mutable fields.  Which means the
    >> heart of the RPL protocol is insecure...  should say that upfront
    >> somewhere. 

    Carsten> No, that is not at all what that means.

    Carsten> I cited AH to provide more evidence the fact that mutable
    Carsten> hbh headers are part of the IPv6 architecture. 

    Carsten> But let's talk about security.

    Carsten> AH, like all of IPsec, is end-to-end.
    Carsten> Routers are not supposed to act on it.
    Carsten> (Even if they wanted, they couldn't, as they are not privy
    Carsten> to the SA governing the AH header.) 

Well, that's a key distribution problem.
There is nothing fundamental about AH that prevents this.

The issues with AH that prevents SEND from using it were really an
oversight in the 2401 specification --- the SEND security would not have
been ignored by insecure nodes, rather than entire packet would have
been dropped.  Too late to revise deployed nodes.
RPL does not have this problem, in my opinion.

AH is a useful construct for layer-3 security, and it may be available
in hardware (almost for free) in many embedded environments. (ixp and
freescale come to mind)

They key distribution problem is a problem that any layer-3 solution
will need to solve.

Carsten talks about who creates AH and who processes it --- in most
cases the DIOs and DODAGs are unicast, or multicast (therefore, "for"
all nodes).  Multicast AH is well understood.

(IPsec guy)

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O9L4CLcPvd0N1lAQILUQf/XkLPiqFX5dT4ELgXwoGDNezPjPC7sYTK
eZjQt1mVrTh28miPP5GGrl8qV25gqidoMNQQ1diD/QhXop0uBjHhMH9XPSFZ/X7J
J14navQ/TH73q0RPOvf61EE3L725eaF5cI0t6n+X0Iyx5lcVoiecJdhM5G4QseHr
MM2Y6hVkzyMSRzWMLnbFnHmnS33UcK+xz0x4119pQwitHW8vgkCfs00bLuJukxeY
mDZWhHRSAF8urN/SarE42j5y+XEDhQiTKuQYgke+UfQOoz+6/Bx2Gsa5jrZbp7Ae
Y8wPHIt4kQvqW8mCTR8ftqav29C3wZc2a+hgTP84IIxYJSuvZ9JF8A==
=Yrni
-----END PGP SIGNATURE-----

From robert.cragie@gridmerge.com  Mon Apr 12 18:27:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF463A698C for ; Mon, 12 Apr 2010 18:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JyS8+iu2BTu for ; Mon, 12 Apr 2010 18:27:03 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id B7C1A3A67E6 for ; Mon, 12 Apr 2010 18:27:02 -0700 (PDT)
Received: from adsl-99-154-54-86.dsl.pltn13.sbcglobal.net ([99.154.54.86] helo=[192.168.1.199]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O1Utw-0005yo-0a for roll@ietf.org; Tue, 13 Apr 2010 02:26:55 +0100
Message-ID: <4BC3C84B.7070904@gridmerge.com>
Date: Tue, 13 Apr 2010 02:26:35 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu>		<9317.1269879175@marajade.sandelman.ca>	<01b901cacf62$7f3e89b0$7dbb9d10$%sturek@att.net>	<20100.1269887835@marajade.sandelman.ca>	<00fa01cacf8c$c0f4cc00$42de6400$%sturek@att.net>	<7375.1269904161@marajade.sandelman.ca>	<01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net>	<17256.1269912377@marajade.sandelman.ca>	<4BB38ECC.5050604@eecs.berkeley.edu>	<5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@cs.stanford.edu>	<4BBCF150.4010701@eecs.berkeley.edu>	<706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu>	<4BBD03AF.9050803@eecs.berkeley.edu>		<7264daf93e85725bf0914cbb858394aa@mail.gmail.com>	<4BBE2785.60000@eecs.berkeley.edu>	<4d3d664ff702246cebfef17d696f073f@mail.gmail.com>	<6643.1270774314@marajade.sandelman.ca>	<978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu> <15465.1271118042@marajade.sandelman.c a>
In-Reply-To: <15465.1271118042@marajade.sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090205030309060201070607"
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Apr 2010 01:27:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms090205030309060201070607
Content-Type: multipart/alternative;
 boundary="------------090907030301050702020009"

This is a multi-part message in MIME format.
--------------090907030301050702020009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

"First, let's get things working right on the assumption of some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)"

+1

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 13/04/2010 1:20 AM, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   =20
>>>>>> "Philip" =3D=3D Philip Levis  writes:
>>>>>>             =20
>      Yoav>  mmm=E2^'. I actually thought that the unicast DIO response =
is
>      Yoav>  immediate, and that on top of that the next (unreset) trick=
le
>      Yoav>  timer a DIO would be multicast. Otherwise, an attacker can
>      Yoav>  send out a DIS and that will cause DIOs from all surroundin=
g
>      Yoav>  nodes to be unicast, i.e. not reach any other nodes=E2^'i.e=
=2E no
>      Yoav>  DODAG
>
>      >>  The threat model that you describe, where an attacker has acce=
ss to send
>      >>  original data into the link appears to be out of scope from wh=
at I have
>      >>  read.
>      >>
>      >>  It seems that we will assume the layer-2 has sufficient protec=
tion that
>      >>  an external attacker can not do what you describe.
>
>      Philip>  Michael,
>
>      Philip>  Unfortunately, we can't assume that layer-2 has any
>      Philip>  protection. This is the operating assumption behind all o=
f
>      Philip>  the security work. Note that the possible presence of lay=
er
>      Philip>  2 mechanisms are why RPL's mechanisms are intended to be
>      Philip>  options: in networks with sufficient layer 2 protection t=
hey
>      Philip>  can be left out, but they can be used in those that need
>      Philip>  it.
>
> First, let's get things working right on the assumption of some layer-2=

> protection.  The layer-2 protection may not be sufficient for our needs=
=2E
>
> Then, once we have done that, let's determine what layer-2 "services" w=
e
> need to reproduce at layer-3. (Remember, I'm an IPsec guy)
>
> That's my take.
>
> - --=20
> ]       He who is tired of Weird Al is tired of life!           |  fire=
walls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net ar=
chitect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device=
 driver[
>     Kyoto Plus: watch the video
> 	then sign the petition.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBS8O42ICLcPvd0N1lAQJ1LwgAwEnjjQV9ZIb7khGDHA1z/eYtOSqGUx+p
> td/q+YkFuqjG9S6ZhuPpiGExjERTxMgDeG/eknD/Xs7DjujG7dINEMFGhaLLIUaC
> qmoJcsOLBbyHdrbpYQxM0o0yGyd27Ret5iFJr4b7+S9qHQfUXUMuRPRAhXySKzit
> NBcdEXN2yNEDtWSY/gnX3C8m0V7GfaOmoXG0QnUkWEKrFFaHVdCfUj8k5o/rB2Ge
> LcH5chfB/HmDIRuW6WXBdbEv/hTqGZP0wO4J4QBkYnXf3s8dCQQ7P4Gl/ZCTxvti
> qbLYeoOVnMi1M1OE8sTyJV71xs1TiKIajzSv9JNSIe9mYPD63Ai78w=3D=3D
> =3Dj7BY
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>   =20

--------------090907030301050702020009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  



    "First, let's get things working right on the assumption o=
f some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)"

    
+1
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 13/04/2010 1:20 AM, Michael Richardson wrote:

    
  
    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


  
    
  
    
    
    
      
    
        
    
          
    
            
    "Philip" =3D=3D Philip Levis <pal@cs.stanford=
=2Eedu> writes:
            
    
          
    
        
    
      
    
    
    
  
    
  
        Yoav> mmm∑. I actually thought=
 that the unicast DIO response is
    Yoav> immediate, and that on top of that the next (unreset) trickl=
e
    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
    Yoav> send out a DIS and that will cause DIOs from all surrounding=

    Yoav> nodes to be unicast, i.e. not reach any other nodesâ&#=
710;‘i.e. no
    Yoav> DODAG

    >> The threat model that you describe, where an attacker has ac=
cess to send
    >> original data into the link appears to be out of scope from =
what I have
    >> read.
    >>=20
    >> It seems that we will assume the layer-2 has sufficient prot=
ection that
    >> an external attacker can not do what you describe. =20

    Philip> Michael,

    Philip> Unfortunately, we can't assume that layer-2 has any
    Philip> protection. This is the operating assumption behind all of=

    Philip> the security work. Note that the possible presence of laye=
r
    Philip> 2 mechanisms are why RPL's mechanisms are intended to be
    Philip> options: in networks with sufficient layer 2 protection th=
ey
    Philip> can be left out, but they can be used in those that need
    Philip> it.=20

First, let's get things working right on the assumption of some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)

That's my take.

- --=20
]       He who is tired of Weird Al is tired of life!           |  firewa=
lls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net arch=
itect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottaw=
a.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com=
/watch?v=3Dkzx1ycLXQSE>
	               then sign the petition.=20


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O42ICLcPvd0N1lAQJ1LwgAwEnjjQV9ZIb7khGDHA1z/eYtOSqGUx+p
td/q+YkFuqjG9S6ZhuPpiGExjERTxMgDeG/eknD/Xs7DjujG7dINEMFGhaLLIUaC
qmoJcsOLBbyHdrbpYQxM0o0yGyd27Ret5iFJr4b7+S9qHQfUXUMuRPRAhXySKzit
NBcdEXN2yNEDtWSY/gnX3C8m0V7GfaOmoXG0QnUkWEKrFFaHVdCfUj8k5o/rB2Ge
LcH5chfB/HmDIRuW6WXBdbEv/hTqGZP0wO4J4QBkYnXf3s8dCQQ7P4Gl/ZCTxvti
qbLYeoOVnMi1M1OE8sTyJV71xs1TiKIajzSv9JNSIe9mYPD63Ai78w=3D=3D
=3Dj7BY
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll

  
    

    



--------------090907030301050702020009--

--------------ms090205030309060201070607
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MTMwMTI2MzVaMCMGCSqGSIb3DQEJBDEWBBQmQruiuB+hUGByzL9Y79PrnibgEjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBALJqi/ONbBNCvu8RnzNY+1NTRDAmrGd6Gcxx4tunVBOojIcz4/L7Jc6Ss4RVx/Xrdpo1
W1XWrjqLSzRe1SRQTJxPlXFSLAUIAUD892SjpHx2BTLoZ7RtgGI/BLgNkftzva2wuK5S24VT
YHeVKwToK+vf/76A9IEkJ7ILqcdsSPGjgTn4jSYp7DleLyvRHO13UmMOQ0Wxf/tHRBagCvkw
4cMraD8JZFry2qb3ChZOOQv4GKTMbfTURRNOAu+754MrDIw7ExbJG3ThKg/ls1c7cSiP4EM5
z7uicFqP1q6Nh5tTpLimtuDgib+gXwluLFyUMHRz6ZQEgYOtCEmNDSYA31QAAAAAAAA=
--------------ms090205030309060201070607--

From jmamodio@gmail.com  Mon Apr 12 20:27:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632C83A6916 for ; Mon, 12 Apr 2010 20:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level: 
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.280,  BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpMlTGDpEYBG for ; Mon, 12 Apr 2010 20:27:27 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9B7003A6851 for ; Mon, 12 Apr 2010 20:27:27 -0700 (PDT)
Received: by vws11 with SMTP id 11so648935vws.31 for ; Mon, 12 Apr 2010 20:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ZdBkBKKRk6YarJbpEoZdav9WR4T8M9giTIdzUpfZPpg=; b=AHzYSrsG2B7zVIOaAIRX0U87cFja/vyXldvR7oWpgZTBITtaQq8/CuFSGJPdwAcSmc I2jAcLgScir54P3SaKWopJQ93Dsjy/CQMijpwFsl3WDWSbGWBBEPtRAeE/WBRd0LEBpC BPamz35qu0d6746C2mXGfByG1CJ/9mOarwnaw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TO2OUgdWiyJYVik5ZLkRV5qUe+LPOpVJefQXMfK45ng/WSQF40AlASPQYPi07K6FX4 WfwvIMvY0qUcJyfIZwNermJIjG2baoWoZslmCiyce0NSf/xB2u0qcCMZpbvUPHfInlVA +nUXsZ6tfOuV6xCqzfxsyw5ummd2V+9FeJWrM=
MIME-Version: 1.0
Received: by 10.220.46.12 with HTTP; Mon, 12 Apr 2010 20:27:19 -0700 (PDT)
In-Reply-To: <16320.1271118718@marajade.sandelman.ca>
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca>
Date: Mon, 12 Apr 2010 22:27:19 -0500
Received: by 10.220.128.30 with SMTP id i30mr2715084vcs.28.1271129239449; Mon,  12 Apr 2010 20:27:19 -0700 (PDT)
Message-ID: 
From: Jorge Amodio 
To: Michael Richardson 
Content-Type: text/plain; charset=ISO-8859-1
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 03:27:28 -0000

> I suggest that we might want to come up with a different term than
> "move" to describe topology changes.

Makes sense.

If you change

           Root
          /     \
        A        B
       /
      C

By  C--A--Root--B, now things move left <-> right, no more up and down.

I believe the whole movement concept is confusing.

My .02
Jorge

From pal@cs.stanford.edu  Mon Apr 12 20:40:18 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266D23A6915 for ; Mon, 12 Apr 2010 20:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.342
X-Spam-Level: 
X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWmZHt16gkeM for ; Mon, 12 Apr 2010 20:40:17 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 36F913A67E1 for ; Mon, 12 Apr 2010 20:40:17 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O1Wyx-00050G-GM; Mon, 12 Apr 2010 20:40:11 -0700
In-Reply-To: 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> 
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Philip Levis 
Date: Mon, 12 Apr 2010 20:40:10 -0700
To: Jorge Amodio 
X-Mailer: Apple Mail (2.753.1)
X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 03:40:18 -0000

On Apr 12, 2010, at 8:27 PM, Jorge Amodio wrote:

>> I suggest that we might want to come up with a different term than
>> "move" to describe topology changes.
>
> Makes sense.
>
> If you change
>
>            Root
>           /     \
>         A        B
>        /
>       C
>
> By  C--A--Root--B, now things move left <-> right, no more up and  
> down.
>
> I believe the whole movement concept is confusing.

What terminology do you think would be better?

The notion of up/down and shallower/deeper are basic terminology in  
tree data structures and algorithms. E.g., depth first search.

"Move" could be "change its position within the DODAG?"

PHil

From jmamodio@gmail.com  Mon Apr 12 20:59:32 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D2A3A659C for ; Mon, 12 Apr 2010 20:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level: 
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-rPpUYba052 for ; Mon, 12 Apr 2010 20:59:32 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CCFBE3A67B2 for ; Mon, 12 Apr 2010 20:59:31 -0700 (PDT)
Received: by vws11 with SMTP id 11so659520vws.31 for ; Mon, 12 Apr 2010 20:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gv3hiuZKcNsnbdwWfHqNExkHlMg8Lge8ovE6n34ZKxE=; b=T8uHjBPDqlwHvaHXUgZWQkEIiMaT3FUZhEPUCRy5HpSZhovLPBxsIhg27EfSYPBa3F jvo3uXIKDBCqLGNAyA0vUH2z9UyIx8qM/vyXb2O/03xVs8P1Y6S3ofI621j07T+w9Aj+ 7y7dVPWo3HFtWbd0iEXUhe1PPM7BcMuHoPUTM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a4C3oQmuQaNtV2RlMs8QwMhhDBxXGJ3d5GCDU3HXnYPFQggOgbg0T4L4nA7BYzKvh1 hgR7XBxMnkI2fqC8TkRm9A49jn5G27OhwO5ss9WauIyi6Uum5o4tI+YGOjqlo5qyRPQT qjewgnFlot8RnGeDtHoFJYsNDlC+xe6vxmnwo=
MIME-Version: 1.0
Received: by 10.220.46.12 with HTTP; Mon, 12 Apr 2010 20:59:23 -0700 (PDT)
In-Reply-To: 
References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com>  <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca>  
Date: Mon, 12 Apr 2010 22:59:23 -0500
Received: by 10.220.63.5 with SMTP id z5mr2652695vch.46.1271131163253; Mon, 12  Apr 2010 20:59:23 -0700 (PDT)
Message-ID: 
From: Jorge Amodio 
To: Philip Levis 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ROLL WG 
Subject: Re: [Roll] The word Up!
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 03:59:32 -0000

>>> I suggest that we might want to come up with a different term than
>>> "move" to describe topology changes.
>>
>> Makes sense.
>>
>> If you change
>>
>> =A0 =A0 =A0 =A0 =A0 Root
>> =A0 =A0 =A0 =A0 =A0/ =A0 =A0 \
>> =A0 =A0 =A0 =A0A =A0 =A0 =A0 =A0B
>> =A0 =A0 =A0 /
>> =A0 =A0 =A0C
>>
>> By =A0C--A--Root--B, now things move left <-> right, no more up and down=
.
>>
>> I believe the whole movement concept is confusing.
>
> What terminology do you think would be better?

Not sure, I've been trying to follow the thread and now I'm lost about
what is moving from where to where and why.

> The notion of up/down and shallower/deeper are basic terminology in tree
> data structures and algorithms. E.g., depth first search.
>
> "Move" could be "change its position within the DODAG?"

up/down can have many interpretations, ie link up/down,
upstream/dowmstream, so on.

My interpretation (apologies in advance if I'm getting this wrong
since I'm now lost on the discussion) the intent is to find a better
way to describe how a particular node given a specific event, changes
its "position" in the  routing tree hierarchy. Is it that ?

Regards
Jorge

From cabo@tzi.org  Tue Apr 13 00:07:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A353A6961 for ; Tue, 13 Apr 2010 00:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.931
X-Spam-Level: 
X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.318,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P0ooDfYClhW for ; Tue, 13 Apr 2010 00:07:41 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2FB4A3A6950 for ; Tue, 13 Apr 2010 00:07:36 -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 o3D77MFP023398; Tue, 13 Apr 2010 09:07:22 +0200 (CEST)
Received: from [192.168.217.101] (p5489ACEE.dip.t-dialin.net [84.137.172.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 96D47C29C;  Tue, 13 Apr 2010 09:07:22 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <16772.1271119153@marajade.sandelman.ca>
Date: Tue, 13 Apr 2010 09:07:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D77938D-C5A2-4267-8E4C-471EA3017F9D@tzi.org>
References: <4BBFB419.10905@gmail.com>  <4BC05CCB.5040009@gmail.com>  <4BC06997.8010703@gmail.com>  <16772.1271119153@marajade.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:07:42 -0000

On Apr 13, 2010, at 02:39, Michael Richardson wrote:

> Carsten talks about who creates AH and who processes it --- in most
> cases the DIOs and DODAGs are unicast, or multicast (therefore, "for"
> all nodes).  Multicast AH is well understood.

Actually, I was considering the case where a *data* packet is being =
forwarded and the routers on the way insert routing information into an =
IPv6 hop-by-hop option, further modify that on the way and (to make AH =
work) finally remove all this stuff again before handing it to the =
destination process.  Any AH in there is protecting the end-to-end =
information; there is no way that same protection can be used to protect =
information that is inserted/modified hop-by-hop.  No, I'm not giving =
the end-to-end keys to every router on the way :-)

(I agree that AH could be used to secure RPL-specific packets sent =
between routers; I'm not so sure this is a good match.)

Gruesse, Carsten


From jpv@cisco.com  Tue Apr 13 00:34:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2FB3A6915 for ; Tue, 13 Apr 2010 00:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.048
X-Spam-Level: 
X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-4.308, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqfNftIW8bQS for ; Tue, 13 Apr 2010 00:34:53 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6C4E23A6892 for ; Tue, 13 Apr 2010 00:34:40 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoCAMS7w0uQ/uCWe2dsb2JhbACbQxUBAQsLIgYcoXyZcYUMBI5T
X-IronPort-AV: E=Sophos;i="4.52,196,1270425600";  d="scan'208";a="5498974"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2010 06:58:48 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3D7YX1h015997; Tue, 13 Apr 2010 07:34:33 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:34:33 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:34:33 +0200
Message-Id: <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>
From: JP Vasseur 
To: Mukul Goyal 
In-Reply-To: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 13 Apr 2010 09:34:32 +0200
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 13 Apr 2010 07:34:33.0184 (UTC) FILETIME=[C2A61E00:01CADADB]
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:34:54 -0000

Hi Mukul,

Thanks for your comments on the draft. See below.

On Mar 28, 2010, at 8:36 AM, Mukul Goyal wrote:

> Here are some comments on draft-ietf-roll-routing-metrics-05. Not  
> sure if people have already identified these issues.
>
> 1) I am concerned about the fact that the metrics draft does not  
> currently allow a metric to be declared "multiplicative" in nature.
>
> The natural way to aggregate the link-level reliabilities into a  
> path-level reliability is by multiplication.
>
> Quoating from section 4.3.1 ("Link Quality Level Reliability  
> Metric") in the metrics draft:
>
> "Aggregated LQL Value: when used an an additive metric (A=0x00), the
>  aggregated LQL value reports the sum of all the LQL values for all
>  links along the path.  When used to report a minimum (A=0x02), the
>  field reports the minimum LQL value of all links along the path."
>
>
> Aggregating the "Link Quality Levels" by adding them together does  
> not make any sense. This allows two routes, with very different end- 
> to-end reliabilities, to have same aggregated LQL values.
>

Two comments:
1) There are situations where indeed adding metrics is just not  
meaningfull, this is why we introduced the concept of recorded metrics
2) But there are cases, where adding LQL is just good enough.

To you second point, using logs/exponential you could concert additive  
into multiplicative metric.
Should you still want "multiplicative" to avoid too much computation  
on the nodes, let's add a flag value here for multiplcative metric (in
the next revision).

> 2) The beginning text in Section 4.3 (Link Reliability) identifies  
> external and multipath interefence as the reasons for poor link  
> reliability. I think that external interference should be described  
> a little more. For CSMA based MAC layers, too much contention for  
> channel access is also a major cause for high packet loss rates,  
> which should be mentioned as well.
>
> 3) There are two typos in the draft:
>
> 1. At the beginning of section 4.3.1:
>
> "The Link Quality Level (LQL) object is used to quantify the link
>  reliability using a discrete value, from 0 to 3 where 0 indicates
>  that the link quality level is unknown and 1 reports the highest link
>  quality level."
>
> 1 should be replaced by 3.
>

This was not a typo and a fairly common choice in protocol to assign  
the lowest value to higher preference (e.g. link metric for IGP,
router preference). That helps lowest path costs.

> 2. Towards the end of 4.3.2:
>
> "The ETX object may be used as a constraint or a path metric.  For
>  example, an Objective Function may indicate that the ETX must not be
>  below some specified value."
>
> Should be: ETX must not be more than some specified value.
>

Good catch, will fix it.

Thanks.

JP.

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


From jpv@cisco.com  Tue Apr 13 00:34:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3D93A684B for ; Tue, 13 Apr 2010 00:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.9
X-Spam-Level: 
X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[AWL=1.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhPR43OradGk for ; Tue, 13 Apr 2010 00:34:57 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 25C313A68E4 for ; Tue, 13 Apr 2010 00:34:49 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAM67w0urR7H+/2dsb2JhbACBPpoFcaIFmXGFDAQ
X-IronPort-AV: E=Sophos;i="4.52,196,1270425600";  d="scan'208,217";a="182146543"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 13 Apr 2010 07:34:43 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3D7YS1S007722; Tue, 13 Apr 2010 07:34:43 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:34:40 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:34:39 +0200
Message-Id: <60054C72-1246-421B-8684-CC4835F5C927@cisco.com>
From: JP Vasseur 
To: Yoav Ben-Yehezkel 
In-Reply-To: <039e01cace94$2be881e0$83b985a0$@com>
Content-Type: multipart/alternative; boundary=Apple-Mail-31-779103719
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 13 Apr 2010 09:34:39 +0200
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> <4BAF6C19.6040004@gridmerge.com> <039e01cace94$2be881e0$83b985a0$@com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 13 Apr 2010 07:34:40.0044 (UTC) FILETIME=[C6BCDEC0:01CADADB]
Cc: roll@ietf.org
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:34:59 -0000

--Apple-Mail-31-779103719
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi,

On Mar 28, 2010, at 6:31 PM, Yoav Ben-Yehezkel wrote:

> Hi,
>
> Just a quick question, is 1 reports the highest or lowest link =20
> quality level?
>

1 is the Highest.

> It seems contradicting in the text.
>
> "
> 4.3.1.  The Link Quality Level Reliability Metric
>
>    The Link Quality Level (LQL) object is used to quantify the link
>    reliability using a discrete value, from 0 to 3 where 0 indicates
>    that the link quality level is unknown and 1 reports the highest =20=

> link
>    quality level.  The mechanisms and algorithms used to compute the =20=

> LQL
>    is implementation specific and outside of the scope of this =20
> document.
> "
>
>
> Whereas in the following text it says:
>
> "
>    The format of the LQL Type 1 sub-object is as follows
>
>      0 1 2 3 4 5 6 7
>     +-+-+-+-+-+-+-+-+
>     |Val| Counter   |
>     +-+-+-+-+-+-+-+-+
>
>     Figure 12: LQL Type 1 sub-Object format
>
>    Val: LQL value from 0 to 3 where 0 means undetermined and 1 =20
> indicates
>    the lowest link quality.
>
>    Counter: number of links.
> "
>

=3D> the latter is a typo (thanks!), will fix it.

> So =96 which is it?
>
> Anyway, WRT to reliability and LQL - there=92s a problem with long =20
> good paths (in the following assume 1 indicates the good link). The =20=

> multiplication of any number of good links will remain 1, where in =20
> fact the reliability will drop significantly after a few hops. Also =20=

> the value 0 indicating unknown will immediately cause the =20
> multiplication to be 0 =96 i.e. unknown (which could make some sense, =20=

> though in summation it should do no difference to the aggregation). =20=

> Could there be a problem with the definitions?
>

Should you want to multiply LQL, 0 must be avoided indeed. Note that =20
the intent was more for recorded metric.

> Just a nice trick - to get the same results as in option 1 (counting =20=

> 1/2/3), one can make a multiplication of primes (say 2, 3, 5), and =20
> aggregate (using multiplication or summation of logs) the divisors =20
> of the aggregated value would be the counters of 2,3,5 which maps to =20=

> 1/2/3 counters, respectively. I don=92t think this is the intent =
though.
>

Thanks.

JP.

> Thoughts?
>
> Yoav
>
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of Robert Cragie
> Sent: Sunday, March 28, 2010 5:48 PM
> To: roll@ietf.org
> Subject: Re: [Roll] The need for multiplicative metrics and other =20
> comments on draft-ietf-roll-routing-metrics-05
>
> Hi Mukul,
>
> Multiplicative metrics make sense if the metric is a probability. If =20=

> the metric is on a logarithmic scale, the sum amounts to a product =20
> anyway so it may be sufficient to keep it as an additive metric. In =20=

> the scale from 1 to 3, perhaps it would be necessary to define what =20=

> 2 represents, so maybe 4.3.1 needs to be clarified.
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 27/03/2010 11:36 PM, Mukul Goyal wrote:
> Here are some comments on draft-ietf-roll-routing-metrics-05. Not =20
> sure if people have already identified these issues.
>
> 1) I am concerned about the fact that the metrics draft does not =20
> currently allow a metric to be declared "multiplicative" in nature.
>
> The natural way to aggregate the link-level reliabilities into a =20
> path-level reliability is by multiplication.
>
> Quoating from section 4.3.1 ("Link Quality Level Reliability =20
> Metric") in the metrics draft:
>
> "Aggregated LQL Value: when used an an additive metric (A=3D0x00), the
>    aggregated LQL value reports the sum of all the LQL values for all
>    links along the path.  When used to report a minimum (A=3D0x02), =
the
>    field reports the minimum LQL value of all links along the path."
>
>
> Aggregating the "Link Quality Levels" by adding them together does =20
> not make any sense. This allows two routes, with very different end-=20=

> to-end reliabilities, to have same aggregated LQL values.
>
> 2) The beginning text in Section 4.3 (Link Reliability) identifies =20
> external and multipath interefence as the reasons for poor link =20
> reliability. I think that external interference should be described =20=

> a little more. For CSMA based MAC layers, too much contention for =20
> channel access is also a major cause for high packet loss rates, =20
> which should be mentioned as well.
>
> 3) There are two typos in the draft:
>
> 1. At the beginning of section 4.3.1:
>
> "The Link Quality Level (LQL) object is used to quantify the link
>    reliability using a discrete value, from 0 to 3 where 0 indicates
>    that the link quality level is unknown and 1 reports the highest =20=

> link
>    quality level."
>
> 1 should be replaced by 3.
>
> 2. Towards the end of 4.3.2:
>
> "The ETX object may be used as a constraint or a path metric.  For
>    example, an Objective Function may indicate that the ETX must not =20=

> be
>    below some specified value."
>
> Should be: ETX must not be more than some specified value.
>
> Thanks
> Mukul
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--Apple-Mail-31-779103719
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

Hi,

    On Mar =
28, 2010, at 6:31 PM, Yoav Ben-Yehezkel wrote:

    Hi,
     
    Just a quick =
question, is 1 reports the highest or lowest link quality level?
    It seems contradicting in the text.
     
    "
    4.3.1.  The Link Quality Level =
Reliability Metric
     
       The Link Quality Level (LQL) =
object is used to quantify the link
       =
reliability using a discrete value, from 0 to 3 where 0 =
indicates
       that the link quality level =
is unknown and 1 =
reports the highest link
       =
quality level.  The mechanisms and algorithms used to compute =
the LQL
       is implementation specific =
and outside of the scope of this document.
    "
     
     
    Whereas in the =
following text it says:
     
    "
       The format of the LQL Type 1 =
sub-object is as follows
     
        =
+-+-+-+-+-+-+-+-+
        |Val| =
Counter   |
        =
+-+-+-+-+-+-+-+-+
     
        Figure 12: LQL Type 1 =
sub-Object format
     
       Val: LQL value from 0 to 3 =
where 0 means undetermined and 1 indicates
       the lowest link =
quality.
     
       Counter: number of =
links.
    "
    So =96 which is it?
     
    Anyway, WRT to =
reliability and LQL - there=92s a problem with long good paths (in the =
following assume 1 indicates the good link). The multiplication of any =
number of good links will remain 1, where in fact the reliability will =
drop significantly after a few hops. Also the value 0 indicating unknown =
will immediately cause the multiplication to be 0 =96 i.e. unknown =
(which could make some sense, though in summation it should do no =
difference to the aggregation). Could there be a problem with the =
definitions?
    Just a nice trick - to get the same results =
as in option 1 (counting 1/2/3), one can make a multiplication of primes =
(say 2, 3, 5), and aggregate (using multiplication or summation of logs) =
the divisors of the aggregated value would be the counters of 2,3,5 =
which maps to 1/2/3 counters, respectively. I don=92t think this is the =
intent though.
    Thoughts?
     
    Yoav
     
     roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert =
Cragie
    Sent: Sunday, March 28, 2010 5:48 =
PM
    To: roll@ietf.org
    Subject: Re: [Roll] The need for =
multiplicative metrics and other comments on =
draft-ietf-roll-routing-metrics-05
     
    Hi Mukul,

    Multiplicative metrics make =
sense if the metric is a probability. If the metric is on a logarithmic =
scale, the sum amounts to a product anyway so it may be sufficient to =
keep it as an additive metric. In the scale from 1 to 3, perhaps it =
would be necessary to define what 2 represents, so maybe 4.3.1 needs to =
be clarified.

    Robert
    Robert Cragie (Pacific =
Gas & Electric)

    On =
27/03/2010 11:36 PM, Mukul Goyal wrote:
    Here are =
some comments on draft-ietf-roll-routing-metrics-05. Not sure if people =
have already identified these issues.
    1) I am concerned about the fact that the =
metrics draft does not currently allow a metric to be declared =
"multiplicative" in nature.
     
    The natural way to aggregate the link-level reliabilities into =
a path-level reliability is by multiplication.
     
    Quoating from section 4.3.1 ("Link =
Quality Level Reliability Metric") in the metrics draft:
     
    "Aggregated LQL Value: when used an an =
additive metric (A=3D0x00), the
       =
aggregated LQL value reports the sum of all the LQL values for =
all
       links along the path.  =
When used to report a minimum (A=3D0x02), the
       field reports the minimum LQL value of all links =
along the path."
     
    Aggregating the "Link Quality Levels" by =
adding them together does not make any sense. This allows two routes, =
with very different end-to-end reliabilities, to have same aggregated =
LQL values.
     
    2) The =
beginning text in Section 4.3 (Link Reliability) identifies external and =
multipath interefence as the reasons for poor link reliability. I think =
that external interference should be described a little more. For CSMA =
based MAC layers, too much contention for channel access is also a major =
cause for high packet loss rates, which should be mentioned as =
well.
     
    3) There =
are two typos in the draft:
     
    1. At the beginning of section 4.3.1: 
     
    "The Link Quality Level (LQL) object is =
used to quantify the link
       =
reliability using a discrete value, from 0 to 3 where 0 =
indicates
       that the link quality level =
is unknown and 1 reports the highest link
     
    1 should be replaced by 3.
     
    2. Towards the end of 4.3.2:
    "The ETX object may be used as a =
constraint or a path metric.  For
       below some specified =
value."
     
    Should be: =
ETX must not be more than some specified value.
     
    Thanks
     
    Roll mailing list
    Roll@ietf.org
     
      =

    _______________________________________________
    Roll =
mailing list
    Roll@ietf.org
    
From: JP Vasseur 
To: Matteo Paris 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 13 Apr 2010 09:36:28 +0200
References: <729879668.597241269801731792.JavaMail.root@mail02.pantherlink.uwm.edu> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 13 Apr 2010 07:36:29.0372 (UTC) FILETIME=[07E6FFC0:01CADADC]
Cc: roll@ietf.org
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:36:45 -0000

Hi,

On Mar 29, 2010, at 6:49 AM, Matteo Paris wrote:

>
> Hi Mukul,
>
> I agree that the available flags do not cover all the possibilities =20=

> for metric calculations. However, I believe we should eliminate the =20=

> flags rather than extend them.
>
> In order to participate in routing, a node must implement the =20
> Objective Function, which already defines how to compute and =20
> propagate the metric. Thus for nodes implementing the OF, the common =20=

> flags are redundant.  Nodes not implementing the metric do not know =20=

> what the metric is and are not allowed to propagate the metric, so =20
> the flags are of no use to them.
>
> I believe the thinking behind the flags was that it would allow any =20=

> node to do something useful with the metric container, even if it =20
> did not implement the OF.  After discussion on the list, this =20
> concept was ruled out, in favor of limiting such nodes to join as =20
> leaves.  So now, the flags no longer serve a purpose.
>

The concept is extremely important and should not be emmbedded into =20
the OF (otherwise you will come up with an exponential number of =20
codepoints). I owe an email about that on the list for some time, will =20=

do it today.

Thanks

JP.

> Matteo
>
>
> At 1:42 PM -0500 3/28/10, Mukul Goyal wrote:
>> Hi Henning
>>
>> The problem is not how do we do multiplication - in a straight =20
>> forward manner or by adding the log values. The issue is that one =20
>> should be able to indicate in the "routing object" (contained in =20
>> the "metrics container" inside a "DIO") that this metric is =20
>> multiplicative. Right now, I can only indicate a metric as either =20
>> additive or max or min.
>>
>> I would like the "A field" in the Routing Object header (Section 2 =20=

>> of the metrics draft) to include an option to specify the metric as =20=

>> multiplicative. Specifically, the text:
>>
>> "o  A Field: The A field is used to indicate whether a routing metric
>>      is additive, reports a maximum or a minimum.
>>
>>      *  A=3D0x00: The routing metric is additive
>>
>>      *  A=3D0x01: The routing metric reports a maximum
>>
>>      *  A=3D0x02: The routing metric reports a minimum
>> "
>>
>> should include one more line:
>> "
>>      *  A=3D0x03: The routing metric is multiplicative
>> "
>>
>> Thanks
>> Mukul
>> ----- Original Message -----
>> From: "Henning Rogge" 
>> To: roll@ietf.org
>> Cc: "Mukul Goyal" 
>> Sent: Sunday, March 28, 2010 11:58:34 AM GMT -06:00 US/Canada Central
>> Subject: Re: [Roll] The need for multiplicative metrics and other =20
>> comments on draft-ietf-roll-routing-metrics-05
>>
>> Am Sonntag 28 M=E4rz 2010 08:36:32 schrieb Mukul Goyal:
>>> Here are some comments on draft-ietf-roll-routing-metrics-05. Not =20=

>>> sure if
>>> people have already identified these issues.
>>>
>>> 1) I am concerned about the fact that the metrics draft does not =20
>>> currently
>>> allow a metric to be declared "multiplicative" in nature.
>>>
>>> The natural way to aggregate the link-level reliabilities into a =20
>>> path-level
>>> reliability is by multiplication.
>> You can transform any multiplicative metric into an additive one =20
>> and the other
>> way around by applying a logarithm or exponential function.
>>
>> Henning Rogge
>>
>> --
>> 1) You can't win.
>> 2) You can't break even.
>> 3) You can't leave the game.
>> - The Laws of Thermodynamics, summarized
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From pthubert@cisco.com  Tue Apr 13 00:48:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9C03A684B for ; Tue, 13 Apr 2010 00:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.853
X-Spam-Level: 
X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[AWL=1.746,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymSDd5rM21aH for ; Tue, 13 Apr 2010 00:48:06 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF5883A69CB for ; Tue, 13 Apr 2010 00:47:24 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAI++w0urRN+K/2dsb2JhbACbQ3GiBpl1gmwIghgE
X-IronPort-AV: E=Sophos;i="4.52,196,1270425600"; d="scan'208";a="250174141"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2010 07:47:19 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3D7lGmu013590; Tue, 13 Apr 2010 07:47:19 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:47:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Apr 2010 09:47:14 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38C5C@XMB-AMS-107.cisco.com>
In-Reply-To: <029001cada6d$ee7a8de0$cb6fa9a0$@alexander@ekasystems.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome
Thread-Index: AcrMj8guVh9b6PuxQCivH4x2A3J44AKYYCvgAJA3Y8AAOMtcQAAN2GfAAAOwoyAAAPs/oAAe3dAQ
References: 	<8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com>	<3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE01C607F5@XMB-AMS-103.cisco.com> <027601cada59$a0c46350$e24d29f0$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5D01A38AD8@XMB-AMS-107.cisco.com> <029001cada6d$ee7a8de0$cb6fa9a0$@alexander@ekasystems.com>
From: "Pascal Thubert (pthubert)" 
To: "Roger Alexander" , "Mathilde Durvy (mdurvy)" , "Navneet Agarwal (navagar)" , "ROLL WG" 
X-OriginalArrivalTime: 13 Apr 2010 07:47:15.0341 (UTC) FILETIME=[88EE0BD0:01CADADD]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:48:07 -0000

Hi Roger:

I'm 100% with you. Let's see what others say...

Pascal

> -----Original Message-----
> From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
> Sent: Monday, April 12, 2010 8:28 PM
> To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy); Navneet
Agarwal
> (navagar); 'ROLL WG'
> Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
>=20
> Hi Pascal,
>=20
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> > Sent: Monday, April 12, 2010 12:23 PM
> > To: Roger Alexander; Mathilde Durvy (mdurvy); Navneet Agarwal
> > (navagar); ROLL WG
> > Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> >
> > Hi Roger:
> >
> > I do believe like you do that incremental updates will be a nice
> > feature and I'll support it in due time. I'm unsure we can fit that
in
> > the current RPL version though, because even if it works better in a
> > large scale stable network, it has probably a less generic
> > applicability than the simple repeat over and over method that RPL
> > uses today. But that's just my vote.
>=20
> In the interest of continued movement on the core spec. this item can
be
> addressed as part of a specific domain applicability provided there
are
> elements in the base DAO/DIO structure that will permit later
inclusion.
>=20
> >
> > For the steps that will make it possible (ask the DAO and multiple
> > targets in a DAO) I think they make sense in the current RPL for
> > merits of their own.
>=20
> I certainly support the DAO Acknowledgment and the option to include
> multiple targets in a DAO message as capabilities that can have
general
> applicability.
>=20
> My suggestion here is to have a target option that would
> > be valid in both DIO and DAO. In the DIO, the use would be the
> > targeted DIO that we discussed for P2P and so on, and in the DAO,
that
> > would be advertising that target (eventually as a response to the
DIO
> above).
> >
> > What do you think?
> >
>=20
> Sure. To the extent that these measures can be defined in ways to
address
> requirements across the multiple RPL domain constituents that would
indeed
> be the preferred way to proceed.
>=20
> >
> > Pascal
> >
> >
> > > -----Original Message-----
> > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf
> > Of
> > > Roger Alexander
> > > Sent: Monday, April 12, 2010 6:03 PM
> > > To: Mathilde Durvy (mdurvy); Navneet Agarwal (navagar); 'ROLL WG'
> > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > >
> > > Hi Navneet, Mathilde,
> > >
> > > Thanks for the feedback on the interop event.
> > >
> > > Roger
> > >
> > > > -----Original Message-----
> > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> > Behalf
> > > > Of Mathilde Durvy (mdurvy)
> > > > Sent: Monday, April 12, 2010 4:16 AM
> > > > To: Navneet Agarwal (navagar); ROLL WG
> > > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > > >
> > > > Hi Navneet,
> > > >
> > > > Thanks for your feedback. I fully agree with the issues you
> > described.
> > > > I just wanted to mention that our interop event was based on
> > revision
> > > > 05 of the RPL draft.
> > > >
> > > > My general impression is that the "DIO part" of RPL is stable,
> > working
> > > > well, and it's probably a good time to freeze the specs there.
> > > > Concerning the "DAO part", we could only test the "fully
storing"
> > mode.
> > > > What I observed was that except for the "DAO rank" issue below,
> > there
> > > > was no interop problems but the scalability of the solution
needs
> > to
> > > > be improved  (the first think to do would be to agree on a way
to
> > > > include several prefixes in a DAO packet).
> > >
> > > I would very strongly endorse this direction of multiple prefixes
> > (the
> > option
> > > to carry full or partial sub-DAG stack) within the DAO message.
This
> > capability
> > > together with the ability to support incremental update of changes
> > between
> > > a node and its DAO parents will greatly improve the scalability of
> > the
> > solution
> > > for networks with storing nodes where nodes can take advantage of
> > > acknowledged/cached information to limit repetitive DAO
> > transmissions.
> > >
> > >
> > > > Also I think RPL is currently at the right level of complexity
for
> > the
> > > > platforms it's targeting however we should be careful not to add
> > > > to much extra features.
> > > >
> > > > Best,
> > > > Mathilde
> > > >
> > > > -----Original Message-----
> > > > From: Navneet Agarwal (navagar)
> > > > Sent: dimanche, 11. avril 2010 07:22
> > > > To: ROLL WG
> > > > Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal
(navagar)
> > > > Subject: RE: [Roll] IPSO Interop event - Feed-back welcome
> > > >
> > > > Hi:
> > > > I have two feedbacks from the router testing perspective.
> > > >
> > > > Feedback-I:
> > > > DAO rank: It seems there very couple of different
interpretations
> > for
> > > > setting this value.
> > > > A. Several implementations were setting the DAO rank to be equal
> > > > to the node rank (value sent in DIO rank). Each node relays this
> > > > info
> > in
> > > > the DAO towards the root. However this does not convey any
> > > > differentiating info to the receiving nodes when the DAOs are
> > received
> > > > thru multiple paths in order to install the best route.
> > > > B. The other implementation was to set the value to 0 (or 1) by
> > > > the node and have the intermediate nodes increment it as the DAO
> > > > rides
> > up
> > > > to the root.
> > > > The DAO rank in this case is more of a hop count and the
receiving
> > > > nodes can make a decision based on the lowest value received
when
> > > > installing the DAO route.
> > > > Pros: Decision is optimized based on hopcount. Relatively
simple.
> > > > Cons: Hopcount does not take link cost into account.
> > > > C. A third proposal was to set the DAO rank equal to the node
rank
> > and
> > > > a link cost in the metric container as each nodes propagates the
> > DAO.
> > > > The receiving nodes would make a decision based on the link
cost.
> > > > Pros: Decision is optimized based on link cost
> > > > Cons: The DAOs would need to carry additional info in the packet
> > > > (bigger
> > > > DAOs) and more processing needed in the nodes to parse and
process.
> > > >
> > > > I think we need some more details the spec for describing the
> > > > value
> > to
> > > > be set in DAO rank.
> > > >
> > > >
> > > > Feedback-II:
> > > > DIO Sequence number: The issue was what should be the initial
> > > > value
> > of
> > > > this field. The spec is not clear on what should be the initial
> > value
> > > > set by the root. This has implications at the LBR in
reload/reboot
> > > > conditions. For example, if the initial value is set to 1 and is
> > > > incremented to say 10. When the LBR reloads/reboots, it would
> > > > start the sequence number with 1 but its DIOs will be rejected
by
> > > > the
> > nodes
> > > > as having stale sequence number. The LBR can store the sequence
in
> > > > persistent memory. An easier option could be use
> > > > 255 as the starting sequence number. Using this value will make
> > sure
> > > > that the sequence number is always valid.
> > > >
> > > > Comments?
> > > >
> > > > Thanks
> > > >
> > > > Regards,
> > > > Navneet
> > > >
> > > > > -----Original Message-----
> > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> > Behalf
> > > > > Of Mathilde Durvy (mdurvy)
> > > > > Sent: Thursday, April 08, 2010 1:46 PM
> > > > > To: JP Vasseur
> > > > > Cc: ROLL WG
> > > > > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
> > > > >
> > > > > Dear All,
> > > > >
> > > > > Following the discussion on the mailing list I just wanted to
> > > > > clarify a few things so that we can find the best way to
> > > > > interact
> > in
> > > > > the future.
> > > > >
> > > > > - We were proposed a slot to announce this first interop event
> > > > > during the ROLL WG meeting, future events may be advertised
only
> > on
> > > > > an IPSO web-site if this is preferred by the WG.
> > > > > - IPSO is not defining standards. It is organizing interop
> > > > > events
> > to
> > > > > ensure that different implementations of the same standard do
> > work
> > > > > together. The current status is that you have to pay a
> > > > > membership fee to participate in these events (and indeed
these
> > > > > events take work, prior preparation, and money to organize).
> > > > > - We understand (at least) some people are still interested in
> > > > interop
> > > > > event feedback. This will be given on individual, voluntary,
> > basis
> > > > > by the participants of the interop event.
> > > > >
> > > > > Best,
> > > > > Mathilde
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: JP Vasseur [mailto:jpv@cisco.com]
> > > > > Sent: vendredi, 26. mars 2010 03:55
> > > > > To: Mathilde Durvy (mdurvy)
> > > > > Cc: ROLL WG
> > > > > Subject: IPSO Interop event - Feed-back welcome
> > > > >
> > > > > Hi,
> > > > >
> > > > > Just re-enforcing my comments during the ROLL WG meeting ...
> > > > > any feed- back from the IPSO interop about any issues that you
> > may
> > > > > have found would be extremely useful to continue to improve
our
> > spec.
> > > > > Feel free to also share good news.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > JP.
> > > > >
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > Roll@ietf.org
> > > https://www.ietf.org/mailman/listinfo/roll


From pthubert@cisco.com  Tue Apr 13 00:48:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67D13A684B for ; Tue, 13 Apr 2010 00:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.182
X-Spam-Level: 
X-Spam-Status: No, score=-8.182 tagged_above=-999 required=5 tests=[AWL=0.928,  BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRdCgSUmhOvv for ; Tue, 13 Apr 2010 00:48:07 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 127A73A69DC for ; Tue, 13 Apr 2010 00:47:25 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,196,1270425600"; d="scan'208";a="513884474"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2010 07:47:19 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3D7kTTE000676; Tue, 13 Apr 2010 07:47:19 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 13 Apr 2010 09:47:16 +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, 13 Apr 2010 09:47:08 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01A38C5D@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
Thread-Index: Acra3YQmilVAN0aqSeq3ZEOdvie1dA==
From: "Pascal Thubert (pthubert)" 
To: "Roger Alexander" , "Navneet Agarwal (navagar)" , "JP Vasseur" , 
X-OriginalArrivalTime: 13 Apr 2010 07:47:16.0982 (UTC) FILETIME=[89E87160:01CADADD]
Cc: ROLL WG 
Subject: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back welcome)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 07:48:08 -0000

Pascal

> One consequence of maintaining multiple DAO parents is the potential
fan
> out of routing paths. With path fan out a node may have multiple
downward
> next hop addresses for a given target destination address. Without
some
> path preference indication there is no information available if a
storing node
> (including the root) wishes to limit the number of downward next hops
> maintained for a given address. It is thus desirable to have some
means of
> path control to limit fan out as well as a preference indication that
can work in
> conjunction with the hop-by-hop DAO exchanges.
>=20
> See the Figure below for an example in which nodes maintain two DAO
> Parents each, where in the worst case the fan out that occurs after
three
> hops results in eight next hop downward paths from the DODAG root
(LBR)
> to a target node (41). Even with the hop-by-hop DAO mechanism it would
be
> desirable to be able to limit fan out as well as to identify path
preference and
> diversity at the root or other intermediate storing node.
>=20
>                     (------------LBR------------)
>                     /    /   / |     | \    \   \
>                    /    /   /  |     |  \    \   \
>                   /    /   /   |     |   \    \   \
>                  /    /   /    |     |    \    \   \
>               (11) (12) (13) (14)   (15) (16) (17) (18)
>                  \   |    |    /     \    |    |   /
>                   \  |    |   /       \   |    |  /
>                    \ |    |  /         \  |    | /
>                   (21)   (22)           (23)  (24)
>                       \    |            |    /
>                        \   |            |   /
>                         \  |            |  /
>                          (31)          (32)
>                              \        /
>                               \      /
>                                \    /
>                                 (41)
>=20

[Pascal] Your schema illustrates clearly that even if we fan out a lot,
it does not mean that a router on the way down will have more feasible
successors.=20

That's one thing that's important to remember, the properties of the DAG
are not symmetrical, so even if we build it to get multiple feasible
successors on the way up, that does not mean that on the reverse DAG to
a target there are multiple successors at each hop towards that target.

In other words, the ROI of fanning out is not guaranteed if we do it
blindly.

> A simple path control bitmap associated with the advertised
Destination
> Address can be included within the DAO to address the issue of path
> preference as well as control of fan out. For a network of
'non-storing'
> nodes the preference indication would be processed only at the root.

[Pascal] so far so good, but that will give you a blind mechanism.=20

> With the path control byte associated with each DAO destination
address, a
> node will be able to specify preference among DAO parent paths and can
> convey limits on the number of downward paths. This is an opportunity
for
> nodes to further influence the downward paths that are established and
> maintained. Consistent with the DV-based RPL operation this DAO path
> control mechanism must operate hop-by-hop avoiding any requirement for
> end-to-end path coordination. To avoid overloading this email thread I
will
> initiate a separate discussion on how a path control element may be
included
> within the DAO.
>=20
[Pascal] Too late, I just did :)

And if I remember, Tim's idea was to control the stretch of the fanout,
by decrementing a counter as the path loses preference point.
At the moment, we have a parent preference 0-lowest to 3 highest. So it
is easy to decrement a counter by (3-pref) and not fan out when the
counter reaches 0.
Tim, could you elaborate on this?

Pascal



From henning.rogge@fkie.fraunhofer.de  Tue Apr 13 01:02:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FB73A69DA for ; Tue, 13 Apr 2010 01:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.649
X-Spam-Level: 
X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFKvSnRHr8FI for ; Tue, 13 Apr 2010 01:02:36 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9E1FC3A69E3 for ; Tue, 13 Apr 2010 01:02:33 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O1b4f-0001rP-UR; Tue, 13 Apr 2010 10:02:21 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O1b4f-0001ep-L2; Tue, 13 Apr 2010 10:02:21 +0200
From: Henning Rogge 
To: roll@ietf.org
Date: Tue, 13 Apr 2010 10:02:12 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-17-generic; KDE/4.4.2; i686; ; )
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>
In-Reply-To: <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1582846.PQ3NLUPJbK"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201004131002.18489.henning.rogge@fkie.fraunhofer.de>
X-Virus-Scanned: yes (ClamAV 0.95.3/10736/Tue Apr 13 07:23:25 2010) by mailguard.fgan.de
X-Scan-Signature: d06c92ca4406a5c9a6ad4030b633b206
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 08:02:37 -0000

--nextPart1582846.PQ3NLUPJbK
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Tue April 13 2010 09:34:32 JP Vasseur wrote:
> To you second point, using logs/exponential you could concert additive
> into multiplicative metric.
You can do this the other way around to (converting a multiplicative metric=
=20
into an additive one).

> Should you still want "multiplicative" to avoid too much computation
> on the nodes, let's add a flag value here for multiplcative metric (in
> the next revision).
The advantage I see with additive metrics is that they are easier to implem=
ent=20
in integer arithmetic. Doing a multiplicative metric in integer arithmetic =
is=20
often a source for subtle bugs.

Henning Rogge

=2D-=20
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

--nextPart1582846.PQ3NLUPJbK
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkvEJQUACgkQRIfGfFXsz+DCPACfd9CuRllweT7IpHTIJLhYJLce
dVcAn18uSnJlqWDfsX91SjS2QhXPRQ7d
=rMm5
-----END PGP SIGNATURE-----

--nextPart1582846.PQ3NLUPJbK--

From alexandru.petrescu@gmail.com  Tue Apr 13 03:31:01 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49EA3A683B for ; Tue, 13 Apr 2010 03:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.712
X-Spam-Level: 
X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.537,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFKn0lQ7DqNa for ; Tue, 13 Apr 2010 03:31:00 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 880FB3A6804 for ; Tue, 13 Apr 2010 03:31:00 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3DAUpZO006272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Apr 2010 12:30:52 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3DAUpq5015270; Tue, 13 Apr 2010 12:30:51 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3DAUo1s025680; Tue, 13 Apr 2010 12:30:51 +0200
Message-ID: <4BC447DA.8050204@gmail.com>
Date: Tue, 13 Apr 2010 12:30:50 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4BBFB419.10905@gmail.com>		<4BC05CCB.5040009@gmail.com>		<4BC06997.8010703@gmail.com>		<16772.1271119153@marajade.sandelman.ca> <1D77938D-C5A2-4267-8E4C-471EA3017F9D@tzi.org>
In-Reply-To: <1D77938D-C5A2-4267-8E4C-471EA3017F9D@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 10:31:01 -0000

Le 13/04/2010 09:07, Carsten Bormann a écrit :
> On Apr 13, 2010, at 02:39, Michael Richardson wrote:
>
>> Carsten talks about who creates AH and who processes it --- in most
>> cases the DIOs and DODAGs are unicast, or multicast (therefore,
>> "for" all nodes).  Multicast AH is well understood.
>
> Actually, I was considering the case where a *data* packet is being
> forwarded and the routers on the way insert routing information into
> an IPv6 hop-by-hop option, further modify that on the way and (to
> make AH work) finally remove all this stuff again before handing it
> to the destination process.

This can't work when the src and dst of the application data are both
Routers within the RPL domain:

       R1---R2---R3 as opposed to

  H1---R1---R2---R3---H2 which could work.

Or are you going to restrict Routers from running applications?

Alex

   Any AH in there is protecting the
> end-to-end information; there is no way that same protection can be
> used to protect information that is inserted/modified hop-by-hop. No,
> I'm not giving the end-to-end keys to every router on the way :-)
>
> (I agree that AH could be used to secure RPL-specific packets sent
> between routers; I'm not so sure this is a good match.)
>
> Gruesse, Carsten
>
> _______________________________________________ Roll mailing list
> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>



From gnawali@cs.stanford.edu  Tue Apr 13 09:44:48 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9A83A6A55 for ; Tue, 13 Apr 2010 09:44:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-IB0hMnH7se for ; Tue, 13 Apr 2010 09:44:47 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id B18C63A6A53 for ; Tue, 13 Apr 2010 09:44:47 -0700 (PDT)
Received: from mail-gw0-f44.google.com ([74.125.83.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O1jEA-0004BC-21 for roll@ietf.org; Tue, 13 Apr 2010 09:44:42 -0700
Received: by gwb1 with SMTP id 1so1913226gwb.31 for ; Tue, 13 Apr 2010 09:44:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.151.12 with HTTP; Tue, 13 Apr 2010 09:44:21 -0700 (PDT)
In-Reply-To: <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>
From: Omprakash Gnawali 
Date: Tue, 13 Apr 2010 09:44:21 -0700
Received: by 10.150.233.18 with SMTP id f18mr5532113ybh.167.1271177081206;  Tue, 13 Apr 2010 09:44:41 -0700 (PDT)
Message-ID: 
To: JP Vasseur 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 13 Apr 2010 16:44:48 -0000

On Tue, Apr 13, 2010 at 12:34 AM, JP Vasseur  wrote:
...
>> 2. Towards the end of 4.3.2:
>>
>> "The ETX object may be used as a constraint or a path metric. =A0For
>> =A0example, an Objective Function may indicate that the ETX must not be
>> =A0below some specified value."
>>
>> Should be: ETX must not be more than some specified value.
>>
>
> Good catch, will fix it.

The ETX Objective Function proposes a threshold. While I was working
on ETXOF, the difficulty was coming up with the "right" threshold for
both link ETX and path ETX. This might be a configuration parameter
but it is not clear what the default value should be. It will be great
to get feedback from the WG on what the default should be.

- om_p

From jpv@cisco.com  Wed Apr 14 01:22:01 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D5E3A684B for ; Wed, 14 Apr 2010 01:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.722
X-Spam-Level: 
X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=-3.612, BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiWIsSo6k-R8 for ; Wed, 14 Apr 2010 01:21:55 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id ECD253A67BD for ; Wed, 14 Apr 2010 01:21:50 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYCAMoXxUuQ/uCWe2dsb2JhbACbVhUBAQsLIgYconqZd4UNBA
X-IronPort-AV: E=Sophos;i="4.52,203,1270425600";  d="scan'208";a="5553818"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2010 07:45:53 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3E8Lhob024973 for ; Wed, 14 Apr 2010 08:21:43 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 10:21:42 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 10:21:29 +0200
Message-Id: 
From: JP Vasseur 
To: roll WG 
In-Reply-To: <79EE5F97-5855-46FE-92DE-8D6FD022C391@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 10:21:29 +0200
References:  <6A2A459175DABE4BB11DE2026AA50A5D01923F41@XMB-AMS-107.cisco.com>  <6A2A459175DABE4BB11DE2026AA50A5D01923F4A@XMB-AMS-107.cisco.com> <79EE5F97-5855-46FE-92DE-8D6FD022C391@cisco.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 08:21:29.0735 (UTC) FILETIME=[7BDB7170:01CADBAB]
Subject: Re: [Roll] DIS information filter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 08:22:01 -0000

So just to make sure that we came to a conclusion. There is a good  
consensus to say that there
are situations where such filter could be useful, thus the DIS format  
in rev-08 will be changed for
an empty body that could potentially carry TLV, with no TLV defined  
for the time being.

Cheers.

JP.

On Apr 6, 2010, at 12:15 PM, JP Vasseur wrote:

> Hi,
>
> On Apr 5, 2010, at 11:43 AM, Pascal Thubert (pthubert) wrote:
>
>> JP:
>>
>> I agree with allowing options and eventually suboptions (since we
>> migrated out of ND messages, the so-called suboptions are really
>> options, we need to fix that) in all RPL messages.
>>
>> This does not mean that everything has to be options. Same goes for  
>> DIO,
>> would you make everything in the base header an option?
>
> Sure, I do agree.
>
>>
>> OTOH, in the current spec, the target in a DAO is not an option. This
>> prevents from packing multiple targets in a single DAO, which is  
>> really
>> sad in the stateful mode.
>>
>> I agree with good sense as long as it is really common.
>
> Agree.
>
> JP.
>
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: JP Vasseur [mailto:jpv@cisco.com]
>>> Sent: Monday, April 05, 2010 11:35 AM
>>> To: Pascal Thubert (pthubert)
>>> Cc: Philip Levis; ROLL WG
>>> Subject: Re: [Roll] DIS information filter
>>>
>>> Hi,
>>>
>>> There is golden rule for deciding this, mostly common sense. The
>> reason why
>>> I would argue for a sub-option in this case is that we may need  
>>> other
>> ones in
>>> the future. It might not be needed in some cases, and we may need  
>>> more
>> in
>>> other cases, a good reason for using options in my opinion.
>>>
>>> Thanks.
>>>
>>> JP.
>>>
>>> On Apr 5, 2010, at 10:58 AM, Pascal Thubert (pthubert) wrote:
>>>
>>>> Hi Phil:
>>>>
>>>> I'm in, agreement with everything you said below. But one thing
>> where
>>>> you lost me.
>>>>
>>>> I understood that you were advocating for simplicity and not using
>> an
>>>> option for something that's really basic/core, thus my post on
>> another
>>>> thread before I saw this where those parms make the DIS message
>>>> itself.
>>>> I tend to prefer the simplicity in this case.
>>>>
>>>> For me an option is good for:
>>>> - something that's used only when an optional behavior applies. For
>>>> instance OF specific suboptions.
>>>> - something that does not need to be repeated in all messages. Like
>> OF
>>>> parms.
>>>> - something that might be repeated multiple times in a message. For
>>>> instance I think that the target of a DAO should be an option so we
>>>> can have multiple of them in one message
>>>> - something that might be used in multiple types of messages. The
>>>> target I mentioned above could be useful in DIO for stimulated
>> repair,
>>>> incoming request and P2P as already discussed in the ML.
>>>>
>>>> So, I agree with accepting options in DIS, I'm just unclear whether
>>>> your proposal is an option or mostly the base DIS.
>>>>
>>>> Votes?
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
>> Behalf
>>>> Of
>>>>> Philip Levis
>>>>> Sent: Friday, April 02, 2010 7:01 PM
>>>>> To: ROLL WG
>>>>> Subject: [Roll] DIS information filter
>>>>>
>>>>> (Trying to restart the thread)
>>>>>
>>>>> In -07, nodes always respond to DIS messages by resetting their
>>>> Trickle
>>>>> timers. A few people on the list have pointed out that this is
>>>> problematic. If
>>>>> an environment has multiple RPL instances, for example, when a  
>>>>> node
>>>>> solicits information it must do so from *all* instances, even if  
>>>>> it
>>>> knows the
>>>>> one it wants to join.
>>>>>
>>>>> The basic issue is that a node may wish to solicit DIOs from  
>>>>> only a
>>>> subset of
>>>>> nodes; it's wasteful to force a lot of nodes to reset their  
>>>>> trickle
>>>> timers
>>>>> unnecessarily.
>>>>>
>>>>> I propose that we add a new suboption to RPL, which is only valid
>> for
>>>> DIS
>>>>> messages. The Solicited Information Filter suboption specifies a
>> set
>>>> of
>>>>> predicates; if a node satisfies the predicates, it MUST reset its
>>>> timer in
>>>>> response to the message. If it does not satisfy the predicates, it
>>>> MUST NOT
>>>>> reset its timer in response to the message.
>>>>>
>>>>> The trick is to make this a simple, fixed-length suboption;  
>>>>> forcing
>>>> nodes to
>>>>> parse all kinds of suboptions is problematic in terms of code  
>>>>> size.
>>>> Similarly,
>>>>> we'd like the suboption to cover the compelling cases but not be  
>>>>> so
>>>> complete
>>>>> that it wastes space on useless fields. So the question is: what
>>>> information do
>>>>> nodes want to filter on?
>>>>>
>>>>> The one that immediately comes to mind is a DODAG Iteration: this
>>>> would
>>>>> imply the RPLInstanceID, Sequence, and DODAGID.
>>>>>
>>>>> There have been a few mentions of Rank. I personally think it  
>>>>> makes
>>>> more
>>>>> sense to handle this through trickle suppression (you generally
>> want
>>>> low-
>>>>> Rank messages more than high-Rank ones), but this seems like a  
>>>>> good
>>>> point
>>>>> of discussion.
>>>>>
>>>>> So my current proposal is that the Solicited Information Suboption
>>>>> has
>>>> the
>>>>> following format:
>>>>>
>>>>>     0                   1                   2                   3
>>>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
>> 1
>>>>>
>>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |   Type = 5    |    Reserved   |   Sequence    |
>> RPLInstanceID
>>>> |
>>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |
>>>> |
>>>>>    +
>>>> +
>>>>>    |                            DODAGID
>>>> |
>>>>>    +
>>>> +
>>>>>    |
>>>> |
>>>>>    +
>>>> +
>>>>>    |
>>>> |
>>>>>
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>> Furthermore, we should reserve values for Sequence, RPLInstanceID,
>>>>> and DODAGID as wildcards ("any value matches"). This would  
>>>>> indicate
>>>>> that
>>>> such
>>>>> values can't be used normally. Alternatively, the reserved region
>>>> could have
>>>>> bits stating which of the three fields to match on.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Phil
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jpv@cisco.com  Wed Apr 14 01:28:46 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1BD3A6976 for ; Wed, 14 Apr 2010 01:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.95
X-Spam-Level: 
X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.648,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ofvwPli2OSP for ; Wed, 14 Apr 2010 01:28:45 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 910483A69D1 for ; Wed, 14 Apr 2010 01:28:45 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD4ZxUurR7H+/2dsb2JhbACbVnGjDJlzhQ0E
X-IronPort-AV: E=Sophos;i="4.52,203,1270425600";  d="scan'208,217";a="514675682"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2010 08:28:39 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3E8SQhx027763 for ; Wed, 14 Apr 2010 08:28:39 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 10:28:37 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 10:28:37 +0200
Message-Id: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com>
From: JP Vasseur 
To: roll WG 
Content-Type: multipart/alternative; boundary=Apple-Mail-75-868740030
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 10:28:36 +0200
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 08:28:37.0158 (UTC) FILETIME=[7A9F0460:01CADBAC]
Subject: [Roll] Important Clarification
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Apr 2010 08:28:46 -0000

--Apple-Mail-75-868740030
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Dear all,

First of all, thanks to all of you for the the number of fruitful  
discussions on the list. We are progressing fast and well.

And it is good to see implementers' feed-back too, very useful.

We all agreed that we had to on several items for the core  
specifications before LC:
	* P2P (a solution should be proposed anytime soon)
	* Security (the security DT is working hard, we can expect some text  
soon too)
	* We agreed on a number of topics to be incorporated in rev-08
	* We will need to work on several optimizations
	* Discussion on source routing
	
But I think that we also agreed to "Freeze" the core specification. In  
other words, at some point, we need to stop
adding features FOR THE CORE specification, sort out all remaining  
issues, while making sure that we satisfy all
MUST requirements (see ticket #25).

Needless to say, that new ideas are extremely welcome, in separate  
documents, but as a WG, we should really
focuss on the core specification for the time being.

Thanks again for the great work and progress.

JP.
--Apple-Mail-75-868740030
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Dear =
all,

    First of all, thanks to all of you for the the =
number of fruitful discussions on the list. We are progressing fast and =
well.

    And it is good to see implementers' =
feed-back too, very useful.

    We all agreed that =
we had to on several items for the core specifications before =
LC:
    	=
* P2P (a solution should be proposed anytime =
soon)
    	=
* Security (the security DT is working hard, we can expect some =
text soon too)
    	* We agreed on a number of topics =
to be incorporated in rev-08
    	* We will need to work on several =
optimizations
    	* Discussion on source =
routing
    	
    But I think that we =
also agreed to "Freeze" the core specification. In other words, =
at some point, we need to stop 
    adding features FOR THE =
CORE specification, sort out all remaining issues, while making sure =
that we satisfy all 
    MUST requirements (see ticket =
#25).

    Needless to say, that new ideas are =
extremely welcome, in separate documents, but as a WG, we =
should really 
    focuss on the core specification for =
the time being.

    Thanks again for the great work =
and progress.

    JP.
    =

--Apple-Mail-75-868740030--

From Daniel.Popa@itron.com  Wed Apr 14 02:28:00 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C565D3A69DB for ; Wed, 14 Apr 2010 02:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level: 
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e15R8DWGq+4d for ; Wed, 14 Apr 2010 02:27:59 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 89DE73A684B for ; Wed, 14 Apr 2010 02:27:59 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADBB4.C1D2AACD"
Date: Wed, 14 Apr 2010 05:27:50 -0400
Message-ID: 
X-MimeOLE: Produced By Microsoft Exchange V6.5
In-Reply-To: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Important Clarification
Thread-Index: AcrbrIWNW/L/+zxWRO6mUwCtH5t1XQABgJWg
References: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com>
From: "Popa, Daniel" 
To: "JP Vasseur" 
Cc: roll@ietf.org
Subject: Re: [Roll] Important Clarification
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Apr 2010 09:28:00 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CADBB4.C1D2AACD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

JP,=20

=20

Do we have some priorities assigned to the (five) open issues (cited in
your email)?=20

=20

If not, I would suggest you assign some priorities among the remaining
open issues and discuss them one-by-one. This will eventually allow us
to close them faster and so speed up the process.=20

=20

Thanks.=20

=20

Cheers,=20

Daniel =20

=20

=20

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
JP Vasseur
Sent: Wednesday, April 14, 2010 10:29 AM
To: roll WG
Subject: [Roll] Important Clarification

=20

Dear all,

=20

First of all, thanks to all of you for the the number of fruitful
discussions on the list. We are progressing fast and well.

=20

And it is good to see implementers' feed-back too, very useful.

=20

We all agreed that we had to on several items for the core
specifications before LC:

          * P2P (a solution should be proposed anytime soon)

          * Security (the security DT is working hard, we can expect
some text soon too)

          * We agreed on a number of topics to be incorporated in rev-08

          * We will need to work on several optimizations

          * Discussion on source routing

         =20

But I think that we also agreed to "Freeze" the core specification. In
other words, at some point, we need to stop=20

adding features FOR THE CORE specification, sort out all remaining
issues, while making sure that we satisfy all=20

MUST requirements (see ticket #25).

=20

Needless to say, that new ideas are extremely welcome, in separate
documents, but as a WG, we should really=20

focuss on the core specification for the time being.

=20

Thanks again for the great work and progress.

=20

JP.


------_=_NextPart_001_01CADBB4.C1D2AACD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    JP, =

    


    &nb=
sp;
    


    Do we =
have
some priorities assigned to the (five) open issues (cited in your =
email)? 
    


    &nb=
sp;
    


    If not, =
I
would suggest you assign some priorities among the remaining open issues =
and
discuss them one-by-one. This will eventually allow us to close them =
faster and
so speed up the process. 
    


    &nb=
sp;
    


    Thanks. =

    


    &nb=
sp;
    


    Cheers, =

    


    Daniel =
 
    


    &nb=
sp;
    


    &nb=
sp;
    


    &nb=
sp;
    


     
    


    


    


    


    From:=

roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
JP
Vasseur
    
Sent: Wednesday, April 14, 2010 10:29 AM
    
To: roll WG
    
Subject: [Roll] Important Clarification
    


    


    


     
    


    Dear all,
    


    


     
    


    


    


    First of all, thanks to all of you for the the =
number of
fruitful discussions on the list. We are progressing fast and =
well.
    


    


    


     
    


    


    


    And it is good to see implementers' feed-back too, =
very
useful.
    


    


    


     
    


    


    


    We all agreed that we had to on several items for =
the core
specifications before LC:
    


    


    


            &n=
bsp; *
P2P (a solution should be proposed anytime soon)
    


    


    


            &n=
bsp; *
Security (the security DT is working hard, we can expect some text soon =
too)
    


    


    


            &n=
bsp; *
We agreed on a number of topics to be incorporated in =
rev-08
    


    


    


            &n=
bsp; *
We will need to work on several optimizations
    


    


    


            &n=
bsp; *
Discussion on source routing
    


    


    


            &n=
bsp; 
    


    


    


    But I think that we also agreed to =
"Freeze" the core
specification. In other words, at some point, we need to =
stop 
    


    


    


    adding features FOR THE CORE specification, sort =
out all
remaining issues, while making sure that we satisfy =
all 
    


    


    


    MUST requirements (see ticket #25).
    


    


    


     
    


    


    


    Needless to say, that new ideas are extremely =
welcome, in
separate documents, but as a WG, we =
should really 
    


    


    


    focuss on the core specification for the time =
being.
    


    


    


     
    


    


    


    Thanks again for the great work and =
progress.
    


    


    


     
    


    


    


    JP.
    


    


    


    





------_=_NextPart_001_01CADBB4.C1D2AACD--

From jpv@cisco.com  Wed Apr 14 05:14:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825E73A69C8 for ; Wed, 14 Apr 2010 05:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.156
X-Spam-Level: 
X-Spam-Status: No, score=-9.156 tagged_above=-999 required=5 tests=[AWL=1.442,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJacJ7tbURhQ for ; Wed, 14 Apr 2010 05:14:53 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 311CD3A6AFD for ; Wed, 14 Apr 2010 05:10:51 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIFACtOxUurR7H+/2dsb2JhbACBP5oZcaMlmW+FDQQ
X-IronPort-AV: E=Sophos;i="4.52,204,1270425600";  d="scan'208,217";a="317068470"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2010 12:10:40 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3ECAAM1021720; Wed, 14 Apr 2010 12:10:40 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:27 +0200
Received: from dhcp-144-254-20-182.cisco.com ([144.254.20.182]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:26 +0200
Message-Id: 
From: JP Vasseur 
To: "Popa, Daniel" 
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-76-882000154
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 14:09:36 +0200
References: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 12:10:26.0852 (UTC) FILETIME=[77D12640:01CADBCB]
Cc: roll@ietf.org
Subject: Re: [Roll] Important Clarification
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Apr 2010 12:14:57 -0000

--Apple-Mail-76-882000154
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi Daniel,

On Apr 14, 2010, at 11:27 AM, Popa, Daniel wrote:

> JP,
>
> Do we have some priorities assigned to the (five) open issues (cited  
> in your email)?
>
> If not, I would suggest you assign some priorities among the  
> remaining open issues and discuss them one-by-one. This will  
> eventually allow us to close them faster and so speed up the process.

We opened tickets and have groups of peope (e.g. security, ...)  
working in parallel.

Thanks.

JP.

>
> Thanks.
>
> Cheers,
> Daniel
>
>
>
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of JP Vasseur
> Sent: Wednesday, April 14, 2010 10:29 AM
> To: roll WG
> Subject: [Roll] Important Clarification
>
> Dear all,
>
> First of all, thanks to all of you for the the number of fruitful  
> discussions on the list. We are progressing fast and well.
>
> And it is good to see implementers' feed-back too, very useful.
>
> We all agreed that we had to on several items for the core  
> specifications before LC:
>           * P2P (a solution should be proposed anytime soon)
>           * Security (the security DT is working hard, we can expect  
> some text soon too)
>           * We agreed on a number of topics to be incorporated in  
> rev-08
>           * We will need to work on several optimizations
>           * Discussion on source routing
>
> But I think that we also agreed to "Freeze" the core specification.  
> In other words, at some point, we need to stop
> adding features FOR THE CORE specification, sort out all remaining  
> issues, while making sure that we satisfy all
> MUST requirements (see ticket #25).
>
> Needless to say, that new ideas are extremely welcome, in separate  
> documents, but as a WG, we should really
> focuss on the core specification for the time being.
>
> Thanks again for the great work and progress.
>
> JP.


--Apple-Mail-76-882000154
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

    On =
Apr 14, 2010, at 11:27 AM, Popa, Daniel wrote:

    JP,
    Do we have some priorities assigned to =
the (five) open issues (cited in your =
email)?
     
    If =
not, I would suggest you assign some priorities among the remaining open =
issues and discuss them one-by-one. This will eventually allow us to =
close them faster and so speed up the =
process.
     
     
    Daniel =
 
     
     
     
     roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP =
Vasseur
    Sent: Wednesday, April 14, 2010 =
10:29 AM
    To: roll =
WG
    Subject: [Roll] Important =
Clarification
    Dear =
all,
    First of all, thanks to =
all of you for the the number of fruitful discussions on the list. We =
are progressing fast and well.
     
    And it is good =
to see implementers' feed-back too, very =
useful.
    We all agreed that we had =
to on several items for the core specifications before =
LC:
            &=
nbsp; * P2P (a =
solution should be proposed anytime =
soon)
            &=
nbsp; * =
Security (the security DT is working hard, we can expect some text soon =
too)
            &=
nbsp; * We =
agreed on a number of topics to be incorporated in =
rev-08
            &=
nbsp; * We will =
need to work on several optimizations
            &=
nbsp; * =
Discussion on source routing
            &=
nbsp;
    But I think that we also =
agreed to "Freeze" the core specification. In other =
words, at some point, we need to =
stop 
    adding features FOR THE =
CORE specification, sort out all remaining issues, while making sure =
that we satisfy all 
    MUST requirements (see ticket =
#25).
    Needless to say, that new =
ideas are extremely welcome, in separate documents, but as a WG, we =
should really 
    focuss on the core specification for the time =
being.
    Thanks again for the =
great work and progress.
     
    ; Wed, 14 Apr 2010 12:10:46 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:25 +0200
Received: from dhcp-144-254-20-182.cisco.com ([144.254.20.182]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:25 +0200
Message-Id: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>
From: JP Vasseur 
To: roll WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 14:08:22 +0200
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 12:10:25.0337 (UTC) FILETIME=[76E9FA90:01CADBCB]
Subject: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 12:14:57 -0000

Dear all,

Just an (important) clarification: as you know, we have defined  
routing "attributes" in the metric ID to be used
as metrics or a constraints. And considering the number of  
applications for RPL, we will more than likely see a
number of combinations of metrics and/or constraints. Should we want  
to specify an OF each time we want to
use of combination of metric/constraint, we would certainly overlflow  
the RFC editor queue ;-) It would be nice
to have a discussion on how we could come up with the limited number  
of OF, taking out the metric/constraint
from the OF semantics. That would greatly simplify the work and still  
gives us the required flexibility.

Thanks.

JP.

From jpv@cisco.com  Wed Apr 14 05:14:57 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27A83A69C8 for ; Wed, 14 Apr 2010 05:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.317
X-Spam-Level: 
X-Spam-Status: No, score=-9.317 tagged_above=-999 required=5 tests=[AWL=1.282,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rryX7TSn+OCL for ; Wed, 14 Apr 2010 05:14:57 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 863DC3A6B5F for ; Wed, 14 Apr 2010 05:10:54 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEADpNxUurR7H+/2dsb2JhbACbWHGjK5lvhQ0E
X-IronPort-AV: E=Sophos;i="4.52,204,1270425600"; d="scan'208";a="250421837"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2010 12:10:47 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3ECARuW022075 for ; Wed, 14 Apr 2010 12:10:47 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:29 +0200
Received: from dhcp-144-254-20-182.cisco.com ([144.254.20.182]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 14:10:29 +0200
Message-Id: 
From: JP Vasseur 
To: roll WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 14:10:26 +0200
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 12:10:29.0243 (UTC) FILETIME=[793DFCB0:01CADBCB]
Subject: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 12:14:57 -0000

Dear all,

Just an (important) clarification: as you know, we have defined  
routing "attributes" in the metric ID to be used
as metrics or a constraints. And considering the number of  
applications for RPL, we will more than likely see a
number of combinations of metrics and/or constraints. Should we want  
to specify an OF each time we want to
use of combination of metric/constraint, we would certainly overlflow  
the RFC editor queue ;-) It would be nice
to have a discussion on how we could come up with the limited number  
of OF, taking out the metric/constraint
from the OF semantics. That would greatly simplify the work and still  
gives us the required flexibility.

Thanks.

JP.

From Daniel.Popa@itron.com  Wed Apr 14 06:24:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1836A3A6A0E for ; Wed, 14 Apr 2010 06:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level: 
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM6QcvYgDxzC for ; Wed, 14 Apr 2010 06:24:33 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 5BA393A686A for ; Wed, 14 Apr 2010 06:20:53 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADBD5.491914B9"
Date: Wed, 14 Apr 2010 09:20:42 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Important Clarification
Thread-Index: Acrby4OmCbrrKjunRlKrKwnMu8CzVgACN4tA
References: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com>  
From: "Popa, Daniel" 
To: "JP Vasseur" 
Cc: roll@ietf.org
Subject: Re: [Roll] Important Clarification
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Apr 2010 13:24:44 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CADBD5.491914B9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi JP,

=20

Is it too late to join and contribute to these groups of people on some
selected topics? If not, where we can find information about the process
each group follows (call meeting, mailing lists, etc....)? - Apologize
if asking redundant information.

=20

Thanks.=20

Daniel=20

=20

=20

=20

=20

From: JP Vasseur [mailto:jpv@cisco.com]=20
Sent: Wednesday, April 14, 2010 2:10 PM
To: Popa, Daniel
Cc: roll@ietf.org
Subject: Re: [Roll] Important Clarification

=20

Hi Daniel,

=20

On Apr 14, 2010, at 11:27 AM, Popa, Daniel wrote:





JP,

=20

Do we have some priorities assigned to the (five) open issues (cited in
your email)?

=20

If not, I would suggest you assign some priorities among the remaining
open issues and discuss them one-by-one. This will eventually allow us
to close them faster and so speed up the process.

=20

We opened tickets and have groups of peope (e.g. security, ...) working
in parallel.

=20

Thanks.

=20

JP.





=20

Thanks.

=20

Cheers,

Daniel =20

=20

=20

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
JP Vasseur
Sent: Wednesday, April 14, 2010 10:29 AM
To: roll WG
Subject: [Roll] Important Clarification

=20

Dear all,

=20

First of all, thanks to all of you for the the number of fruitful
discussions on the list. We are progressing fast and well.

=20

And it is good to see implementers' feed-back too, very useful.

=20

We all agreed that we had to on several items for the core
specifications before LC:

          * P2P (a solution should be proposed anytime soon)

          * Security (the security DT is working hard, we can expect
some text soon too)

          * We agreed on a number of topics to be incorporated in rev-08

          * We will need to work on several optimizations

          * Discussion on source routing

        =20

But I think that we also agreed to "Freeze" the core specification. In
other words, at some point, we need to stop=20

adding features FOR THE CORE specification, sort out all remaining
issues, while making sure that we satisfy all=20

MUST requirements (see ticket #25).

=20

Needless to say, that new ideas are extremely welcome, in separate
documents, but as a WG, we should really=20

focuss on the core specification for the time being.

=20

Thanks again for the great work and progress.

=20

JP.

=20


------_=_NextPart_001_01CADBD5.491914B9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi =
JP,
    


    &nb=
sp;
    


    Is it =
too late
to join and contribute to these groups of people on some selected =
topics? If
not, where we can find information about the process each group follows =
(call
meeting, mailing lists, etc….)? – Apologize if asking =
redundant
information.
    


    &nb=
sp;
    


    Thanks. =

    


    Daniel =

    


    &nb=
sp;
    


    &nb=
sp;
    


    &nb=
sp;
    


     
    


    


    


    


    From:=
 JP Vasseur
[mailto:jpv@cisco.com] 
    
Sent: Wednesday, April 14, 2010 2:10 PM
    
To: Popa, Daniel
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Important Clarification
    


    


    


     
    


    Hi Daniel,
    


    


     
    


    


    


    On Apr 14, 2010, at 11:27 AM, Popa, Daniel =
wrote:
    


    



    

    

    


    


    


    


    JP,
    


    


    


     
    


    


    


    Do we have some priorities assigned to the (five) open =
issues
(cited in your email)?
    


    


    


     
    


    


    


    If not, I would suggest you assign some priorities among =
the
remaining open issues and discuss them one-by-one. This will eventually =
allow
us to close them faster and so speed up the process.
    


    


    


    


    


     
    


    


    


    We opened tickets and have groups of peope (e.g. =
security,
...) working in parallel.
    


    


    


     
    


    


    


    Thanks.
    


    


    


     
    


    


    


    JP.
    


    



    

    

    


    


    


    


     
    


    


    


    Thanks.
    


    


    


     
    


    


    


    Cheers,
    


    


    


    Daniel  
    


    


    


     
    


    


    


     
    


    


    


     
    


    


    


     
    


    


    


    


    


    


    From:=
 =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
    
Sent: Wednesday, =
April 14,
2010 10:29 AM
    
To: roll WG
    
Subject: [Roll] =
Important
Clarification
    


    


    


    


    


     
    


    


    


    Dear =
all,
    


    


    


    


     
    


    


    


    


    


    First of all, thanks to =
all of you
for the the number of fruitful discussions on the list. We are =
progressing fast
and well.
    


    


    


    


    


     
    


    


    


    


    


    And it is good to see
implementers' feed-back too, very useful.
    


    


    


    


    


     
    


    


    


    


    


    We all agreed that we =
had to on
several items for the core specifications before =
LC:
    


    


    


    


    


            &nb=
sp; * P2P (a solution should be proposed anytime =
soon)
    


    


    


    


    


            &nb=
sp; * Security (the security DT is working hard, we =
can expect
some text soon too)
    


    


    


    


    


            &nb=
sp; * We agreed on a number of topics to be =
incorporated in
rev-08
    


    


    


    


    


            &nb=
sp; * We will need to work on several =
optimizations
    


    


    


    


    


            &nb=
sp; * Discussion on source =
routing
    


    


    


    


    


            &nb=
sp;
    


    


    


    


    


    But I think that we =
also agreed to
"Freeze" the core specification. In other =
words, at some
point, we need to stop 
    


    


    


    


    


    adding features FOR THE =
CORE
specification, sort out all remaining issues, while making sure that
we satisfy all 
    


    


    


    


    


    MUST requirements (see =
ticket #25).
    


    


    


    


    


     
    


    


    


    


    


    Needless to say, that =
new ideas
are extremely welcome, in separate documents, but as a WG, we =
should really 
    


    


    


    


    


    focuss on the core =
specification
for the time being.
    


    


    


    


    


     
    


    


    


    


    


    Thanks again for the =
great work
and progress.
    


    


    


    


    


     
    


    


    


    


    


    JP.
    


    


    


    


    


    


    


     
    


    


    


    





------_=_NextPart_001_01CADBD5.491914B9--

From jpv@cisco.com  Wed Apr 14 06:27:12 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229C328C1CE for ; Wed, 14 Apr 2010 06:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.445
X-Spam-Level: 
X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[AWL=-2.847, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07WbFeOBUU+O for ; Wed, 14 Apr 2010 06:27:11 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 557C828C288 for ; Wed, 14 Apr 2010 06:24:01 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwBAEZfxUuQ/uCWe2dsb2JhbACBP5oZFQEBCwsiBhyjTJlzhQ0E
X-IronPort-AV: E=Sophos;i="4.52,204,1270425600"; d="scan'208,217";a="5570104"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2010 12:48:03 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3EDNs9Z021440; Wed, 14 Apr 2010 13:23:54 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 15:23:54 +0200
Received: from dhcp-144-254-20-182.cisco.com ([144.254.20.182]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 15:23:53 +0200
Message-Id: <3E20671D-A702-490B-946B-42B42577E151@cisco.com>
From: JP Vasseur 
To: "Popa, Daniel" 
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-89-886454741
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 15:23:50 +0200
References: <4A669227-5B38-4F58-BB1E-56799EB9438A@cisco.com>   
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 13:23:53.0413 (UTC) FILETIME=[BA54FF50:01CADBD5]
Cc: roll@ietf.org
Subject: Re: [Roll] Important Clarification
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Apr 2010 13:27:12 -0000

--Apple-Mail-89-886454741
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi, Daniel,

On Apr 14, 2010, at 3:20 PM, Popa, Daniel wrote:

> Hi JP,
>
> Is it too late to join and contribute to these groups of people on =20
> some selected topics? If not, where we can find information about =20
> the process each group follows (call meeting, mailing lists, etc=85.)? =
=20
> =96 Apologize if asking redundant information.

Not at all, you're welcome to contribute !
For the security aspect, the DT will come up with a proposal that will =20=

be discussed on the mailing list.
For the other topics, there will all be discussed on the mailing list =20=

too!

Thanks.

JP.

>
> Thanks.
> Daniel
>
>
>
>
> From: JP Vasseur [mailto:jpv@cisco.com]
> Sent: Wednesday, April 14, 2010 2:10 PM
> To: Popa, Daniel
> Cc: roll@ietf.org
> Subject: Re: [Roll] Important Clarification
>
> Hi Daniel,
>
> On Apr 14, 2010, at 11:27 AM, Popa, Daniel wrote:
>
>
> JP,
>
> Do we have some priorities assigned to the (five) open issues (cited =20=

> in your email)?
>
> If not, I would suggest you assign some priorities among the =20
> remaining open issues and discuss them one-by-one. This will =20
> eventually allow us to close them faster and so speed up the process.
>
> We opened tickets and have groups of peope (e.g. security, ...) =20
> working in parallel.
>
> Thanks.
>
> JP.
>
>
>
> Thanks.
>
> Cheers,
> Daniel
>
>
>
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of JP Vasseur
> Sent: Wednesday, April 14, 2010 10:29 AM
> To: roll WG
> Subject: [Roll] Important Clarification
>
> Dear all,
>
> First of all, thanks to all of you for the the number of fruitful =20
> discussions on the list. We are progressing fast and well.
>
> And it is good to see implementers' feed-back too, very useful.
>
> We all agreed that we had to on several items for the core =20
> specifications before LC:
>           * P2P (a solution should be proposed anytime soon)
>           * Security (the security DT is working hard, we can expect =20=

> some text soon too)
>           * We agreed on a number of topics to be incorporated in =20
> rev-08
>           * We will need to work on several optimizations
>           * Discussion on source routing
>
> But I think that we also agreed to "Freeze" the core specification. =20=

> In other words, at some point, we need to stop
> adding features FOR THE CORE specification, sort out all remaining =20
> issues, while making sure that we satisfy all
> MUST requirements (see ticket #25).
>
> Needless to say, that new ideas are extremely welcome, in separate =20
> documents, but as a WG, we should really
> focuss on the core specification for the time being.
>
> Thanks again for the great work and progress.
>
> JP.
>


--Apple-Mail-89-886454741
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

Hi, =
Daniel,

    On Apr 14, 2010, at 3:20 PM, Popa, Daniel =
wrote:

    Hi JP,
    Is it too late to join and contribute =
to these groups of people on some selected topics? If not, where we can =
find information about the process each group follows (call meeting, =
mailing lists, etc=85.)? =96 Apologize if asking redundant =
information.
     
    Daniel
     
     JP =
Vasseur [mailto:jpv@cisco.com] 
    Sent: Wednesday, April 14, 2010 =
2:10 PM
    To: Popa, =
Daniel
    Cc: roll@ietf.org
    Subject: Re: [Roll] Important =
Clarification
    Hi =
Daniel,
    On Apr 14, 2010, at 11:27 =
AM, Popa, Daniel wrote:
    Do =
we have some priorities assigned to the (five) open issues (cited in =
your email)?If =
not, I would suggest you assign some priorities among the remaining open =
issues and discuss them one-by-one. This will eventually allow us to =
close them faster and so speed up the process.
     
    We opened =
tickets and have groups of peope (e.g. security, ...) working in =
parallel.
     
    From:roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP =
Vasseur
    Sent: Wednesday, April 14, 2010 =
10:29 AM
    To: roll =
WG
    Subject: [Roll] Important =
Clarification     
    Dear =
all,
    First of all, thanks to all of =
you for the the number of fruitful discussions on the list. We are =
progressing fast and =
well.
    And it is good to see =
implementers' feed-back too, very =
useful.
    We all agreed that we had to on =
several items for the core specifications before =
LC:
    * P2P (a solution =
should be proposed anytime =
soon)
    * Security (the =
security DT is working hard, we can expect some text soon =
too)
    * We agreed on a =
number of topics to be incorporated in =
rev-08
    * We will need to =
work on several =
optimizations
    * Discussion on =
source routing
    But I think that we also agreed to "Freeze" =
the core specification. In other =
words, at some point, we need to =
stop 
    adding features FOR THE CORE =
specification, sort out all remaining issues, while making sure that =
we satisfy =
all 
    MUST requirements (see ticket =
#25).
    Needless to say, that new ideas =
are extremely welcome, in separate documents, but as a WG, we =
should really 
    focuss on the core specification =
for the time being.
    Thanks again for the great work =
and progress.
     

    =

--Apple-Mail-89-886454741--

From alexandru.petrescu@gmail.com  Wed Apr 14 10:26:17 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329A63A68C6 for ; Wed, 14 Apr 2010 10:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level: 
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.406,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEgmuNPmNIwL for ; Wed, 14 Apr 2010 10:26:16 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 048353A66B4 for ; Wed, 14 Apr 2010 10:26:15 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3EHQ6dF029128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Apr 2010 19:26:06 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3EHQ6Yd008481; Wed, 14 Apr 2010 19:26:06 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3EHQ6xV015691; Wed, 14 Apr 2010 19:26:06 +0200
Message-ID: <4BC5FAAE.7050902@gmail.com>
Date: Wed, 14 Apr 2010 19:26:06 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Alexandru Petrescu 
References: <4BBFB419.10905@gmail.com>		<4BC05CCB.5040009@gmail.com>		<4BC06997.8010703@gmail.com>		<16772.1271119153@marajade.sandelman.ca> <1D77938D-C5A2-4267-8E4C-471EA3017F9D@tzi.org> <4BC447DA.8050204@gmail.com>
In-Reply-To: <4BC447DA.8050204@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: roll@ietf.org
Subject: Re: [Roll] Flow Labels are wrongly used and insecure
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 17:26:17 -0000

Following up on my own post...

I just found out about the 6MAN WG proposal to have mutable Flow 
Labels... maybe that will fly maybe that will not.  It's too early to 
decide and rely RPL on it?  I think?

(also I found Flow Labels aren't typically covered by AH, I stand
  corrected on this - but it makes insecure the overall idea of using
  the Flow Labels at the heart of RPL - be them mutable or not).

Alex

Le 13/04/2010 12:30, Alexandru Petrescu a écrit :
> Le 13/04/2010 09:07, Carsten Bormann a écrit :
>> On Apr 13, 2010, at 02:39, Michael Richardson wrote:
>>
>>> Carsten talks about who creates AH and who processes it --- in
>>> most cases the DIOs and DODAGs are unicast, or multicast
>>> (therefore, "for" all nodes). Multicast AH is well understood.
>>
>> Actually, I was considering the case where a *data* packet is
>> being forwarded and the routers on the way insert routing
>> information into an IPv6 hop-by-hop option, further modify that on
>> the way and (to make AH work) finally remove all this stuff again
>> before handing it to the destination process.
>
> This can't work when the src and dst of the application data are
> both Routers within the RPL domain:
>
> R1---R2---R3 as opposed to
>
> H1---R1---R2---R3---H2 which could work.
>
> Or are you going to restrict Routers from running applications?
>
> Alex
>
> Any AH in there is protecting the
>> end-to-end information; there is no way that same protection can
>> be used to protect information that is inserted/modified
>> hop-by-hop. No, I'm not giving the end-to-end keys to every router
>> on the way :-)
>>
>> (I agree that AH could be used to secure RPL-specific packets sent
>> between routers; I'm not so sure this is a good match.)
>>
>> Gruesse, Carsten
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>
>
>
>



From rdroms.ietf@gmail.com  Wed Apr 14 10:30:35 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A24728C0FF for ; Wed, 14 Apr 2010 10:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm4kfMQSMq1n for ; Wed, 14 Apr 2010 10:30:34 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 65AEE28C107 for ; Wed, 14 Apr 2010 10:30:11 -0700 (PDT)
Received: by vws11 with SMTP id 11so170139vws.31 for ; Wed, 14 Apr 2010 10:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=Nh4v3fTAdEgAnlI6/4HALgS7l2ofOreW2WD6CNQNo/g=; b=JBzhV5RO+dkL5fUJ9j7igU2PXgkOf5OH7TzpVYietCkcTg+oiySz5lq/TMjW4pmOsm c9ivTGrdjGlixTeaKUL2ZppM0jGhq0kJhVqgf/QMhGTlXkK3OmHnPAB1ILshKIvqWHOt 1W1KwnvzP8ezE/FuXxRttA47mXt6mIG2wANDQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=L6/2e3YJ5IJ8RwNTDnmxSekJPBCHkxc6CBfk0evz/SXsy5DI7UNkLL3MrXIaDj8VZN vfE5lSht3C44DgRC27AVmSHNXrRyrFVTrO0vtu5s6BOiaiUinBE8rQhRsIASoP5sHkmU N4/Fl4kRElM7w2vIxxHTox0WcRz751tTOoCvM=
Received: by 10.220.108.83 with SMTP id e19mr4219184vcp.165.1271266201534; Wed, 14 Apr 2010 10:30:01 -0700 (PDT)
Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 21sm11493600vws.2.2010.04.14.10.30.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 10:30:00 -0700 (PDT)
Message-Id: 
From: Ralph Droms 
To: roll@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 13:29:58 -0400
X-Mailer: Apple Mail (2.936)
Subject: [Roll] draft-ietf-roll-rpl-07
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 17:30:35 -0000

Is section 7.1 intended to give suggestions for just MP2P forwarding  
or for all flows?

- Ralph


From jeonggil.ko@gmail.com  Wed Apr 14 10:32:58 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D690B28C0D0 for ; Wed, 14 Apr 2010 10:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6mU6e42hzDy for ; Wed, 14 Apr 2010 10:32:57 -0700 (PDT)
Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by core3.amsl.com (Postfix) with ESMTP id C161F28C111 for ; Wed, 14 Apr 2010 10:32:55 -0700 (PDT)
Received: by qyk10 with SMTP id 10so455471qyk.25 for ; Wed, 14 Apr 2010 10:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=xuRxD41te9Xu78na6WC/TKTpZFp4Ee4mVuqaGQTFuKk=; b=jubgz3PQs4kE65hfXfZWDHEDeMTc2K3Ak+UOvdDLi0DMhaGL9guvbRGdSNnpNPnOcv nkPqFVLTo59RgspHuRl/9sOdlciH2tnjaYWJbK9MNbS2Qe/+/rh+Yhi9Jpaiu3wEzqSL Xz8umvQWdnNbe2lmiad7yZtm3EZf6c7dmwpxM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B77lyalflxvhzGAbo6EdbhK4qMDmAJGAggkC5+KtarndRGcFC6tpdRHQ3lylE6WgNI LnPJr8acSDRhqcq+ETLYODkwgbJ3Xgcr6wWhAS6QYJaKddKLTuH/Pwt1jxjuoolLjzpa sDVda+MLS3yJGF0kwgTVa5zo4yv3fH9rBecMc=
Received: by 10.224.63.68 with SMTP id a4mr2745019qai.275.1271266366987; Wed, 14 Apr 2010 10:32:46 -0700 (PDT)
Received: from python.isi.jhu.edu (python.isi.jhu.edu [128.220.247.192]) by mx.google.com with ESMTPS id 5sm2668525qwg.28.2010.04.14.10.32.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 10:32:45 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: "JeongGil Ko (John)" 
In-Reply-To: 
Date: Wed, 14 Apr 2010 13:32:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <239BF41C-06D4-45E0-871F-FEBE69848362@cs.jhu.edu>
References: 
To: Ralph Droms 
X-Mailer: Apple Mail (2.1078)
Cc: roll@ietf.org
Subject: Re: [Roll] draft-ietf-roll-rpl-07
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 17:32:58 -0000

On Apr 14, 2010, at 1:29 PM, Ralph Droms wrote:

> Is section 7.1 intended to give suggestions for just MP2P forwarding =
or for all flows?
>=20

I would say that this should go for all flows :)

John

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

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From jpv@cisco.com  Wed Apr 14 11:43:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFC53A68DB for ; Wed, 14 Apr 2010 11:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.186
X-Spam-Level: 
X-Spam-Status: No, score=-9.186 tagged_above=-999 required=5 tests=[AWL=1.413,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq04SNg9bpMD for ; Wed, 14 Apr 2010 11:43:09 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6CD4C3A6993 for ; Wed, 14 Apr 2010 11:43:05 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcCABqpxUuQ/uCWe2dsb2JhbACbVhUBAQsLIgYcpAyZd4UNBI5e
X-IronPort-AV: E=Sophos;i="4.52,206,1270425600"; d="scan'208";a="59412776"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2010 18:42:57 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3EIgvx4005652; Wed, 14 Apr 2010 18:42:57 GMT
Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 20:42:57 +0200
Received: from dhcp-144-254-20-182.cisco.com ([144.254.20.182]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 14 Apr 2010 20:42:57 +0200
Message-Id: <0CE7C95E-3BF1-41EC-BB1F-5EAD0F7D6BE5@cisco.com>
From: JP Vasseur 
To: JeongGil Ko (John) 
In-Reply-To: <239BF41C-06D4-45E0-871F-FEBE69848362@cs.jhu.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 14 Apr 2010 20:42:54 +0200
References:  <239BF41C-06D4-45E0-871F-FEBE69848362@cs.jhu.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 14 Apr 2010 18:42:57.0303 (UTC) FILETIME=[4CFACA70:01CADC02]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17320.001
X-TM-AS-Result: No--10.623200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Cc: roll@ietf.org, Ralph Droms 
Subject: Re: [Roll] draft-ietf-roll-rpl-07
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 18:43:10 -0000

indeed.

On Apr 14, 2010, at 7:32 PM, JeongGil Ko (John) wrote:

>
> On Apr 14, 2010, at 1:29 PM, Ralph Droms wrote:
>
>> Is section 7.1 intended to give suggestions for just MP2P  
>> forwarding or for all flows?
>>
>
> I would say that this should go for all flows :)
>
> John
>
>> - Ralph
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From pal@cs.stanford.edu  Wed Apr 14 13:30:52 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC823A6A9A for ; Wed, 14 Apr 2010 13:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.506
X-Spam-Level: 
X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f893GZjLZsHu for ; Wed, 14 Apr 2010 13:30:52 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id CD0B328C12B for ; Wed, 14 Apr 2010 13:28:58 -0700 (PDT)
Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O29Ce-00089i-SG; Wed, 14 Apr 2010 13:28:53 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <239BF41C-06D4-45E0-871F-FEBE69848362@cs.jhu.edu>
Date: Wed, 14 Apr 2010 13:28:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C0EFCE7-946F-442F-BB99-54C2D167B108@cs.stanford.edu>
References:  <239BF41C-06D4-45E0-871F-FEBE69848362@cs.jhu.edu>
To: JeongGil Ko (John) 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011
Cc: roll@ietf.org, Ralph Droms 
Subject: Re: [Roll] draft-ietf-roll-rpl-07
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 20:30:52 -0000

On Apr 14, 2010, at 10:32 AM, JeongGil Ko (John) wrote:

>=20
> On Apr 14, 2010, at 1:29 PM, Ralph Droms wrote:
>=20
>> Is section 7.1 intended to give suggestions for just MP2P forwarding =
or for all flows?
>>=20
>=20
> I would say that this should go for all flows :)
>=20
> John

7.1 definitely needs improvement; once we have the proposals for P2P and =
DAOs on the table, I think we can revisit it. It really needs to be more =
than "suggestions" for interoperability reasons; it has that name =
currently because it's in flux.

Phil=

From gnawali@cs.stanford.edu  Wed Apr 14 15:01:16 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36A028C13D for ; Wed, 14 Apr 2010 15:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.048
X-Spam-Level: 
X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQPExuKFvJY0 for ; Wed, 14 Apr 2010 15:01:16 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 04F3728C13B for ; Wed, 14 Apr 2010 15:01:16 -0700 (PDT)
Received: from mail-gw0-f44.google.com ([74.125.83.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2Adx-0006ae-Qk for roll@ietf.org; Wed, 14 Apr 2010 15:01:10 -0700
Received: by gwb1 with SMTP id 1so298337gwb.31 for ; Wed, 14 Apr 2010 15:01:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Wed, 14 Apr 2010 15:00:48 -0700 (PDT)
In-Reply-To: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>
From: Omprakash Gnawali 
Date: Wed, 14 Apr 2010 15:00:48 -0700
Received: by 10.150.61.4 with SMTP id j4mr7540378yba.303.1271282468103; Wed,  14 Apr 2010 15:01:08 -0700 (PDT)
Message-ID: 
To: JP Vasseur 
Content-Type: text/plain; charset=ISO-8859-1
X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982
Cc: roll WG 
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 22:01:16 -0000

On Wed, Apr 14, 2010 at 5:08 AM, JP Vasseur  wrote:
> Dear all,
>
> Just an (important) clarification: as you know, we have defined routing
> "attributes" in the metric ID to be used
> as metrics or a constraints. And considering the number of applications for
> RPL, we will more than likely see a
> number of combinations of metrics and/or constraints. Should we want to
> specify an OF each time we want to
> use of combination of metric/constraint, we would certainly overlflow the
> RFC editor queue ;-) It would be nice
> to have a discussion on how we could come up with the limited number of OF,
> taking out the metric/constraint
> from the OF semantics. That would greatly simplify the work and still gives
> us the required flexibility.

This makes sense if we take the position that the intricate logic that
makes a metric actually work in path selection is implementation
detail.

To say that -- all that is necessary for ETX metric-based routing is a
little bit of hysteresis and adding the metric along the links --
would be too simplistic and an implementation that does just that
probably will perform poorly in practice. A lot of thought and
experiences have guided the use of these metrics in the wireless
networks so it makes sense to write them down somewhere. The metric
draft does not seem the place to write them path selection logic
specific to that metric.

It would be instructive to look at all the additive metrics - hopcount
(OF0) and ETX (ETXOF), latency, etc. to see if they can be practically
treated as just numbers without regard to what they are during path
selection. Are there wireless networks that everyone is happy with
where the network can route on any additive metric without any metric
specific logic in path selection? If there are, it would make a case
for metric-agnostic OFs but I haven't personally seen such examples.

I can see a few common metrics to have their own objective functions
to incorporate the experiences on how to properly use those metrics in
path selection. At least - Hopcount, ETX, and latency. If we make sure
that the design of new OFs is guided by deep experience, I doubt we
will have a large number of OFs in the near future. Then as there is
more experience using other metrics, there can be more objective
functions.

Lets discuss and find ways to make the best use of these metrics. That
discussion should decide the number of RFCs we need.

Thanks.

- om_p

From gnawali@cs.stanford.edu  Wed Apr 14 16:55:55 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F453A693E; Wed, 14 Apr 2010 16:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq7kP22rT2XM; Wed, 14 Apr 2010 16:55:54 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A71A03A67AD; Wed, 14 Apr 2010 16:55:54 -0700 (PDT)
Received: from mail-yw0-f185.google.com ([209.85.211.185]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2CQu-0004jm-4x; Wed, 14 Apr 2010 16:55:48 -0700
Received: by ywh16 with SMTP id 16so368783ywh.32 for ; Wed, 14 Apr 2010 16:55:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Wed, 14 Apr 2010 16:55:27 -0700 (PDT)
In-Reply-To: <201003171752.36500.hrogge@googlemail.com>
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151814.08275.hrogge@googlemail.com>  <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> <201003171752.36500.hrogge@googlemail.com>
From: Omprakash Gnawali 
Date: Wed, 14 Apr 2010 16:55:27 -0700
Received: by 10.150.242.3 with SMTP id p3mr7141888ybh.130.1271289347142; Wed,  14 Apr 2010 16:55:47 -0700 (PDT)
Message-ID: 
To: Henning Rogge 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scan-Signature: f824399eb00b5943f8bdbe5dd24fccda
Cc: roll@ietf.org, MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 14 Apr 2010 23:55:55 -0000

On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge  wrot=
e:
> Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
>> > We have experimented with EWMA based in the Freifunk networks (IEEE
>> > 802.11 based meshs), and we had better experience with the fixed windo=
w
>> > than the EWMA. EWMA is more difficult to adapt to events that don't
>> > occur on a regular interval.
>>
>> Interesting. I'd love to see what the link behavior of these networks lo=
ok
>> like.
> My experience in emulation with EWMA is that their two advantages (a sing=
le
> tuning parameter and more influence to recent data) is their disadvantage=
 too.
> EWMA values. Because of the higher influence of recent data EWMA-based ET=
X
> tends to jump up/down more because of it's binary input (packet
> received/lost).
>
>> Do you have a writeup of what led you to this conclusion?
> No, sorry.
>
>> >> A fixed sized window assumes that channel dynamics only occur on a ti=
me
>> >> scale ~ the size of the window or longer. Clearly this isn't the case
>> >> with interference. Measurements I've seen of the 2.4GHz band point to
>> >> signal dynamics on the range of <500ms.
>> >
>> > You don't want your LQ value change quicker than you can transport it =
to
>> > the network. That can be a desaster (depending on protocol and network
>> > topology).
>>
>> Ah -- I think this is where we differ. I want the LQ value to be as
>> accurate as possible: the perfect LQ would simply output 0 or 1 (will th=
is
>> packet be delivered).
> This metric would be nearly useless for multihop networks. ;)
>
>> It's then up to the routing protocol to apply
>> hysteresis or smoothing in order to keep the topology stable. Otherwise
>> you've coupled the two designs.
> I would think that hysteresis is part of the metric generation process. A=
 good
> hysteresis can keep the "speed" of the metric change down to something th=
e
> adhoc network can handle. Unless the "fast time" variations of the metric=
 are
> higher than the hysteresis threshold.

I finished doing experiments comparing ewma link estimator and fixed
window estimator with a window size of 10.

Here are the results:
http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html

The summary is window ETX seems too sensitive causing high churn and
resulting in poor path selection. EWMA seems to work much better.

- om_p

From pal@cs.stanford.edu  Wed Apr 14 17:15:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D64B3A699C; Wed, 14 Apr 2010 17:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.514
X-Spam-Level: 
X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8HZyY53BtYT; Wed, 14 Apr 2010 17:15:55 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8C0823A69D7; Wed, 14 Apr 2010 17:15:39 -0700 (PDT)
Received: from dn0a2018d5.sunet ([10.32.24.213]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O2Ck0-00078e-L7; Wed, 14 Apr 2010 17:15:32 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: Philip Levis 
In-Reply-To: 
Date: Wed, 14 Apr 2010 17:15:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <86366D32-CFDA-41B8-9D65-77A66D7DADAA@cs.stanford.edu>
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151814.08275.hrogge@googlemail.com> <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> <201003171752.36500.hrogge@googlemail.com> 
To: Omprakash Gnawali 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: e1c7b331cb521454e7d22df558880a52
Cc: roll@ietf.org, MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 00:15:56 -0000

On Apr 14, 2010, at 4:55 PM, Omprakash Gnawali wrote:

> On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge  =
wrote:
>> Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
>>>> We have experimented with EWMA based in the Freifunk networks (IEEE
>>>> 802.11 based meshs), and we had better experience with the fixed =
window
>>>> than the EWMA. EWMA is more difficult to adapt to events that don't
>>>> occur on a regular interval.
>>>=20
>>> Interesting. I'd love to see what the link behavior of these =
networks look
>>> like.
>> My experience in emulation with EWMA is that their two advantages (a =
single
>> tuning parameter and more influence to recent data) is their =
disadvantage too.
>> EWMA values. Because of the higher influence of recent data =
EWMA-based ETX
>> tends to jump up/down more because of it's binary input (packet
>> received/lost).
>>=20
>>> Do you have a writeup of what led you to this conclusion?
>> No, sorry.
>>=20
>>>>> A fixed sized window assumes that channel dynamics only occur on a =
time
>>>>> scale ~ the size of the window or longer. Clearly this isn't the =
case
>>>>> with interference. Measurements I've seen of the 2.4GHz band point =
to
>>>>> signal dynamics on the range of <500ms.
>>>>=20
>>>> You don't want your LQ value change quicker than you can transport =
it to
>>>> the network. That can be a desaster (depending on protocol and =
network
>>>> topology).
>>>=20
>>> Ah -- I think this is where we differ. I want the LQ value to be as
>>> accurate as possible: the perfect LQ would simply output 0 or 1 =
(will this
>>> packet be delivered).
>> This metric would be nearly useless for multihop networks. ;)
>>=20
>>> It's then up to the routing protocol to apply
>>> hysteresis or smoothing in order to keep the topology stable. =
Otherwise
>>> you've coupled the two designs.
>> I would think that hysteresis is part of the metric generation =
process. A good
>> hysteresis can keep the "speed" of the metric change down to =
something the
>> adhoc network can handle. Unless the "fast time" variations of the =
metric are
>> higher than the hysteresis threshold.
>=20
> I finished doing experiments comparing ewma link estimator and fixed
> window estimator with a window size of 10.
>=20
> Here are the results:
> http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html
>=20
> The summary is window ETX seems too sensitive causing high churn and
> resulting in poor path selection. EWMA seems to work much better.

Om,

These are interesting results, but are probably also dependent on the =
parameters used. For example, we settled on an alpha of 0.9 for EWMA in =
CTP based on a lot of experiments. Maybe the right thing to do is =
experiment with window sizes, find the "best" window size, then compare =
that with EWMA?

Phil=

From gnawali@cs.stanford.edu  Wed Apr 14 19:13:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679693A6A84; Wed, 14 Apr 2010 19:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.512
X-Spam-Level: 
X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po5VoOQsOd+O; Wed, 14 Apr 2010 19:13:26 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8D4573A6994; Wed, 14 Apr 2010 19:13:24 -0700 (PDT)
Received: from mail-gw0-f44.google.com ([74.125.83.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2EZy-0003up-4c; Wed, 14 Apr 2010 19:13:18 -0700
Received: by gwb1 with SMTP id 1so457610gwb.31 for ; Wed, 14 Apr 2010 19:13:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Wed, 14 Apr 2010 19:12:57 -0700 (PDT)
In-Reply-To: <86366D32-CFDA-41B8-9D65-77A66D7DADAA@cs.stanford.edu>
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151814.08275.hrogge@googlemail.com>  <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> <201003171752.36500.hrogge@googlemail.com>    <86366D32-CFDA-41B8-9D65-77A66D7DADAA@cs.stanford.edu>
From: Omprakash Gnawali 
Date: Wed, 14 Apr 2010 19:12:57 -0700
Received: by 10.150.66.4 with SMTP id o4mr7904688yba.225.1271297597093; Wed,  14 Apr 2010 19:13:17 -0700 (PDT)
Message-ID: 
To: Philip Levis 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scan-Signature: fc10fe39d01b15c9e7c4ee19c7bcb625
Cc: roll@ietf.org, MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 02:13:30 -0000

On Wed, Apr 14, 2010 at 5:15 PM, Philip Levis  wrote:
>
> On Apr 14, 2010, at 4:55 PM, Omprakash Gnawali wrote:
>
>> On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge  w=
rote:
>>> Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
>>>>> We have experimented with EWMA based in the Freifunk networks (IEEE
>>>>> 802.11 based meshs), and we had better experience with the fixed wind=
ow
>>>>> than the EWMA. EWMA is more difficult to adapt to events that don't
>>>>> occur on a regular interval.
>>>>
>>>> Interesting. I'd love to see what the link behavior of these networks =
look
>>>> like.
>>> My experience in emulation with EWMA is that their two advantages (a si=
ngle
>>> tuning parameter and more influence to recent data) is their disadvanta=
ge too.
>>> EWMA values. Because of the higher influence of recent data EWMA-based =
ETX
>>> tends to jump up/down more because of it's binary input (packet
>>> received/lost).
>>>
>>>> Do you have a writeup of what led you to this conclusion?
>>> No, sorry.
>>>
>>>>>> A fixed sized window assumes that channel dynamics only occur on a t=
ime
>>>>>> scale ~ the size of the window or longer. Clearly this isn't the cas=
e
>>>>>> with interference. Measurements I've seen of the 2.4GHz band point t=
o
>>>>>> signal dynamics on the range of <500ms.
>>>>>
>>>>> You don't want your LQ value change quicker than you can transport it=
 to
>>>>> the network. That can be a desaster (depending on protocol and networ=
k
>>>>> topology).
>>>>
>>>> Ah -- I think this is where we differ. I want the LQ value to be as
>>>> accurate as possible: the perfect LQ would simply output 0 or 1 (will =
this
>>>> packet be delivered).
>>> This metric would be nearly useless for multihop networks. ;)
>>>
>>>> It's then up to the routing protocol to apply
>>>> hysteresis or smoothing in order to keep the topology stable. Otherwis=
e
>>>> you've coupled the two designs.
>>> I would think that hysteresis is part of the metric generation process.=
 A good
>>> hysteresis can keep the "speed" of the metric change down to something =
the
>>> adhoc network can handle. Unless the "fast time" variations of the metr=
ic are
>>> higher than the hysteresis threshold.
>>
>> I finished doing experiments comparing ewma link estimator and fixed
>> window estimator with a window size of 10.
>>
>> Here are the results:
>> http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html
>>
>> The summary is window ETX seems too sensitive causing high churn and
>> resulting in poor path selection. EWMA seems to work much better.
>
> Om,
>
> These are interesting results, but are probably also dependent on the par=
ameters used. For example, we settled on an alpha of 0.9 for EWMA in CTP ba=
sed on a lot of experiments. Maybe the right thing to do is experiment with=
 window sizes, find the "best" window size, then compare that with EWMA?

Sorry, it wasn't the intention to say window ETX is always worse than
EWMA. Agree - the results are dependent on the experiment parameters.
I expect things to be "smoother" with larger windows. Maybe I should
try a window size of 16 next time. On quiet channels there does not
seem to be much difference. The focus of future study should be noisy
channels.

- om_p

From henning.rogge@fkie.fraunhofer.de  Wed Apr 14 23:13:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E8C3A6909; Wed, 14 Apr 2010 23:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.649
X-Spam-Level: 
X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lacqmEOyOm13; Wed, 14 Apr 2010 23:13:51 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 5F7183A68F6; Wed, 14 Apr 2010 23:13:51 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O2IKP-0008Th-Hm; Thu, 15 Apr 2010 08:13:29 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O2IKP-0003U3-5e; Thu, 15 Apr 2010 08:13:29 +0200
From: Henning Rogge 
To: roll@ietf.org
Date: Thu, 15 Apr 2010 08:13:19 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-17-generic; KDE/4.4.2; i686; ; )
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart10596094.n00uGehz3H"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201004150813.26049.henning.rogge@fkie.fraunhofer.de>
X-Virus-Scanned: yes (ClamAV 0.95.3/10745/Thu Apr 15 06:07:27 2010) by mailguard.fgan.de
X-Scan-Signature: 64797cdc552258667c28460e5fcfa91c
Cc: MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 06:13:54 -0000

--nextPart10596094.n00uGehz3H
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Thu April 15 2010 01:55:27 Omprakash Gnawali wrote:
> On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge =20
wrote:
> > Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
> >> > We have experimented with EWMA based in the Freifunk networks (IEEE
> >> > 802.11 based meshs), and we had better experience with the fixed
> >> > window than the EWMA. EWMA is more difficult to adapt to events that
> >> > don't occur on a regular interval.
> >>=20
> >> Interesting. I'd love to see what the link behavior of these networks
> >> look like.
> >=20
> > My experience in emulation with EWMA is that their two advantages (a
> > single tuning parameter and more influence to recent data) is their
> > disadvantage too. EWMA values. Because of the higher influence of recent
> > data EWMA-based ETX tends to jump up/down more because of it's binary
> > input (packet
> > received/lost).
> >=20
> >> Do you have a writeup of what led you to this conclusion?
> >=20
> > No, sorry.
> >=20
> >> >> A fixed sized window assumes that channel dynamics only occur on a
> >> >> time scale ~ the size of the window or longer. Clearly this isn't
> >> >> the case with interference. Measurements I've seen of the 2.4GHz
> >> >> band point to signal dynamics on the range of <500ms.
> >> >=20
> >> > You don't want your LQ value change quicker than you can transport it
> >> > to the network. That can be a desaster (depending on protocol and
> >> > network topology).
> >>=20
> >> Ah -- I think this is where we differ. I want the LQ value to be as
> >> accurate as possible: the perfect LQ would simply output 0 or 1 (will
> >> this packet be delivered).
> >=20
> > This metric would be nearly useless for multihop networks. ;)
> >=20
> >> It's then up to the routing protocol to apply
> >> hysteresis or smoothing in order to keep the topology stable. Otherwise
> >> you've coupled the two designs.
> >=20
> > I would think that hysteresis is part of the metric generation process.=
 A
> > good hysteresis can keep the "speed" of the metric change down to
> > something the adhoc network can handle. Unless the "fast time"
> > variations of the metric are higher than the hysteresis threshold.
>=20
> I finished doing experiments comparing ewma link estimator and fixed
> window estimator with a window size of 10.
10 seems to be a very low ETX window size.
=20
> Here are the results:
> http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html
>=20
> The summary is window ETX seems too sensitive causing high churn and
> resulting in poor path selection. EWMA seems to work much better.
Using all incoming packets to calculate the ETX value and using a fixed sli=
ding=20
window of binary events (received/lost) is not a good idea.

Packet transmission over a link does not happen in constant intervals, so t=
he=20
your metric will jump up/down very quickly if you receive/loose a burst of=
=20
packets.

I'm not surprised that ETX does not behave well in this scenario.

Henning Rogge

=2D-=20
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

--nextPart10596094.n00uGehz3H
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkvGrn8ACgkQRIfGfFXsz+BVZACgh5VOoqYbHIVSzEPRee6p/71q
ufMAoI/rFTmq+IwvTSmzEOeT5wOGXi+e
=Vwl5
-----END PGP SIGNATURE-----

--nextPart10596094.n00uGehz3H--

From yoav@yitran.com  Wed Apr 14 23:56:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346553A69AA; Wed, 14 Apr 2010 23:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.901
X-Spam-Level: 
X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90iCZUAfFZFG; Wed, 14 Apr 2010 23:56:27 -0700 (PDT)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 958493A67F7; Wed, 14 Apr 2010 23:56:26 -0700 (PDT)
Received: from source ([209.85.210.190]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKS8a4lDeE2NVXTiNcqyvseLTDMzyirpEs@postini.com; Wed, 14 Apr 2010 23:56:20 PDT
Received: by yxe28 with SMTP id 28so576448yxe.6 for ; Wed, 14 Apr 2010 23:56:19 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <20100223045634.C3F6328C44F@core3.amsl.com>	<201003171752.36500.hrogge@googlemail.com>	   <201004150813.26049.henning.rogge@fkie.fraunhofer.de>
In-Reply-To: <201004150813.26049.henning.rogge@fkie.fraunhofer.de>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrcYtaso+he0H0dQqe0ed0xas4SDQABTbTA
Date: Thu, 15 Apr 2010 09:56:20 +0300
Received: by 10.100.245.19 with SMTP id s19mr7671950anh.190.1271314578961;  Wed, 14 Apr 2010 23:56:18 -0700 (PDT)
Message-ID: 
To: Henning Rogge , roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 06:56:28 -0000

I agree that doing a windowing mechanism on "failure rates" (i.e.
#retransmissions over a fixed time window) instead of a windowing
mechanism on "number of failures" without any time normalization would
make more sense as a meaningful metric.

Thanks,
Yoav


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Henning Rogge
Sent: Thursday, April 15, 2010 9:13 AM
To: roll@ietf.org
Cc: MANET IETF; Marcello Caleffi; Thomas Heide Clausen
Subject: Re: [Roll] [manet] Fwd: New Version Notification for
draft-gnawali-roll-etxof-00

On Thu April 15 2010 01:55:27 Omprakash Gnawali wrote:
> On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge 
wrote:
> > Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
> >> > We have experimented with EWMA based in the Freifunk networks
> >> > (IEEE
> >> > 802.11 based meshs), and we had better experience with the fixed
> >> > window than the EWMA. EWMA is more difficult to adapt to events
> >> > that don't occur on a regular interval.
> >>
> >> Interesting. I'd love to see what the link behavior of these
> >> networks look like.
> >
> > My experience in emulation with EWMA is that their two advantages (a
> > single tuning parameter and more influence to recent data) is their
> > disadvantage too. EWMA values. Because of the higher influence of
> > recent data EWMA-based ETX tends to jump up/down more because of
> > it's binary input (packet received/lost).
> >
> >> Do you have a writeup of what led you to this conclusion?
> >
> > No, sorry.
> >
> >> >> A fixed sized window assumes that channel dynamics only occur on
> >> >> a time scale ~ the size of the window or longer. Clearly this
> >> >> isn't the case with interference. Measurements I've seen of the
> >> >> 2.4GHz band point to signal dynamics on the range of <500ms.
> >> >
> >> > You don't want your LQ value change quicker than you can
> >> > transport it to the network. That can be a desaster (depending on
> >> > protocol and network topology).
> >>
> >> Ah -- I think this is where we differ. I want the LQ value to be as
> >> accurate as possible: the perfect LQ would simply output 0 or 1
> >> (will this packet be delivered).
> >
> > This metric would be nearly useless for multihop networks. ;)
> >
> >> It's then up to the routing protocol to apply hysteresis or
> >> smoothing in order to keep the topology stable. Otherwise you've
> >> coupled the two designs.
> >
> > I would think that hysteresis is part of the metric generation
> > process. A good hysteresis can keep the "speed" of the metric change
> > down to something the adhoc network can handle. Unless the "fast time"
> > variations of the metric are higher than the hysteresis threshold.
>
> I finished doing experiments comparing ewma link estimator and fixed
> window estimator with a window size of 10.
10 seems to be a very low ETX window size.

> Here are the results:
> http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html
>
> The summary is window ETX seems too sensitive causing high churn and
> resulting in poor path selection. EWMA seems to work much better.
Using all incoming packets to calculate the ETX value and using a fixed
sliding window of binary events (received/lost) is not a good idea.

Packet transmission over a link does not happen in constant intervals, so
the your metric will jump up/down very quickly if you receive/loose a
burst of packets.

I'm not surprised that ETX does not behave well in this scenario.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation=
,
Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

From henning.rogge@fkie.fraunhofer.de  Thu Apr 15 00:02:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B6F3A6AC4; Thu, 15 Apr 2010 00:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level: 
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ank7V0FKQm6p; Thu, 15 Apr 2010 00:02:26 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 3969B3A6B4C; Thu, 15 Apr 2010 00:02:10 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O2J5I-0005QC-Au; Thu, 15 Apr 2010 09:01:56 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1O2J5I-0003fr-0d; Thu, 15 Apr 2010 09:01:56 +0200
From: Henning Rogge 
To: "Yoav Ben-Yehezkel" 
Date: Thu, 15 Apr 2010 09:01:44 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-17-generic; KDE/4.4.2; i686; ; )
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201004150813.26049.henning.rogge@fkie.fraunhofer.de> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2470394.aDCsUdTI10"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201004150901.50525.henning.rogge@fkie.fraunhofer.de>
X-Virus-Scanned: yes (ClamAV 0.95.3/10745/Thu Apr 15 06:07:27 2010) by mailguard.fgan.de
X-Scan-Signature: 4752504f224081e57c30a21c7b02e935
Cc: roll@ietf.org, MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 07:02:27 -0000

--nextPart2470394.aDCsUdTI10
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Thu April 15 2010 08:56:20 Yoav Ben-Yehezkel wrote:
> I agree that doing a windowing mechanism on "failure rates" (i.e.
> #retransmissions over a fixed time window) instead of a windowing
> mechanism on "number of failures" without any time normalization would
> make more sense as a meaningful metric.
It might be interesting if EWMA over "failure rates" behaves as well (or=20
better) than sliding window over failure rates.

Henning Rogge

=2D-=20
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

--nextPart2470394.aDCsUdTI10
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkvGudkACgkQRIfGfFXsz+DhVgCeMOzoKKWqmQcQX2vDjv0RyrQp
WDUAniaOs+6E3k7dQl5DgYt0sFBVIbU9
=XBAT
-----END PGP SIGNATURE-----

--nextPart2470394.aDCsUdTI10--

From jpv@cisco.com  Thu Apr 15 02:10:23 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4923A68F9 for ; Thu, 15 Apr 2010 02:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.304
X-Spam-Level: 
X-Spam-Status: No, score=-9.304 tagged_above=-999 required=5 tests=[AWL=1.295,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q71e-LU6qGA7 for ; Thu, 15 Apr 2010 02:10:22 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1E7963A6AE3 for ; Thu, 15 Apr 2010 02:10:16 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD91xkurR7Hu/2dsb2JhbACbYnGkDJofhQ4Ejl8
X-IronPort-AV: E=Sophos;i="4.52,211,1270425600"; d="scan'208";a="515350723"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2010 09:10:09 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3F9A6Fr006684; Thu, 15 Apr 2010 09:10:09 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 11:10:06 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 11:10:05 +0200
Message-Id: <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com>
From: JP Vasseur 
To: Omprakash Gnawali 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 11:10:04 +0200
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 09:10:05.0834 (UTC) FILETIME=[706696A0:01CADC7B]
Cc: roll WG 
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 09:10:24 -0000

On Apr 15, 2010, at 12:00 AM, Omprakash Gnawali wrote:

> On Wed, Apr 14, 2010 at 5:08 AM, JP Vasseur  wrote:
>> Dear all,
>>
>> Just an (important) clarification: as you know, we have defined  
>> routing
>> "attributes" in the metric ID to be used
>> as metrics or a constraints. And considering the number of  
>> applications for
>> RPL, we will more than likely see a
>> number of combinations of metrics and/or constraints. Should we  
>> want to
>> specify an OF each time we want to
>> use of combination of metric/constraint, we would certainly  
>> overlflow the
>> RFC editor queue ;-) It would be nice
>> to have a discussion on how we could come up with the limited  
>> number of OF,
>> taking out the metric/constraint
>> from the OF semantics. That would greatly simplify the work and  
>> still gives
>> us the required flexibility.
>
> This makes sense if we take the position that the intricate logic that
> makes a metric actually work in path selection is implementation
> detail.
>
> To say that -- all that is necessary for ETX metric-based routing is a
> little bit of hysteresis and adding the metric along the links --
> would be too simplistic and an implementation that does just that
> probably will perform poorly in practice. A lot of thought and
> experiences have guided the use of these metrics in the wireless
> networks so it makes sense to write them down somewhere. The metric
> draft does not seem the place to write them path selection logic
> specific to that metric.
>
> It would be instructive to look at all the additive metrics - hopcount
> (OF0) and ETX (ETXOF), latency, etc. to see if they can be practically
> treated as just numbers without regard to what they are during path
> selection. Are there wireless networks that everyone is happy with
> where the network can route on any additive metric without any metric
> specific logic in path selection? If there are, it would make a case
> for metric-agnostic OFs but I haven't personally seen such examples.
>
> I can see a few common metrics to have their own objective functions
> to incorporate the experiences on how to properly use those metrics in
> path selection. At least - Hopcount, ETX, and latency. If we make sure
> that the design of new OFs is guided by deep experience, I doubt we
> will have a large number of OFs in the near future. Then as there is
> more experience using other metrics, there can be more objective
> functions.
>
> Lets discuss and find ways to make the best use of these metrics. That
> discussion should decide the number of RFCs we need.

Yes, we may have OF where specific handling of the metrics are  
required and must then be
part of the OF itself. For many other ones, we could certainly use a  
generic OF and leave
the metric out of it, relying on the semantic defined in the metric  
ID. We're in sync.

Cheers.

JP.

>
> Thanks.
>
> - om_p


From jpv@cisco.com  Thu Apr 15 04:54:23 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F96F28C19F for ; Thu, 15 Apr 2010 04:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.403
X-Spam-Level: 
X-Spam-Status: No, score=-5.403 tagged_above=-999 required=5 tests=[AWL=-2.805, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quCQf-l4+6K2 for ; Thu, 15 Apr 2010 04:54:22 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4BEB328C1AB for ; Thu, 15 Apr 2010 04:53:24 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQCAIKaxkuQ/uCWe2dsb2JhbACbbhUBAQsLIgYcpBmaIIUOBA
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208,217";a="5615007"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2010 11:17:20 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FBrFxX016390; Thu, 15 Apr 2010 11:53:15 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 13:53:15 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 13:53:14 +0200
Message-Id: <7A7BD61F-61E1-409A-A6E3-FDFA6EDE782B@cisco.com>
From: JP Vasseur 
To: Ulrich Herberg 
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-143-967417197
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 13:53:13 +0200
References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <4BBCF150.4010701@eecs.berkeley.edu> <706329BD-DDDA-4F26-996D-B4E36F0CE66D@cs.stanford.edu> <4BBD03AF.9050803@eecs.berkeley.edu>  <7264daf93e85725bf0914cbb858394aa@mail.gmail.com> <4BBE2785.60000@eecs.berkeley.edu> <4d3d664ff702246cebfef17d696f073f@mail.gmail.com> <6643.1270774314@marajade.sandelman.ca> <978A012F-FC07-4881-8039-FF3A63D50935@cs.stanford.edu> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 11:53:15.0056 (UTC) FILETIME=[3B3B5300:01CADC92]
Cc: roll WG 
Subject: Re: [Roll] Mixed mode operation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 11:54:23 -0000

--Apple-Mail-143-967417197
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit


On Apr 9, 2010, at 11:23 AM, Ulrich Herberg wrote:

>
> On Fri, Apr 9, 2010 at 4:11 AM, Philip Levis   
> wrote:
>
> On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:
> [...]
> >
> > The threat model that you describe, where an attacker has access  
> to send
> > original data into the link appears to be out of scope from what I  
> have
> > read.
> >
> > It seems that we will assume the layer-2 has sufficient protection  
> that
> > an external attacker can not do what you describe.
>
> Michael,
>
> Unfortunately, we can't assume that layer-2 has any protection. This  
> is the operating assumption behind all of the security work. Note  
> that the possible presence of layer 2 mechanisms are why RPL's  
> mechanisms are intended to be options: in networks with sufficient  
> layer 2 protection they can be left out, but they can be used in  
> those that need it.
>
> Phil
>
>
> I agree with Phil. Since ROLL does not assume a particular L2, we  
> cannot assume any security protection in lower layers.
>

Clearly the correct assumption, and the security DT is working with  
that in mind for sure.

JP.

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


--Apple-Mail-143-967417197
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


    On Apr 9, 2010, =
at 11:23 AM, Ulrich Herberg wrote:


    On Fri, Apr 9, 2010 at 4:11 AM, Philip Levis <pal@cs.stanford.edu> =
wrote:
     =


     On Apr 8, 2010, at 5:51 PM, Michael Richardson =
wrote:
    [...] 
     
     =
>
     > The threat model that you describe, where an attacker has =
access to send
     > original data into the link appears to be out of =
scope from what I have
     > read.
     >
     > It seems that we =
will assume the layer-2 has sufficient protection that
     > an =
external attacker can not do what you describe.
     
     =

    Michael,
     
     Unfortunately, we can't assume that layer-2 has =
any protection. This is the operating assumption behind all of the =
security work. Note that the possible presence of layer 2 mechanisms are =
why RPL's mechanisms are intended to be options: in networks with =
sufficient layer 2 protection they can be left out, but they can be used =
in those that need it.
     

     =
Phil


    I agree with Phil. Since =
ROLL does not assume a particular L2, we cannot assume any security =
protection in lower =
layers.


    Clearly the =
correct assumption, and the security DT is working with that in mind for =
sure.

    JP.

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

    =

--Apple-Mail-143-967417197--

From jpv@cisco.com  Thu Apr 15 05:01:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EA53A6A0B for ; Thu, 15 Apr 2010 05:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.203
X-Spam-Level: 
X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[AWL=1.396,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTY18kH1RZs3 for ; Thu, 15 Apr 2010 05:01:02 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 89DF33A6B7D for ; Thu, 15 Apr 2010 05:00:45 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQCANqcxkuQ/uCWe2dsb2JhbACbbhUBAQsLIgYcpAiaIIUOBA
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="59446089"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2010 12:00:38 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FC0c3x018279 for ; Thu, 15 Apr 2010 12:00:38 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:00:37 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:00:37 +0200
Message-Id: 
From: JP Vasseur 
To: roll WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:00:37 +0200
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:00:37.0688 (UTC) FILETIME=[430F9B80:01CADC93]
Subject: [Roll] Movng examples in RPL to another ID
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:01:03 -0000

Dear all,

Since we started to work on RPL, we have been including examples in  
the spec to help understand the proposal. Then discuss with the WG  
before removing the example. But these examples have some values so  
what we will do is to move them to a separate informational ID.

Thanks.

JP.

From jpv@cisco.com  Thu Apr 15 05:31:13 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C66028C0E8 for ; Thu, 15 Apr 2010 05:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=-3.905, BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mirzuy93bzZY for ; Thu, 15 Apr 2010 05:31:09 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 10D6428C283 for ; Thu, 15 Apr 2010 05:26:31 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQCAMGixkuQ/uCWe2dsb2JhbACBPpowFQEBCwsiBhykAJofhQ4E
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208,217";a="5616517"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2010 11:50:29 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCQOuV024703; Thu, 15 Apr 2010 12:26:24 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:26:23 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:26:21 +0200
Message-Id: <3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>
From: JP Vasseur 
To: d.sturek@att.net
In-Reply-To: <011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-146-969404916
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:26:20 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net> <4BBDED7C.40009@gridmerge.com> <011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:26:21.0745 (UTC) FILETIME=[DB640210:01CADC96]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:31:13 -0000

--Apple-Mail-146-969404916
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi Don,

On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:

> I think the issue is this:
> 1)       ROLL cannot meet its charter without source routing

Absolutely.

> 2)       Claiming the feature is now to be addressed in 6LowPAN  
> seems a bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE  
> 802.15.4.

You are absolutely right. IPHC is 15.4 specific. This is why the idea  
of using a Label a la MPLS would be an interesting approach IMO. The  
labe could be locall significant using DAO as a label distribution  
mechanism. Completely link layer agnostic.

JP.

> How are those addressed?
>
> Don
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
> Sent: Thursday, April 08, 2010 7:52 AM
> To: d.sturek@att.net
> Cc: daniel.gavelle@jennic.com; roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and  
> SourceRoutingOperations
>
> Hi Don,
>
> It's not so much that 6lowpan is concerning itself with source  
> routing, it is concerning itself with efficient header compression,  
> which would include IPv6 extension headers such as RH0. Whatever  
> ends up getting used for source routing needs to be some sort of  
> IPv6 extension header. Source routing for IPv6 would naturally  
> contain IPv6 addresses. The question is whether we want to invent  
> some new extension header specifically for ROLL which uses something  
> other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme  
> mentioned.
>
> I agree, ROLL must accommodate source routing one way or another.
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 2:35 PM, Don Sturek wrote:
> I can't see why 6LowPAN (and specifically the HC draft) would  
> concern itself
> with source routing.
>
> Surely source routing is a concern of ROLL (and not 6LowPAN).
>
> I don't see how ROLL completes its charter or addresses its  
> requirements
> without adding source routing.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of
> Daniel Gavelle
> Sent: Thursday, April 08, 2010 6:12 AM
> To: robert.cragie@gridmerge.com
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Rob,
>
> I agree that the source routing for the data frames should be done as
> part of the 6LowPAN HC.  This already has a stateful IPV6 address
> compression based on contexts.  It should be possible to compress the
> addresses down to two bytes per address if IPv6 addresses are derived
> from the 16 bit short address are being used in the LowPAN.
>
> We don't want to hold up the current HC draft that is going through  
> last
> call but the work could be done as a new RFC / amendment.  Source
> routing compression may need a fix for the problem of HC compression
> extending beyond the first fragment.
>
> Doing the work in the 6LowPAN group means that the compression can
> easily be used for any source routing protocol, not just ROLL.  It  
> could
> be done as a compression for the existing R0 routing header.  Maybe  
> this
> thread needs moving to the 6LowPAN reflector.
>
> Daniel.
>
>
> Robert Cragie wrote:
>
> Hi Pascal,
>
> Source routing should of course use the IPv6 addresses which means a  
> lot
> of overhead for certain underlying link layers, e.g. 802.15.4. I think
> it is generally cleaner to do the compression at a layer which may
> require it only, e.g. define it in the 6lowpan HC. This is then free  
> to
> some extent to specify how the compression is done. Although I doubt
> this would go down well in the 6lowpan WG...
>
> The tag scheme would work but it specifically scopes the source  
> routing
> to nodes which operate the scheme. This is probably acceptable
> practically but doesn't 'smell right' somehow.
>
> With regard to the original proposal: it is probably necessary to  
> carry
> the full source route all the way to at least the penultimate node and
> use an index to show the current position in the route for potential
> backtrace and error reporting back along the same route (assuming link
> symmetry). This is how RH0 works.
>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com 
>
>
> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>
> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types.  
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define  
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could  
> hide a
> short address of the child - if it cares to do it that way - looks  
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can  
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to  
> store
> a state with the full information in memory, and then place an index  
> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>
>
> -----Original Message-----
> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
> Sent: Thursday, April 08, 2010 11:40 AM
> To: ROLL WG
> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi Pascal, John,
>
> Since source routing explicitly gives forwarding instruction to each
> intermediate node, it can make sense to use only (MAC address based)
>
>
> L2
>
>
> forwarding instead of (IPv6 address based) L3 forwarding.
>
> This brings two advantages:
>  - avoid processing each transit packets up to L3.
>  - use MAC addresses that - in ROLL environment - have inherently
>
>
> shorter
>
>
> length than an IPv6 address.
>
> Cheers,
> Daniel
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>
>
> Of
>
>
> Pascal Thubert (pthubert)
> Sent: jeudi 8 avril 2010 11:15
> To: JeongGil Ko (John); ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi John:
>
> IPv6 already has a number of routing headers, in particular RH0,
>
>
> though it is
>
>
> being deprecated for general use in the Internet.
> And there are reasons why the fields in RH0/1 are there and we need to
> make sure we lose none of that. In particular a RH is recoverable, and
>
>
> it is
>
>
> easy to spot the consumed entries.
>
> On top of this our new problems are:
> - make sure the RH stays within the RPL network (since it is used
>
>
> downwards
>
>
> that should be doable)
> - control the size (that probably means compress)
>
> Cheers,
>
> Pascal
>
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>
>
> Of
>
>
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>
> Hi!
>
> Great to see all this discussions on downwards route establishment!
>
>
> To
>
>
> add
>
>
> one more to the conversations here is a proposal for source routing
>
>
> headers.
>
>
> In non-storing mode (where only the root has individual path
>
>
> information)
>
>
> the root will be attaching a source routing header to the data
>
>
> packet
>
>
> that a
>
>
> source node wants to send to a specific destination. We can always
>
>
> make the
>
>
> header super fancy but in my opinion I think we only need two fields
>
>
> in this
>
>
> header and here it is! Feel free to break the stuff and mangle with
>
>
> it
>
>
> so that it
>
>
> looks great in the specs later on. FYI, this is the format that I am
>
>
> using in my
>
>
> implementations so it does work :)
>
> 1. Source Routing Header Format
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
>
>
> |
>
>
> +-+-+-+-+-+-+-+-+
>
>
> +
>
>
> |                       Source Route Entry (128*NEntry bits)
>
>
> |
>
>
> +
>
>
> +
>
>
> |
>
>
> |
>
>
>       Figure 1. Proposed Source Routing Header Format; each line is
>
>
> 32
>
>
> bits:)
>
>
> - NEntry: Indicates the number of 128 bit addresses that the source
>
>
> route
>
>
> entry field is carrying.
>
> - Source Route Entry: List of 128 bit address that consist the route
>
>
> to the
>
>
> destination. Here, the address of the node that is one hop away from
>
>
> the
>
>
> *destination* comes first.
>
> 2. Source Routing Packet Operations
>
> When source routing is initiated at a storing node (e.g., root of
>
>
> the
>
>
> DODAG),
>
>
> the header is attached on the data packet for the entire route
>
>
> (i.e.,
>
>
> from
>
>
> next hop node to the destination). This header is positioned in
>
>
> front
>
>
> of the
>
>
> user payload. When the next hop node receives a packet that is not
>
>
> destined
>
>
> to itself AND the network is NOT provisioned to be in 'storing mode'
>
>
> then it
>
>
> checks NEntry to find what the next hop is in the source route
>
>
> entry.
>
>
> Since
>
>
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>
>
> terms
>
>
> of hops)
>
>
> order, a node can figure out what the next hop address is with only
>
>
> the
>
>
> NEntry value (since it already knows how big an ipv6 address is).
>
>
> After
>
>
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures
>
>
> that
>
>
> we
>
>
> avoid the overhead of carrying the entire source route throughout
>
>
> the
>
>
> data
>
>
> path.
>
> The approach itself should be very simple and trivial for everyone
>
>
> to
>
>
> follow.
>
>
> So we can start from here and build on!
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--Apple-Mail-146-969404916
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Don,

    On =
Apr 8, 2010, at 4:59 PM, Don Sturek wrote:

    I think the issue is =
this:
    1)  ROLL cannot meet its charter without source =
routing

    Ab=
solutely.

    2)  Claiming the feature is now to be addressed in =
6LowPAN seems a bit wrong.  ROLL has as its scope MAC/PHYs other =
than IEEE 802.15.4.  =


    You are =
absolutely right. IPHC is 15.4 specific. This is why the idea of using a =
Label a la MPLS would be an interesting approach IMO. The labe could be =
locall significant using DAO as a label distribution mechanism. =
Completely link layer =
agnostic.

    JP.

    How =
are those addressed?
     
     
     Robert Cragie [ 
    Sent: Thursday, April 08, 2010 =
7:52 AM
    To: d.sturek@att.net
    Cc: daniel.gavelle@jennic.com; roll@ietf.org
    Subject: Re: [Roll] Proposal for =
Source Routing Header Format and =
SourceRoutingOperations
     
    Hi Don,

    It's not so much that 6lowpan =
is concerning itself with source routing, it is concerning itself with =
efficient header compression, which would include IPv6 extension headers =
such as RH0. Whatever ends up getting =
used for source routing needs to be some sort of IPv6 extension header. =
Source routing for IPv6 would naturally contain IPv6 addresses. The =
question is whether we want to invent some new extension header =
specifically for ROLL which uses something other (i.e. smaller) than =
IPv6 addresses, e.g. the tag scheme mentioned.

    I agree, ROLL must =
accommodate source routing one way or =
another.

    Robert
    Robert Cragie (Pacific =
Gas & Electric)
    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, =
WF4 4WA, UK
    +44 (0) 1924 910888

    On 08/04/2010 2:35 PM, Don Sturek =
wrote:
    I can't see why 6LowPAN (and specifically =
the HC draft) would concern itself
    with source routing.
    Surely source routing is a =
concern of ROLL (and not 6LowPAN).
     
    I don't see how ROLL =
completes its charter or addresses its requirements
    without adding source routing.
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
    Daniel =
Gavelle
    Sent: Thursday, April 08, =
2010 6:12 AM
    To: Cc: roll@ietf.org
    Subject: Re: [Roll] Proposal for Source Routing Header Format =
and
    Rob,
     
    I agree that the =
source routing for the data frames should be done as =

    part of the 6LowPAN HC.  This =
already has a stateful IPV6 address 
    compression based on contexts.  It should be possible to =
compress the 
    addresses down to two =
bytes per address if IPv6 addresses are derived 
    from the 16 bit short address are being used in the =
LowPAN.
     
    We don't want to hold up the current HC draft that is going =
through last 
    call but the work =
could be done as a new RFC / amendment.  Source =

    routing compression may need a fix for =
the problem of HC compression 
    extending =
beyond the first fragment.
    Doing the work in the =
6LowPAN group means that the compression can 
    easily be used for any source routing protocol, not just =
ROLL.  It could 
    be done as a =
compression for the existing R0 routing header.  Maybe this =

    thread needs moving to the 6LowPAN =
reflector.
     
    Daniel.
     
    Robert Cragie wrote:
      =

    Hi Pascal,
    Source routing should of =
course use the IPv6 addresses which means a lot 
    of overhead for certain underlying link layers, e.g. 802.15.4. =
I think 
    it is generally cleaner to =
do the compression at a layer which may 
    require it only, e.g. define it in the 6lowpan HC. This is then =
free to 
    some extent to specify how =
the compression is done. Although I doubt 
    this would go down well in the 6lowpan =
WG...
     
    The tag scheme would work but it specifically scopes the source =
routing 
    to nodes which operate the =
scheme. This is probably acceptable 
    practically but doesn't 'smell right' =
somehow.
     
    With regard to the original proposal: it is probably necessary =
to carry 
    the full source route all =
the way to at least the penultimate node and 
    use an index to show the current position in the route for =
potential 
    backtrace and error =
reporting back along the same route (assuming link 
    symmetry). This is how RH0 works.
     
     
    Robert Cragie (Pacific Gas & Electric)
     
    Gridmerge =
Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, =
UK
    +44 (0) 1924 910888
    http://www.gridmerge.com  
    On 08/04/2010 10:57 AM, =
Pascal Thubert (pthubert) wrote:
    Hi =
Daniel:
     
    Routers might have multiple interfaces of multiple MAC types. =
Internet 0
    even has a MAC-less =
format.
    So the result of you =
proposal, which looks like a great idea in a pure
    802.15.4 world with short addresses, becomes a nightmare to =
define in a
    fully generic =
fashion.
     
    OTOH, a locally significant opaque tag in which the parent =
could hide a
    short address of the =
child - if it cares to do it that way - looks like
    a way more acceptable approach
     
    So it seems to me that =
you can get what you want as long as we can make
    the tag big enough for short addresses. When the tag is too =
small to
    contain what the parent =
really needs, then the parent will have to store
    a state with the full information in memory, and then place an =
index of
    some sort in the =
tag.
     
    What do you think?
    Pascal
     
      
          
    From: Popa, =
Daniel [Sent: Thursday, April 08, 2010 11:40 AM
    To: ROLL WG
    Cc: Pascal Thubert =
(pthubert); JeongGil Ko (John)
    Subject: =
RE: [Roll] Proposal for Source Routing Header Format =
and
    Hi Pascal, =
John,
     
    Since source routing explicitly gives forwarding instruction to =
each
    intermediate node, it can make sense to =
use only (MAC address based)
    L2
      =

    forwarding =
instead of (IPv6 address based) L3 forwarding.
     
    This brings two =
advantages:
     - avoid processing each =
transit packets up to L3.
     - use MAC addresses =
that - in ROLL environment - have inherently
        
    shorter
      =

    length than =
an IPv6 address.
    Cheers,
    Daniel
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
        
            
    Of
      =

    Pascal =
Thubert (pthubert)
    Sent: jeudi 8 avril =
2010 11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: [Roll] Proposal for Source =
Routing Header Format and
    Hi =
John:
     
    IPv6 already has a number of routing headers, in particular =
RH0,
        
            
    though it is
      =

    being =
deprecated for general use in the Internet.
    And there are reasons why the fields in RH0/1 are there and we =
need to
    make sure we lose none of =
that. In particular a RH is recoverable, and
        
    it is
      =

    easy to =
spot the consumed entries.
    On top of this our new =
problems are:
    - make sure the RH =
stays within the RPL network (since it is used
        
    downwards
      =

    that should =
be doable)
    - control the size (that =
probably means compress)
    Cheers,
     
     
     
        =

    -----Original Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
          =

    Of
        
    JeongGil Ko (John)
    Sent: =
Wednesday, April 07, 2010 10:05 PM
    To: ROLL WG
    Subject: [Roll] =
Proposal for Source Routing Header Format and =
Source
    RoutingOperations
     
     
    Great to see all this discussions on downwards route =
establishment!
              <=
/pre>
      
          
        
            
    one more to the conversations here is a proposal for source =
routing
              <=
/pre>
    headers.
        
    In non-storing mode (where only the root has individual =
path
          =

    information)
        
    the root will be attaching a source routing header to the =
data
          =

      
          
    that =
a
        
            
    source node wants to send to a specific destination. We can =
always
          =

    make the
        
    header super fancy but in my opinion I think we only need two =
fields
          =

    in this
        
    header and here it is! Feel free to break the stuff and mangle =
with
          =

      
          
    so that =
it
        
            
    looks great in the specs later on. FYI, this is the format that =
I am
          =

    using in my
        
    implementations so it does work :)
     
    1. Source Routing =
Header Format
    |   NEntry (8 bits)   =
|
          =

    |
    +-+-+-+-+-+-+-+-+
              <=
/pre>
    +
    |          =
            &n=
bsp;Source Route Entry (128*NEntry bits)
          
              <=
/pre>
    |
    +
              <=
/pre>
    +
    |
              <=
/pre>
    |
          Figure 1. Proposed Source =
Routing Header Format; each line is
          
              <=
/pre>
      
          
        =

    - NEntry: Indicates the number of 128 bit addresses that the =
source
          =

    route
        
    entry field is carrying.
     
    - Source Route Entry: =
List of 128 bit address that consist the route
          
              <=
/pre>
    to the
        
    destination. Here, the address of the node that is one hop away =
from
          =

    the
        
    *destination* comes first.
     
    2. Source Routing =
Packet Operations
    When source routing is =
initiated at a storing node (e.g., root of
          
              <=
/pre>
      
          
        =

    the header is attached on the data packet for the entire =
route
          =

      
          
        
            
    next hop node to the destination). This header is positioned =
in
          =

      
          
    of =
the
        
            
    user payload. When the next hop node receives a packet that is =
not
          =

    destined
        
    to itself AND the network is NOT provisioned to be in 'storing =
mode'
          =

    then it
        
    checks NEntry to find what the next hop is in the source =
route
          =

      
          
        =

    the 'Source Route Entry' is ordered in 'farthest -> closest' =
(in
          =

      
          
    of =
hops)
        
            
    order, a node can figure out what the next hop address is with =
only
          =

    the
        
    NEntry value (since it already knows how big an ipv6 address =
is).
          =

    After
        
    collecting the next hop node's address, the node erases this =
address
    element from the entry and =
decreases NEntry by one. This assures
          
              <=
/pre>
      
          
        
            
    avoid the overhead of carrying the entire source route =
throughout
              <=
/pre>
      
          
        
            
    path.
    The approach itself should =
be very simple and trivial for everyone
          
              <=
/pre>
      
          
        =

    So we can start from here and build on!
     
     
    -John
    ------
    JeongGil Ko (John)
    Ph.D. =
Student
    Department of Computer =
Science
    Johns Hopkins =
University
     
    Roll mailing list
    Roll@ietf.org
          
              <=
/pre>
    Roll mailing list
    Roll@ietf.org
        
    Roll mailing list
    Roll@ietf.org
     
      =

     
     
    _______________________________________________
    Roll mailing list
    Roll@ietf.org
        
     
      =

    _______________________________________________
    =
Roll mailing list
    Roll@ietf.org
    
From: JP Vasseur 
To: Philip Levis 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:28:21 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:28:22.0496 (UTC) FILETIME=[235D2600:01CADC97]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:34:02 -0000

On Apr 8, 2010, at 5:35 PM, Philip Levis wrote:

>
> On Apr 8, 2010, at 6:35 AM, Don Sturek wrote:
>
>> I can't see why 6LowPAN (and specifically the HC draft) would  
>> concern itself
>> with source routing.
>>
>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>
>> I don't see how ROLL completes its charter or addresses its  
>> requirements
>> without adding source routing.
>
>
> The basic guideline is that ROLL (or WGs in general) shouldn't  
> replicate functionality or mechanisms that already exist, and that  
> given WGs operate within a particular layer of the protocol stack.
>
> In this particular case, the reason why 6lowpan was brought up is  
> the RH0 header. In terms of charter, it's not ROLL's job to specify  
> a way to compress the RH0 header. From ROLL's perspective, there are  
> IPv6 addresses and nothing less. 6lowpan, however, can specify ways  
> in which IPv6 headers are compressed.
>
> Does that make sense?

Not quite. We as a WG first need to agree on how we would like to  
perform source routing (compresed header, labels, ...), we'll figure  
out where it should be done.

JP.

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


From jpv@cisco.com  Thu Apr 15 05:35:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256B528C1A8 for ; Thu, 15 Apr 2010 05:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.908
X-Spam-Level: 
X-Spam-Status: No, score=-8.908 tagged_above=-999 required=5 tests=[AWL=1.691,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI-1J0AN4GEQ for ; Thu, 15 Apr 2010 05:35:13 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B2A1D3A6BA5 for ; Thu, 15 Apr 2010 05:29:54 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucFAC+jxkurRN+K/2dsb2JhbACPdIt6caQFmh+FDgQ
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="317414803"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2010 12:29:48 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCTO66024611; Thu, 15 Apr 2010 12:29:48 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:29:46 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:29:46 +0200
Message-Id: <53A55221-C3BD-424D-BA81-EF41B0BB4E05@cisco.com>
From: JP Vasseur 
To: d.sturek@att.net
In-Reply-To: <01e601cad73a$1016b8c0$30442a40$@sturek@att.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:29:45 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com> <4BBDD602.7040707@jennic.com> <008801cad720$555a0a50$000e1ef0$@sturek@att.net>  <01e601cad73a$1016b8c0$30442a40$@sturek@att.net>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:29:46.0146 (UTC) FILETIME=[55392020:01CADC97]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:35:14 -0000

On Apr 8, 2010, at 6:39 PM, Don Sturek wrote:

> Hi Phil,
>
> It does make sense unless we see that ROLL creates different  
> dependencies
> with different MAC/PHYs.
>
> If we don't expect there to be dependencies on lower layer support  
> for each
> MAC/PHY then creating a dependency on RH0 support in 6LowPAN makes  
> sense.
> If instead each MAC/PHY will require similar changes then I still  
> prefer to
> use a MAC/PHY independent solution (like tags).
>

me too (co-chair hat off).

> Don
>
>
> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: Thursday, April 08, 2010 8:36 AM
> To: d.sturek@att.net
> Cc: daniel.gavelle@jennic.com; robert.cragie@gridmerge.com; roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
>
> On Apr 8, 2010, at 6:35 AM, Don Sturek wrote:
>
>> I can't see why 6LowPAN (and specifically the HC draft) would concern
> itself
>> with source routing.
>>
>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>
>> I don't see how ROLL completes its charter or addresses its  
>> requirements
>> without adding source routing.
>
>
> The basic guideline is that ROLL (or WGs in general) shouldn't  
> replicate
> functionality or mechanisms that already exist, and that given WGs  
> operate
> within a particular layer of the protocol stack.
>
> In this particular case, the reason why 6lowpan was brought up is  
> the RH0
> header. In terms of charter, it's not ROLL's job to specify a way to
> compress the RH0 header. From ROLL's perspective, there are IPv6  
> addresses
> and nothing less. 6lowpan, however, can specify ways in which IPv6  
> headers
> are compressed.
>
> Does that make sense?
>
> Phil=
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From pthubert@cisco.com  Thu Apr 15 05:39:48 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC9B28C2BF for ; Thu, 15 Apr 2010 05:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.872
X-Spam-Level: 
X-Spam-Status: No, score=-8.872 tagged_above=-999 required=5 tests=[AWL=1.726,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWwpkoMneUqD for ; Thu, 15 Apr 2010 05:39:37 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 82F0928C1A8 for ; Thu, 15 Apr 2010 05:35:31 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600";  d="scan'208,217";a="515453900"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2010 12:35:25 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCZGf6016840; Thu, 15 Apr 2010 12:35:24 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:35:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADC98.1CE549F4"
Date: Thu, 15 Apr 2010 14:35:16 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>
In-Reply-To: <3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source RoutingHeader	Format	and	SourceRoutingOperations
Thread-Index: Acrcl5A+OpYRO6OrQfiUN3gjHEEcvAAABbtQ
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net> <3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>
From: "Pascal Thubert (pthubert)" 
To: "JP Vasseur" , 
X-OriginalArrivalTime: 15 Apr 2010 12:35:21.0414 (UTC) FILETIME=[1D0EF660:01CADC98]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:39:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CADC98.1CE549F4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi JP and all;

=20

I'm not fully clear what the WG group really wants to do at this point.
I sensed an agreement to endorse something very close to IPv6 RH0 in the
core spec, and provide a separate spec that would enable labels in the
Source route DAO and the hop by hop header.

=20

Is that a honest reading of the mailing list?

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
JP Vasseur
Sent: Thursday, April 15, 2010 2:26 PM
To: d.sturek@att.net
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

=20

Hi Don,

=20

On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:





I think the issue is this:

1)       ROLL cannot meet its charter without source routing

=20

Absolutely.





2)       Claiming the feature is now to be addressed in 6LowPAN seems a
bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4. =20

=20

You are absolutely right. IPHC is 15.4 specific. This is why the idea of
using a Label a la MPLS would be an interesting approach IMO. The labe
could be locall significant using DAO as a label distribution mechanism.
Completely link layer agnostic.

=20

JP.





How are those addressed?

=20

Don

=20

=20

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20
Sent: Thursday, April 08, 2010 7:52 AM
To: d.sturek@att.net
Cc: daniel.gavelle@jennic.com; roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

=20

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing,
it is concerning itself with efficient header compression, which would
include IPv6 extension headers such as RH0
 . Whatever ends up getting
used for source routing needs to be some sort of IPv6 extension header.
Source routing for IPv6 would naturally contain IPv6 addresses. The
question is whether we want to invent some new extension header
specifically for ROLL which uses something other (i.e. smaller) than
IPv6 addresses, e.g. the tag scheme mentioned.

I agree, ROLL must accommodate source routing one way or another.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 08/04/2010 2:35 PM, Don Sturek wrote:

I can't see why 6LowPAN (and specifically the HC draft) would concern
itself
with source routing.
=20
Surely source routing is a concern of ROLL (and not 6LowPAN).
=20
I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.
=20
Don
=20
=20
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
=20
Rob,
=20
I agree that the source routing for the data frames should be done as=20
part of the 6LowPAN HC.  This already has a stateful IPV6 address=20
compression based on contexts.  It should be possible to compress the=20
addresses down to two bytes per address if IPv6 addresses are derived=20
from the 16 bit short address are being used in the LowPAN.
=20
We don't want to hold up the current HC draft that is going through last

call but the work could be done as a new RFC / amendment.  Source=20
routing compression may need a fix for the problem of HC compression=20
extending beyond the first fragment.
=20
Doing the work in the 6LowPAN group means that the compression can=20
easily be used for any source routing protocol, not just ROLL.  It could

be done as a compression for the existing R0 routing header.  Maybe this

thread needs moving to the 6LowPAN reflector.
=20
Daniel.
=20
=20
Robert Cragie wrote:
 =20

	Hi Pascal,
	=20
	Source routing should of course use the IPv6 addresses which
means a lot=20
	of overhead for certain underlying link layers, e.g. 802.15.4. I
think=20
	it is generally cleaner to do the compression at a layer which
may=20
	require it only, e.g. define it in the 6lowpan HC. This is then
free to=20
	some extent to specify how the compression is done. Although I
doubt=20
	this would go down well in the 6lowpan WG...
	=20
	The tag scheme would work but it specifically scopes the source
routing=20
	to nodes which operate the scheme. This is probably acceptable=20
	practically but doesn't 'smell right' somehow.
	=20
	With regard to the original proposal: it is probably necessary
to carry=20
	the full source route all the way to at least the penultimate
node and=20
	use an index to show the current position in the route for
potential=20
	backtrace and error reporting back along the same route
(assuming link=20
	symmetry). This is how RH0 works.
	=20
	Robert
	=20
	Robert Cragie (Pacific Gas & Electric)
	=20
	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888
	http://www.gridmerge.com 
=20
	=20
	=20
	On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
	   =20

		Hi Daniel:
		=20
		Routers might have multiple interfaces of multiple MAC
types. Internet 0
		even has a MAC-less format.
		So the result of you proposal, which looks like a great
idea in a pure
		802.15.4 world with short addresses, becomes a nightmare
to define in a
		fully generic fashion.
		=20
		OTOH, a locally significant opaque tag in which the
parent could hide a
		short address of the child - if it cares to do it that
way - looks like
		a way more acceptable approach
		=20
		So it seems to me that you can get what you want as long
as we can make
		the tag big enough for short addresses. When the tag is
too small to
		contain what the parent really needs, then the parent
will have to store
		a state with the full information in memory, and then
place an index of
		some sort in the tag.
		=20
		What do you think?
		=20
		Pascal
		=20
		=20
		 =20
		     =20

			-----Original Message-----
			From: Popa, Daniel
[mailto:Daniel.Popa@itron.com]
			Sent: Thursday, April 08, 2010 11:40 AM
			To: ROLL WG
			Cc: Pascal Thubert (pthubert); JeongGil Ko
(John)
			Subject: RE: [Roll] Proposal for Source Routing
Header Format and
			SourceRoutingOperations
			=20
			Hi Pascal, John,
			=20
			Since source routing explicitly gives forwarding
instruction to each
			intermediate node, it can make sense to use only
(MAC address based)
			   =20
			       =20

		L2
		 =20
		     =20

			forwarding instead of (IPv6 address based) L3
forwarding.
			=20
			This brings two advantages:
			 - avoid processing each transit packets up to
L3.
			 - use MAC addresses that - in ROLL environment
- have inherently
			   =20
			       =20

		shorter
		 =20
		     =20

			length than an IPv6 address.
			=20
			Cheers,
			Daniel
			=20
			=20
			=20
			-----Original Message-----
			From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf
			   =20
			       =20

		Of
		 =20
		     =20

			Pascal Thubert (pthubert)
			Sent: jeudi 8 avril 2010 11:15
			To: JeongGil Ko (John); ROLL WG
			Subject: Re: [Roll] Proposal for Source Routing
Header Format and
			SourceRoutingOperations
			=20
			Hi John:
			=20
			IPv6 already has a number of routing headers, in
particular RH0,
			   =20
			       =20

		though it is
		 =20
		     =20

			being deprecated for general use in the
Internet.
			And there are reasons why the fields in RH0/1
are there and we need to
			make sure we lose none of that. In particular a
RH is recoverable, and
			   =20
			       =20

		it is
		 =20
		     =20

			easy to spot the consumed entries.
			=20
			On top of this our new problems are:
			- make sure the RH stays within the RPL network
(since it is used
			   =20
			       =20

		downwards
		 =20
		     =20

			that should be doable)
			- control the size (that probably means
compress)
			=20
			Cheers,
			=20
			Pascal
			=20
			=20
			   =20
			       =20

				-----Original Message-----
				From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf
				     =20
				         =20

			Of
			   =20
			       =20

				JeongGil Ko (John)
				Sent: Wednesday, April 07, 2010 10:05 PM
				To: ROLL WG
				Subject: [Roll] Proposal for Source
Routing Header Format and Source
				RoutingOperations
				=20
				Hi!
				=20
				Great to see all this discussions on
downwards route establishment!
				     =20
				         =20

		To
		 =20
		     =20

			add
			   =20
			       =20

				one more to the conversations here is a
proposal for source routing
				     =20
				         =20

			headers.
			   =20
			       =20

				In non-storing mode (where only the root
has individual path
				     =20
				         =20

			information)
			   =20
			       =20

				the root will be attaching a source
routing header to the data
				     =20
				         =20

		packet
		 =20
		     =20

			that a
			   =20
			       =20

				source node wants to send to a specific
destination. We can always
				     =20
				         =20

			make the
			   =20
			       =20

				header super fancy but in my opinion I
think we only need two fields
				     =20
				         =20

			in this
			   =20
			       =20

				header and here it is! Feel free to
break the stuff and mangle with
				     =20
				         =20

		it
		 =20
		     =20

			so that it
			   =20
			       =20

				looks great in the specs later on. FYI,
this is the format that I am
				     =20
				         =20

			using in my
			   =20
			       =20

				implementations so it does work :)
				=20
				1. Source Routing Header Format
				=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
				|   NEntry (8 bits)   |
				     =20
				         =20

			|
			   =20
			       =20

				+-+-+-+-+-+-+-+-+
				     =20
				         =20

			+
			   =20
			       =20

				|                       Source Route
Entry (128*NEntry bits)
				     =20
				         =20

			|
			   =20
			       =20

				+
				     =20
				         =20

			+
			   =20
			       =20

				|
				     =20
				         =20

			|
			   =20
			       =20

				      Figure 1. Proposed Source Routing
Header Format; each line is
				     =20
				         =20

		32
		 =20
		     =20

			bits:)
			   =20
			       =20

				- NEntry: Indicates the number of 128
bit addresses that the source
				     =20
				         =20

			route
			   =20
			       =20

				entry field is carrying.
				=20
				- Source Route Entry: List of 128 bit
address that consist the route
				     =20
				         =20

			to the
			   =20
			       =20

				destination. Here, the address of the
node that is one hop away from
				     =20
				         =20

			the
			   =20
			       =20

				*destination* comes first.
				=20
				2. Source Routing Packet Operations
				=20
				When source routing is initiated at a
storing node (e.g., root of
				     =20
				         =20

		the
		 =20
		     =20

			DODAG),
			   =20
			       =20

				the header is attached on the data
packet for the entire route
				     =20
				         =20

		(i.e.,
		 =20
		     =20

			from
			   =20
			       =20

				next hop node to the destination). This
header is positioned in
				     =20
				         =20

		front
		 =20
		     =20

			of the
			   =20
			       =20

				user payload. When the next hop node
receives a packet that is not
				     =20
				         =20

			destined
			   =20
			       =20

				to itself AND the network is NOT
provisioned to be in 'storing mode'
				     =20
				         =20

			then it
			   =20
			       =20

				checks NEntry to find what the next hop
is in the source route
				     =20
				         =20

		entry.
		 =20
		     =20

			Since
			   =20
			       =20

				the 'Source Route Entry' is ordered in
'farthest -> closest' (in
				     =20
				         =20

		terms
		 =20
		     =20

			of hops)
			   =20
			       =20

				order, a node can figure out what the
next hop address is with only
				     =20
				         =20

			the
			   =20
			       =20

				NEntry value (since it already knows how
big an ipv6 address is).
				     =20
				         =20

			After
			   =20
			       =20

				collecting the next hop node's address,
the node erases this address
				element from the entry and decreases
NEntry by one. This assures
				     =20
				         =20

		that
		 =20
		     =20

			we
			   =20
			       =20

				avoid the overhead of carrying the
entire source route throughout
				     =20
				         =20

		the
		 =20
		     =20

			data
			   =20
			       =20

				path.
				=20
				The approach itself should be very
simple and trivial for everyone
				     =20
				         =20

		to
		 =20
		     =20

			follow.
			   =20
			       =20

				So we can start from here and build on!
				=20
				Thanks.
				=20
				-John
				=20
				------
				JeongGil Ko (John)
				Ph.D. Student
				Department of Computer Science
				Johns Hopkins University
				http://www.cs.jhu.edu/~jgko
				=20
=09
_______________________________________________
				Roll mailing list
				Roll@ietf.org
=09
https://www.ietf.org/mailman/listinfo/roll
				     =20
				         =20

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

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

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

=20
 =20

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

=20


------_=_NextPart_001_01CADC98.1CE549F4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Hi JP and all;
     
    I’m not fully clear what the WG group really wants to do at =
this point. I sensed an agreement to endorse something very close to =
IPv6 RH0 in the core spec, and provide a separate spec that would enable =
labels in the Source route DAO and the hop by hop =
header.
     
    Is that a honest reading of the mailing list?
     
    Pascal
     
    From:=
 =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
JP Vasseur
    Sent: Thursday, April 15, 2010 2:26 =
PM
    To: d.sturek@att.net
    Cc: =
roll@ietf.org
    Subject: Re: [Roll] Proposal for Source =
RoutingHeader Format and =
SourceRoutingOperations
     
    Hi =
Don,
     
    On =
Apr 8, 2010, at 4:59 PM, Don Sturek wrote:


    I think the issue is this:
    1)       ROLL cannot meet its charter without source routing
     
    Absolutely.


    2)       Claiming the feature is now to be addressed in 6LowPAN seems a =
bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE =
802.15.4.  
     
    You are absolutely right. IPHC is 15.4 specific. This =
is why the idea of using a Label a la MPLS would be an interesting =
approach IMO. The labe could be locall significant using DAO as a label =
distribution mechanism. Completely link layer =
agnostic.
     
    JP.


    How are those addressed?
     
    Don
     
     
     
    Hi Don,

    It's not so =
much that 6lowpan is concerning itself with source routing, it is =
concerning itself with efficient header compression, which would include =
IPv6 extension headers such as RH0. Whatever =
ends up getting used for source routing needs to be some sort of IPv6 =
extension header. Source routing for IPv6 would naturally contain IPv6 =
addresses. The question is whether we want to invent some new extension =
header specifically for ROLL which uses something other (i.e. smaller) =
than IPv6 addresses, e.g. the tag scheme mentioned.

    I agree, ROLL =
must accommodate source routing one way or =
another.

    Robert
    Robert Cragie =
(Pacific Gas & Electric)
    =
Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, =
UK
    +44 (0) 1924 910888
    http://www.gridmerge.com

    On 08/04/2010 2:35 PM, Don Sturek =
wrote:
    I =
can't see why 6LowPAN (and specifically the HC draft) would concern =
itself
    with =
source routing.
     
    Surely source routing is a concern of ROLL (and =
not 6LowPAN).
     
    I don't see how ROLL completes its charter or =
addresses its requirements
    without adding source =
routing.
     
    Don
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf Of
    Daniel Gavelle
    Sent: Thursday, April 08, 2010 6:12 =
AM
    To: robert.cragie@gridmerge.com
    Cc: roll@ietf.org
    Subject: Re: [Roll] Proposal for Source =
Routing Header Format and
    SourceRoutingOperations
     
    Rob,
     
    I agree that the source routing for the data =
frames should be done as 
    part of the 6LowPAN HC.  This already has a =
stateful IPV6 address 
    compression based on contexts.  It should be =
possible to compress the 
    addresses down to two bytes per address if IPv6 =
addresses are derived 
    from the 16 bit short address are being used in =
the LowPAN.
     
    We don't want to hold up the current HC draft that =
is going through last 
    call but the work could be done as a new RFC / =
amendment.  Source 
    routing compression may need a fix for the problem =
of HC compression 
    extending beyond the first =
fragment.
     
    Doing the work in the 6LowPAN group means that the =
compression can 
    easily be used for any source routing protocol, =
not just ROLL.  It could 
    be done as a compression for the existing R0 =
routing header.  Maybe this 
    thread needs moving to the 6LowPAN =
reflector.
     
    Daniel.
     
     
    Robert Cragie =
wrote:
      =

    Hi Pascal,
     
    Source routing should of course use the IPv6 =
addresses which means a lot 
    of overhead for certain underlying link layers, =
e.g. 802.15.4. I think 
    it is generally cleaner to do the compression at a =
layer which may 
    require it only, e.g. define it in the 6lowpan HC. =
This is then free to 
    some extent to specify how the compression is =
done. Although I doubt 
    this would go down well in the 6lowpan =
WG...
     
    The tag scheme would work but it specifically =
scopes the source routing 
    to nodes which operate the scheme. This is =
probably acceptable 
    practically but doesn't 'smell right' =
somehow.
     
    With regard to the original proposal: it is =
probably necessary to carry 
    the full source route all the way to at least the =
penultimate node and 
    use an index to show the current position in the =
route for potential 
    backtrace and error reporting back along the same =
route (assuming link 
    symmetry). This is how RH0 =
works.
     
    Robert
     
    Robert Cragie (Pacific Gas & =
Electric)
     
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, =
UK
    +44 (0) 1924 =
910888
    http://www.gridmerge.com <http://www.gridmerge.com/><=
o:p>
     
     
    On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) =
wrote:
        =

    Hi Daniel:
     
    Routers might have multiple interfaces of multiple =
MAC types. Internet 0
    even has a MAC-less =
format.
    So the =
result of you proposal, which looks like a great idea in a =
pure
    802.15.4 =
world with short addresses, becomes a nightmare to define in =
a
    fully generic =
fashion.
     
    OTOH, a locally significant opaque tag in which =
the parent could hide a
    short address of the child - if it cares to do it =
that way - looks like
    a way more acceptable =
approach
     
    So it seems to me that you can get what you want =
as long as we can make
    the tag big enough for short addresses. When the =
tag is too small to
    contain what the parent really needs, then the =
parent will have to store
    a state with the full information in memory, and =
then place an index of
    some sort in the =
tag.
     
    What do you =
think?
     
    Pascal
     
     
      
          
    -----Original =
Message-----
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    Sent: Thursday, =
April 08, 2010 11:40 AM
    To: ROLL WG
    Cc: Pascal Thubert (pthubert); JeongGil Ko =
(John)
    Subject: =
RE: [Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Hi Pascal, John,
     
    Since source routing explicitly gives forwarding =
instruction to each
    intermediate node, it can make sense to use only =
(MAC address based)
        =

            
    L2
      
          
    forwarding instead of (IPv6 address based) L3 =
forwarding.
     
    This brings two =
advantages:
     - =
avoid processing each transit packets up to =
L3.
     - use MAC =
addresses that - in ROLL environment - have =
inherently
        =

            
    shorter
      
          
    length than an IPv6 =
address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
        =

            
    Of
      
          
    Pascal Thubert =
(pthubert)
    Sent: =
jeudi 8 avril 2010 11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: =
[Roll] Proposal for Source Routing Header Format =
and
    SourceRoutingOperations
     
    Hi John:
     
    IPv6 already has a number of routing headers, in =
particular RH0,
        =

            
    though it is
      
          
    being deprecated for general use in the =
Internet.
    And =
there are reasons why the fields in RH0/1 are there and we need =
to
    make sure we =
lose none of that. In particular a RH is recoverable, =
and
        =

            
    it =
is
      =

          
    easy to spot the consumed =
entries.
     
    On top of this our new problems =
are:
    - make sure =
the RH stays within the RPL network (since it is =
used
        =

            
    downwards
      
          
    that should be =
doable)
    - =
control the size (that probably means =
compress)
     
    Cheers,
     
    Pascal
     
     
        =

            
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
          =

            &nb=
sp; 
    Of
        =

            
    JeongGil Ko =
(John)
    Sent: =
Wednesday, April 07, 2010 10:05 PM
    To: ROLL WG
    Subject: [Roll] Proposal for Source Routing Header =
Format and Source
    RoutingOperations
     
    Hi!
     
    Great to see all this discussions on downwards =
route establishment!
          =

            &nb=
sp; 
    To
      
          
    add
        =

            
    one more to the conversations here is a proposal =
for source routing
          =

            &nb=
sp; 
    headers.
        =

            
    In non-storing mode (where only the root has =
individual path
          =

            &nb=
sp; 
    information)
        =

            
    the root will be attaching a source routing header =
to the data
          =

            &nb=
sp; 
    packet
      
          
    that a
        =

            
    source node wants to send to a specific =
destination. We can always
          =

            &nb=
sp; 
    make the
        =

            
    header super fancy but in my opinion I think we =
only need two fields
          =

            &nb=
sp; 
    in this
        =

            
    header and here it is! Feel free to break the =
stuff and mangle with
          =

            &nb=
sp; 
    it
      
          
    so that it
        =

            
    looks great in the specs later on. FYI, this is =
the format that I am
          =

            &nb=
sp; 
    using in my
        =

            
    implementations so it does work =
:)
     
    1. Source Routing Header =
Format
     
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+
    |   NEntry (8 bits)   =
|
          =

            &nb=
sp; 
    |
        =

            
    +-+-+-+-+-+-+-+-+
          =

            &nb=
sp; 
    +
        =

            
    |        &n=
bsp; =
            &=
nbsp;Source Route Entry (128*NEntry =
bits)
          =

            &nb=
sp; 
    |
        =

            
    +
          =

            &nb=
sp; 
    +
        =

            
    |
          =

            &nb=
sp; 
    |
        =

            
          Figure 1. Proposed =
Source Routing Header Format; each line =
is
          =

            &nb=
sp; 
    32
      
          
    bits:)
        =

            
    - NEntry: Indicates the number of 128 bit =
addresses that the source
          =

            &nb=
sp; 
    route
        =

            
    entry field is =
carrying.
     
    - Source Route Entry: List of 128 bit address that =
consist the route
          =

            &nb=
sp; 
    to the
        =

            
    destination. Here, the address of the node that is =
one hop away from
          =

            &nb=
sp; 
    the
        =

            
    *destination* comes =
first.
     
    2. Source Routing Packet =
Operations
     
    When source routing is initiated at a storing node =
(e.g., root of
          =

            &nb=
sp; 
    the
      
          
    DODAG),
        =

            
    the header is attached on the data packet for the =
entire route
          =

            &nb=
sp; 
    (i.e.,
      
          
    from
        =

            
    next hop node to the destination). This header is =
positioned in
          =

            &nb=
sp; 
    front
      
          
    of the
        =

            
    user payload. When the next hop node receives a =
packet that is not
          =

            &nb=
sp; 
    destined
        =

            
    to itself AND the network is NOT provisioned to be =
in 'storing mode'
          =

            &nb=
sp; 
    then it
        =

            
    checks NEntry to find what the next hop is in the =
source route
          =

            &nb=
sp; 
    entry.
      
          
    Since
        =

            
    the 'Source Route Entry' is ordered in 'farthest =
-> closest' (in
          =

            &nb=
sp; 
    terms
      
          
    of hops)
        =

            
    order, a node can figure out what the next hop =
address is with only
          =

            &nb=
sp; 
    the
        =

            
    NEntry value (since it already knows how big an =
ipv6 address is).
          =

            &nb=
sp; 
    After
        =

            
    collecting the next hop node's address, the node =
erases this address
    element from the entry and decreases NEntry by =
one. This assures
          =

            &nb=
sp; 
    that
      
          
    we
        =

            
    avoid the overhead of carrying the entire source =
route throughout
          =

            &nb=
sp; 
    the
      
          
    data
        =

            
    path.
     
    The approach itself should be very simple and =
trivial for everyone
          =

            &nb=
sp; 
    to
      
          
    follow.
        =

            
    So we can start from here and build =
on!
     
    Thanks.
     
    -John
     
    ------
    JeongGil Ko =
(John)
    Ph.D. =
Student
    Department of Computer =
Science
    Johns =
Hopkins University
    http://www.cs.jhu.edu/~jgko=

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

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

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

     
      
    _______________________________________________
    Roll mailing =
list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
     
    
------_=_NextPart_001_01CADC98.1CE549F4--

From jpv@cisco.com  Thu Apr 15 05:40:43 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AC63A69F9 for ; Thu, 15 Apr 2010 05:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.064
X-Spam-Level: 
X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlfscdY-WH6f for ; Thu, 15 Apr 2010 05:40:42 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 72C1628C241 for ; Thu, 15 Apr 2010 05:36:33 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJekxkutJV2b/2dsb2JhbACbbnGkApohhQ4Ejl8
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="102027775"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2010 12:36:26 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o3FCaQAG021708;  Thu, 15 Apr 2010 12:36:26 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 07:36:25 -0500
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 07:36:24 -0500
Message-Id: <1F6FE73F-4951-4AED-BE7D-7EDEBACAD981@cisco.com>
From: JP Vasseur 
To: Kris Pister 
In-Reply-To: <4BBE2455.6040700@eecs.berkeley.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:36:22 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>  <6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com> <7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com> <4BBE2455.6040700@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:36:25.0430 (UTC) FILETIME=[43370760:01CADC98]
Cc: ROLL WG , "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing Header Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:40:43 -0000

On Apr 8, 2010, at 8:45 PM, Kris Pister wrote:

> +1
>
> Jonathan Hui wrote:
>>
>> To make the source route header compact, I favor the tag/label  
>> approach over some other compaction mechanism that operates  
>> directly on a list of IPv6 addresses.  Tags/labels can be made  
>> general enough such that they can be derived in different ways.   
>> Because the tags/labels have scope local to each node, the  
>> mechanism is pretty general already.  For those that are already  
>> managing unique 802.15.4 short addresses across a network, I can  
>> see that it is attractive to utilize the short address directly and  
>> reduce state on devices.  In other cases, it may be best for the  
>> node to dynamically assign tags/labels for its neighbors.
>>
>> Either way, while the tag/label mechanism is simple, it is far more  
>> flexible than an approach to compacting a list of IPv6 addresses.   
>> And note that the idea of using tags/labels is nothing new.

And has proven to be quite efficient.

>> Of course we will adapt the basic mechanism a bit (label  
>> distribution, headers formats, etc), but the core ideas have been  
>> deployed in traditional IP networks for quite some time.

Even MPLS has different label distribution (LDP, following the IGP  
path - or RSVP-TE for Source routing). That does not even require  
label stacking to establish LSPs.

>>
>> I reiterated a lot of what was already stated before by others, but  
>> that is what I think.
>>
>> -- 
>> Jonathan Hui
>>
>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>> Hi Daniel:
>>>
>>> Routers might have multiple interfaces of multiple MAC types.  
>>> Internet 0
>>> even has a MAC-less format.
>>> So the result of you proposal, which looks like a great idea in a  
>>> pure
>>> 802.15.4 world with short addresses, becomes a nightmare to define  
>>> in a
>>> fully generic fashion.
>>>
>>> OTOH, a locally significant opaque tag in which the parent could  
>>> hide a
>>> short address of the child - if it cares to do it that way - looks  
>>> like
>>> a way more acceptable approach
>>>
>>> So it seems to me that you can get what you want as long as we can  
>>> make
>>> the tag big enough for short addresses. When the tag is too small to
>>> contain what the parent really needs, then the parent will have to  
>>> store
>>> a state with the full information in memory, and then place an  
>>> index of
>>> some sort in the tag.
>>>
>>> What do you think?
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>>> Sent: Thursday, April 08, 2010 11:40 AM
>>>> To: ROLL WG
>>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi Pascal, John,
>>>>
>>>> Since source routing explicitly gives forwarding instruction to  
>>>> each
>>>> intermediate node, it can make sense to use only (MAC address  
>>>> based)
>>> L2
>>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>>
>>>> This brings two advantages:
>>>> - avoid processing each transit packets up to L3.
>>>> - use MAC addresses that - in ROLL environment - have inherently
>>> shorter
>>>> length than an IPv6 address.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On  
>>>> Behalf
>>> Of
>>>> Pascal Thubert (pthubert)
>>>> Sent: jeudi 8 avril 2010 11:15
>>>> To: JeongGil Ko (John); ROLL WG
>>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>>> SourceRoutingOperations
>>>>
>>>> Hi John:
>>>>
>>>> IPv6 already has a number of routing headers, in particular RH0,
>>> though it is
>>>> being deprecated for general use in the Internet.
>>>> And there are reasons why the fields in RH0/1 are there and we  
>>>> need to
>>>> make sure we lose none of that. In particular a RH is  
>>>> recoverable, and
>>> it is
>>>> easy to spot the consumed entries.
>>>>
>>>> On top of this our new problems are:
>>>> - make sure the RH stays within the RPL network (since it is used
>>> downwards
>>>> that should be doable)
>>>> - control the size (that probably means compress)
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On  
>>>>> Behalf
>>>> Of
>>>>> JeongGil Ko (John)
>>>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>>> To: ROLL WG
>>>>> Subject: [Roll] Proposal for Source Routing Header Format and  
>>>>> Source
>>>>> RoutingOperations
>>>>>
>>>>> Hi!
>>>>>
>>>>> Great to see all this discussions on downwards route  
>>>>> establishment!
>>> To
>>>> add
>>>>> one more to the conversations here is a proposal for source  
>>>>> routing
>>>> headers.
>>>>> In non-storing mode (where only the root has individual path
>>>> information)
>>>>> the root will be attaching a source routing header to the data
>>> packet
>>>> that a
>>>>> source node wants to send to a specific destination. We can always
>>>> make the
>>>>> header super fancy but in my opinion I think we only need two  
>>>>> fields
>>>> in this
>>>>> header and here it is! Feel free to break the stuff and mangle  
>>>>> with
>>> it
>>>> so that it
>>>>> looks great in the specs later on. FYI, this is the format that  
>>>>> I am
>>>> using in my
>>>>> implementations so it does work :)
>>>>>
>>>>> 1. Source Routing Header Format
>>>>>
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> |   NEntry (8 bits)   |
>>>> |
>>>>> +-+-+-+-+-+-+-+-+
>>>> +
>>>>> |                       Source Route Entry (128*NEntry bits)
>>>> |
>>>>> +
>>>> +
>>>>> |
>>>> |
>>>>>
>>>>>     Figure 1. Proposed Source Routing Header Format; each line is
>>> 32
>>>> bits:)
>>>>>
>>>>> - NEntry: Indicates the number of 128 bit addresses that the  
>>>>> source
>>>> route
>>>>> entry field is carrying.
>>>>>
>>>>> - Source Route Entry: List of 128 bit address that consist the  
>>>>> route
>>>> to the
>>>>> destination. Here, the address of the node that is one hop away  
>>>>> from
>>>> the
>>>>> *destination* comes first.
>>>>>
>>>>> 2. Source Routing Packet Operations
>>>>>
>>>>> When source routing is initiated at a storing node (e.g., root of
>>> the
>>>> DODAG),
>>>>> the header is attached on the data packet for the entire route
>>> (i.e.,
>>>> from
>>>>> next hop node to the destination). This header is positioned in
>>> front
>>>> of the
>>>>> user payload. When the next hop node receives a packet that is not
>>>> destined
>>>>> to itself AND the network is NOT provisioned to be in 'storing  
>>>>> mode'
>>>> then it
>>>>> checks NEntry to find what the next hop is in the source route
>>> entry.
>>>> Since
>>>>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>>> terms
>>>> of hops)
>>>>> order, a node can figure out what the next hop address is with  
>>>>> only
>>>> the
>>>>> NEntry value (since it already knows how big an ipv6 address is).
>>>> After
>>>>> collecting the next hop node's address, the node erases this  
>>>>> address
>>>>> element from the entry and decreases NEntry by one. This assures
>>> that
>>>> we
>>>>> avoid the overhead of carrying the entire source route throughout
>>> the
>>>> data
>>>>> path.
>>>>>
>>>>> The approach itself should be very simple and trivial for everyone
>>> to
>>>> follow.
>>>>> So we can start from here and build on!
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -John
>>>>>
>>>>> ------
>>>>> JeongGil Ko (John)
>>>>> Ph.D. Student
>>>>> Department of Computer Science
>>>>> Johns Hopkins University
>>>>> http://www.cs.jhu.edu/~jgko
>>>>>
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From d.sturek@att.net  Thu Apr 15 05:52:47 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C0428C219 for ; Thu, 15 Apr 2010 05:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level: 
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=0.216,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byWJvuSjShMc for ; Thu, 15 Apr 2010 05:52:34 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 1AEE228C1A5 for ; Thu, 15 Apr 2010 05:48:23 -0700 (PDT)
Received: (qmail 79512 invoked from network); 15 Apr 2010 12:48:14 -0000
Received: from adsl-69-224-122-222.dsl.sndg02.pacbell.net (d.sturek@69.224.122.222 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 15 Apr 2010 05:48:13 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: G3NPSu8VM1l15RSyVX5ozpdMorpcJBZm01_va48SWS3RS8tFjiYuJZQ_7y3aRo.UeJtpNRTylFxVJDdmbs9K4AlCEZBKF0fQ1LL4yJKNm.WyPskhg_F32fWWfxUuCHiBXQmmAHvG1sy3nd.mx.H1EnbTekxP0aDUp5PEcPomnoXOhmVdSUrvToLBRvFpZfhcrDZdXYd43MdvWz_axvGwExzdKt1kzXXDKKZ7COlgdyC9CMR67iEwg8VWMDCV2jPoNepOjke1c1BhHNjMo40c7SOJ_VWL.sOv_KDenfwCZtvgF9O48A--
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Pascal Thubert \(pthubert\)'" , "'JP Vasseur'" 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net> <3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>
Date: Thu, 15 Apr 2010 05:48:11 -0700
Message-ID: <00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01CADC5F.3BEFDE20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrcl5A+OpYRO6OrQfiUN3gjHEEcvAAABbtQAABkpiA=
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Apr 2010 12:52:48 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00CC_01CADC5F.3BEFDE20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Pascal,

 

I believe what you wrote below was the majority view on the reflector.

 

Don

 

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] 
Sent: Thursday, April 15, 2010 5:35 AM
To: JP Vasseur; d.sturek@att.net
Cc: roll@ietf.org
Subject: RE: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

 

Hi JP and all;

 

I'm not fully clear what the WG group really wants to do at this point. I
sensed an agreement to endorse something very close to IPv6 RH0 in the core
spec, and provide a separate spec that would enable labels in the Source
route DAO and the hop by hop header.

 

Is that a honest reading of the mailing list?

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP
Vasseur
Sent: Thursday, April 15, 2010 2:26 PM
To: d.sturek@att.net
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

 

Hi Don,

 

On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:

 

I think the issue is this:

1)       ROLL cannot meet its charter without source routing

 

Absolutely.

 

2)       Claiming the feature is now to be addressed in 6LowPAN seems a bit
wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  

 

You are absolutely right. IPHC is 15.4 specific. This is why the idea of
using a Label a la MPLS would be an interesting approach IMO. The labe could
be locall significant using DAO as a label distribution mechanism.
Completely link layer agnostic.

 

JP.

 

How are those addressed?

 

Don

 

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] 
Sent: Thursday, April 08, 2010 7:52 AM
To: d.sturek@att.net
Cc: daniel.gavelle@jennic.com; roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

 

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing, it
is concerning itself with efficient header compression, which would include
IPv6 extension headers such as RH0
 . Whatever ends up getting used
for source routing needs to be some sort of IPv6 extension header. Source
routing for IPv6 would naturally contain IPv6 addresses. The question is
whether we want to invent some new extension header specifically for ROLL
which uses something other (i.e. smaller) than IPv6 addresses, e.g. the tag
scheme mentioned.

I agree, ROLL must accommodate source routing one way or another.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 08/04/2010 2:35 PM, Don Sturek wrote:

I can't see why 6LowPAN (and specifically the HC draft) would concern itself
with source routing.
 
Surely source routing is a concern of ROLL (and not 6LowPAN).
 
I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.
 
Don
 
 
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Rob,
 
I agree that the source routing for the data frames should be done as 
part of the 6LowPAN HC.  This already has a stateful IPV6 address 
compression based on contexts.  It should be possible to compress the 
addresses down to two bytes per address if IPv6 addresses are derived 
from the 16 bit short address are being used in the LowPAN.
 
We don't want to hold up the current HC draft that is going through last 
call but the work could be done as a new RFC / amendment.  Source 
routing compression may need a fix for the problem of HC compression 
extending beyond the first fragment.
 
Doing the work in the 6LowPAN group means that the compression can 
easily be used for any source routing protocol, not just ROLL.  It could 
be done as a compression for the existing R0 routing header.  Maybe this 
thread needs moving to the 6LowPAN reflector.
 
Daniel.
 
 
Robert Cragie wrote:
  

Hi Pascal,
 
Source routing should of course use the IPv6 addresses which means a lot 
of overhead for certain underlying link layers, e.g. 802.15.4. I think 
it is generally cleaner to do the compression at a layer which may 
require it only, e.g. define it in the 6lowpan HC. This is then free to 
some extent to specify how the compression is done. Although I doubt 
this would go down well in the 6lowpan WG...
 
The tag scheme would work but it specifically scopes the source routing 
to nodes which operate the scheme. This is probably acceptable 
practically but doesn't 'smell right' somehow.
 
With regard to the original proposal: it is probably necessary to carry 
the full source route all the way to at least the penultimate node and 
use an index to show the current position in the route for potential 
backtrace and error reporting back along the same route (assuming link 
symmetry). This is how RH0 works.
 
Robert
 
Robert Cragie (Pacific Gas & Electric)
 
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  

 
 
On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
    

Hi Daniel:
 
Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.
 
OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach
 
So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.
 
What do you think?
 
Pascal
 
 
  
      

-----Original Message-----
From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,
 
Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based)
    
        

L2
  
      

forwarding instead of (IPv6 address based) L3 forwarding.
 
This brings two advantages:
 - avoid processing each transit packets up to L3.
 - use MAC addresses that - in ROLL environment - have inherently
    
        

shorter
  
      

length than an IPv6 address.
 
Cheers,
Daniel
 
 
 
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
    
        

Of
  
      

Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi John:
 
IPv6 already has a number of routing headers, in particular RH0,
    
        

though it is
  
      

being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
    
        

it is
  
      

easy to spot the consumed entries.
 
On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
    
        

downwards
  
      

that should be doable)
- control the size (that probably means compress)
 
Cheers,
 
Pascal
 
 
    
        

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
      
          

Of
    
        

JeongGil Ko (John)
Sent: Wednesday, April 07, 2010 10:05 PM
To: ROLL WG
Subject: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations
 
Hi!
 
Great to see all this discussions on downwards route establishment!
      
          

To
  
      

add
    
        

one more to the conversations here is a proposal for source routing
      
          

headers.
    
        

In non-storing mode (where only the root has individual path
      
          

information)
    
        

the root will be attaching a source routing header to the data
      
          

packet
  
      

that a
    
        

source node wants to send to a specific destination. We can always
      
          

make the
    
        

header super fancy but in my opinion I think we only need two fields
      
          

in this
    
        

header and here it is! Feel free to break the stuff and mangle with
      
          

it
  
      

so that it
    
        

looks great in the specs later on. FYI, this is the format that I am
      
          

using in my
    
        

implementations so it does work :)
 
1. Source Routing Header Format
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |
      
          

|
    
        

+-+-+-+-+-+-+-+-+
      
          

+
    
        

|                       Source Route Entry (128*NEntry bits)
      
          

|
    
        

+
      
          

+
    
        

|
      
          

|
    
        

      Figure 1. Proposed Source Routing Header Format; each line is
      
          

32
  
      

bits:)
    
        

- NEntry: Indicates the number of 128 bit addresses that the source
      
          

route
    
        

entry field is carrying.
 
- Source Route Entry: List of 128 bit address that consist the route
      
          

to the
    
        

destination. Here, the address of the node that is one hop away from
      
          

the
    
        

*destination* comes first.
 
2. Source Routing Packet Operations
 
When source routing is initiated at a storing node (e.g., root of
      
          

the
  
      

DODAG),
    
        

the header is attached on the data packet for the entire route
      
          

(i.e.,
  
      

from
    
        

next hop node to the destination). This header is positioned in
      
          

front
  
      

of the
    
        

user payload. When the next hop node receives a packet that is not
      
          

destined
    
        

to itself AND the network is NOT provisioned to be in 'storing mode'
      
          

then it
    
        

checks NEntry to find what the next hop is in the source route
      
          

entry.
  
      

Since
    
        

the 'Source Route Entry' is ordered in 'farthest -> closest' (in
      
          

terms
  
      

of hops)
    
        

order, a node can figure out what the next hop address is with only
      
          

the
    
        

NEntry value (since it already knows how big an ipv6 address is).
      
          

After
    
        

collecting the next hop node's address, the node erases this address
element from the entry and decreases NEntry by one. This assures
      
          

that
  
      

we
    
        

avoid the overhead of carrying the entire source route throughout
      
          

the
  
      

data
    
        

path.
 
The approach itself should be very simple and trivial for everyone
      
          

to
  
      

follow.
    
        

So we can start from here and build on!
 
Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko
 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
      
          

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

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

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

 
  

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

 


------=_NextPart_000_00CC_01CADC5F.3BEFDE20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi Pascal,
    


     
    


    I believe what you wrote below was the majority view on =
the
reflector.
    


     
    


    Don
    


     
    


     
    


    


    


    From:=
 Pascal =
Thubert
(pthubert) [mailto:pthubert@cisco.com] 
    
Sent: Thursday, April 15, 2010 5:35 AM
    
To: JP Vasseur; d.sturek@att.net
    
Cc: roll@ietf.org
    
Subject: RE: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations
    


    


    


     
    


    Hi JP and all;
    


     
    


    I’m not fully clear what the WG group really wants =
to do
at this point. I sensed an agreement to endorse something very close to =
IPv6
RH0 in the core spec, and provide a separate spec that would enable =
labels in
the Source route DAO and the hop by hop header.
    


     
    


    Is that a honest reading of the mailing =
list?
    


     
    


    


    Pascal
    


    


     
    


    


    


    


    From:=

roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
JP
Vasseur
    
Sent: Thursday, April 15, 2010 2:26 PM
    
To: d.sturek@att.net
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations
    


    


    


     
    


    Hi Don,
    


    


     
    


    


    


    On Apr 8, 2010, at 4:59 PM, Don Sturek =
wrote:
    


    


     
    


    


    


    


    I think the issue is this:
    


    


    


    1)       ROLL cannot meet =
its
charter without source routing
    


    


    


    


    


     
    


    


    


    Absolutely.
    


    


     
    


    


    


    


    2)       Claiming the =
feature is
now to be addressed in 6LowPAN seems a bit wrong.  ROLL has as its =
scope
MAC/PHYs other than IEEE 802.15.4.  
    


    


    


    


    


     
    


    


    


    You are absolutely right. IPHC is 15.4 specific. =
This is why
the idea of using a Label a la MPLS would be an interesting approach =
IMO. The
labe could be locall significant using DAO as a label distribution =
mechanism.
Completely link layer agnostic.
    


    


    


     
    


    


    


    JP.
    


    


     
    


    


    


    


    How are those =
addressed?
    


    


    


     
    


    


    


    Don
    


    


    


     
    


    


    


     
    


    


    


    


    


    From:=
 Robert =
Cragie [mailto:robert.cragie@gridmerg=
e.com] 
    
Sent: Thursday, =
April 08,
2010 7:52 AM
    
To: d.sturek@att.net
    
Cc: daniel.gavelle@jennic.com;<=
span
class=3Dapple-converted-space>     roll@ietf.org
    
Subject: Re: =
[Roll]
Proposal for Source Routing Header Format and =
SourceRoutingOperations
    


    


    


    


    


     
    


    


    


    Hi Don,
    

    
It's not so much that 6lowpan is concerning itself with source routing, =
it is
concerning itself with efficient header compression, which would include =
IPv6
extension headers such as RH0. Whatever =
ends up
getting used for source routing needs to be some sort of IPv6 extension =
header.
Source routing for IPv6 would naturally contain IPv6 addresses. The =
question is
whether we want to invent some new extension header specifically for =
ROLL which
uses something other (i.e. smaller) than IPv6 addresses, e.g. the tag =
scheme
mentioned.
    

    
I agree, ROLL must accommodate source routing one way or another.
    

    
Robert
    


    


    


    Robert
Cragie (Pacific Gas & Electric)
    


    =
Gridmerge
Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    


    



    
On 08/04/2010 2:35 PM, Don Sturek wrote:
    


    


    I can't see why 6LowPAN (and =
specifically the HC draft) would concern =
itself
    with source =
routing.
     
    Surely source routing is a concern of ROLL (and =
not 6LowPAN).
     
    I don't see how ROLL completes its charter or =
addresses its requirements
    without adding source =
routing.
     
    Don
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf Of
    Daniel Gavelle
    Sent: Thursday, April 08, 2010 6:12 =
AM
    To: robert.cragie@gridmerge.com
    Cc: roll@ietf.org
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format and
    SourceRoutingOperations
     
    Rob,
     
    I agree that the source routing for the data =
frames should be done as 
    part of the 6LowPAN HC.  This already has a =
stateful IPV6 address 
    compression based on contexts.  It should be =
possible to compress the 
    addresses down to two bytes per address if IPv6 =
addresses are derived 
    from the 16 bit short address are being used in =
the LowPAN.
     
    We don't want to hold up the current HC draft that =
is going through last 
    call but the work could be done as a new RFC / =
amendment.  Source 
    routing compression may need a fix for the problem =
of HC compression 
    extending beyond the first =
fragment.
     
    Doing the work in the 6LowPAN group means that the =
compression can 
    easily be used for any source routing protocol, =
not just ROLL.  It could 
    be done as a compression for the existing R0 =
routing header.  Maybe this 
    thread needs moving to the 6LowPAN =
reflector.
     
    Daniel.
     
     
    Robert Cragie =
wrote:
      
    


    Hi Pascal,
     
    Source routing should of course use the IPv6 =
addresses which means a lot 
    of overhead for certain underlying link layers, =
e.g. 802.15.4. I think 
    it is generally cleaner to do the compression at a =
layer which may 
    require it only, e.g. define it in the 6lowpan HC. =
This is then free to 
    some extent to specify how the compression is =
done. Although I doubt 
    this would go down well in the 6lowpan =
WG...
     
    The tag scheme would work but it specifically =
scopes the source routing 
    to nodes which operate the scheme. This is =
probably acceptable 
    practically but doesn't 'smell right' =
somehow.
     
    With regard to the original proposal: it is =
probably necessary to carry 
    the full source route all the way to at least the =
penultimate node and 
    use an index to show the current position in the =
route for potential 
    backtrace and error reporting back along the same =
route (assuming link 
    symmetry). This is how RH0 =
works.
     
    Robert
     
    Robert Cragie (Pacific Gas & =
Electric)
     
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, =
UK
    +44 (0) 1924 =
910888
    http://www.gridmerge.com <http://www.gridmerge.com/><=
o:p>
     
     
    On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) =
wrote:
        
    


    Hi Daniel:
     
    Routers might have multiple interfaces of multiple =
MAC types. Internet 0
    even has a MAC-less =
format.
    So the result of you proposal, which looks like a =
great idea in a pure
    802.15.4 world with short addresses, becomes a =
nightmare to define in a
    fully generic =
fashion.
     
    OTOH, a locally significant opaque tag in which =
the parent could hide a
    short address of the child - if it cares to do it =
that way - looks like
    a way more acceptable =
approach
     
    So it seems to me that you can get what you want =
as long as we can make
    the tag big enough for short addresses. When the =
tag is too small to
    contain what the parent really needs, then the =
parent will have to store
    a state with the full information in memory, and =
then place an index of
    some sort in the =
tag.
     
    What do you =
think?
     
    Pascal
     
     
      
          
    


    -----Original =
Message-----
    From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
    Sent: Thursday, April 08, 2010 11:40 =
AM
    To: ROLL WG
    Cc: Pascal Thubert (pthubert); JeongGil Ko =
(John)
    Subject: RE: [Roll] Proposal for Source Routing =
Header Format and
    SourceRoutingOperations
     
    Hi Pascal, John,
     
    Since source routing explicitly gives forwarding =
instruction to each
    intermediate node, it can make sense to use only =
(MAC address based)
        =

            
    


    L2
      
          
    


    forwarding instead of (IPv6 address based) L3 =
forwarding.
     
    This brings two =
advantages:
     - avoid processing each transit packets up to =
L3.
     - use MAC addresses that - in ROLL environment - =
have inherently
        =

            
    


    shorter
      
          
    


    length than an IPv6 =
address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
        =

            
    


    Of
      
          
    


    Pascal Thubert =
(pthubert)
    Sent: jeudi 8 avril 2010 =
11:15
    To: JeongGil Ko (John); ROLL =
WG
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format and
    SourceRoutingOperations
     
    Hi John:
     
    IPv6 already has a number of routing headers, in =
particular RH0,
        =

            
    


    though it =
is
      
          
    


    being deprecated for general use in the =
Internet.
    And there are reasons why the fields in RH0/1 are =
there and we need to
    make sure we lose none of that. In particular a RH =
is recoverable, and
        =

            
    


    it is
      
          
    


    easy to spot the consumed =
entries.
     
    On top of this our new problems =
are:
    - make sure the RH stays within the RPL network =
(since it is used
        =

            
    


    downwards
      
          
    


    that should be =
doable)
    - control the size (that probably means =
compress)
     
    Cheers,
     
    Pascal
     
     
        =

            
    


    -----Original =
Message-----
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf
          =

            &nb=
sp; 
    


    Of
        =

            
    


    JeongGil Ko =
(John)
    Sent: Wednesday, April 07, 2010 10:05 =
PM
    To: ROLL WG
    Subject: [Roll] Proposal for Source Routing Header =
Format and Source
    RoutingOperations
     
    Hi!
     
    Great to see all this discussions on downwards =
route establishment!
          =

            &nb=
sp; 
    


    


    To
      
          
    


    add
        =

            
    


    one more to the conversations here is a proposal =
for source routing
          =

            &nb=
sp; 
    


    headers.
        =

            
    


    In non-storing mode (where only the root has =
individual path
          =

            &nb=
sp; 
    


    information)
        =

            
    


    the root will be attaching a source routing header =
to the data
          =

            &nb=
sp; 
    


    


    packet
      
          
    


    that a
        =

            
    


    source node wants to send to a specific =
destination. We can always
          =

            &nb=
sp; 
    


    make =
the
        =

            
    


    header super fancy but in my opinion I think we =
only need two fields
          =

            &nb=
sp; 
    


    in =
this
        =

            
    


    header and here it is! Feel free to break the =
stuff and mangle with
          =

            &nb=
sp; 
    


    


    it
      
          
    


    so that it
        =

            
    


    looks great in the specs later on. FYI, this is =
the format that I am
          =

            &nb=
sp; 
    


    using in =
my
        =

            
    


    implementations so it does work =
:)
     
    1. Source Routing Header =
Format
     
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+
    |   NEntry (8 bits)   =
|
          =

            &nb=
sp; 
    


    |
        =

            
    


    +-+-+-+-+-+-+-+-+
          =

            &nb=
sp; 
    


    +
        =

            
    


    |        &n=
bsp; =
            &=
nbsp;Source Route Entry (128*NEntry =
bits)
          =

            &nb=
sp; 
    


    |
        =

            
    


    +
          =

            &nb=
sp; 
    


    +
        =

            
    


    |
          =

            &nb=
sp; 
    


    |
        =

            
    


          Figure 1. Proposed =
Source Routing Header Format; each line =
is
          =

            &nb=
sp; 
    


    


    32
      
          
    


    bits:)
        =

            
    


    - NEntry: Indicates the number of 128 bit =
addresses that the source
          =

            &nb=
sp; 
    


    route
        =

            
    


    entry field is =
carrying.
     
    - Source Route Entry: List of 128 bit address that =
consist the route
          =

            &nb=
sp; 
    


    to =
the
        =

            
    


    destination. Here, the address of the node that is =
one hop away from
          =

            &nb=
sp; 
    


    the
        =

            
    


    *destination* comes =
first.
     
    2. Source Routing Packet =
Operations
     
    When source routing is initiated at a storing node =
(e.g., root of
          =

            &nb=
sp; 
    


    


    the
      
          
    


    DODAG),
        
            
    


    the header is attached on the data packet for the =
entire route
          =

            &nb=
sp; 
    


    


    (i.e.,
      
          
    


    from
        =

            
    


    next hop node to the destination). This header is =
positioned in
          =

            &nb=
sp; 
    


    


    front
      
          
    


    of the
        =

            
    


    user payload. When the next hop node receives a =
packet that is not
          =

            &nb=
sp; 
    


    destined
        =

            
    


    to itself AND the network is NOT provisioned to be =
in 'storing mode'
          =

            &nb=
sp; 
    


    then =
it
        =

            
    


    checks NEntry to find what the next hop is in the =
source route
          =

            &nb=
sp; 
    


    


    entry.
      
          
    


    Since
        =

            
    


    the 'Source Route Entry' is ordered in 'farthest =
-> closest' (in
          =

            &nb=
sp; 
    


    


    terms
      
          
    


    of hops)
        =

            
    


    order, a node can figure out what the next hop =
address is with only
          =

            &nb=
sp; 
    


    the
        =

            
    


    NEntry value (since it already knows how big an =
ipv6 address is).
          =

            &nb=
sp; 
    


    After
        =

            
    


    collecting the next hop node's address, the node =
erases this address
    element from the entry and decreases NEntry by =
one. This assures
          =

            &nb=
sp; 
    


    


    that
      
          
    


    we
        =

            
    


    avoid the overhead of carrying the entire source =
route throughout
          =

            &nb=
sp; 
    


    


    the
      
          
    


    data
        =

            
    


    path.
     
    The approach itself should be very simple and =
trivial for everyone
          =

            &nb=
sp; 
    


    


    to
      
          
    


    follow.
        
            
    


    So we can start from here and build =
on!
     
    Thanks.
     
    -John
     
    ------
    JeongGil Ko =
(John)
    Ph.D. Student
    Department of Computer =
Science
    Johns Hopkins =
University
    http://www.cs.jhu.edu/~jgko=

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

            &nb=
sp; 
    


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

            
    


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


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

    


     
      
    


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


    


    


     
    


    


    


    





------=_NextPart_000_00CC_01CADC5F.3BEFDE20--


From jpv@cisco.com  Thu Apr 15 05:52:53 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CEB28C19B for ; Thu, 15 Apr 2010 05:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.002
X-Spam-Level: 
X-Spam-Status: No, score=-9.002 tagged_above=-999 required=5 tests=[AWL=1.597,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xRm9g5ofg2C for ; Thu, 15 Apr 2010 05:52:51 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E101628C1AD for ; Thu, 15 Apr 2010 05:48:29 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABqoxkurR7Ht/2dsb2JhbACbbnGjc5okglmCNQQ
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="250584764"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2010 12:48:23 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCmHNA001498; Thu, 15 Apr 2010 12:48:23 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:48:15 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:48:14 +0200
Message-Id: <042F4007-F9A8-40A1-BA9C-2FC713C12CB0@cisco.com>
From: JP Vasseur 
To: Jonathan Hui 
In-Reply-To: <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:48:13 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:48:14.0348 (UTC) FILETIME=[E9C354C0:01CADC99]
Cc: roll@ietf.org, "Popa, Daniel" 
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:52:53 -0000

Sitll co-chair hat off

On Apr 9, 2010, at 5:00 PM, Jonathan Hui wrote:

>
> Hi Daniel,
>
> Some comments:
>
> - I'm not in favor of having variable sized tags.  It complicates =20
> processing and state maintenance.  It makes dealing with RH0-style =20
> headers difficult because it causes you to move large portions of =20
> the header around when you simply need to perform a label swap.  We =20=

> should pick a fixed size that is reasonable (e.g. 16-bits).  =20
> Anything too large diminishes a primary reason for having tags - a =20
> compact identifier for the next hop.
>

Agreed

> - For a source routing header, I'd much rather see something derived =20=

> from the RH0 format.
>

Agreed

> - For different levels of service, the nice thing with tags is that =20=

> the tag itself can identify not only a destination but also how to =20
> get there (path, service level, etc.).  That is the primary reason =20
> why labels are used in traditional IP networks today.

TO be accurate this is for VPN too ;-) with stacked labels. But you =20
are correct that one can use labels to build Label Switch Paths (LSP), =20=

with potentially different objectives (traffic engineering).

> Of course, it means that you will have to maintain multiple tags for =20=

> the same destination.  And if you're directly mapping the full =20
> 802.15.4 short address space into the tag space, then you have to be =20=

> more careful about managing the mapping (e.g. make sure short =20
> addresses can be encoded within 14 or 15 bits).  Alternatively, =20
> maybe 16 bits is not enough for what you want to do.  In the end, =20
> I'm not sure we want to explicitly reserve bits for indicating a =20
> service level rather than simply keeping a flat tag namespace.

This is also what I would recommend.

> The use case should define what to do with the bits.
>
> --
> Jonathan Hui
>
> On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
>
>> Hi Pascal,
>>
>> I have first set of proposals concerning the tag/label size and =20
>> content:
>>
>> -          Tag/Label size:
>> o   As 802.15.4-2006 defines addressing modes with 16-bit short =20
>> address and 64-bit extended address for Src and Dest Addressing =20
>> Mode, I think we should have the same flexibility for tag/label =20
>> addressing mode =3D> tag/label should potentially accommodate values =20=

>> represented on a field with a length up to 64 bits.
>> o   Currently, there are ongoing activities to amend MAC Layer for =20=

>> 802.15.4-2006 (TG 4e) that might alter the aforementioned values =20
>> for MAC address size. I will try have some further information =20
>> about MAC Addr Length issue and be back on the mailing list asap.
>>
>> -          Tag/Label contents:
>>
>> -------------------------------------
>> | Control fields | Label Value |
>> -------------------------------------
>>
>> o   Control fields
>> =A7  2 bits to signal labeling/tagging mode:  short/extended labels  =20=

>> =3D> the bit-length of the =93Label Value (LV)=94  field
>> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 =
bits.
>> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map =20=

>> IPv6 priority field into label priority).
>> =A7  Eventually, 1 bit for bottom of the stack flag - for source =20
>> routing;  if set to 1 =3D> the current label/tag is last in the =
stack.
>> =A7  1 or 2 bits RFU.
>> =A7  Eventually, some bits for hop counts (?).
>> o   Label Value (LV) field
>> =A7  The value of the label/tag
>>
>>
>> Thanks.
>>
>> Cheers,
>> Daniel
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>> Behalf Of Pascal Thubert (pthubert)
>> Sent: vendredi 9 avril 2010 10:36
>> To: robert.cragie@gridmerge.com; Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =20
>> SourceRoutingOperations
>>
>> I read this as a consensus to use tags J If anyone disagree please =20=

>> speak up now!
>>
>> There have been plenty iterations/versions of tagging since Frame =20
>> Relay (pure switching), IBM=92s HPR (pure source route), Cisco=92s =
tag =20
>> switching and MPLS. More often than not, a combination of the 2 =20
>> models is used so that tags can be both swapped and stacked.
>>
>> -          In pure switching, there=92s only one tag in the packet. A =
=20
>> tag can be locally significant, in which case it has to be swapped =20=

>> as the packet progresses. For RPL, it means that a node uses as =20
>> many tags as it has children that use it has DAO targets in its =20
>> subdag.
>>
>> -          In the pure source route model, tags are stacked in an =20
>> ordered list that forms a strict routing header. A tag can be =20
>> locally significant to the interpreter and is consumed (marked or =20
>> removed) as the packet progresses. For RPL, it means that a node =20
>> uses as many tags as it has children that use this node as DAO =20
>> parent.
>>
>> It also appears that the 2 tagging models map quite well with the =20
>> DAO models we have in RPL since the split that we decided with =20
>> issue #26. The fact that the combination of the 2 models is =20
>> possible in the real world today gives us a hint that we are not =20
>> closing the door to the mixed model in the future.
>>
>> The next step I wish to agree upon:
>> -          Use locally significant tags which implies tag =20
>> assignment by the node that uses it later and tag swapping for the =20=

>> stateful case.
>> -          Tag distribution in DAO (there are options there that we =20=

>> need to dig further)
>> -          Tag content and size (people have asked for at least 2 =20
>> octets to fit 15.4 short addresses, do we need some control field =20
>> as well?)
>> -          RH format (inherit RH0 fields with labels instead of =20
>> addresses? What about the tag swapping  case, RH as well?)
>>
>> Advice?
>>
>>
>>
>>
>> Pascal
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20
>> Behalf Of Robert Cragie
>> Sent: Thursday, April 08, 2010 11:34 PM
>> To: Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing Header Formatand =20
>> SourceRoutingOperations
>>
>> OK, sounds good. End of topic as far as I am concerned. +1
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>>
>> Hi Robert,
>>
>> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>>
>>
>> A couple of questions:
>>    =95 I presume the source route header using these tags/labels is =20=

>> an IPv6 extension header. What value for extension header type =20
>> would this be? Would we need to specify a LOWPAN_NHC value for this =20=

>> so we can still use LOWPAN_NCH for UDP frames?
>>
>> We already have a draft requesting a new IPv6 Hop-by-Hop Option and =20=

>> presented it at 6man in Anaheim.  The option is designed to carry =20
>> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC =20
>> value for the IPv6 Hop-by-Hop Option header.
>>
>>
>>    =95 Can you point to where the 'core ideas have been deployed in =20=

>> traditional IP networks for quite some time'?
>>
>> MPLS.  Again, I think the mechanisms will need to be adapted, but =20
>> the core ideas are not new.
>>
>> --=20
>> Jonathan Hui
>>
>>
>> Thanks
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>
>>
>>
>> To make the source route header compact, I favor the tag/label =20
>> approach over some other compaction mechanism that operates =20
>> directly on a list of IPv6 addresses.  Tags/labels can be made =20
>> general enough such that they can be derived in different ways.  =20
>> Because the tags/labels have scope local to each node, the =20
>> mechanism is pretty general already.  For those that are already =20
>> managing unique 802.15.4 short addresses across a network, I can =20
>> see that it is attractive to utilize the short address directly and =20=

>> reduce state on devices.  In other cases, it may be best for the =20
>> node to dynamically assign tags/labels for its neighbors.
>>
>> Either way, while the tag/label mechanism is simple, it is far more =20=

>> flexible than an approach to compacting a list of IPv6 addresses.  =20=

>> And note that the idea of using tags/labels is nothing new.  Of =20
>> course we will adapt the basic mechanism a bit (label distribution, =20=

>> headers formats, etc), but the core ideas have been deployed in =20
>> traditional IP networks for quite some time.
>>
>> I reiterated a lot of what was already stated before by others, but =20=

>> that is what I think.
>>
>> --=20
>> Jonathan Hui
>>
>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types. =20
>> Internet 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a =20
>> pure
>> 802.15.4 world with short addresses, becomes a nightmare to define =20=

>> in a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could =20
>> hide a
>> short address of the child - if it cares to do it that way - looks =20=

>> like
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can =20=

>> make
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to =20=

>> store
>> a state with the full information in memory, and then place an =20
>> index of
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
>> L2
>>
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
>> shorter
>>
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
>> though it is
>>
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need =20=

>> to
>> make sure we lose none of that. In particular a RH is recoverable, =20=

>> and
>> it is
>>
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
>> downwards
>>
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> JeongGil Ko (John)
>> Sent: Wednesday, April 07, 2010 10:05 PM
>> To: ROLL WG
>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>> RoutingOperations
>>
>> Hi!
>>
>> Great to see all this discussions on downwards route establishment!
>> To
>>
>> add
>>
>> one more to the conversations here is a proposal for source routing
>> headers.
>>
>> In non-storing mode (where only the root has individual path
>> information)
>>
>> the root will be attaching a source routing header to the data
>> packet
>>
>> that a
>>
>> source node wants to send to a specific destination. We can always
>> make the
>>
>> header super fancy but in my opinion I think we only need two fields
>> in this
>>
>> header and here it is! Feel free to break the stuff and mangle with
>> it
>>
>> so that it
>>
>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>
>> implementations so it does work :)
>>
>> 1. Source Routing Header Format
>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   NEntry (8 bits)   |
>> |
>>
>> +-+-+-+-+-+-+-+-+
>> +
>>
>> |                       Source Route Entry (128*NEntry bits)
>> |
>>
>> +
>> +
>>
>> |
>> |
>>
>>
>>     Figure 1. Proposed Source Routing Header Format; each line is
>> 32
>>
>> bits:)
>>
>>
>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>
>> entry field is carrying.
>>
>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>
>> destination. Here, the address of the node that is one hop away from
>> the
>>
>> *destination* comes first.
>>
>> 2. Source Routing Packet Operations
>>
>> When source routing is initiated at a storing node (e.g., root of
>> the
>>
>> DODAG),
>>
>> the header is attached on the data packet for the entire route
>> (i.e.,
>>
>> from
>>
>> next hop node to the destination). This header is positioned in
>> front
>>
>> of the
>>
>> user payload. When the next hop node receives a packet that is not
>> destined
>>
>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>
>> checks NEntry to find what the next hop is in the source route
>> entry.
>>
>> Since
>>
>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>> terms
>>
>> of hops)
>>
>> order, a node can figure out what the next hop address is with only
>> the
>>
>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>
>> collecting the next hop node's address, the node erases this address
>> element from the entry and decreases NEntry by one. This assures
>> that
>>
>> we
>>
>> avoid the overhead of carrying the entire source route throughout
>> the
>>
>> data
>>
>> path.
>>
>> The approach itself should be very simple and trivial for everyone
>> to
>>
>> follow.
>>
>> So we can start from here and build on!
>>
>> Thanks.
>>
>> -John
>>
>> ------
>> JeongGil Ko (John)
>> Ph.D. Student
>> Department of Computer Science
>> Johns Hopkins University
>> http://www.cs.jhu.edu/~jgko
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jpv@cisco.com  Thu Apr 15 05:53:50 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9581328C14B for ; Thu, 15 Apr 2010 05:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.086
X-Spam-Level: 
X-Spam-Status: No, score=-9.086 tagged_above=-999 required=5 tests=[AWL=1.513,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAvX0d9ODFUT for ; Thu, 15 Apr 2010 05:53:48 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CD8D128C1BA for ; Thu, 15 Apr 2010 05:49:46 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJKoxkurR7Hu/2dsb2JhbACbbnGjdZokglmCNQQ
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="183472275"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2010 12:49:40 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCna4m024854; Thu, 15 Apr 2010 12:49:39 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:49:32 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:49:31 +0200
Message-Id: <02A6AA89-1A00-4A02-8121-D8012EFCF611@cisco.com>
From: JP Vasseur 
To: "Popa, Daniel" 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:49:30 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:49:31.0863 (UTC) FILETIME=[17F72E70:01CADC9A]
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:53:50 -0000

Hi Daniel,

On Apr 9, 2010, at 6:01 PM, Popa, Daniel wrote:

> Hi Jonathan,
>
> Thanks for comments.
>
> Some additional comments between your lines.
>
> Cheers,
> Daniel
>
> -----Original Message-----
> From: Jonathan Hui [mailto:jhui@archrock.com]
> Sent: vendredi 9 avril 2010 17:00
> To: Popa, Daniel
> Cc: Pascal Thubert (pthubert); roll@ietf.org; =
robert.cragie@gridmerge.com
> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand =20
> SourceRoutingOperations
>
>
> Hi Daniel,
>
> Some comments:
>
> - I'm not in favor of having variable sized tags.  It complicates
> processing and state maintenance.  It makes dealing with RH0-style
> headers difficult because it causes you to move large portions of the
> header around when you simply need to perform a label swap.  We should
> pick a fixed size that is reasonable (e.g. 16-bits).  Anything too
> large diminishes a primary reason for having tags - a compact
> identifier for the next hop.
>
> ---
> DP1: Let assume we have X bits for control. The problem with a short =20=

> tag is that it burdens the management of mapping Link Layer =20
> addresses larger 16 bits into a (16-X)-bit field.
> DP2: It will be quite mission impossible to chose the right length =20
> for the "Tag Value" field. And I agree a too large tag decreases the =20=

> reason of having tags.
>
> DP3: I'm not necessarily in favor of having tags with different =20
> sizes within the same network. I'm rather in favor of having the =20
> flexibility to chose the size of the label that meets the network =20
> design objectives. There were discussions about 802.15.4 address =20
> space but there can be many other scenarios that might adopt ROLL, =20
> where the Link Layer addressing is different from 802.15.4 MAC =20
> addressing. So, having the possibility to chose for your network the =20=

> size of the label is a "nice to have" feature.

But supporting multiple PHY/MAC does not imply that you need different =20=

label sizes ?

JP.

> ---
>
>
> - For a source routing header, I'd much rather see something derived
> from the RH0 format.
>
> - For different levels of service, the nice thing with tags is that
> the tag itself can identify not only a destination but also how to get
> there (path, service level, etc.).  That is the primary reason why
> labels are used in traditional IP networks today.  Of course, it means
> that you will have to maintain multiple tags for the same
> destination.
>
> --
> DP: For this reason is nice to have 1 or 2 bits for service level =20
> within the tag, to avoid burdening nodes by maintaining multiple =20
> tags for the same destination.
> --=20
>
> And if you're directly mapping the full 802.15.4 short
> address space into the tag space, then you have to be more careful
> about managing the mapping (e.g. make sure short addresses can be
> encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not
> enough for what you want to do.  In the end, I'm not sure we want to
> explicitly reserve bits for indicating a service level rather than
> simply keeping a flat tag namespace.  The use case should define what
> to do with the bits.
>
> --
> Jonathan Hui
>
> On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
>
>> Hi Pascal,
>>
>> I have first set of proposals concerning the tag/label size and
>> content:
>>
>> -          Tag/Label size:
>> o   As 802.15.4-2006 defines addressing modes with 16-bit short
>> address and 64-bit extended address for Src and Dest Addressing
>> Mode, I think we should have the same flexibility for tag/label
>> addressing mode =3D> tag/label should potentially accommodate values
>> represented on a field with a length up to 64 bits.
>> o   Currently, there are ongoing activities to amend MAC Layer for
>> 802.15.4-2006 (TG 4e) that might alter the aforementioned values for
>> MAC address size. I will try have some further information about MAC
>> Addr Length issue and be back on the mailing list asap.
>>
>> -          Tag/Label contents:
>>
>> -------------------------------------
>> | Control fields | Label Value |
>> -------------------------------------
>>
>> o   Control fields
>> =A7  2 bits to signal labeling/tagging mode:  short/extended labels
>> =3D> the bit-length of the "Label Value (LV)"  field
>> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 =
bits.
>> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map
>> IPv6 priority field into label priority).
>> =A7  Eventually, 1 bit for bottom of the stack flag - for source
>> routing;  if set to 1 =3D> the current label/tag is last in the =
stack.
>> =A7  1 or 2 bits RFU.
>> =A7  Eventually, some bits for hop counts (?).
>> o   Label Value (LV) field
>> =A7  The value of the label/tag
>>
>>
>> Thanks.
>>
>> Cheers,
>> Daniel
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of Pascal Thubert (pthubert)
>> Sent: vendredi 9 avril 2010 10:36
>> To: robert.cragie@gridmerge.com; Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
>> SourceRoutingOperations
>>
>> I read this as a consensus to use tags J If anyone disagree please
>> speak up now!
>>
>> There have been plenty iterations/versions of tagging since Frame
>> Relay (pure switching), IBM's HPR (pure source route), Cisco's tag
>> switching and MPLS. More often than not, a combination of the 2
>> models is used so that tags can be both swapped and stacked.
>>
>> -          In pure switching, there's only one tag in the packet. A
>> tag can be locally significant, in which case it has to be swapped
>> as the packet progresses. For RPL, it means that a node uses as many
>> tags as it has children that use it has DAO targets in its subdag.
>>
>> -          In the pure source route model, tags are stacked in an
>> ordered list that forms a strict routing header. A tag can be
>> locally significant to the interpreter and is consumed (marked or
>> removed) as the packet progresses. For RPL, it means that a node
>> uses as many tags as it has children that use this node as DAO =20
>> parent.
>>
>> It also appears that the 2 tagging models map quite well with the
>> DAO models we have in RPL since the split that we decided with issue
>> #26. The fact that the combination of the 2 models is possible in
>> the real world today gives us a hint that we are not closing the
>> door to the mixed model in the future.
>>
>> The next step I wish to agree upon:
>> -          Use locally significant tags which implies tag assignment
>> by the node that uses it later and tag swapping for the stateful =20
>> case.
>> -          Tag distribution in DAO (there are options there that we
>> need to dig further)
>> -          Tag content and size (people have asked for at least 2
>> octets to fit 15.4 short addresses, do we need some control field as
>> well?)
>> -          RH format (inherit RH0 fields with labels instead of
>> addresses? What about the tag swapping  case, RH as well?)
>>
>> Advice?
>>
>>
>>
>>
>> Pascal
>>
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of Robert Cragie
>> Sent: Thursday, April 08, 2010 11:34 PM
>> To: Jonathan Hui
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] Proposal for Source Routing Header Formatand
>> SourceRoutingOperations
>>
>> OK, sounds good. End of topic as far as I am concerned. +1
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
>>
>> Hi Robert,
>>
>> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
>>
>>
>> A couple of questions:
>>    * I presume the source route header using these tags/labels is
>> an IPv6 extension header. What value for extension header type would
>> this be? Would we need to specify a LOWPAN_NHC value for this so we
>> can still use LOWPAN_NCH for UDP frames?
>>
>> We already have a draft requesting a new IPv6 Hop-by-Hop Option and
>> presented it at 6man in Anaheim.  The option is designed to carry
>> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value
>> for the IPv6 Hop-by-Hop Option header.
>>
>>
>>    * Can you point to where the 'core ideas have been deployed in
>> traditional IP networks for quite some time'?
>>
>> MPLS.  Again, I think the mechanisms will need to be adapted, but
>> the core ideas are not new.
>>
>> --=20
>> Jonathan Hui
>>
>>
>> Thanks
>>
>> Robert
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
>>
>>
>>
>> To make the source route header compact, I favor the tag/label
>> approach over some other compaction mechanism that operates directly
>> on a list of IPv6 addresses.  Tags/labels can be made general enough
>> such that they can be derived in different ways.  Because the tags/
>> labels have scope local to each node, the mechanism is pretty
>> general already.  For those that are already managing unique
>> 802.15.4 short addresses across a network, I can see that it is
>> attractive to utilize the short address directly and reduce state on
>> devices.  In other cases, it may be best for the node to dynamically
>> assign tags/labels for its neighbors.
>>
>> Either way, while the tag/label mechanism is simple, it is far more
>> flexible than an approach to compacting a list of IPv6 addresses.
>> And note that the idea of using tags/labels is nothing new.  Of
>> course we will adapt the basic mechanism a bit (label distribution,
>> headers formats, etc), but the core ideas have been deployed in
>> traditional IP networks for quite some time.
>>
>> I reiterated a lot of what was already stated before by others, but
>> that is what I think.
>>
>> --=20
>> Jonathan Hui
>>
>> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>> Hi Daniel:
>>
>> Routers might have multiple interfaces of multiple MAC types.
>> Internet 0
>> even has a MAC-less format.
>> So the result of you proposal, which looks like a great idea in a =20
>> pure
>> 802.15.4 world with short addresses, becomes a nightmare to define
>> in a
>> fully generic fashion.
>>
>> OTOH, a locally significant opaque tag in which the parent could
>> hide a
>> short address of the child - if it cares to do it that way - looks
>> like
>> a way more acceptable approach
>>
>> So it seems to me that you can get what you want as long as we can
>> make
>> the tag big enough for short addresses. When the tag is too small to
>> contain what the parent really needs, then the parent will have to
>> store
>> a state with the full information in memory, and then place an index
>> of
>> some sort in the tag.
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>> Sent: Thursday, April 08, 2010 11:40 AM
>> To: ROLL WG
>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>> Subject: RE: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi Pascal, John,
>>
>> Since source routing explicitly gives forwarding instruction to each
>> intermediate node, it can make sense to use only (MAC address based)
>> L2
>>
>> forwarding instead of (IPv6 address based) L3 forwarding.
>>
>> This brings two advantages:
>> - avoid processing each transit packets up to L3.
>> - use MAC addresses that - in ROLL environment - have inherently
>> shorter
>>
>> length than an IPv6 address.
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> Pascal Thubert (pthubert)
>> Sent: jeudi 8 avril 2010 11:15
>> To: JeongGil Ko (John); ROLL WG
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Hi John:
>>
>> IPv6 already has a number of routing headers, in particular RH0,
>> though it is
>>
>> being deprecated for general use in the Internet.
>> And there are reasons why the fields in RH0/1 are there and we need =20=

>> to
>> make sure we lose none of that. In particular a RH is recoverable, =20=

>> and
>> it is
>>
>> easy to spot the consumed entries.
>>
>> On top of this our new problems are:
>> - make sure the RH stays within the RPL network (since it is used
>> downwards
>>
>> that should be doable)
>> - control the size (that probably means compress)
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of
>>
>> JeongGil Ko (John)
>> Sent: Wednesday, April 07, 2010 10:05 PM
>> To: ROLL WG
>> Subject: [Roll] Proposal for Source Routing Header Format and Source
>> RoutingOperations
>>
>> Hi!
>>
>> Great to see all this discussions on downwards route establishment!
>> To
>>
>> add
>>
>> one more to the conversations here is a proposal for source routing
>> headers.
>>
>> In non-storing mode (where only the root has individual path
>> information)
>>
>> the root will be attaching a source routing header to the data
>> packet
>>
>> that a
>>
>> source node wants to send to a specific destination. We can always
>> make the
>>
>> header super fancy but in my opinion I think we only need two fields
>> in this
>>
>> header and here it is! Feel free to break the stuff and mangle with
>> it
>>
>> so that it
>>
>> looks great in the specs later on. FYI, this is the format that I am
>> using in my
>>
>> implementations so it does work :)
>>
>> 1. Source Routing Header Format
>>
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   NEntry (8 bits)   |
>> |
>>
>> +-+-+-+-+-+-+-+-+
>> +
>>
>> |                       Source Route Entry (128*NEntry bits)
>> |
>>
>> +
>> +
>>
>> |
>> |
>>
>>
>>     Figure 1. Proposed Source Routing Header Format; each line is
>> 32
>>
>> bits:)
>>
>>
>> - NEntry: Indicates the number of 128 bit addresses that the source
>> route
>>
>> entry field is carrying.
>>
>> - Source Route Entry: List of 128 bit address that consist the route
>> to the
>>
>> destination. Here, the address of the node that is one hop away from
>> the
>>
>> *destination* comes first.
>>
>> 2. Source Routing Packet Operations
>>
>> When source routing is initiated at a storing node (e.g., root of
>> the
>>
>> DODAG),
>>
>> the header is attached on the data packet for the entire route
>> (i.e.,
>>
>> from
>>
>> next hop node to the destination). This header is positioned in
>> front
>>
>> of the
>>
>> user payload. When the next hop node receives a packet that is not
>> destined
>>
>> to itself AND the network is NOT provisioned to be in 'storing mode'
>> then it
>>
>> checks NEntry to find what the next hop is in the source route
>> entry.
>>
>> Since
>>
>> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>> terms
>>
>> of hops)
>>
>> order, a node can figure out what the next hop address is with only
>> the
>>
>> NEntry value (since it already knows how big an ipv6 address is).
>> After
>>
>> collecting the next hop node's address, the node erases this address
>> element from the entry and decreases NEntry by one. This assures
>> that
>>
>> we
>>
>> avoid the overhead of carrying the entire source route throughout
>> the
>>
>> data
>>
>> path.
>>
>> The approach itself should be very simple and trivial for everyone
>> to
>>
>> follow.
>>
>> So we can start from here and build on!
>>
>> Thanks.
>>
>> -John
>>
>> ------
>> JeongGil Ko (John)
>> Ph.D. Student
>> Department of Computer Science
>> Johns Hopkins University
>> http://www.cs.jhu.edu/~jgko
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From richard.kelsey@ember.com  Thu Apr 15 05:54:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF8028C1CF for ; Thu, 15 Apr 2010 05:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.763
X-Spam-Level: 
X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IExdVsMYz+MI for ; Thu, 15 Apr 2010 05:54:41 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3C3753A6BA5 for ; Thu, 15 Apr 2010 05:50:59 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 08:53:57 -0400
Date: Thu, 15 Apr 2010 08:48:52 -0400
Message-Id: <87r5mg285n.fsf@kelsey-ws.hq.ember.com>
To: JP Vasseur 
In-reply-to: <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com> (message from JP Vasseur on Thu, 15 Apr 2010 11:10:04 +0200)
From: Richard Kelsey 
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>  <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com>
X-OriginalArrivalTime: 15 Apr 2010 12:53:57.0435 (UTC) FILETIME=[B64240B0:01CADC9A]
Cc: roll@ietf.org
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 12:54:42 -0000

> From: JP Vasseur 
> Date: Thu, 15 Apr 2010 11:10:04 +0200
>
> Yes, we may have OF where specific handling of the metrics
> are required and must then be part of the OF itself. For
> many other ones, we could certainly use a generic OF and
> leave the metric out of it, relying on the semantic
> defined in the metric ID. We're in sync.

Well, I'm not entirely in sync :-).

I completely agree that we should define at least one
generic OF that does not depend on the details of the
metrics in use.

Where I disagree is with metric containers needing to
describe the properties of the metrics (additive, etc.).
For a node to make use of an OF and associated metrics, it
has to implement both the OF and the metrics.  While the OF
might be able to get away with only knowing that a metric is
additive, implementing the metric requires knowing what it
is.  To participate in a DODAG that uses ETX, for example, a
node has to know how to calculate ETX.  It doesn't seem like
a stretch for the node to also know that ETX is additive.

                              -Richard Kelsey

From jpv@cisco.com  Thu Apr 15 06:00:57 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C41E28C18F for ; Thu, 15 Apr 2010 06:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.162
X-Spam-Level: 
X-Spam-Status: No, score=-9.162 tagged_above=-999 required=5 tests=[AWL=1.437,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tcAcoCbRbiP for ; Thu, 15 Apr 2010 06:00:56 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1391028C0E8 for ; Thu, 15 Apr 2010 06:00:01 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOqqxkurR7Hu/2dsb2JhbACbbnGjcpolgm4IghgE
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="183479698"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2010 12:59:54 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCxg8P003518; Thu, 15 Apr 2010 12:59:54 GMT
Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:59:52 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 14:59:52 +0200
Message-Id: 
From: JP Vasseur 
To: Richard Kelsey 
In-Reply-To: <87r5mg285n.fsf@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 14:59:48 +0200
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>  <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com> <87r5mg285n.fsf@kelsey-ws.hq.ember.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 12:59:52.0318 (UTC) FILETIME=[89C919E0:01CADC9B]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17320.004
X-TM-AS-Result: No--18.184200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Cc: roll@ietf.org
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 13:00:57 -0000

On Apr 15, 2010, at 2:48 PM, Richard Kelsey wrote:

>> From: JP Vasseur 
>> Date: Thu, 15 Apr 2010 11:10:04 +0200
>>
>> Yes, we may have OF where specific handling of the metrics
>> are required and must then be part of the OF itself. For
>> many other ones, we could certainly use a generic OF and
>> leave the metric out of it, relying on the semantic
>> defined in the metric ID. We're in sync.
>
> Well, I'm not entirely in sync :-).
>
> I completely agree that we should define at least one
> generic OF that does not depend on the details of the
> metrics in use.

OK.

>
> Where I disagree is with metric containers needing to
> describe the properties of the metrics (additive, etc.).
> For a node to make use of an OF and associated metrics, it
> has to implement both the OF and the metrics.  While the OF
> might be able to get away with only knowing that a metric is
> additive, implementing the metric requires knowing what it
> is.

There are several reson that I think are strongly advocating for  
decoupling
the metrics from the OF:
1) The number of OFs that we would have to define considering the number
of potential combinations of {metrics,constraints}
2) That provides much more flexibility ... for example, you may want  
to define
a simple OF and let the root choose (or even dynamically adapt the  
metrics
and constraints to take into account). For the sale of illustration,  
the root may
receive for feed-back suggesting to relax a constraint "on the fly",  
which could
be done without having to support multiple OF on the node.

> To participate in a DODAG that uses ETX, for example, a
> node has to know how to calculate ETX.  It doesn't seem like
> a stretch for the node to also know that ETX is additive.
>
>                              -Richard Kelsey


From jpv@cisco.com  Thu Apr 15 06:01:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4972728C194 for ; Thu, 15 Apr 2010 06:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.23
X-Spam-Level: 
X-Spam-Status: No, score=-9.23 tagged_above=-999 required=5 tests=[AWL=1.368,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkEQMRZHiotr for ; Thu, 15 Apr 2010 06:01:22 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 449F928C1A1 for ; Thu, 15 Apr 2010 06:00:41 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQCAOqqxkuQ/uCWe2dsb2JhbACBPpowFQEBCwsiBhyjcpolhQ4E
X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208,217";a="59449051"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2010 13:00:33 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FD0Xca003018; Thu, 15 Apr 2010 13:00:33 GMT
Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 15:00:32 +0200
Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 15 Apr 2010 15:00:30 +0200
Message-Id: 
From: JP Vasseur 
To: 
In-Reply-To: <00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-147-971454196
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 15 Apr 2010 15:00:30 +0200
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net> <3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com> <00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 15 Apr 2010 13:00:30.0615 (UTC) FILETIME=[A09CC270:01CADC9B]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17320.004
X-TM-AS-Result: No--56.651400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader	Format	and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 13:01:30 -0000

--Apple-Mail-147-971454196
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Also my reading (again, co-chair hat off).

On Apr 15, 2010, at 2:48 PM, Don Sturek wrote:

> Hi Pascal,
>
> I believe what you wrote below was the majority view on the reflector.
>
> Don
>
>
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Thursday, April 15, 2010 5:35 AM
> To: JP Vasseur; d.sturek@att.net
> Cc: roll@ietf.org
> Subject: RE: [Roll] Proposal for Source RoutingHeader Format and =20
> SourceRoutingOperations
>
> Hi JP and all;
>
> I=92m not fully clear what the WG group really wants to do at this =20
> point. I sensed an agreement to endorse something very close to IPv6 =20=

> RH0 in the core spec, and provide a separate spec that would enable =20=

> labels in the Source route DAO and the hop by hop header.
>
> Is that a honest reading of the mailing list?
>
> Pascal
>
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of JP Vasseur
> Sent: Thursday, April 15, 2010 2:26 PM
> To: d.sturek@att.net
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source RoutingHeader Format and =20
> SourceRoutingOperations
>
> Hi Don,
>
> On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:
>
>
> I think the issue is this:
> 1)       ROLL cannot meet its charter without source routing
>
> Absolutely.
>
>
> 2)       Claiming the feature is now to be addressed in 6LowPAN =20
> seems a bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE =20
> 802.15.4.
>
> You are absolutely right. IPHC is 15.4 specific. This is why the =20
> idea of using a Label a la MPLS would be an interesting approach =20
> IMO. The labe could be locall significant using DAO as a label =20
> distribution mechanism. Completely link layer agnostic.
>
> JP.
>
>
> How are those addressed?
>
> Don
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
> Sent: Thursday, April 08, 2010 7:52 AM
> To: d.sturek@att.net
> Cc: daniel.gavelle@jennic.com; roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and =20
> SourceRoutingOperations
>
> Hi Don,
>
> It's not so much that 6lowpan is concerning itself with source =20
> routing, it is concerning itself with efficient header compression, =20=

> which would include IPv6 extension headers such as RH0. Whatever =20
> ends up getting used for source routing needs to be some sort of =20
> IPv6 extension header. Source routing for IPv6 would naturally =20
> contain IPv6 addresses. The question is whether we want to invent =20
> some new extension header specifically for ROLL which uses something =20=

> other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme =20
> mentioned.
>
> I agree, ROLL must accommodate source routing one way or another.
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
> On 08/04/2010 2:35 PM, Don Sturek wrote:
> I can't see why 6LowPAN (and specifically the HC draft) would =20
> concern itself
> with source routing.
>
> Surely source routing is a concern of ROLL (and not 6LowPAN).
>
> I don't see how ROLL completes its charter or addresses its =20
> requirements
> without adding source routing.
>
> Don
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20=

> Of
> Daniel Gavelle
> Sent: Thursday, April 08, 2010 6:12 AM
> To: robert.cragie@gridmerge.com
> Cc: roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Rob,
>
> I agree that the source routing for the data frames should be done as
> part of the 6LowPAN HC.  This already has a stateful IPV6 address
> compression based on contexts.  It should be possible to compress the
> addresses down to two bytes per address if IPv6 addresses are derived
> from the 16 bit short address are being used in the LowPAN.
>
> We don't want to hold up the current HC draft that is going through =20=

> last
> call but the work could be done as a new RFC / amendment.  Source
> routing compression may need a fix for the problem of HC compression
> extending beyond the first fragment.
>
> Doing the work in the 6LowPAN group means that the compression can
> easily be used for any source routing protocol, not just ROLL.  It =20
> could
> be done as a compression for the existing R0 routing header.  Maybe =20=

> this
> thread needs moving to the 6LowPAN reflector.
>
> Daniel.
>
>
> Robert Cragie wrote:
>
> Hi Pascal,
>
> Source routing should of course use the IPv6 addresses which means a =20=

> lot
> of overhead for certain underlying link layers, e.g. 802.15.4. I think
> it is generally cleaner to do the compression at a layer which may
> require it only, e.g. define it in the 6lowpan HC. This is then free =20=

> to
> some extent to specify how the compression is done. Although I doubt
> this would go down well in the 6lowpan WG...
>
> The tag scheme would work but it specifically scopes the source =20
> routing
> to nodes which operate the scheme. This is probably acceptable
> practically but doesn't 'smell right' somehow.
>
> With regard to the original proposal: it is probably necessary to =20
> carry
> the full source route all the way to at least the penultimate node and
> use an index to show the current position in the route for potential
> backtrace and error reporting back along the same route (assuming link
> symmetry). This is how RH0 works.
>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com 
>
>
> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>
> Hi Daniel:
>
> Routers might have multiple interfaces of multiple MAC types. =20
> Internet 0
> even has a MAC-less format.
> So the result of you proposal, which looks like a great idea in a pure
> 802.15.4 world with short addresses, becomes a nightmare to define =20
> in a
> fully generic fashion.
>
> OTOH, a locally significant opaque tag in which the parent could =20
> hide a
> short address of the child - if it cares to do it that way - looks =20
> like
> a way more acceptable approach
>
> So it seems to me that you can get what you want as long as we can =20
> make
> the tag big enough for short addresses. When the tag is too small to
> contain what the parent really needs, then the parent will have to =20
> store
> a state with the full information in memory, and then place an index =20=

> of
> some sort in the tag.
>
> What do you think?
>
> Pascal
>
>
>
>
> -----Original Message-----
> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
> Sent: Thursday, April 08, 2010 11:40 AM
> To: ROLL WG
> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi Pascal, John,
>
> Since source routing explicitly gives forwarding instruction to each
> intermediate node, it can make sense to use only (MAC address based)
>
>
> L2
>
>
> forwarding instead of (IPv6 address based) L3 forwarding.
>
> This brings two advantages:
>  - avoid processing each transit packets up to L3.
>  - use MAC addresses that - in ROLL environment - have inherently
>
>
> shorter
>
>
> length than an IPv6 address.
>
> Cheers,
> Daniel
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>
>
> Of
>
>
> Pascal Thubert (pthubert)
> Sent: jeudi 8 avril 2010 11:15
> To: JeongGil Ko (John); ROLL WG
> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
>
> Hi John:
>
> IPv6 already has a number of routing headers, in particular RH0,
>
>
> though it is
>
>
> being deprecated for general use in the Internet.
> And there are reasons why the fields in RH0/1 are there and we need to
> make sure we lose none of that. In particular a RH is recoverable, and
>
>
> it is
>
>
> easy to spot the consumed entries.
>
> On top of this our new problems are:
> - make sure the RH stays within the RPL network (since it is used
>
>
> downwards
>
>
> that should be doable)
> - control the size (that probably means compress)
>
> Cheers,
>
> Pascal
>
>
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>
>
> Of
>
>
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
>
> Hi!
>
> Great to see all this discussions on downwards route establishment!
>
>
> To
>
>
> add
>
>
> one more to the conversations here is a proposal for source routing
>
>
> headers.
>
>
> In non-storing mode (where only the root has individual path
>
>
> information)
>
>
> the root will be attaching a source routing header to the data
>
>
> packet
>
>
> that a
>
>
> source node wants to send to a specific destination. We can always
>
>
> make the
>
>
> header super fancy but in my opinion I think we only need two fields
>
>
> in this
>
>
> header and here it is! Feel free to break the stuff and mangle with
>
>
> it
>
>
> so that it
>
>
> looks great in the specs later on. FYI, this is the format that I am
>
>
> using in my
>
>
> implementations so it does work :)
>
> 1. Source Routing Header Format
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   NEntry (8 bits)   |
>
>
> |
>
>
> +-+-+-+-+-+-+-+-+
>
>
> +
>
>
> |                       Source Route Entry (128*NEntry bits)
>
>
> |
>
>
> +
>
>
> +
>
>
> |
>
>
> |
>
>
>       Figure 1. Proposed Source Routing Header Format; each line is
>
>
> 32
>
>
> bits:)
>
>
> - NEntry: Indicates the number of 128 bit addresses that the source
>
>
> route
>
>
> entry field is carrying.
>
> - Source Route Entry: List of 128 bit address that consist the route
>
>
> to the
>
>
> destination. Here, the address of the node that is one hop away from
>
>
> the
>
>
> *destination* comes first.
>
> 2. Source Routing Packet Operations
>
> When source routing is initiated at a storing node (e.g., root of
>
>
> the
>
>
> DODAG),
>
>
> the header is attached on the data packet for the entire route
>
>
> (i.e.,
>
>
> from
>
>
> next hop node to the destination). This header is positioned in
>
>
> front
>
>
> of the
>
>
> user payload. When the next hop node receives a packet that is not
>
>
> destined
>
>
> to itself AND the network is NOT provisioned to be in 'storing mode'
>
>
> then it
>
>
> checks NEntry to find what the next hop is in the source route
>
>
> entry.
>
>
> Since
>
>
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
>
>
> terms
>
>
> of hops)
>
>
> order, a node can figure out what the next hop address is with only
>
>
> the
>
>
> NEntry value (since it already knows how big an ipv6 address is).
>
>
> After
>
>
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures
>
>
> that
>
>
> we
>
>
> avoid the overhead of carrying the entire source route throughout
>
>
> the
>
>
> data
>
>
> path.
>
> The approach itself should be very simple and trivial for everyone
>
>
> to
>
>
> follow.
>
>
> So we can start from here and build on!
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko (John)
> Ph.D. Student
> Department of Computer Science
> Johns Hopkins University
> http://www.cs.jhu.edu/~jgko
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
> =
------------------------------------------------------------------------
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>


--Apple-Mail-147-971454196
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

Also my reading (again, =
co-chair hat off).

    On Apr 15, 2010, at 2:48 PM, Don =
Sturek wrote:

    Hi Pascal,
    I believe what you wrote below was the majority view =
on the reflector.
     
    Don
     
     Pascal =
Thubert (pthubert) [mailto:pthubert@cisco.com] 
    Sent: Thursday, April 15, 2010 =
5:35 AM
    To: JP=
 Vasseur; d.sturek@att.net
    Cc: roll@ietf.org
    Subject: RE: [Roll] Proposal for =
Source RoutingHeader Format and =
SourceRoutingOperations
     
    Hi JP and all;
    I=92m not fully clear what the WG group really wants =
to do at this point. I sensed an agreement to endorse something very =
close to IPv6 RH0 in the core spec, and provide a separate spec that =
would enable labels in the Source route DAO and the hop by hop =
header.
     
    Is that a honest reading of the =
mailing list?
     
     
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP =
Vasseur
    Sent: Thursday, April 15, 2010 =
2:26 PM
    To: d.sturek@att.net
    Cc: roll@ietf.org
    Subject: Re: [Roll] Proposal for =
Source RoutingHeader Format and =
SourceRoutingOperations
     
    Hi =
Don,
     
    On Apr 8, 2010, at 4:59 PM, Don Sturek =
wrote:
    I think the issue is this:
      ROLL cannot meet its charter without source =
routing 
     
      Claiming the feature is now to be addressed in =
6LowPAN seems a bit wrong.  ROLL has as its scope MAC/PHYs other =
than IEEE 802.15.4.  
    You are absolutely =
right. IPHC is 15.4 specific. This is why the idea of using a Label a la =
MPLS would be an interesting approach IMO. The labe could be locall =
significant using DAO as a label distribution mechanism. Completely link =
layer agnostic.
    How are =
those addressed? Don  
    From:Robert Cragie [ 
    Sent: Thursday, April 08, 2010 =
7:52 AM
    To: d.sturek@att.net
    Cc: daniel.gavelle@jennic.com; roll@ietf.org
    Subject: Re: [Roll] Proposal for =
Source Routing Header Format and SourceRoutingOperations    Hi Don,

    It's not so much that 6lowpan is concerning =
itself with source routing, it is concerning itself with efficient =
header compression, which would include IPv6 extension headers such =
as RH0. Whatever ends up getting =
used for source routing needs to be some sort of IPv6 extension header. =
Source routing for IPv6 would naturally contain IPv6 addresses. The =
question is whether we want to invent some new extension header =
specifically for ROLL which uses something other (i.e. smaller) than =
IPv6 addresses, e.g. the tag scheme mentioned.

    I agree, ROLL must =
accommodate source routing one way or =
another.

    Robert
    Robert Cragie (Pacific Gas & =
Electric)
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888

    On 08/04/2010 2:35 PM, =
Don Sturek wrote:
    I can't see why 6LowPAN (and specifically the HC draft) would =
concern itself
    with =
source routing.
    I =
don't see how ROLL completes its charter or addresses its =
requirements
     
    Don
     
     
    -----Original =
Message-----
    From: =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
    Sent: =
Thursday, April 08, 2010 6:12 AM
    To: Cc: Subject: Re: [Roll] Proposal for Source Routing Header Format =
and
     
    I =
agree that the source routing for the data frames should be done as =

    part of the =
6LowPAN HC.  This already has a stateful IPV6 address =

    compression =
based on contexts.  It should be possible to compress the =

    addresses =
down to two bytes per address if IPv6 addresses are derived =

    from the 16 =
bit short address are being used in the =
LowPAN.
    We =
don't want to hold up the current HC draft that is going through last =

    call but =
the work could be done as a new RFC / amendment.  Source =

    routing =
compression may need a fix for the problem of HC compression =

    extending =
beyond the first fragment.
     
    Doing the work in the 6LowPAN group means that =
the compression can 
    easily be used for any source routing protocol, not just =
ROLL.  It could 
    be done as a compression for the existing R0 routing =
header.  Maybe this 
    thread needs moving to the 6LowPAN =
reflector.
      
    Hi =
Pascal,
    of overhead =
for certain underlying link layers, e.g. 802.15.4. I think =

    it is =
generally cleaner to do the compression at a layer which may =

    require it =
only, e.g. define it in the 6lowpan HC. This is then free to =

    some extent =
to specify how the compression is done. Although I doubt =

    this would =
go down well in the 6lowpan WG...
     
    The tag scheme would work but it specifically =
scopes the source routing 
    to nodes which operate the scheme. This is =
probably acceptable 
    practically but doesn't 'smell right' =
somehow.
    With =
regard to the original proposal: it is probably necessary to carry =

    the full =
source route all the way to at least the penultimate node and =

    use an =
index to show the current position in the route for potential =

    backtrace =
and error reporting back along the same route (assuming link =

    symmetry). =
This is how RH0 works.
     
     
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    +44 (0) 1924 910888
     
     
    On 08/04/2010 10:57 AM, Pascal Thubert =
(pthubert) wrote:
    Hi Daniel:
     
    even has a =
MAC-less format.
    So =
the result of you proposal, which looks like a great idea in a =
pure
    802.15.4 =
world with short addresses, becomes a nightmare to define in =
a
    fully =
generic fashion.
    OTOH, =
a locally significant opaque tag in which the parent could hide =
a
    short =
address of the child - if it cares to do it that way - looks =
like
    a way more =
acceptable approach
     
    So it =
seems to me that you can get what you want as long as we can =
make
    the tag big =
enough for short addresses. When the tag is too small =
to
    contain =
what the parent really needs, then the parent will have to =
store
    a =
state with the full information in memory, and then place an index =
of
    some sort =
in the tag.
    What =
do you think?
    -----Original Message-----
    From: Popa, Daniel [Sent: Thursday, April 08, 2010 11:40 =
AM
    To: ROLL =
WG
    Cc: Pascal =
Thubert (pthubert); JeongGil Ko (John)
    Subject: RE: [Roll] Proposal for Source Routing =
Header Format and
     
    Hi =
Pascal, John,
    Since =
source routing explicitly gives forwarding instruction to =
each
      =

    forwarding instead of (IPv6 address based) L3 =
forwarding.
    This =
brings two advantages:
     - avoid processing each transit packets up to =
L3.
     - use MAC =
addresses that - in ROLL environment - have =
inherently
    length than an IPv6 address.
     
    Cheers,
    Daniel
     
     
     
    -----Original =
Message-----
    From: =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
      =

    Pascal Thubert (pthubert)
    Sent: jeudi 8 avril 2010 =
11:15
    To: =
JeongGil Ko (John); ROLL WG
    Subject: Re: [Roll] Proposal for Source Routing =
Header Format and
     
    Hi =
John:
    IPv6 =
already has a number of routing headers, in particular =
RH0,
    though it =
is
      =

    being deprecated for general use in the =
Internet.
    And =
there are reasons why the fields in RH0/1 are there and we need =
to
    make sure =
we lose none of that. In particular a RH is recoverable, =
and
    it =
is
      =

    easy to spot the consumed entries.
     
    On top of this our new problems =
are:
    - make sure =
the RH stays within the RPL network (since it is =
used
    that should be doable)
    - control the size (that probably means =
compress)
    -----Original =
Message-----
    From: =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
    JeongGil Ko (John)
    Sent: Wednesday, April 07, 2010 10:05 =
PM
    To: ROLL =
WG
    Subject: =
[Roll] Proposal for Source Routing Header Format and =
Source
     
    Great =
to see all this discussions on downwards route =
establishment!
      =

    add
    one more to the conversations here is a =
proposal for source routing
          =

    In non-storing mode (where only the root has =
individual path
    the root will be attaching a source routing =
header to the data
    that a
    source node wants to send to a specific =
destination. We can always
          =

    make =
the
    header super fancy but in my opinion I think we =
only need two fields
          
    in =
this
    header and here it is! Feel free to break the =
stuff and mangle with
          
      =

    so that it
        
    looks great in the specs later on. FYI, this is =
the format that I am
          
    using in =
my
    implementations so it does work =
:)
    1. =
Source Routing Header Format
     
    |   NEntry (8 =
bits)   |
          
    +-+-+-+-+-+-+-+-+
          =

          =

    +
          =

    |
          =

          Figure 1. =
Proposed Source Routing Header Format; each line =
is
      =

    bits:)
    - NEntry: Indicates the number of 128 bit =
addresses that the source
          
    entry field is =
carrying.
    - =
Source Route Entry: List of 128 bit address that consist the =
route
    to =
the
    destination. Here, the address of the node that =
is one hop away from
          
    *destination* comes =
first.
    2. =
Source Routing Packet Operations
     
    When source routing is initiated at a storing =
node (e.g., root of
          
    DODAG),
    the header is attached on the data packet for =
the entire route
    from
    next hop node to the destination). This header =
is positioned in
    of the
    user payload. When the next hop node receives a =
packet that is not
    to itself AND the network is NOT provisioned to =
be in 'storing mode'
          
    then =
it
    checks NEntry to find what the next hop is in =
the source route
    Since
    the 'Source Route Entry' is ordered in =
'farthest -> closest' (in
          =

    of hops)
    order, a node can figure out what the next hop =
address is with only
          
    NEntry value (since it already knows how big an =
ipv6 address is).
    collecting the next hop node's address, the =
node erases this address
    element from the entry and decreases NEntry by one. This =
assures
    we
    avoid the overhead of carrying the entire =
source route throughout
          
    data
    path.
     
    The approach itself should be very simple and =
trivial for everyone
          
      =

    follow.
    So we can start from here and build =
on!
    Ph.D. Student
    Department of Computer Science
    Johns Hopkins =
University
     
    Roll mailing =
list
    Roll@ietf.org
          =

    Roll mailing =
list
    Roll@ietf.org
        
    Roll mailing =
list
    Roll@ietf.org
     
      
     
    Roll mailing =
list
    Roll@ietf.org
        =

    _______________________________________________
    Roll mailing =
list
    Roll@ietf.org
     which could
> be done without having to support multiple OF on the node.

JP,

I agree with everything you say here.  But none of it
requires that metric containers be self-describing.  Yes,
there needs to be a separation between metrics and the OF.
That interface does not need to be reflected in the packets.
The OF and metric implementations live in the same layer on
the same node.  They do not need to use IP to communicate.

                           -Richard Kelsey

From Daniel.Popa@itron.com  Thu Apr 15 06:42:24 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB7E3A6A0C for ; Thu, 15 Apr 2010 06:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlGECpvT2SnL for ; Thu, 15 Apr 2010 06:42:21 -0700 (PDT)
Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 892F43A6782 for ; Thu, 15 Apr 2010 06:42:21 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Apr 2010 09:42:13 -0400
Message-ID: 
In-Reply-To: <02A6AA89-1A00-4A02-8121-D8012EFCF611@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
Thread-Index: AcrcmiD+hguefELTS/qkj4YXWXxbAwABKr9A
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com><7209B835-138E-43CF-B920-CBDDD3C221F0@archrock.com><4BBE453E.7070508@gridmerge.com><4BBE4BDB.5070901@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD77F@XMB-AMS-107.cisco.com>  <88C9A030-714A-4E10-9651-0B2A67ED2814@archrock.com>  <02A6AA89-1A00-4A02-8121-D8012EFCF611@cisco.com>
From: "Popa, Daniel" 
To: "JP Vasseur" 
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 13:42:24 -0000

Hi JP,=20

> -----Original Message-----
> From: JP Vasseur [mailto:jpv@cisco.com]
> Sent: Thursday, April 15, 2010 2:50 PM
> To: Popa, Daniel
> Cc: Jonathan Hui; roll@ietf.org
> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
> SourceRoutingOperations
>=20
> Hi Daniel,
>=20
> On Apr 9, 2010, at 6:01 PM, Popa, Daniel wrote:
>=20
> > Hi Jonathan,
> >
> > Thanks for comments.
> >
> > Some additional comments between your lines.
> >
> > Cheers,
> > Daniel
> >
> > -----Original Message-----
> > From: Jonathan Hui [mailto:jhui@archrock.com]
> > Sent: vendredi 9 avril 2010 17:00
> > To: Popa, Daniel
> > Cc: Pascal Thubert (pthubert); roll@ietf.org;
> robert.cragie@gridmerge.com
> > Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
> > SourceRoutingOperations
> >
> >
> > Hi Daniel,
> >
> > Some comments:
> >
> > - I'm not in favor of having variable sized tags.  It complicates
> > processing and state maintenance.  It makes dealing with RH0-style
> > headers difficult because it causes you to move large portions of =
the
> > header around when you simply need to perform a label swap.  We
> should
> > pick a fixed size that is reasonable (e.g. 16-bits).  Anything too
> > large diminishes a primary reason for having tags - a compact
> > identifier for the next hop.
> >
> > ---
> > DP1: Let assume we have X bits for control. The problem with a short
> > tag is that it burdens the management of mapping Link Layer
> > addresses larger 16 bits into a (16-X)-bit field.
> > DP2: It will be quite mission impossible to chose the right length
> > for the "Tag Value" field. And I agree a too large tag decreases the
> > reason of having tags.
> >
> > DP3: I'm not necessarily in favor of having tags with different
> > sizes within the same network. I'm rather in favor of having the
> > flexibility to chose the size of the label that meets the network
> > design objectives. There were discussions about 802.15.4 address
> > space but there can be many other scenarios that might adopt ROLL,
> > where the Link Layer addressing is different from 802.15.4 MAC
> > addressing. So, having the possibility to chose for your network the
> > size of the label is a "nice to have" feature.
>=20
> But supporting multiple PHY/MAC does not imply that you need different
> label sizes ?
>=20
> JP.

[] You are right: My proposal is to have the possibility to define a =
scope for the label/tag and choose its size as a function of its scope =
(global, local, site, etc) and network design objectives. It makes =
tagging/labeling more powerful when mapping different Link Layer =
addressing scheme into label/tags.=20

 Daniel

>=20
> > ---
> >
> >
> > - For a source routing header, I'd much rather see something derived
> > from the RH0 format.
> >
> > - For different levels of service, the nice thing with tags is that
> > the tag itself can identify not only a destination but also how to
> get
> > there (path, service level, etc.).  That is the primary reason why
> > labels are used in traditional IP networks today.  Of course, it
> means
> > that you will have to maintain multiple tags for the same
> > destination.
> >
> > --
> > DP: For this reason is nice to have 1 or 2 bits for service level
> > within the tag, to avoid burdening nodes by maintaining multiple
> > tags for the same destination.
> > --
> >
> > And if you're directly mapping the full 802.15.4 short
> > address space into the tag space, then you have to be more careful
> > about managing the mapping (e.g. make sure short addresses can be
> > encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not
> > enough for what you want to do.  In the end, I'm not sure we want to
> > explicitly reserve bits for indicating a service level rather than
> > simply keeping a flat tag namespace.  The use case should define =
what
> > to do with the bits.
> >
> > --
> > Jonathan Hui
> >
> > On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:
> >
> >> Hi Pascal,
> >>
> >> I have first set of proposals concerning the tag/label size and
> >> content:
> >>
> >> -          Tag/Label size:
> >> o   As 802.15.4-2006 defines addressing modes with 16-bit short
> >> address and 64-bit extended address for Src and Dest Addressing
> >> Mode, I think we should have the same flexibility for tag/label
> >> addressing mode =3D> tag/label should potentially accommodate =
values
> >> represented on a field with a length up to 64 bits.
> >> o   Currently, there are ongoing activities to amend MAC Layer for
> >> 802.15.4-2006 (TG 4e) that might alter the aforementioned values =
for
> >> MAC address size. I will try have some further information about =
MAC
> >> Addr Length issue and be back on the mailing list asap.
> >>
> >> -          Tag/Label contents:
> >>
> >> -------------------------------------
> >> | Control fields | Label Value |
> >> -------------------------------------
> >>
> >> o   Control fields
> >> =A7  2 bits to signal labeling/tagging mode:  short/extended labels
> >> =3D> the bit-length of the "Label Value (LV)"  field
> >> =B7         2 bits =3D> 4 modes for LV length : 8, 16, 32 and 64 =
bits.
> >> =A7  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map
> >> IPv6 priority field into label priority).
> >> =A7  Eventually, 1 bit for bottom of the stack flag - for source
> >> routing;  if set to 1 =3D> the current label/tag is last in the =
stack.
> >> =A7  1 or 2 bits RFU.
> >> =A7  Eventually, some bits for hop counts (?).
> >> o   Label Value (LV) field
> >> =A7  The value of the label/tag
> >>
> >>
> >> Thanks.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
> >> Of Pascal Thubert (pthubert)
> >> Sent: vendredi 9 avril 2010 10:36
> >> To: robert.cragie@gridmerge.com; Jonathan Hui
> >> Cc: roll@ietf.org
> >> Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
> >> SourceRoutingOperations
> >>
> >> I read this as a consensus to use tags J If anyone disagree please
> >> speak up now!
> >>
> >> There have been plenty iterations/versions of tagging since Frame
> >> Relay (pure switching), IBM's HPR (pure source route), Cisco's tag
> >> switching and MPLS. More often than not, a combination of the 2
> >> models is used so that tags can be both swapped and stacked.
> >>
> >> -          In pure switching, there's only one tag in the packet. A
> >> tag can be locally significant, in which case it has to be swapped
> >> as the packet progresses. For RPL, it means that a node uses as =
many
> >> tags as it has children that use it has DAO targets in its subdag.
> >>
> >> -          In the pure source route model, tags are stacked in an
> >> ordered list that forms a strict routing header. A tag can be
> >> locally significant to the interpreter and is consumed (marked or
> >> removed) as the packet progresses. For RPL, it means that a node
> >> uses as many tags as it has children that use this node as DAO
> >> parent.
> >>
> >> It also appears that the 2 tagging models map quite well with the
> >> DAO models we have in RPL since the split that we decided with =
issue
> >> #26. The fact that the combination of the 2 models is possible in
> >> the real world today gives us a hint that we are not closing the
> >> door to the mixed model in the future.
> >>
> >> The next step I wish to agree upon:
> >> -          Use locally significant tags which implies tag =
assignment
> >> by the node that uses it later and tag swapping for the stateful
> >> case.
> >> -          Tag distribution in DAO (there are options there that we
> >> need to dig further)
> >> -          Tag content and size (people have asked for at least 2
> >> octets to fit 15.4 short addresses, do we need some control field =
as
> >> well?)
> >> -          RH format (inherit RH0 fields with labels instead of
> >> addresses? What about the tag swapping  case, RH as well?)
> >>
> >> Advice?
> >>
> >>
> >>
> >>
> >> Pascal
> >>
> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
> >> Of Robert Cragie
> >> Sent: Thursday, April 08, 2010 11:34 PM
> >> To: Jonathan Hui
> >> Cc: roll@ietf.org
> >> Subject: Re: [Roll] Proposal for Source Routing Header Formatand
> >> SourceRoutingOperations
> >>
> >> OK, sounds good. End of topic as far as I am concerned. +1
> >>
> >> Robert
> >> Robert Cragie (Pacific Gas & Electric)
> >>
> >> Gridmerge Ltd.
> >> 89 Greenfield Crescent,
> >> Wakefield, WF4 4WA, UK
> >> +44 (0) 1924 910888
> >> http://www.gridmerge.com
> >>
> >>
> >> On 08/04/2010 10:17 PM, Jonathan Hui wrote:
> >>
> >> Hi Robert,
> >>
> >> On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:
> >>
> >>
> >> A couple of questions:
> >>    * I presume the source route header using these tags/labels is
> >> an IPv6 extension header. What value for extension header type =
would
> >> this be? Would we need to specify a LOWPAN_NHC value for this so we
> >> can still use LOWPAN_NCH for UDP frames?
> >>
> >> We already have a draft requesting a new IPv6 Hop-by-Hop Option and
> >> presented it at 6man in Anaheim.  The option is designed to carry
> >> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC =
value
> >> for the IPv6 Hop-by-Hop Option header.
> >>
> >>
> >>    * Can you point to where the 'core ideas have been deployed in
> >> traditional IP networks for quite some time'?
> >>
> >> MPLS.  Again, I think the mechanisms will need to be adapted, but
> >> the core ideas are not new.
> >>
> >> --
> >> Jonathan Hui
> >>
> >>
> >> Thanks
> >>
> >> Robert
> >> Robert Cragie (Pacific Gas & Electric)
> >>
> >> Gridmerge Ltd.
> >> 89 Greenfield Crescent,
> >> Wakefield, WF4 4WA, UK
> >> +44 (0) 1924 910888
> >> http://www.gridmerge.com
> >>
> >>
> >> On 08/04/2010 3:57 PM, Jonathan Hui wrote:
> >>
> >>
> >>
> >> To make the source route header compact, I favor the tag/label
> >> approach over some other compaction mechanism that operates =
directly
> >> on a list of IPv6 addresses.  Tags/labels can be made general =
enough
> >> such that they can be derived in different ways.  Because the tags/
> >> labels have scope local to each node, the mechanism is pretty
> >> general already.  For those that are already managing unique
> >> 802.15.4 short addresses across a network, I can see that it is
> >> attractive to utilize the short address directly and reduce state =
on
> >> devices.  In other cases, it may be best for the node to =
dynamically
> >> assign tags/labels for its neighbors.
> >>
> >> Either way, while the tag/label mechanism is simple, it is far more
> >> flexible than an approach to compacting a list of IPv6 addresses.
> >> And note that the idea of using tags/labels is nothing new.  Of
> >> course we will adapt the basic mechanism a bit (label distribution,
> >> headers formats, etc), but the core ideas have been deployed in
> >> traditional IP networks for quite some time.
> >>
> >> I reiterated a lot of what was already stated before by others, but
> >> that is what I think.
> >>
> >> --
> >> Jonathan Hui
> >>
> >> On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert) wrote:
> >>
> >>
> >> Hi Daniel:
> >>
> >> Routers might have multiple interfaces of multiple MAC types.
> >> Internet 0
> >> even has a MAC-less format.
> >> So the result of you proposal, which looks like a great idea in a
> >> pure
> >> 802.15.4 world with short addresses, becomes a nightmare to define
> >> in a
> >> fully generic fashion.
> >>
> >> OTOH, a locally significant opaque tag in which the parent could
> >> hide a
> >> short address of the child - if it cares to do it that way - looks
> >> like
> >> a way more acceptable approach
> >>
> >> So it seems to me that you can get what you want as long as we can
> >> make
> >> the tag big enough for short addresses. When the tag is too small =
to
> >> contain what the parent really needs, then the parent will have to
> >> store
> >> a state with the full information in memory, and then place an =
index
> >> of
> >> some sort in the tag.
> >>
> >> What do you think?
> >>
> >> Pascal
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
> >> Sent: Thursday, April 08, 2010 11:40 AM
> >> To: ROLL WG
> >> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> >> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> >> SourceRoutingOperations
> >>
> >> Hi Pascal, John,
> >>
> >> Since source routing explicitly gives forwarding instruction to =
each
> >> intermediate node, it can make sense to use only (MAC address =
based)
> >> L2
> >>
> >> forwarding instead of (IPv6 address based) L3 forwarding.
> >>
> >> This brings two advantages:
> >> - avoid processing each transit packets up to L3.
> >> - use MAC addresses that - in ROLL environment - have inherently
> >> shorter
> >>
> >> length than an IPv6 address.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
> >> Of
> >>
> >> Pascal Thubert (pthubert)
> >> Sent: jeudi 8 avril 2010 11:15
> >> To: JeongGil Ko (John); ROLL WG
> >> Subject: Re: [Roll] Proposal for Source Routing Header Format and
> >> SourceRoutingOperations
> >>
> >> Hi John:
> >>
> >> IPv6 already has a number of routing headers, in particular RH0,
> >> though it is
> >>
> >> being deprecated for general use in the Internet.
> >> And there are reasons why the fields in RH0/1 are there and we need
> >> to
> >> make sure we lose none of that. In particular a RH is recoverable,
> >> and
> >> it is
> >>
> >> easy to spot the consumed entries.
> >>
> >> On top of this our new problems are:
> >> - make sure the RH stays within the RPL network (since it is used
> >> downwards
> >>
> >> that should be doable)
> >> - control the size (that probably means compress)
> >>
> >> Cheers,
> >>
> >> Pascal
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
> >> Of
> >>
> >> JeongGil Ko (John)
> >> Sent: Wednesday, April 07, 2010 10:05 PM
> >> To: ROLL WG
> >> Subject: [Roll] Proposal for Source Routing Header Format and =
Source
> >> RoutingOperations
> >>
> >> Hi!
> >>
> >> Great to see all this discussions on downwards route establishment!
> >> To
> >>
> >> add
> >>
> >> one more to the conversations here is a proposal for source routing
> >> headers.
> >>
> >> In non-storing mode (where only the root has individual path
> >> information)
> >>
> >> the root will be attaching a source routing header to the data
> >> packet
> >>
> >> that a
> >>
> >> source node wants to send to a specific destination. We can always
> >> make the
> >>
> >> header super fancy but in my opinion I think we only need two =
fields
> >> in this
> >>
> >> header and here it is! Feel free to break the stuff and mangle with
> >> it
> >>
> >> so that it
> >>
> >> looks great in the specs later on. FYI, this is the format that I =
am
> >> using in my
> >>
> >> implementations so it does work :)
> >>
> >> 1. Source Routing Header Format
> >>
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |   NEntry (8 bits)   |
> >> |
> >>
> >> +-+-+-+-+-+-+-+-+
> >> +
> >>
> >> |                       Source Route Entry (128*NEntry bits)
> >> |
> >>
> >> +
> >> +
> >>
> >> |
> >> |
> >>
> >>
> >>     Figure 1. Proposed Source Routing Header Format; each line is
> >> 32
> >>
> >> bits:)
> >>
> >>
> >> - NEntry: Indicates the number of 128 bit addresses that the source
> >> route
> >>
> >> entry field is carrying.
> >>
> >> - Source Route Entry: List of 128 bit address that consist the =
route
> >> to the
> >>
> >> destination. Here, the address of the node that is one hop away =
from
> >> the
> >>
> >> *destination* comes first.
> >>
> >> 2. Source Routing Packet Operations
> >>
> >> When source routing is initiated at a storing node (e.g., root of
> >> the
> >>
> >> DODAG),
> >>
> >> the header is attached on the data packet for the entire route
> >> (i.e.,
> >>
> >> from
> >>
> >> next hop node to the destination). This header is positioned in
> >> front
> >>
> >> of the
> >>
> >> user payload. When the next hop node receives a packet that is not
> >> destined
> >>
> >> to itself AND the network is NOT provisioned to be in 'storing =
mode'
> >> then it
> >>
> >> checks NEntry to find what the next hop is in the source route
> >> entry.
> >>
> >> Since
> >>
> >> the 'Source Route Entry' is ordered in 'farthest -> closest' (in
> >> terms
> >>
> >> of hops)
> >>
> >> order, a node can figure out what the next hop address is with only
> >> the
> >>
> >> NEntry value (since it already knows how big an ipv6 address is).
> >> After
> >>
> >> collecting the next hop node's address, the node erases this =
address
> >> element from the entry and decreases NEntry by one. This assures
> >> that
> >>
> >> we
> >>
> >> avoid the overhead of carrying the entire source route throughout
> >> the
> >>
> >> data
> >>
> >> path.
> >>
> >> The approach itself should be very simple and trivial for everyone
> >> to
> >>
> >> follow.
> >>
> >> So we can start from here and build on!
> >>
> >> Thanks.
> >>
> >> -John
> >>
> >> ------
> >> JeongGil Ko (John)
> >> Ph.D. Student
> >> Department of Computer Science
> >> Johns Hopkins University
> >> http://www.cs.jhu.edu/~jgko
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >>
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll


From alexandru.petrescu@gmail.com  Thu Apr 15 08:11:16 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A908828C259 for ; Thu, 15 Apr 2010 08:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.351,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7oDcMWftk-d for ; Thu, 15 Apr 2010 08:11:14 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id CA9083A6A1D for ; Thu, 15 Apr 2010 08:11:06 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3FFAwYI001197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Apr 2010 17:10:58 +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 o3FFAwdc016907 for ; Thu, 15 Apr 2010 17:10:58 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3FFAvl0004973 for ; Thu, 15 Apr 2010 17:10:58 +0200
Message-ID: <4BC72C81.4000901@gmail.com>
Date: Thu, 15 Apr 2010 17:10:57 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>	<3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>	<00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] Proposal for Source	RoutingHeader Format and SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 15:11:16 -0000

Le 15/04/2010 15:00, JP Vasseur a écrit :
 > Also my reading (again, co-chair hat off).

I am not sure why you need routing headers, flow labels, hbh.

The routing protocols I know of rarely if ever employ any of these.  (DSR?).

Why don't you (RPL designers) go simply with the ICMP extensions?

I really do not see why a Routing Header is needed for RPL.

(sounds to me like we have a set of hammers available: RH, HbH, Flow
  Labels, MPLS and we're looking for nails.)

Alex

Le 15/04/2010 15:00, JP Vasseur a écrit :
> Also my reading (again, co-chair hat off).
>
> On Apr 15, 2010, at 2:48 PM, Don Sturek wrote:
>
>> Hi Pascal,
>> I believe what you wrote below was the majority view on the reflector.
>> Don
>> *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>> *Sent:* Thursday, April 15, 2010 5:35 AM
>> *To:* JP Vasseur; d.sturek@att.net 
>> *Cc:* roll@ietf.org 
>> *Subject:* RE: [Roll] Proposal for Source RoutingHeader Format and
>> SourceRoutingOperations
>> Hi JP and all;
>> I’m not fully clear what the WG group really wants to do at this
>> point. I sensed an agreement to endorse something very close to IPv6
>> RH0 in the core spec, and provide a separate spec that would enable
>> labels in the Source route DAO and the hop by hop header.
>> Is that a honest reading of the mailing list?
>> Pascal
>> *From:* roll-bounces@ietf.org 
>> [mailto:roll-bounces@ietf.org] *On Behalf Of *JP Vasseur
>> *Sent:* Thursday, April 15, 2010 2:26 PM
>> *To:* d.sturek@att.net 
>> *Cc:* roll@ietf.org 
>> *Subject:* Re: [Roll] Proposal for Source RoutingHeader Format and
>> SourceRoutingOperations
>> Hi Don,
>> On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:
>>
>> I think the issue is this:
>> 1) ROLL cannot meet its charter without source routing
>> Absolutely.
>>
>> 2) Claiming the feature is now to be addressed in 6LowPAN seems a bit
>> wrong. ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.
>> You are absolutely right. IPHC is 15.4 specific. This is why the idea
>> of using a Label a la MPLS would be an interesting approach IMO. The
>> labe could be locall significant using DAO as a label distribution
>> mechanism. Completely link layer agnostic.
>> JP.
>>
>> How are those addressed?
>> Don
>> *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com]
>> *Sent:* Thursday, April 08, 2010 7:52 AM
>> *To:* d.sturek@att.net 
>> *Cc:* daniel.gavelle@jennic.com ;
>> roll@ietf.org 
>> *Subject:* Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>> Hi Don,
>>
>> It's not so much that 6lowpan is concerning itself with source
>> routing, it is concerning itself with efficient header compression,
>> which would include IPv6 extension headers such as RH0
>> . Whatever ends up getting
>> used for source routing needs to be some sort of IPv6 extension
>> header. Source routing for IPv6 would naturally contain IPv6
>> addresses. The question is whether we want to invent some new
>> extension header specifically for ROLL which uses something other
>> (i.e. smaller) than IPv6 addresses, e.g. the tag scheme mentioned.
>>
>> I agree, ROLL must accommodate source routing one way or another.
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com 
>>
>>
>> On 08/04/2010 2:35 PM, Don Sturek wrote:
>> I can't see why 6LowPAN (and specifically the HC draft) would concern itself
>> with source routing.
>>
>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>
>> I don't see how ROLL completes its charter or addresses its requirements
>> without adding source routing.
>>
>> Don
>>
>>
>> -----Original Message-----
>> From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf Of
>> Daniel Gavelle
>> Sent: Thursday, April 08, 2010 6:12 AM
>> To:robert.cragie@gridmerge.com  
>> Cc:roll@ietf.org  
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Rob,
>>
>> I agree that the source routing for the data frames should be done as
>> part of the 6LowPAN HC.    This already has a stateful IPV6 address
>> compression based on contexts.    It should be possible to compress the
>> addresses down to two bytes per address if IPv6 addresses are derived
>> from the 16 bit short address are being used in the LowPAN.
>>
>> We don't want to hold up the current HC draft that is going through last
>> call but the work could be done as a new RFC / amendment.    Source
>> routing compression may need a fix for the problem of HC compression
>> extending beyond the first fragment.
>>
>> Doing the work in the 6LowPAN group means that the compression can
>> easily be used for any source routing protocol, not just ROLL.    It could
>> be done as a compression for the existing R0 routing header.    Maybe this
>> thread needs moving to the 6LowPAN reflector.
>>
>> Daniel.
>>
>>
>> Robert Cragie wrote:
>>
>>
>>     Hi Pascal,
>>
>>
>>
>>     Source routing should of course use the IPv6 addresses which means a lot
>>
>>     of overhead for certain underlying link layers, e.g. 802.15.4. I think
>>
>>     it is generally cleaner to do the compression at a layer which may
>>
>>     require it only, e.g. define it in the 6lowpan HC. This is then free to
>>
>>     some extent to specify how the compression is done. Although I doubt
>>
>>     this would go down well in the 6lowpan WG...
>>
>>
>>
>>     The tag scheme would work but it specifically scopes the source routing
>>
>>     to nodes which operate the scheme. This is probably acceptable
>>
>>     practically but doesn't 'smell right' somehow.
>>
>>
>>
>>     With regard to the original proposal: it is probably necessary to carry
>>
>>     the full source route all the way to at least the penultimate node and
>>
>>     use an index to show the current position in the route for potential
>>
>>     backtrace and error reporting back along the same route (assuming link
>>
>>     symmetry). This is how RH0 works.
>>
>>
>>
>>     Robert
>>
>>
>>
>>     Robert Cragie (Pacific Gas&  Electric)
>>
>>
>>
>>     Gridmerge Ltd.
>>
>>     89 Greenfield Crescent,
>>
>>     Wakefield, WF4 4WA, UK
>>
>>     +44 (0) 1924 910888
>>
>>     http://www.gridmerge.com  
>>
>>
>>
>>
>>
>>     On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>>
>>         Hi Daniel:
>>
>>
>>
>>         Routers might have multiple interfaces of multiple MAC types. Internet 0
>>
>>         even has a MAC-less format.
>>
>>         So the result of you proposal, which looks like a great idea in a pure
>>
>>         802.15.4 world with short addresses, becomes a nightmare to define in a
>>
>>         fully generic fashion.
>>
>>
>>
>>         OTOH, a locally significant opaque tag in which the parent could hide a
>>
>>         short address of the child - if it cares to do it that way - looks like
>>
>>         a way more acceptable approach
>>
>>
>>
>>         So it seems to me that you can get what you want as long as we can make
>>
>>         the tag big enough for short addresses. When the tag is too small to
>>
>>         contain what the parent really needs, then the parent will have to store
>>
>>         a state with the full information in memory, and then place an index of
>>
>>         some sort in the tag.
>>
>>
>>
>>         What do you think?
>>
>>
>>
>>         Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>
>>             Sent: Thursday, April 08, 2010 11:40 AM
>>
>>             To: ROLL WG
>>
>>             Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>
>>             Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi Pascal, John,
>>
>>
>>
>>             Since source routing explicitly gives forwarding instruction to each
>>
>>             intermediate node, it can make sense to use only (MAC address based)
>>
>>
>>
>>
>>
>>         L2
>>
>>
>>
>>
>>
>>             forwarding instead of (IPv6 address based) L3 forwarding.
>>
>>
>>
>>             This brings two advantages:
>>
>>               - avoid processing each transit packets up to L3.
>>
>>               - use MAC addresses that - in ROLL environment - have inherently
>>
>>
>>
>>
>>
>>         shorter
>>
>>
>>
>>
>>
>>             length than an IPv6 address.
>>
>>
>>
>>             Cheers,
>>
>>             Daniel
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>         Of
>>
>>
>>
>>
>>
>>             Pascal Thubert (pthubert)
>>
>>             Sent: jeudi 8 avril 2010 11:15
>>
>>             To: JeongGil Ko (John); ROLL WG
>>
>>             Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi John:
>>
>>
>>
>>             IPv6 already has a number of routing headers, in particular RH0,
>>
>>
>>
>>
>>
>>         though it is
>>
>>
>>
>>
>>
>>             being deprecated for general use in the Internet.
>>
>>             And there are reasons why the fields in RH0/1 are there and we need to
>>
>>             make sure we lose none of that. In particular a RH is recoverable, and
>>
>>
>>
>>
>>
>>         it is
>>
>>
>>
>>
>>
>>             easy to spot the consumed entries.
>>
>>
>>
>>             On top of this our new problems are:
>>
>>             - make sure the RH stays within the RPL network (since it is used
>>
>>
>>
>>
>>
>>         downwards
>>
>>
>>
>>
>>
>>             that should be doable)
>>
>>             - control the size (that probably means compress)
>>
>>
>>
>>             Cheers,
>>
>>
>>
>>             Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                 -----Original Message-----
>>
>>                 From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>             Of
>>
>>
>>
>>
>>
>>                 JeongGil Ko (John)
>>
>>                 Sent: Wednesday, April 07, 2010 10:05 PM
>>
>>                 To: ROLL WG
>>
>>                 Subject: [Roll] Proposal for Source Routing Header Format and Source
>>
>>                 RoutingOperations
>>
>>
>>
>>                 Hi!
>>
>>
>>
>>                 Great to see all this discussions on downwards route establishment!
>>
>>
>>
>>
>>
>>         To
>>
>>
>>
>>
>>
>>             add
>>
>>
>>
>>
>>
>>                 one more to the conversations here is a proposal for source routing
>>
>>
>>
>>
>>
>>             headers.
>>
>>
>>
>>
>>
>>                 In non-storing mode (where only the root has individual path
>>
>>
>>
>>
>>
>>             information)
>>
>>
>>
>>
>>
>>                 the root will be attaching a source routing header to the data
>>
>>
>>
>>
>>
>>         packet
>>
>>
>>
>>
>>
>>             that a
>>
>>
>>
>>
>>
>>                 source node wants to send to a specific destination. We can always
>>
>>
>>
>>
>>
>>             make the
>>
>>
>>
>>
>>
>>                 header super fancy but in my opinion I think we only need two fields
>>
>>
>>
>>
>>
>>             in this
>>
>>
>>
>>
>>
>>                 header and here it is! Feel free to break the stuff and mangle with
>>
>>
>>
>>
>>
>>         it
>>
>>
>>
>>
>>
>>             so that it
>>
>>
>>
>>
>>
>>                 looks great in the specs later on. FYI, this is the format that I am
>>
>>
>>
>>
>>
>>             using in my
>>
>>
>>
>>
>>
>>                 implementations so it does work :)
>>
>>
>>
>>                 1. Source Routing Header Format
>>
>>
>>
>>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                 |      NEntry (8 bits)      |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +-+-+-+-+-+-+-+-+
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |                                              Source Route Entry (128*NEntry bits)
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                             Figure 1. Proposed Source Routing Header Format; each line is
>>
>>
>>
>>
>>
>>         32
>>
>>
>>
>>
>>
>>             bits:)
>>
>>
>>
>>
>>
>>                 - NEntry: Indicates the number of 128 bit addresses that the source
>>
>>
>>
>>
>>
>>             route
>>
>>
>>
>>
>>
>>                 entry field is carrying.
>>
>>
>>
>>                 - Source Route Entry: List of 128 bit address that consist the route
>>
>>
>>
>>
>>
>>             to the
>>
>>
>>
>>
>>
>>                 destination. Here, the address of the node that is one hop away from
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 *destination* comes first.
>>
>>
>>
>>                 2. Source Routing Packet Operations
>>
>>
>>
>>                 When source routing is initiated at a storing node (e.g., root of
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             DODAG),
>>
>>
>>
>>
>>
>>                 the header is attached on the data packet for the entire route
>>
>>
>>
>>
>>
>>         (i.e.,
>>
>>
>>
>>
>>
>>             from
>>
>>
>>
>>
>>
>>                 next hop node to the destination). This header is positioned in
>>
>>
>>
>>
>>
>>         front
>>
>>
>>
>>
>>
>>             of the
>>
>>
>>
>>
>>
>>                 user payload. When the next hop node receives a packet that is not
>>
>>
>>
>>
>>
>>             destined
>>
>>
>>
>>
>>
>>                 to itself AND the network is NOT provisioned to be in 'storing mode'
>>
>>
>>
>>
>>
>>             then it
>>
>>
>>
>>
>>
>>                 checks NEntry to find what the next hop is in the source route
>>
>>
>>
>>
>>
>>         entry.
>>
>>
>>
>>
>>
>>             Since
>>
>>
>>
>>
>>
>>                 the 'Source Route Entry' is ordered in 'farthest ->  closest' (in
>>
>>
>>
>>
>>
>>         terms
>>
>>
>>
>>
>>
>>             of hops)
>>
>>
>>
>>
>>
>>                 order, a node can figure out what the next hop address is with only
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 NEntry value (since it already knows how big an ipv6 address is).
>>
>>
>>
>>
>>
>>             After
>>
>>
>>
>>
>>
>>                 collecting the next hop node's address, the node erases this address
>>
>>                 element from the entry and decreases NEntry by one. This assures
>>
>>
>>
>>
>>
>>         that
>>
>>
>>
>>
>>
>>             we
>>
>>
>>
>>
>>
>>                 avoid the overhead of carrying the entire source route throughout
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             data
>>
>>
>>
>>
>>
>>                 path.
>>
>>
>>
>>                 The approach itself should be very simple and trivial for everyone
>>
>>
>>
>>
>>
>>         to
>>
>>
>>
>>
>>
>>             follow.
>>
>>
>>
>>
>>
>>                 So we can start from here and build on!
>>
>>
>>
>>                 Thanks.
>>
>>
>>
>>                 -John
>>
>>
>>
>>                 ------
>>
>>                 JeongGil Ko (John)
>>
>>                 Ph.D. Student
>>
>>                 Department of Computer Science
>>
>>                 Johns Hopkins University
>>
>>                 http://www.cs.jhu.edu/~jgko
>>
>>
>>
>>                 _______________________________________________
>>
>>                 Roll mailing list
>>
>>                 Roll@ietf.org  
>>
>>                 https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             Roll mailing list
>>
>>             Roll@ietf.org  
>>
>>             https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         Roll mailing list
>>
>>         Roll@ietf.org  
>>
>>         https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     ------------------------------------------------------------------------
>>
>>
>>
>>     _______________________________________________
>>
>>     Roll mailing list
>>
>>     Roll@ietf.org  
>>
>>     https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org 
>> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll



From alexandru.petrescu@gmail.com  Thu Apr 15 08:15:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C4F3A696D for ; Thu, 15 Apr 2010 08:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.331,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEBTPlvkmnUL for ; Thu, 15 Apr 2010 08:15:24 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 89B863A692D for ; Thu, 15 Apr 2010 08:15:18 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3FFF9S0008633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Apr 2010 17:15:09 +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 o3FFF9ob017952 for ; Thu, 15 Apr 2010 17:15:09 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3FFF7tR006572 for ; Thu, 15 Apr 2010 17:15:08 +0200
Message-ID: <4BC72D7B.5010802@gmail.com>
Date: Thu, 15 Apr 2010 17:15:07 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>	<3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>	<00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] Proposal for Source	RoutingHeader Format and SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 15:15:27 -0000

Le 15/04/2010 15:00, JP Vasseur a écrit :
[...]

>>> I think the issue is this:
 >>>
>>> 1) ROLL cannot meet its charter without source routing
 >>
>> Absolutely.

(You will excuse me but I don't know who precisely am I talking to about 
this particular point.)

What particular point in the ROLL Charter makes RPL need Routing 
Headers?  I don't seem to find any.

What do you agree about?

Alex

>>
>> 2) Claiming the feature is now to be addressed in 6LowPAN seems a bit
>> wrong. ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.
>> You are absolutely right. IPHC is 15.4 specific. This is why the idea
>> of using a Label a la MPLS would be an interesting approach IMO. The
>> labe could be locall significant using DAO as a label distribution
>> mechanism. Completely link layer agnostic.
>> JP.
>>
>> How are those addressed?
>> Don
>> *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com]
>> *Sent:* Thursday, April 08, 2010 7:52 AM
>> *To:* d.sturek@att.net 
>> *Cc:* daniel.gavelle@jennic.com ;
>> roll@ietf.org 
>> *Subject:* Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>> Hi Don,
>>
>> It's not so much that 6lowpan is concerning itself with source
>> routing, it is concerning itself with efficient header compression,
>> which would include IPv6 extension headers such as RH0
>> . Whatever ends up getting
>> used for source routing needs to be some sort of IPv6 extension
>> header. Source routing for IPv6 would naturally contain IPv6
>> addresses. The question is whether we want to invent some new
>> extension header specifically for ROLL which uses something other
>> (i.e. smaller) than IPv6 addresses, e.g. the tag scheme mentioned.
>>
>> I agree, ROLL must accommodate source routing one way or another.
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com 
>>
>>
>> On 08/04/2010 2:35 PM, Don Sturek wrote:
>> I can't see why 6LowPAN (and specifically the HC draft) would concern itself
>> with source routing.
>>
>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>
>> I don't see how ROLL completes its charter or addresses its requirements
>> without adding source routing.
>>
>> Don
>>
>>
>> -----Original Message-----
>> From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf Of
>> Daniel Gavelle
>> Sent: Thursday, April 08, 2010 6:12 AM
>> To:robert.cragie@gridmerge.com  
>> Cc:roll@ietf.org  
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Rob,
>>
>> I agree that the source routing for the data frames should be done as
>> part of the 6LowPAN HC.    This already has a stateful IPV6 address
>> compression based on contexts.    It should be possible to compress the
>> addresses down to two bytes per address if IPv6 addresses are derived
>> from the 16 bit short address are being used in the LowPAN.
>>
>> We don't want to hold up the current HC draft that is going through last
>> call but the work could be done as a new RFC / amendment.    Source
>> routing compression may need a fix for the problem of HC compression
>> extending beyond the first fragment.
>>
>> Doing the work in the 6LowPAN group means that the compression can
>> easily be used for any source routing protocol, not just ROLL.    It could
>> be done as a compression for the existing R0 routing header.    Maybe this
>> thread needs moving to the 6LowPAN reflector.
>>
>> Daniel.
>>
>>
>> Robert Cragie wrote:
>>
>>
>>     Hi Pascal,
>>
>>
>>
>>     Source routing should of course use the IPv6 addresses which means a lot
>>
>>     of overhead for certain underlying link layers, e.g. 802.15.4. I think
>>
>>     it is generally cleaner to do the compression at a layer which may
>>
>>     require it only, e.g. define it in the 6lowpan HC. This is then free to
>>
>>     some extent to specify how the compression is done. Although I doubt
>>
>>     this would go down well in the 6lowpan WG...
>>
>>
>>
>>     The tag scheme would work but it specifically scopes the source routing
>>
>>     to nodes which operate the scheme. This is probably acceptable
>>
>>     practically but doesn't 'smell right' somehow.
>>
>>
>>
>>     With regard to the original proposal: it is probably necessary to carry
>>
>>     the full source route all the way to at least the penultimate node and
>>
>>     use an index to show the current position in the route for potential
>>
>>     backtrace and error reporting back along the same route (assuming link
>>
>>     symmetry). This is how RH0 works.
>>
>>
>>
>>     Robert
>>
>>
>>
>>     Robert Cragie (Pacific Gas&  Electric)
>>
>>
>>
>>     Gridmerge Ltd.
>>
>>     89 Greenfield Crescent,
>>
>>     Wakefield, WF4 4WA, UK
>>
>>     +44 (0) 1924 910888
>>
>>     http://www.gridmerge.com  
>>
>>
>>
>>
>>
>>     On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>>
>>         Hi Daniel:
>>
>>
>>
>>         Routers might have multiple interfaces of multiple MAC types. Internet 0
>>
>>         even has a MAC-less format.
>>
>>         So the result of you proposal, which looks like a great idea in a pure
>>
>>         802.15.4 world with short addresses, becomes a nightmare to define in a
>>
>>         fully generic fashion.
>>
>>
>>
>>         OTOH, a locally significant opaque tag in which the parent could hide a
>>
>>         short address of the child - if it cares to do it that way - looks like
>>
>>         a way more acceptable approach
>>
>>
>>
>>         So it seems to me that you can get what you want as long as we can make
>>
>>         the tag big enough for short addresses. When the tag is too small to
>>
>>         contain what the parent really needs, then the parent will have to store
>>
>>         a state with the full information in memory, and then place an index of
>>
>>         some sort in the tag.
>>
>>
>>
>>         What do you think?
>>
>>
>>
>>         Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>
>>             Sent: Thursday, April 08, 2010 11:40 AM
>>
>>             To: ROLL WG
>>
>>             Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>
>>             Subject: RE: [Roll] Proposal for Source Routing Header Format and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi Pascal, John,
>>
>>
>>
>>             Since source routing explicitly gives forwarding instruction to each
>>
>>             intermediate node, it can make sense to use only (MAC address based)
>>
>>
>>
>>
>>
>>         L2
>>
>>
>>
>>
>>
>>             forwarding instead of (IPv6 address based) L3 forwarding.
>>
>>
>>
>>             This brings two advantages:
>>
>>               - avoid processing each transit packets up to L3.
>>
>>               - use MAC addresses that - in ROLL environment - have inherently
>>
>>
>>
>>
>>
>>         shorter
>>
>>
>>
>>
>>
>>             length than an IPv6 address.
>>
>>
>>
>>             Cheers,
>>
>>             Daniel
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>         Of
>>
>>
>>
>>
>>
>>             Pascal Thubert (pthubert)
>>
>>             Sent: jeudi 8 avril 2010 11:15
>>
>>             To: JeongGil Ko (John); ROLL WG
>>
>>             Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi John:
>>
>>
>>
>>             IPv6 already has a number of routing headers, in particular RH0,
>>
>>
>>
>>
>>
>>         though it is
>>
>>
>>
>>
>>
>>             being deprecated for general use in the Internet.
>>
>>             And there are reasons why the fields in RH0/1 are there and we need to
>>
>>             make sure we lose none of that. In particular a RH is recoverable, and
>>
>>
>>
>>
>>
>>         it is
>>
>>
>>
>>
>>
>>             easy to spot the consumed entries.
>>
>>
>>
>>             On top of this our new problems are:
>>
>>             - make sure the RH stays within the RPL network (since it is used
>>
>>
>>
>>
>>
>>         downwards
>>
>>
>>
>>
>>
>>             that should be doable)
>>
>>             - control the size (that probably means compress)
>>
>>
>>
>>             Cheers,
>>
>>
>>
>>             Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                 -----Original Message-----
>>
>>                 From:roll-bounces@ietf.org    [mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>             Of
>>
>>
>>
>>
>>
>>                 JeongGil Ko (John)
>>
>>                 Sent: Wednesday, April 07, 2010 10:05 PM
>>
>>                 To: ROLL WG
>>
>>                 Subject: [Roll] Proposal for Source Routing Header Format and Source
>>
>>                 RoutingOperations
>>
>>
>>
>>                 Hi!
>>
>>
>>
>>                 Great to see all this discussions on downwards route establishment!
>>
>>
>>
>>
>>
>>         To
>>
>>
>>
>>
>>
>>             add
>>
>>
>>
>>
>>
>>                 one more to the conversations here is a proposal for source routing
>>
>>
>>
>>
>>
>>             headers.
>>
>>
>>
>>
>>
>>                 In non-storing mode (where only the root has individual path
>>
>>
>>
>>
>>
>>             information)
>>
>>
>>
>>
>>
>>                 the root will be attaching a source routing header to the data
>>
>>
>>
>>
>>
>>         packet
>>
>>
>>
>>
>>
>>             that a
>>
>>
>>
>>
>>
>>                 source node wants to send to a specific destination. We can always
>>
>>
>>
>>
>>
>>             make the
>>
>>
>>
>>
>>
>>                 header super fancy but in my opinion I think we only need two fields
>>
>>
>>
>>
>>
>>             in this
>>
>>
>>
>>
>>
>>                 header and here it is! Feel free to break the stuff and mangle with
>>
>>
>>
>>
>>
>>         it
>>
>>
>>
>>
>>
>>             so that it
>>
>>
>>
>>
>>
>>                 looks great in the specs later on. FYI, this is the format that I am
>>
>>
>>
>>
>>
>>             using in my
>>
>>
>>
>>
>>
>>                 implementations so it does work :)
>>
>>
>>
>>                 1. Source Routing Header Format
>>
>>
>>
>>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                 |      NEntry (8 bits)      |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +-+-+-+-+-+-+-+-+
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |                                              Source Route Entry (128*NEntry bits)
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                             Figure 1. Proposed Source Routing Header Format; each line is
>>
>>
>>
>>
>>
>>         32
>>
>>
>>
>>
>>
>>             bits:)
>>
>>
>>
>>
>>
>>                 - NEntry: Indicates the number of 128 bit addresses that the source
>>
>>
>>
>>
>>
>>             route
>>
>>
>>
>>
>>
>>                 entry field is carrying.
>>
>>
>>
>>                 - Source Route Entry: List of 128 bit address that consist the route
>>
>>
>>
>>
>>
>>             to the
>>
>>
>>
>>
>>
>>                 destination. Here, the address of the node that is one hop away from
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 *destination* comes first.
>>
>>
>>
>>                 2. Source Routing Packet Operations
>>
>>
>>
>>                 When source routing is initiated at a storing node (e.g., root of
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             DODAG),
>>
>>
>>
>>
>>
>>                 the header is attached on the data packet for the entire route
>>
>>
>>
>>
>>
>>         (i.e.,
>>
>>
>>
>>
>>
>>             from
>>
>>
>>
>>
>>
>>                 next hop node to the destination). This header is positioned in
>>
>>
>>
>>
>>
>>         front
>>
>>
>>
>>
>>
>>             of the
>>
>>
>>
>>
>>
>>                 user payload. When the next hop node receives a packet that is not
>>
>>
>>
>>
>>
>>             destined
>>
>>
>>
>>
>>
>>                 to itself AND the network is NOT provisioned to be in 'storing mode'
>>
>>
>>
>>
>>
>>             then it
>>
>>
>>
>>
>>
>>                 checks NEntry to find what the next hop is in the source route
>>
>>
>>
>>
>>
>>         entry.
>>
>>
>>
>>
>>
>>             Since
>>
>>
>>
>>
>>
>>                 the 'Source Route Entry' is ordered in 'farthest ->  closest' (in
>>
>>
>>
>>
>>
>>         terms
>>
>>
>>
>>
>>
>>             of hops)
>>
>>
>>
>>
>>
>>                 order, a node can figure out what the next hop address is with only
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 NEntry value (since it already knows how big an ipv6 address is).
>>
>>
>>
>>
>>
>>             After
>>
>>
>>
>>
>>
>>                 collecting the next hop node's address, the node erases this address
>>
>>                 element from the entry and decreases NEntry by one. This assures
>>
>>
>>
>>
>>
>>         that
>>
>>
>>
>>
>>
>>             we
>>
>>
>>
>>
>>
>>                 avoid the overhead of carrying the entire source route throughout
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             data
>>
>>
>>
>>
>>
>>                 path.
>>
>>
>>
>>                 The approach itself should be very simple and trivial for everyone
>>
>>
>>
>>
>>
>>         to
>>
>>
>>
>>
>>
>>             follow.
>>
>>
>>
>>
>>
>>                 So we can start from here and build on!
>>
>>
>>
>>                 Thanks.
>>
>>
>>
>>                 -John
>>
>>
>>
>>                 ------
>>
>>                 JeongGil Ko (John)
>>
>>                 Ph.D. Student
>>
>>                 Department of Computer Science
>>
>>                 Johns Hopkins University
>>
>>                 http://www.cs.jhu.edu/~jgko
>>
>>
>>
>>                 _______________________________________________
>>
>>                 Roll mailing list
>>
>>                 Roll@ietf.org  
>>
>>                 https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             Roll mailing list
>>
>>             Roll@ietf.org  
>>
>>             https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         Roll mailing list
>>
>>         Roll@ietf.org  
>>
>>         https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     ------------------------------------------------------------------------
>>
>>
>>
>>     _______________________________________________
>>
>>     Roll mailing list
>>
>>     Roll@ietf.org  
>>
>>     https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org 
>> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll



From d.sturek@att.net  Thu Apr 15 08:23:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FEE28C240 for ; Thu, 15 Apr 2010 08:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.629
X-Spam-Level: 
X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrfXzW2n5wHY for ; Thu, 15 Apr 2010 08:23:51 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 7BA123A69ED for ; Thu, 15 Apr 2010 08:23:08 -0700 (PDT)
Received: (qmail 73208 invoked from network); 15 Apr 2010 15:22:52 -0000
Received: from adsl-69-224-122-222.dsl.sndg02.pacbell.net (d.sturek@69.224.122.222 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 15 Apr 2010 08:22:51 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: dSOjkpoVM1maE4pJO.tZcheyk527ZxA8L3Gi.ojz0IhU9ggC0DmvXHtFg5dq9uk7TlW6V2Q_ddM4WKkQdE3.sxRRd8fKeog.lD45O0JOtARn5LYOE2Y3pIjJBuMIllZmtr64ANCSgHJHQZWvh.ai1hQIw5fj._w.R92ockaUIwJYondzdnbhkYxLFtrQJTMkLSeKTA9kW7INs7EnW64oTS4TTwGRMHeV9LJPLEu2__o5.AshMrMKlaAaSQgmNysBowwuAidsGkHo_FbSTLRQYaL1J8xoDdvR963W7dI9c3QTdM0wpg--
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Alexandru Petrescu'" , 
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>	<3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>	<00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net>	 <4BC72D7B.5010802@gmail.com>
In-Reply-To: <4BC72D7B.5010802@gmail.com>
Date: Thu, 15 Apr 2010 08:22:48 -0700
Message-ID: <019901cadcaf$828285e0$878791a0$@sturek@att.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrcrnsHAEGJ67ShSJKGi4qj8E1/FwAANZIQ
Content-Language: en-us
Subject: Re: [Roll] Proposal for Source	RoutingHeader Format and	SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Apr 2010 15:23:59 -0000

Hi Alex,

This thread confirms the need, for non-storing ROLL RPL devices, in
supplying source routing from the DAG root to devices in the DAG.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Alexandru Petrescu
Sent: Thursday, April 15, 2010 8:15 AM
To: roll@ietf.org
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

Le 15/04/2010 15:00, JP Vasseur a =E9crit :
[...]

>>> I think the issue is this:
 >>>
>>> 1) ROLL cannot meet its charter without source routing
 >>
>> Absolutely.

(You will excuse me but I don't know who precisely am I talking to about =

this particular point.)

What particular point in the ROLL Charter makes RPL need Routing=20
Headers?  I don't seem to find any.

What do you agree about?

Alex

>>
>> 2) Claiming the feature is now to be addressed in 6LowPAN seems a bit
>> wrong. ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.
>> You are absolutely right. IPHC is 15.4 specific. This is why the idea
>> of using a Label a la MPLS would be an interesting approach IMO. The
>> labe could be locall significant using DAO as a label distribution
>> mechanism. Completely link layer agnostic.
>> JP.
>>
>> How are those addressed?
>> Don
>> *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com]
>> *Sent:* Thursday, April 08, 2010 7:52 AM
>> *To:* d.sturek@att.net 
>> *Cc:* daniel.gavelle@jennic.com ;
>> roll@ietf.org 
>> *Subject:* Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>> Hi Don,
>>
>> It's not so much that 6lowpan is concerning itself with source
>> routing, it is concerning itself with efficient header compression,
>> which would include IPv6 extension headers such as RH0
>> . Whatever ends up =
getting
>> used for source routing needs to be some sort of IPv6 extension
>> header. Source routing for IPv6 would naturally contain IPv6
>> addresses. The question is whether we want to invent some new
>> extension header specifically for ROLL which uses something other
>> (i.e. smaller) than IPv6 addresses, e.g. the tag scheme mentioned.
>>
>> I agree, ROLL must accommodate source routing one way or another.
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com 
>>
>>
>> On 08/04/2010 2:35 PM, Don Sturek wrote:
>> I can't see why 6LowPAN (and specifically the HC draft) would concern
itself
>> with source routing.
>>
>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>
>> I don't see how ROLL completes its charter or addresses its =
requirements
>> without adding source routing.
>>
>> Don
>>
>>
>> -----Original Message-----
>> From:roll-bounces@ietf.org  
[mailto:roll-bounces@ietf.org] On Behalf Of
>> Daniel Gavelle
>> Sent: Thursday, April 08, 2010 6:12 AM
>> To:robert.cragie@gridmerge.com  
>> Cc:roll@ietf.org  
>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>> SourceRoutingOperations
>>
>> Rob,
>>
>> I agree that the source routing for the data frames should be done as
>> part of the 6LowPAN HC.    This already has a stateful IPV6 address
>> compression based on contexts.    It should be possible to compress =
the
>> addresses down to two bytes per address if IPv6 addresses are derived
>> from the 16 bit short address are being used in the LowPAN.
>>
>> We don't want to hold up the current HC draft that is going through =
last
>> call but the work could be done as a new RFC / amendment.    Source
>> routing compression may need a fix for the problem of HC compression
>> extending beyond the first fragment.
>>
>> Doing the work in the 6LowPAN group means that the compression can
>> easily be used for any source routing protocol, not just ROLL.    It
could
>> be done as a compression for the existing R0 routing header.    Maybe
this
>> thread needs moving to the 6LowPAN reflector.
>>
>> Daniel.
>>
>>
>> Robert Cragie wrote:
>>
>>
>>     Hi Pascal,
>>
>>
>>
>>     Source routing should of course use the IPv6 addresses which =
means a
lot
>>
>>     of overhead for certain underlying link layers, e.g. 802.15.4. I
think
>>
>>     it is generally cleaner to do the compression at a layer which =
may
>>
>>     require it only, e.g. define it in the 6lowpan HC. This is then =
free
to
>>
>>     some extent to specify how the compression is done. Although I =
doubt
>>
>>     this would go down well in the 6lowpan WG...
>>
>>
>>
>>     The tag scheme would work but it specifically scopes the source
routing
>>
>>     to nodes which operate the scheme. This is probably acceptable
>>
>>     practically but doesn't 'smell right' somehow.
>>
>>
>>
>>     With regard to the original proposal: it is probably necessary to
carry
>>
>>     the full source route all the way to at least the penultimate =
node
and
>>
>>     use an index to show the current position in the route for =
potential
>>
>>     backtrace and error reporting back along the same route (assuming
link
>>
>>     symmetry). This is how RH0 works.
>>
>>
>>
>>     Robert
>>
>>
>>
>>     Robert Cragie (Pacific Gas&  Electric)
>>
>>
>>
>>     Gridmerge Ltd.
>>
>>     89 Greenfield Crescent,
>>
>>     Wakefield, WF4 4WA, UK
>>
>>     +44 (0) 1924 910888
>>
>>     http://www.gridmerge.com  
>>
>>
>>
>>
>>
>>     On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>>
>>
>>
>>         Hi Daniel:
>>
>>
>>
>>         Routers might have multiple interfaces of multiple MAC types.
Internet 0
>>
>>         even has a MAC-less format.
>>
>>         So the result of you proposal, which looks like a great idea =
in a
pure
>>
>>         802.15.4 world with short addresses, becomes a nightmare to
define in a
>>
>>         fully generic fashion.
>>
>>
>>
>>         OTOH, a locally significant opaque tag in which the parent =
could
hide a
>>
>>         short address of the child - if it cares to do it that way -
looks like
>>
>>         a way more acceptable approach
>>
>>
>>
>>         So it seems to me that you can get what you want as long as =
we
can make
>>
>>         the tag big enough for short addresses. When the tag is too =
small
to
>>
>>         contain what the parent really needs, then the parent will =
have
to store
>>
>>         a state with the full information in memory, and then place =
an
index of
>>
>>         some sort in the tag.
>>
>>
>>
>>         What do you think?
>>
>>
>>
>>         Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>
>>             Sent: Thursday, April 08, 2010 11:40 AM
>>
>>             To: ROLL WG
>>
>>             Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>
>>             Subject: RE: [Roll] Proposal for Source Routing Header =
Format
and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi Pascal, John,
>>
>>
>>
>>             Since source routing explicitly gives forwarding =
instruction
to each
>>
>>             intermediate node, it can make sense to use only (MAC =
address
based)
>>
>>
>>
>>
>>
>>         L2
>>
>>
>>
>>
>>
>>             forwarding instead of (IPv6 address based) L3 forwarding.
>>
>>
>>
>>             This brings two advantages:
>>
>>               - avoid processing each transit packets up to L3.
>>
>>               - use MAC addresses that - in ROLL environment - have
inherently
>>
>>
>>
>>
>>
>>         shorter
>>
>>
>>
>>
>>
>>             length than an IPv6 address.
>>
>>
>>
>>             Cheers,
>>
>>             Daniel
>>
>>
>>
>>
>>
>>
>>
>>             -----Original Message-----
>>
>>             From:roll-bounces@ietf.org  =

[mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>         Of
>>
>>
>>
>>
>>
>>             Pascal Thubert (pthubert)
>>
>>             Sent: jeudi 8 avril 2010 11:15
>>
>>             To: JeongGil Ko (John); ROLL WG
>>
>>             Subject: Re: [Roll] Proposal for Source Routing Header =
Format
and
>>
>>             SourceRoutingOperations
>>
>>
>>
>>             Hi John:
>>
>>
>>
>>             IPv6 already has a number of routing headers, in =
particular
RH0,
>>
>>
>>
>>
>>
>>         though it is
>>
>>
>>
>>
>>
>>             being deprecated for general use in the Internet.
>>
>>             And there are reasons why the fields in RH0/1 are there =
and
we need to
>>
>>             make sure we lose none of that. In particular a RH is
recoverable, and
>>
>>
>>
>>
>>
>>         it is
>>
>>
>>
>>
>>
>>             easy to spot the consumed entries.
>>
>>
>>
>>             On top of this our new problems are:
>>
>>             - make sure the RH stays within the RPL network (since it =
is
used
>>
>>
>>
>>
>>
>>         downwards
>>
>>
>>
>>
>>
>>             that should be doable)
>>
>>             - control the size (that probably means compress)
>>
>>
>>
>>             Cheers,
>>
>>
>>
>>             Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                 -----Original Message-----
>>
>>                 From:roll-bounces@ietf.org
  [mailto:roll-bounces@ietf.org] On Behalf
>>
>>
>>
>>
>>
>>             Of
>>
>>
>>
>>
>>
>>                 JeongGil Ko (John)
>>
>>                 Sent: Wednesday, April 07, 2010 10:05 PM
>>
>>                 To: ROLL WG
>>
>>                 Subject: [Roll] Proposal for Source Routing Header =
Format
and Source
>>
>>                 RoutingOperations
>>
>>
>>
>>                 Hi!
>>
>>
>>
>>                 Great to see all this discussions on downwards route
establishment!
>>
>>
>>
>>
>>
>>         To
>>
>>
>>
>>
>>
>>             add
>>
>>
>>
>>
>>
>>                 one more to the conversations here is a proposal for
source routing
>>
>>
>>
>>
>>
>>             headers.
>>
>>
>>
>>
>>
>>                 In non-storing mode (where only the root has =
individual
path
>>
>>
>>
>>
>>
>>             information)
>>
>>
>>
>>
>>
>>                 the root will be attaching a source routing header to =
the
data
>>
>>
>>
>>
>>
>>         packet
>>
>>
>>
>>
>>
>>             that a
>>
>>
>>
>>
>>
>>                 source node wants to send to a specific destination. =
We
can always
>>
>>
>>
>>
>>
>>             make the
>>
>>
>>
>>
>>
>>                 header super fancy but in my opinion I think we only =
need
two fields
>>
>>
>>
>>
>>
>>             in this
>>
>>
>>
>>
>>
>>                 header and here it is! Feel free to break the stuff =
and
mangle with
>>
>>
>>
>>
>>
>>         it
>>
>>
>>
>>
>>
>>             so that it
>>
>>
>>
>>
>>
>>                 looks great in the specs later on. FYI, this is the
format that I am
>>
>>
>>
>>
>>
>>             using in my
>>
>>
>>
>>
>>
>>                 implementations so it does work :)
>>
>>
>>
>>                 1. Source Routing Header Format
>>
>>
>>
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                 |      NEntry (8 bits)      |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +-+-+-+-+-+-+-+-+
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |                                              Source
Route Entry (128*NEntry bits)
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                 +
>>
>>
>>
>>
>>
>>             +
>>
>>
>>
>>
>>
>>                 |
>>
>>
>>
>>
>>
>>             |
>>
>>
>>
>>
>>
>>                             Figure 1. Proposed Source Routing Header
Format; each line is
>>
>>
>>
>>
>>
>>         32
>>
>>
>>
>>
>>
>>             bits:)
>>
>>
>>
>>
>>
>>                 - NEntry: Indicates the number of 128 bit addresses =
that
the source
>>
>>
>>
>>
>>
>>             route
>>
>>
>>
>>
>>
>>                 entry field is carrying.
>>
>>
>>
>>                 - Source Route Entry: List of 128 bit address that
consist the route
>>
>>
>>
>>
>>
>>             to the
>>
>>
>>
>>
>>
>>                 destination. Here, the address of the node that is =
one
hop away from
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 *destination* comes first.
>>
>>
>>
>>                 2. Source Routing Packet Operations
>>
>>
>>
>>                 When source routing is initiated at a storing node =
(e.g.,
root of
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             DODAG),
>>
>>
>>
>>
>>
>>                 the header is attached on the data packet for the =
entire
route
>>
>>
>>
>>
>>
>>         (i.e.,
>>
>>
>>
>>
>>
>>             from
>>
>>
>>
>>
>>
>>                 next hop node to the destination). This header is
positioned in
>>
>>
>>
>>
>>
>>         front
>>
>>
>>
>>
>>
>>             of the
>>
>>
>>
>>
>>
>>                 user payload. When the next hop node receives a =
packet
that is not
>>
>>
>>
>>
>>
>>             destined
>>
>>
>>
>>
>>
>>                 to itself AND the network is NOT provisioned to be in
'storing mode'
>>
>>
>>
>>
>>
>>             then it
>>
>>
>>
>>
>>
>>                 checks NEntry to find what the next hop is in the =
source
route
>>
>>
>>
>>
>>
>>         entry.
>>
>>
>>
>>
>>
>>             Since
>>
>>
>>
>>
>>
>>                 the 'Source Route Entry' is ordered in 'farthest ->
closest' (in
>>
>>
>>
>>
>>
>>         terms
>>
>>
>>
>>
>>
>>             of hops)
>>
>>
>>
>>
>>
>>                 order, a node can figure out what the next hop =
address is
with only
>>
>>
>>
>>
>>
>>             the
>>
>>
>>
>>
>>
>>                 NEntry value (since it already knows how big an ipv6
address is).
>>
>>
>>
>>
>>
>>             After
>>
>>
>>
>>
>>
>>                 collecting the next hop node's address, the node =
erases
this address
>>
>>                 element from the entry and decreases NEntry by one. =
This
assures
>>
>>
>>
>>
>>
>>         that
>>
>>
>>
>>
>>
>>             we
>>
>>
>>
>>
>>
>>                 avoid the overhead of carrying the entire source =
route
throughout
>>
>>
>>
>>
>>
>>         the
>>
>>
>>
>>
>>
>>             data
>>
>>
>>
>>
>>
>>                 path.
>>
>>
>>
>>                 The approach itself should be very simple and trivial =
for
everyone
>>
>>
>>
>>
>>
>>         to
>>
>>
>>
>>
>>
>>             follow.
>>
>>
>>
>>
>>
>>                 So we can start from here and build on!
>>
>>
>>
>>                 Thanks.
>>
>>
>>
>>                 -John
>>
>>
>>
>>                 ------
>>
>>                 JeongGil Ko (John)
>>
>>                 Ph.D. Student
>>
>>                 Department of Computer Science
>>
>>                 Johns Hopkins University
>>
>>                 http://www.cs.jhu.edu/~jgko
>>
>>
>>
>>                 _______________________________________________
>>
>>                 Roll mailing list
>>
>>                 Roll@ietf.org  
>>
>>                 https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             Roll mailing list
>>
>>             Roll@ietf.org  
>>
>>             https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         Roll mailing list
>>
>>         Roll@ietf.org  
>>
>>         https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>>
>>
>>     _______________________________________________
>>
>>     Roll mailing list
>>
>>     Roll@ietf.org  
>>
>>     https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org 
>> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


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


From alexandru.petrescu@gmail.com  Thu Apr 15 08:36:43 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660DA3A6B00 for ; Thu, 15 Apr 2010 08:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.314,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zur77FJmpGfP for ; Thu, 15 Apr 2010 08:36:41 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AB28C3A69A0 for ; Thu, 15 Apr 2010 08:36:40 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3FFaU0R013774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 17:36:31 +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 o3FFaUHq022384; Thu, 15 Apr 2010 17:36:30 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3FFaTKo013360; Thu, 15 Apr 2010 17:36:30 +0200
Message-ID: <4BC7327D.60607@gmail.com>
Date: Thu, 15 Apr 2010 17:36:29 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: d.sturek@att.net
References: <4E9673D3-54B5-4354-9BC3-BDAFA5E23CE9@cs.jhu.edu>	<6A2A459175DABE4BB11DE2026AA50A5D019BD314@XMB-AMS-107.cisco.com>		<6A2A459175DABE4BB11DE2026AA50A5D019BD373@XMB-AMS-107.cisco.com>	<4BBDC39F.3040601@gridmerge.com><4BBDD602.7040707@jennic.com><008801cad720$555a0a50$000e1ef0$@sturek@att.net><4BBDED7C.40009@gridmerge.com><011f01cad72c$148cdff0$3da69fd0$@sturek@att.net>	<3FA73ABC-B68C-4BB8-B0FA-9E77AB9A5D58@cisco.com>	<6A2A459175DABE4BB11DE2026AA50A5D01AB8B16@XMB-AMS-107.cisco.com>	<00cb01cadc99$e84eb620$b8ec2260$@sturek@att.net>	 <4BC72D7B.5010802@gmail.com> <019901cadcaf$828285e0$878791a0$@sturek@att.net>
In-Reply-To: <019901cadcaf$828285e0$878791a0$@sturek@att.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: roll@ietf.org
Subject: Re: [Roll] Proposal for Source	RoutingHeader Format and SourceRoutingOperations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 15:36:43 -0000

Le 15/04/2010 17:22, Don Sturek a écrit :
> Hi Alex,
>
> This thread confirms the need, for non-storing ROLL RPL devices,

Non-storing means they do not store routing tables?

If they don't then do we talk IP at all here?  (IP routers w/o routing
tables?)

Routing Headers wouldn't work in the absence of Routing Table entries
either.

I do not see the conceptual link between non-storing devices and the
necessity of Routing Headers.

But not sure whydo we need here RHs.  Simply non-storing is not a reason
I can understand quickly.

Alex
PS: If needed, I can explain the way I understand the reason why the use
of RH was proposed in the context of nesting moving networks - mainly
because all came with their built-in addresses already
preassigned and thus tunnels were everywhere too thick - so RHs were
preferred instead.  But here - how are the addresses?

> in supplying source routing from the DAG root to devices in the DAG.
>
> Don
>
>
> -----Original Message----- From: roll-bounces@ietf.org
> [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent:
> Thursday, April 15, 2010 8:15 AM To: roll@ietf.org Subject: Re:
> [Roll] Proposal for Source RoutingHeader Format and
> SourceRoutingOperations
>
> Le 15/04/2010 15:00, JP Vasseur a écrit : [...]
>
>>>> I think the issue is this:
>>>>
>>>> 1) ROLL cannot meet its charter without source routing
>>>
>>> Absolutely.
>
> (You will excuse me but I don't know who precisely am I talking to
> about this particular point.)
>
> What particular point in the ROLL Charter makes RPL need Routing
> Headers?  I don't seem to find any.
>
> What do you agree about?
>
> Alex
>
>>>
>>> 2) Claiming the feature is now to be addressed in 6LowPAN seems
>>> a bit wrong. ROLL has as its scope MAC/PHYs other than IEEE
>>> 802.15.4. You are absolutely right. IPHC is 15.4 specific. This
>>> is why the idea of using a Label a la MPLS would be an
>>> interesting approach IMO. The labe could be locall significant
>>> using DAO as a label distribution mechanism. Completely link
>>> layer agnostic. JP.
>>>
>>> How are those addressed? Don *From:* Robert Cragie
>>> [mailto:robert.cragie@gridmerge.com] *Sent:* Thursday, April 08,
>>> 2010 7:52 AM *To:* d.sturek@att.net
>>> *Cc:*
>>> daniel.gavelle@jennic.com;
>>> roll@ietf.org *Subject:* Re: [Roll]
>>> Proposal for Source Routing Header Format and
>>> SourceRoutingOperations Hi Don,
>>>
>>> It's not so much that 6lowpan is concerning itself with source
>>> routing, it is concerning itself with efficient header
>>> compression, which would include IPv6 extension headers such as
>>> RH0 . Whatever ends
>>> up getting used for source routing needs to be some sort of IPv6
>>> extension header. Source routing for IPv6 would naturally contain
>>> IPv6 addresses. The question is whether we want to invent some
>>> new extension header specifically for ROLL which uses something
>>> other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme
>>> mentioned.
>>>
>>> I agree, ROLL must accommodate source routing one way or
>>> another.
>>>
>>> Robert
>>>
>>> Robert Cragie (Pacific Gas&  Electric)
>>>
>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK
>>> +44 (0) 1924 910888
>>> http://www.gridmerge.com
>>>
>>>
>>> On 08/04/2010 2:35 PM, Don Sturek wrote: I can't see why 6LowPAN
>>> (and specifically the HC draft) would concern
> itself
>>> with source routing.
>>>
>>> Surely source routing is a concern of ROLL (and not 6LowPAN).
>>>
>>> I don't see how ROLL completes its charter or addresses its
>>> requirements without adding source routing.
>>>
>>> Don
>>>
>>>
>>> -----Original Message-----
>>> From:roll-bounces@ietf.org
> [mailto:roll-bounces@ietf.org] On Behalf Of
>>> Daniel Gavelle Sent: Thursday, April 08, 2010 6:12 AM
>>> To:robert.cragie@gridmerge.com
>>>
>>>
>>>
>>>
>>>
Cc:roll@ietf.org
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format and
>>> SourceRoutingOperations
>>>
>>> Rob,
>>>
>>> I agree that the source routing for the data frames should be
>>> done as part of the 6LowPAN HC.    This already has a stateful
>>> IPV6 address compression based on contexts.    It should be
>>> possible to compress the addresses down to two bytes per address
>>> if IPv6 addresses are derived from the 16 bit short address are
>>> being used in the LowPAN.
>>>
>>> We don't want to hold up the current HC draft that is going
>>> through last call but the work could be done as a new RFC /
>>> amendment.    Source routing compression may need a fix for the
>>> problem of HC compression extending beyond the first fragment.
>>>
>>> Doing the work in the 6LowPAN group means that the compression
>>> can easily be used for any source routing protocol, not just
>>> ROLL.    It
> could
>>> be done as a compression for the existing R0 routing header.
>>> Maybe
> this
>>> thread needs moving to the 6LowPAN reflector.
>>>
>>> Daniel.
>>>
>>>
>>> Robert Cragie wrote:
>>>
>>>
>>> Hi Pascal,
>>>
>>>
>>>
>>> Source routing should of course use the IPv6 addresses which
>>> means a
> lot
>>>
>>> of overhead for certain underlying link layers, e.g. 802.15.4. I
> think
>>>
>>> it is generally cleaner to do the compression at a layer which
>>> may
>>>
>>> require it only, e.g. define it in the 6lowpan HC. This is then
>>> free
> to
>>>
>>> some extent to specify how the compression is done. Although I
>>> doubt
>>>
>>> this would go down well in the 6lowpan WG...
>>>
>>>
>>>
>>> The tag scheme would work but it specifically scopes the source
> routing
>>>
>>> to nodes which operate the scheme. This is probably acceptable
>>>
>>> practically but doesn't 'smell right' somehow.
>>>
>>>
>>>
>>> With regard to the original proposal: it is probably necessary
>>> to
> carry
>>>
>>> the full source route all the way to at least the penultimate
>>> node
> and
>>>
>>> use an index to show the current position in the route for
>>> potential
>>>
>>> backtrace and error reporting back along the same route
>>> (assuming
> link
>>>
>>> symmetry). This is how RH0 works.
>>>
>>>
>>>
>>> Robert
>>>
>>>
>>>
>>> Robert Cragie (Pacific Gas&   Electric)
>>>
>>>
>>>
>>> Gridmerge Ltd.
>>>
>>> 89 Greenfield Crescent,
>>>
>>> Wakefield, WF4 4WA, UK
>>>
>>> +44 (0) 1924 910888
>>>
>>> http://www.gridmerge.com
>>>
>>>
>>>
>>>
>>>
>>> On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>>>
>>>
>>>
>>> Hi Daniel:
>>>
>>>
>>>
>>> Routers might have multiple interfaces of multiple MAC types.
> Internet 0
>>>
>>> even has a MAC-less format.
>>>
>>> So the result of you proposal, which looks like a great idea in
>>> a
> pure
>>>
>>> 802.15.4 world with short addresses, becomes a nightmare to
> define in a
>>>
>>> fully generic fashion.
>>>
>>>
>>>
>>> OTOH, a locally significant opaque tag in which the parent could
> hide a
>>>
>>> short address of the child - if it cares to do it that way -
> looks like
>>>
>>> a way more acceptable approach
>>>
>>>
>>>
>>> So it seems to me that you can get what you want as long as we
> can make
>>>
>>> the tag big enough for short addresses. When the tag is too
>>> small
> to
>>>
>>> contain what the parent really needs, then the parent will have
> to store
>>>
>>> a state with the full information in memory, and then place an
> index of
>>>
>>> some sort in the tag.
>>>
>>>
>>>
>>> What do you think?
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From: Popa, Daniel [mailto:Daniel.Popa@itron.com]
>>>
>>> Sent: Thursday, April 08, 2010 11:40 AM
>>>
>>> To: ROLL WG
>>>
>>> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
>>>
>>> Subject: RE: [Roll] Proposal for Source Routing Header Format
> and
>>>
>>> SourceRoutingOperations
>>>
>>>
>>>
>>> Hi Pascal, John,
>>>
>>>
>>>
>>> Since source routing explicitly gives forwarding instruction
> to each
>>>
>>> intermediate node, it can make sense to use only (MAC address
> based)
>>>
>>>
>>>
>>>
>>>
>>> L2
>>>
>>>
>>>
>>>
>>>
>>> forwarding instead of (IPv6 address based) L3 forwarding.
>>>
>>>
>>>
>>> This brings two advantages:
>>>
>>> - avoid processing each transit packets up to L3.
>>>
>>> - use MAC addresses that - in ROLL environment - have
> inherently
>>>
>>>
>>>
>>>
>>>
>>> shorter
>>>
>>>
>>>
>>>
>>>
>>> length than an IPv6 address.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From:roll-bounces@ietf.org
> [mailto:roll-bounces@ietf.org] On Behalf
>>>
>>>
>>>
>>>
>>>
>>> Of
>>>
>>>
>>>
>>>
>>>
>>> Pascal Thubert (pthubert)
>>>
>>> Sent: jeudi 8 avril 2010 11:15
>>>
>>> To: JeongGil Ko (John); ROLL WG
>>>
>>> Subject: Re: [Roll] Proposal for Source Routing Header Format
> and
>>>
>>> SourceRoutingOperations
>>>
>>>
>>>
>>> Hi John:
>>>
>>>
>>>
>>> IPv6 already has a number of routing headers, in particular
> RH0,
>>>
>>>
>>>
>>>
>>>
>>> though it is
>>>
>>>
>>>
>>>
>>>
>>> being deprecated for general use in the Internet.
>>>
>>> And there are reasons why the fields in RH0/1 are there and
> we need to
>>>
>>> make sure we lose none of that. In particular a RH is
> recoverable, and
>>>
>>>
>>>
>>>
>>>
>>> it is
>>>
>>>
>>>
>>>
>>>
>>> easy to spot the consumed entries.
>>>
>>>
>>>
>>> On top of this our new problems are:
>>>
>>> - make sure the RH stays within the RPL network (since it is
> used
>>>
>>>
>>>
>>>
>>>
>>> downwards
>>>
>>>
>>>
>>>
>>>
>>> that should be doable)
>>>
>>> - control the size (that probably means compress)
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From:roll-bounces@ietf.org
>    [mailto:roll-bounces@ietf.org] On
> Behalf
>>>
>>>
>>>
>>>
>>>
>>> Of
>>>
>>>
>>>
>>>
>>>
>>> JeongGil Ko (John)
>>>
>>> Sent: Wednesday, April 07, 2010 10:05 PM
>>>
>>> To: ROLL WG
>>>
>>> Subject: [Roll] Proposal for Source Routing Header Format
> and Source
>>>
>>> RoutingOperations
>>>
>>>
>>>
>>> Hi!
>>>
>>>
>>>
>>> Great to see all this discussions on downwards route
> establishment!
>>>
>>>
>>>
>>>
>>>
>>> To
>>>
>>>
>>>
>>>
>>>
>>> add
>>>
>>>
>>>
>>>
>>>
>>> one more to the conversations here is a proposal for
> source routing
>>>
>>>
>>>
>>>
>>>
>>> headers.
>>>
>>>
>>>
>>>
>>>
>>> In non-storing mode (where only the root has individual
> path
>>>
>>>
>>>
>>>
>>>
>>> information)
>>>
>>>
>>>
>>>
>>>
>>> the root will be attaching a source routing header to the
> data
>>>
>>>
>>>
>>>
>>>
>>> packet
>>>
>>>
>>>
>>>
>>>
>>> that a
>>>
>>>
>>>
>>>
>>>
>>> source node wants to send to a specific destination. We
> can always
>>>
>>>
>>>
>>>
>>>
>>> make the
>>>
>>>
>>>
>>>
>>>
>>> header super fancy but in my opinion I think we only need
> two fields
>>>
>>>
>>>
>>>
>>>
>>> in this
>>>
>>>
>>>
>>>
>>>
>>> header and here it is! Feel free to break the stuff and
> mangle with
>>>
>>>
>>>
>>>
>>>
>>> it
>>>
>>>
>>>
>>>
>>>
>>> so that it
>>>
>>>
>>>
>>>
>>>
>>> looks great in the specs later on. FYI, this is the
> format that I am
>>>
>>>
>>>
>>>
>>>
>>> using in my
>>>
>>>
>>>
>>>
>>>
>>> implementations so it does work :)
>>>
>>>
>>>
>>> 1. Source Routing Header Format
>>>
>>>
>>>
>>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>> |      NEntry (8 bits)      |
>>>
>>>
>>>
>>>
>>>
>>> |
>>>
>>>
>>>
>>>
>>>
>>> +-+-+-+-+-+-+-+-+
>>>
>>>
>>>
>>>
>>>
>>> +
>>>
>>>
>>>
>>>
>>>
>>> |                                              Source
> Route Entry (128*NEntry bits)
>>>
>>>
>>>
>>>
>>>
>>> |
>>>
>>>
>>>
>>>
>>>
>>> +
>>>
>>>
>>>
>>>
>>>
>>> +
>>>
>>>
>>>
>>>
>>>
>>> |
>>>
>>>
>>>
>>>
>>>
>>> |
>>>
>>>
>>>
>>>
>>>
>>> Figure 1. Proposed Source Routing Header
> Format; each line is
>>>
>>>
>>>
>>>
>>>
>>> 32
>>>
>>>
>>>
>>>
>>>
>>> bits:)
>>>
>>>
>>>
>>>
>>>
>>> - NEntry: Indicates the number of 128 bit addresses that
> the source
>>>
>>>
>>>
>>>
>>>
>>> route
>>>
>>>
>>>
>>>
>>>
>>> entry field is carrying.
>>>
>>>
>>>
>>> - Source Route Entry: List of 128 bit address that
> consist the route
>>>
>>>
>>>
>>>
>>>
>>> to the
>>>
>>>
>>>
>>>
>>>
>>> destination. Here, the address of the node that is one
> hop away from
>>>
>>>
>>>
>>>
>>>
>>> the
>>>
>>>
>>>
>>>
>>>
>>> *destination* comes first.
>>>
>>>
>>>
>>> 2. Source Routing Packet Operations
>>>
>>>
>>>
>>> When source routing is initiated at a storing node (e.g.,
> root of
>>>
>>>
>>>
>>>
>>>
>>> the
>>>
>>>
>>>
>>>
>>>
>>> DODAG),
>>>
>>>
>>>
>>>
>>>
>>> the header is attached on the data packet for the entire
> route
>>>
>>>
>>>
>>>
>>>
>>> (i.e.,
>>>
>>>
>>>
>>>
>>>
>>> from
>>>
>>>
>>>
>>>
>>>
>>> next hop node to the destination). This header is
> positioned in
>>>
>>>
>>>
>>>
>>>
>>> front
>>>
>>>
>>>
>>>
>>>
>>> of the
>>>
>>>
>>>
>>>
>>>
>>> user payload. When the next hop node receives a packet
> that is not
>>>
>>>
>>>
>>>
>>>
>>> destined
>>>
>>>
>>>
>>>
>>>
>>> to itself AND the network is NOT provisioned to be in
> 'storing mode'
>>>
>>>
>>>
>>>
>>>
>>> then it
>>>
>>>
>>>
>>>
>>>
>>> checks NEntry to find what the next hop is in the source
> route
>>>
>>>
>>>
>>>
>>>
>>> entry.
>>>
>>>
>>>
>>>
>>>
>>> Since
>>>
>>>
>>>
>>>
>>>
>>> the 'Source Route Entry' is ordered in 'farthest ->
> closest' (in
>>>
>>>
>>>
>>>
>>>
>>> terms
>>>
>>>
>>>
>>>
>>>
>>> of hops)
>>>
>>>
>>>
>>>
>>>
>>> order, a node can figure out what the next hop address is
> with only
>>>
>>>
>>>
>>>
>>>
>>> the
>>>
>>>
>>>
>>>
>>>
>>> NEntry value (since it already knows how big an ipv6
> address is).
>>>
>>>
>>>
>>>
>>>
>>> After
>>>
>>>
>>>
>>>
>>>
>>> collecting the next hop node's address, the node erases
> this address
>>>
>>> element from the entry and decreases NEntry by one. This
> assures
>>>
>>>
>>>
>>>
>>>
>>> that
>>>
>>>
>>>
>>>
>>>
>>> we
>>>
>>>
>>>
>>>
>>>
>>> avoid the overhead of carrying the entire source route
> throughout
>>>
>>>
>>>
>>>
>>>
>>> the
>>>
>>>
>>>
>>>
>>>
>>> data
>>>
>>>
>>>
>>>
>>>
>>> path.
>>>
>>>
>>>
>>> The approach itself should be very simple and trivial for
> everyone
>>>
>>>
>>>
>>>
>>>
>>> to
>>>
>>>
>>>
>>>
>>>
>>> follow.
>>>
>>>
>>>
>>>
>>>
>>> So we can start from here and build on!
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> -John
>>>
>>>
>>>
>>> ------
>>>
>>> JeongGil Ko (John)
>>>
>>> Ph.D. Student
>>>
>>> Department of Computer Science
>>>
>>> Johns Hopkins University
>>>
>>> http://www.cs.jhu.edu/~jgko
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Roll mailing list
>>>
>>> Roll@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Roll mailing list
>>>
>>> Roll@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Roll mailing list
>>>
>>> Roll@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>
>
>
>
_______________________________________________
>>>
>>> Roll mailing list
>>>
>>> Roll@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________ Roll mailing list
> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>



From gnawali@cs.stanford.edu  Thu Apr 15 09:20:31 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0989D3A694E; Thu, 15 Apr 2010 09:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.677
X-Spam-Level: 
X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-EM7qFUBkiX; Thu, 15 Apr 2010 09:20:29 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A72833A698D; Thu, 15 Apr 2010 09:20:27 -0700 (PDT)
Received: from mail-yx0-f184.google.com ([209.85.210.184]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2Rng-0001ff-Mm; Thu, 15 Apr 2010 09:20:21 -0700
Received: by yxe14 with SMTP id 14so856723yxe.5 for ; Thu, 15 Apr 2010 09:20:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Thu, 15 Apr 2010 09:12:27 -0700 (PDT)
In-Reply-To: <201004150813.26049.henning.rogge@fkie.fraunhofer.de>
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com>    <201004150813.26049.henning.rogge@fkie.fraunhofer.de>
From: Omprakash Gnawali 
Date: Thu, 15 Apr 2010 09:12:27 -0700
Received: by 10.150.160.16 with SMTP id i16mr508255ybe.172.1271347967265; Thu,  15 Apr 2010 09:12:47 -0700 (PDT)
Message-ID: 
To: Henning Rogge 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50
Cc: roll@ietf.org, MANET IETF , Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:20:31 -0000

On Wed, Apr 14, 2010 at 11:13 PM, Henning Rogge
 wrote:
> On Thu April 15 2010 01:55:27 Omprakash Gnawali wrote:
>> On Wed, Mar 17, 2010 at 9:52 AM, Henning Rogge 
> wrote:
>> > Am Mittwoch 17 M=E4rz 2010 17:25:25 schrieb Philip Levis:
>> >> > We have experimented with EWMA based in the Freifunk networks (IEEE
>> >> > 802.11 based meshs), and we had better experience with the fixed
>> >> > window than the EWMA. EWMA is more difficult to adapt to events tha=
t
>> >> > don't occur on a regular interval.
>> >>
>> >> Interesting. I'd love to see what the link behavior of these networks
>> >> look like.
>> >
>> > My experience in emulation with EWMA is that their two advantages (a
>> > single tuning parameter and more influence to recent data) is their
>> > disadvantage too. EWMA values. Because of the higher influence of rece=
nt
>> > data EWMA-based ETX tends to jump up/down more because of it's binary
>> > input (packet
>> > received/lost).
>> >
>> >> Do you have a writeup of what led you to this conclusion?
>> >
>> > No, sorry.
>> >
>> >> >> A fixed sized window assumes that channel dynamics only occur on a
>> >> >> time scale ~ the size of the window or longer. Clearly this isn't
>> >> >> the case with interference. Measurements I've seen of the 2.4GHz
>> >> >> band point to signal dynamics on the range of <500ms.
>> >> >
>> >> > You don't want your LQ value change quicker than you can transport =
it
>> >> > to the network. That can be a desaster (depending on protocol and
>> >> > network topology).
>> >>
>> >> Ah -- I think this is where we differ. I want the LQ value to be as
>> >> accurate as possible: the perfect LQ would simply output 0 or 1 (will
>> >> this packet be delivered).
>> >
>> > This metric would be nearly useless for multihop networks. ;)
>> >
>> >> It's then up to the routing protocol to apply
>> >> hysteresis or smoothing in order to keep the topology stable. Otherwi=
se
>> >> you've coupled the two designs.
>> >
>> > I would think that hysteresis is part of the metric generation process=
. A
>> > good hysteresis can keep the "speed" of the metric change down to
>> > something the adhoc network can handle. Unless the "fast time"
>> > variations of the metric are higher than the hysteresis threshold.
>>
>> I finished doing experiments comparing ewma link estimator and fixed
>> window estimator with a window size of 10.
> 10 seems to be a very low ETX window size.
>
>> Here are the results:
>> http://stuff.stanford.edu/~om_p/ctp/ewmawindowle.html
>>
>> The summary is window ETX seems too sensitive causing high churn and
>> resulting in poor path selection. EWMA seems to work much better.
> Using all incoming packets to calculate the ETX value and using a fixed s=
liding
> window of binary events (received/lost) is not a good idea.
>
> Packet transmission over a link does not happen in constant intervals, so=
 the
> your metric will jump up/down very quickly if you receive/loose a burst o=
f
> packets.
>
> I'm not surprised that ETX does not behave well in this scenario.

Earlier you had mentioned that Window ETX has been used in a
deployment (Freifunk?) and it showed great improvement over EWMA ETX.
It will be great if you can send the precise details of that estimator
and the experiment/deployment scenario so I can evaluate it on the
15.4 on the 54-node testbed. There are probably many ways to improve
the Window ETX but I am afraid I don't have the cycles to explore that
rather large design space. I am simply offering to provide a data
point or two on mechanisms that are known to work on other
environments or experiments.

- om_p

From gnawali@cs.stanford.edu  Thu Apr 15 09:22:48 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F241E28C1E2; Thu, 15 Apr 2010 09:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.327
X-Spam-Level: 
X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znDf6RRNyeen; Thu, 15 Apr 2010 09:22:46 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 3EE0A28C186; Thu, 15 Apr 2010 09:21:34 -0700 (PDT)
Received: from mail-yx0-f184.google.com ([209.85.210.184]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2Rom-0001kx-3B; Thu, 15 Apr 2010 09:21:28 -0700
Received: by yxe14 with SMTP id 14so857217yxe.5 for ; Thu, 15 Apr 2010 09:21:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Thu, 15 Apr 2010 09:21:07 -0700 (PDT)
In-Reply-To: 
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com>    <201004150813.26049.henning.rogge@fkie.fraunhofer.de> 
From: Omprakash Gnawali 
Date: Thu, 15 Apr 2010 09:21:07 -0700
Received: by 10.150.77.25 with SMTP id z25mr618065yba.111.1271348487100; Thu,  15 Apr 2010 09:21:27 -0700 (PDT)
Message-ID: 
To: Yoav Ben-Yehezkel 
Content-Type: text/plain; charset=ISO-8859-1
X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3
Cc: MANET IETF , roll@ietf.org, Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:22:48 -0000

On Wed, Apr 14, 2010 at 11:56 PM, Yoav Ben-Yehezkel  wrote:
> I agree that doing a windowing mechanism on "failure rates" (i.e.
> #retransmissions over a fixed time window) instead of a windowing
> mechanism on "number of failures" without any time normalization would
> make more sense as a meaningful metric.

My implementation used a fixed window (10) of the number of packets
success/failure. I wasn't sure that is what you were referring to with
"number of failures".

Failure rate makes sense but there are may other design choices that
make sense as well. If you have experimental parameters and evidence,
which makes this approach to make more sense, it will be great if you
can share them, especially the experiment setup parameters (the
estimator as well as network on which such ideas were tested) so that
my experiments aren't too far off from yours.

- om_p

From pal@cs.stanford.edu  Thu Apr 15 09:26:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF4128C1F3; Thu, 15 Apr 2010 09:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2P0JLXxcE4Z; Thu, 15 Apr 2010 09:26:07 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 52BC328C23A; Thu, 15 Apr 2010 09:24:50 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O2Rrv-0007JZ-SH; Thu, 15 Apr 2010 09:24:44 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: 
Date: Thu, 15 Apr 2010 09:24:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com>  <201004150813.26049.henning.rogge@fkie.fraunhofer.de>  
To: Omprakash Gnawali 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: 5e15904e367bf57319d290d73554c551
Cc: roll@ietf.org, MANET IETF , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:26:08 -0000

On Apr 15, 2010, at 9:21 AM, Omprakash Gnawali wrote:

> On Wed, Apr 14, 2010 at 11:56 PM, Yoav Ben-Yehezkel  =
wrote:
>> I agree that doing a windowing mechanism on "failure rates" (i.e.
>> #retransmissions over a fixed time window) instead of a windowing
>> mechanism on "number of failures" without any time normalization =
would
>> make more sense as a meaningful metric.
>=20
> My implementation used a fixed window (10) of the number of packets
> success/failure. I wasn't sure that is what you were referring to with
> "number of failures".
>=20
> Failure rate makes sense but there are may other design choices that
> make sense as well. If you have experimental parameters and evidence,
> which makes this approach to make more sense, it will be great if you
> can share them, especially the experiment setup parameters (the
> estimator as well as network on which such ideas were tested) so that
> my experiments aren't too far off from yours.

I think the basic difference is whether the link quality is measured =
with data packets or periodic beacons. The standard mesh approach is the =
latter, while your experiment used the former?

Phil=

From hrogge@googlemail.com  Thu Apr 15 09:26:09 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36ED28C1F3; Thu, 15 Apr 2010 09:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.742
X-Spam-Level: 
X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGh7qeMKQ7Tp; Thu, 15 Apr 2010 09:26:08 -0700 (PDT)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 2F7FE28C201; Thu, 15 Apr 2010 09:24:51 -0700 (PDT)
Received: by ewy24 with SMTP id 24so603857ewy.13 for ; Thu, 15 Apr 2010 09:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=3hsyw3P/w2jN2SPDdRkD55zIcqaYWtr4gc2S9j5PSg4=; b=PlSI8dfKD9kd3Tzu8TjrKHjWGt36PLiDXlGuDMy/aF22jejW3SLZoBS6MgICVWNYvS Opki3NdphHlPWGXoZBOOHPi41GtzxGELNakng9sdMrfXzvaR87tw7wcxeyBe5x412d6o Ah2nSBsEJef01OdhD6OPRlhU7pMR3fFyJoECM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=WSO7aL3oAxPWBBYJgdT62lqKVrFxREwvux4G/FSfkFe9nY+ZW76GtnsVrsjTFNDzkD h7f+b8A3yVHQDqf4RFJd7y1NOtlTzJ1EA7exlHZ1OOaTcfyzfxwXfCe0wz6Mr2tON/Xi 57OZ27vlZI6BoKLNXZbnEkfutOqxXcZivp3HE=
Received: by 10.213.46.13 with SMTP id h13mr4981899ebf.83.1271348679657; Thu, 15 Apr 2010 09:24:39 -0700 (PDT)
Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 13sm1084935ewy.9.2010.04.15.09.24.36 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 09:24:36 -0700 (PDT)
From: Henning Rogge 
To: Omprakash Gnawali 
Date: Thu, 15 Apr 2010 18:24:29 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo-r1; KDE/4.4.2; x86_64; ; )
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201004150813.26049.henning.rogge@fkie.fraunhofer.de> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1378858.PTfBUQz9lo"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201004151824.35134.hrogge@googlemail.com>
Cc: MANET IETF , roll@ietf.org, Marcello Caleffi , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:26:09 -0000

--nextPart1378858.PTfBUQz9lo
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am Donnerstag 15 April 2010 18:12:27 schrieb Omprakash Gnawali:
> Earlier you had mentioned that Window ETX has been used in a
> deployment (Freifunk?) and it showed great improvement over EWMA ETX.
> It will be great if you can send the precise details of that estimator
> and the experiment/deployment scenario so I can evaluate it on the
> 15.4 on the 54-node testbed. There are probably many ways to improve
> the Window ETX but I am afraid I don't have the cycles to explore that
> rather large design space. I am simply offering to provide a data
> point or two on mechanisms that are known to work on other
> environments or experiments.
We have used packet based ETX for a long time (with a window size of 128), =
but=20
it was not 'time stable' (because the it averaged the arrival of packets, n=
ot=20
the arrival rate). We tried to replace it with an ETX based on EWMA, but it=
=20
didn't worked well for our scenario, either converging to slowly or jumping=
=20
up/down too much (the code had no working hysteresis at this point).

At the moment we are using a ETX with a sliding window which counts the=20
received and lost packets during each second, then add them all together an=
d=20
use them to calculate the average rate, this seems to be working very well=
=20
(and is very easy to do in integer arithmetics).

I was thinking about using an EWMA over a "rate within the last second" val=
ue,=20
but I fear that it breaks down if it get's not enough packets within a seco=
nd.=20
This would mean the 'inaccurate' new measurement will influence the total E=
TX=20
value too much.

Henning Rogge


=2D-=20
1) You can't win.
2) You can't break even.
3) You can't leave the game.
=E2=80=94 The Laws of Thermodynamics, summarized

--nextPart1378858.PTfBUQz9lo
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEABECAAYFAkvHPcMACgkQcenvcwAcHWe3FgCfYggRa0kW0DA5nqsjxWwOxs/7
og4AniY8SkvXURJ9EjQltyAcQh5XkltV
=sOG9
-----END PGP SIGNATURE-----

--nextPart1378858.PTfBUQz9lo--

From hrogge@googlemail.com  Thu Apr 15 09:28:12 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5E93A6B92; Thu, 15 Apr 2010 09:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.763
X-Spam-Level: 
X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSk9c4WQv0Vp; Thu, 15 Apr 2010 09:28:11 -0700 (PDT)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D790E3A6BB9; Thu, 15 Apr 2010 09:27:44 -0700 (PDT)
Received: by ewy24 with SMTP id 24so605194ewy.13 for ; Thu, 15 Apr 2010 09:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=/lS9AmTIQkQo31vbQpV+kmyQ41f/6LfwfvWzydPMXMw=; b=gowBmNKzSQXzY2K+I+PDjgzT93QY6nFAMdM0s7oEsaKs9h5x21DEa+CEWtB4UBKzjS eKY6UNwQJy8Mcn/vaf3ak5Uw75DgtZ8xtB9fcQIG1HkCc4LdEXyD5fjShz8tQJJAcfva aVeC62csw6FJSBiXwM5hgIaGDzu9X8vE4qw7E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=EU2bGE0+/cGvxjs15tEEQ8tXC6N7ncWbe0RfxLh+hPnIehOY5cGBSPBXnzVpJr9Tqh 7TzgpdTwGVrO7Hmg/+tbiGmDYpdHZRr1yVENOZ8YNpL/OruO60JscfBUAJ9w/psAvo25 nSGlhbf17j7dzNt8fA2H6iZVA9nA8Fpxdzmg0=
Received: by 10.213.2.79 with SMTP id 15mr173063ebi.96.1271348854252; Thu, 15 Apr 2010 09:27:34 -0700 (PDT)
Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 16sm1097962ewy.3.2010.04.15.09.27.33 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 09:27:33 -0700 (PDT)
From: Henning Rogge 
To: roll@ietf.org
Date: Thu, 15 Apr 2010 18:27:27 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo-r1; KDE/4.4.2; x86_64; ; )
References: <20100223045634.C3F6328C44F@core3.amsl.com>  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1749298.pNIFpbnNdK"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201004151827.32470.hrogge@googlemail.com>
Cc: MANET IETF , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:28:13 -0000

--nextPart1749298.pNIFpbnNdK
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am Donnerstag 15 April 2010 18:24:42 schrieb Philip Levis:
> I think the basic difference is whether the link quality is measured with
> data packets or periodic beacons. The standard mesh approach is the
> latter, while your experiment used the former?
In OLSR you can measure the arrival rate of all OLSR packets instead of usi=
ng=20
only the Hello messages. This allow you for a better estimation of link=20
quality for larger meshs (more TCs !).

Henning Rogge

=2D-=20
1) You can't win.
2) You can't break even.
3) You can't leave the game.
=E2=80=94 The Laws of Thermodynamics, summarized

--nextPart1749298.pNIFpbnNdK
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEABECAAYFAkvHPnQACgkQcenvcwAcHWekBACdEAmDmMV1dhqVsFEueUMLODhL
gBgAn2usIDOH7xNlk+1vaxH2ziGv72+X
=hKIu
-----END PGP SIGNATURE-----

--nextPart1749298.pNIFpbnNdK--

From yoav@yitran.com  Thu Apr 15 09:31:55 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6E93A6BC0; Thu, 15 Apr 2010 09:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.674
X-Spam-Level: 
X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.303,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KokYVETbKIdf; Thu, 15 Apr 2010 09:31:54 -0700 (PDT)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 4C3493A6BC6; Thu, 15 Apr 2010 09:31:53 -0700 (PDT)
Received: from source ([209.85.218.214]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKS8c/cq8/ACTYpC32V+ZzU6YaFp5AxrV/@postini.com; Thu, 15 Apr 2010 09:31:47 PDT
Received: by mail-bw0-f214.google.com with SMTP id 6so1638916bwz.33 for ; Thu, 15 Apr 2010 09:31:46 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com>     <201004150813.26049.henning.rogge@fkie.fraunhofer.de>     
In-Reply-To: 
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrcuDEj6ehl5Cl5Tpm0bN2TaEKE2wAABo5w
Date: Thu, 15 Apr 2010 19:31:48 +0300
Received: by 10.204.33.194 with SMTP id i2mr337242bkd.140.1271349106046; Thu,  15 Apr 2010 09:31:46 -0700 (PDT)
Message-ID: <29a9d0f5f41f677c71869f6986129cf4@mail.gmail.com>
To: Philip Levis , Omprakash Gnawali 
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll@ietf.org, MANET IETF , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:31:55 -0000

Yes. That was my intention and I think also the MANET RFC spoke of some
TIME_INTERVAL.

I'm sorry Omprakash that I have no inputs that I can share with you other
than my intuition from past experience of a somewhat similar mechanism in
a proprietary protocol (for measuring management packet rates), so I know
the windowed estimation of rates works pretty well. The only issue is to
select a large enough time-window size to have a reasonable amount of
samples.

Thanks,
Yoav


-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu]
Sent: Thursday, April 15, 2010 7:25 PM
To: Omprakash Gnawali
Cc: Yoav Ben-Yehezkel; MANET IETF; roll@ietf.org; Thomas Heide Clausen
Subject: Re: [manet] [Roll] Fwd: New Version Notification for
draft-gnawali-roll-etxof-00


On Apr 15, 2010, at 9:21 AM, Omprakash Gnawali wrote:

> On Wed, Apr 14, 2010 at 11:56 PM, Yoav Ben-Yehezkel 
wrote:
>> I agree that doing a windowing mechanism on "failure rates" (i.e.
>> #retransmissions over a fixed time window) instead of a windowing
>> mechanism on "number of failures" without any time normalization would
>> make more sense as a meaningful metric.
>
> My implementation used a fixed window (10) of the number of packets
> success/failure. I wasn't sure that is what you were referring to with
> "number of failures".
>
> Failure rate makes sense but there are may other design choices that
> make sense as well. If you have experimental parameters and evidence,
> which makes this approach to make more sense, it will be great if you
> can share them, especially the experiment setup parameters (the
> estimator as well as network on which such ideas were tested) so that
> my experiments aren't too far off from yours.

I think the basic difference is whether the link quality is measured with
data packets or periodic beacons. The standard mesh approach is the
latter, while your experiment used the former?

Phil

From gnawali@cs.stanford.edu  Thu Apr 15 09:52:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBD33A6BB7; Thu, 15 Apr 2010 09:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.667
X-Spam-Level: 
X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPz+nz6h3ADf; Thu, 15 Apr 2010 09:52:43 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id DFD053A6BB4; Thu, 15 Apr 2010 09:52:43 -0700 (PDT)
Received: from mail-gw0-f44.google.com ([74.125.83.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2SIv-0006w7-AI; Thu, 15 Apr 2010 09:52:37 -0700
Received: by gwj19 with SMTP id 19so16206gwj.31 for ; Thu, 15 Apr 2010 09:52:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.95.1 with HTTP; Thu, 15 Apr 2010 09:52:13 -0700 (PDT)
In-Reply-To: 
References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003171752.36500.hrogge@googlemail.com>    <201004150813.26049.henning.rogge@fkie.fraunhofer.de>     
From: Omprakash Gnawali 
Date: Thu, 15 Apr 2010 09:52:13 -0700
Received: by 10.150.56.27 with SMTP id e27mr548208yba.81.1271350356399; Thu,  15 Apr 2010 09:52:36 -0700 (PDT)
Message-ID: 
To: Philip Levis 
Content-Type: text/plain; charset=ISO-8859-1
X-Scan-Signature: b64bce576883819501cf77c9371f4538
Cc: roll@ietf.org, MANET IETF , Thomas Heide Clausen 
Subject: Re: [Roll] [manet] Fwd: New Version Notification for draft-gnawali-roll-etxof-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 15 Apr 2010 16:52:44 -0000

On Thu, Apr 15, 2010 at 9:24 AM, Philip Levis  wrote:
>
> On Apr 15, 2010, at 9:21 AM, Omprakash Gnawali wrote:
>
>> On Wed, Apr 14, 2010 at 11:56 PM, Yoav Ben-Yehezkel  wrote:
>>> I agree that doing a windowing mechanism on "failure rates" (i.e.
>>> #retransmissions over a fixed time window) instead of a windowing
>>> mechanism on "number of failures" without any time normalization would
>>> make more sense as a meaningful metric.
>>
>> My implementation used a fixed window (10) of the number of packets
>> success/failure. I wasn't sure that is what you were referring to with
>> "number of failures".
>>
>> Failure rate makes sense but there are may other design choices that
>> make sense as well. If you have experimental parameters and evidence,
>> which makes this approach to make more sense, it will be great if you
>> can share them, especially the experiment setup parameters (the
>> estimator as well as network on which such ideas were tested) so that
>> my experiments aren't too far off from yours.
>
> I think the basic difference is whether the link quality is measured with data packets or periodic beacons. The standard mesh approach is the latter, while your experiment used the former?

I was using data and control packets. This might be one major
difference between the standard mesh approach and CTP-ewma/window
approach.

- om_p

From nicolas.dejean.ietf@googlemail.com  Fri Apr 16 12:48:00 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C415D3A69A6 for ; Fri, 16 Apr 2010 12:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.863
X-Spam-Level: *
X-Spam-Status: No, score=1.863 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNdMJXGe1-4D for ; Fri, 16 Apr 2010 12:47:59 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 471EC28C149 for ; Fri, 16 Apr 2010 12:47:56 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so954488qwb.31 for ; Fri, 16 Apr 2010 12:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oAvx95vOHAoGhnoqSs7mMAQ5Cg3YHoeVOK2sfPyKIAM=; b=d5N9XUTNgXBb9HKaaghN+PKt42zqexEV6K2HjtxFTP8LXqlayMj8nDqWpySd6BtpzF V6hkxrgNBaywkC9wIUgWGodNbyVjo7JVxGSd/c3/EGAsrxZ1kmFv4Zc7NcW6heJR5ew3 vd2wI/SsG7UoPVJv9zYYkk7CRdEIHPpPvSnd0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bFTk9d6Tg5g62EC82QSkUUx5zTeIhpLQwVzG2keueVufoZv53nh9ggGVvEcQ6+yby9 SCGgh+J9jIlnBM6jY+OE513uDZNOa+zOv2t6vCROPhoq5scZgF5XKR8ttiOAKkLcoyuE bgQLbg7hlriokaVtFo5p5WuUVjFR+k44yMIWk=
MIME-Version: 1.0
Received: by 10.229.18.80 with HTTP; Fri, 16 Apr 2010 12:47:43 -0700 (PDT)
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019BD364@XMB-AMS-107.cisco.com>
References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> <6E216052-FF19-45BC-8BF7-0261E007A3B4@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D01923FED@XMB-AMS-107.cisco.com> <929D4899-351F-4E4D-9A76-E642A000A84D@cs.stanford.edu> <4BBB3809.3090102@ieee.org> <2B49DC29-6FB3-40E6-9C95-96634CE8BE9B@cs.stanford.edu> <001c01cad5c4$77c8b8f0$675a2ad0$@com>  <168d73a61dcec2047687f031edd1e3d7@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D019BD364@XMB-AMS-107.cisco.com>
Date: Fri, 16 Apr 2010 21:47:43 +0200
Received: by 10.229.239.149 with SMTP id kw21mr2690273qcb.99.1271447263463;  Fri, 16 Apr 2010 12:47:43 -0700 (PDT)
Message-ID: 
From: Nicolas DEJEAN 
To: "Pascal Thubert (pthubert)" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: roll@ietf.org, phoebus@ieee.org
Subject: Re: [Roll] [roll] #29: DIS packet format
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 16 Apr 2010 19:48:00 -0000

Hi all,

I would like to study this topic on the use case point of view.

Thank you for reading.

Nicolas.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Importance of the bottom-up connection method:
---------------------------------------------------------------------

According to my understanding of RPL, it seems that an orphan router
that wants to join a network without waiting for potentially late DIO
should do the following:
- optionally sending a DIS for quick connection,
-=A0interpretation of DIOs obtained in response for parent(s) selection,
-=A0optionally DAO generation for becoming a destination.

=A0According to my experience in metering network:
- some known cases require a bottom-up installation:
    - punctually adding new endpoints (local extension) or replacing
endpoints (maintenance) in an existing and well working network,
    -=A0add a complete new application in an existing and well working
network (for instance, an electricity metering network has been
deployed and it is now expected to connect water/gas meters to the
electricity meters)
-=A0a utility technician wants to connect its equipment and be sure that
it is really connected in a reasonable time and often in the shortest
possible time (1 minute =3D 1 euro !)

=A0In this case, it seems really important for this kind of applications
to have an efficient connection process bottom-up.

Parameterization of the Trickle Timer:
-----------------------------------------------------

For reaching expected battery lifetime on both battery-operated
routers and endpoints, the parameters of the Trickle Timer should be
set in a way that ensures low energy loss even when running at its
minimum period.
-=A0Otherwise, the cost of a single endpoint connection could be
dramatic as it resets the Trickle Timer of all the devices in its RF
range, triggering extra transmissions and overhearing.
-=A0If we consider an installation session that lasts several days, that
also means that potentially, the routers in the area of the considered
DODAG would reset their timer interval to =A0the minimal period many
times for several days.

So, on the one hand, we need a short term mechanism for quick
installation processes, and on the other hand we want to have the
Trickle Timer as relaxed as possible for reaching the expected battery
lifetime of the installed devices.

For instance, a parameterization of the Trickle Timer could be:
- min period =3D 1 hour,
-=A0max period =3D 1 day (or even a few days)

=A0As the initial goal of the Trickle Timer is to provide a smart
consistency maintenance mechanism through the network, which it does
perfectly, we can conclude that we need another mechanism for reaching
the second requirement of this class of applications, i.e. a quick
connection process.

Quick connection process proposal:
---------------------------------------------------

In a general manner, I fully agree with most of the proposals of
Phoebus and Pascal in the current thread:
- Do not link the reset of the Trickle Timer with the method of
transmission of DIS (unicast/multicast) but instead use a flag for
that purpose:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03570.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03571.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03590.html
    - http://www.ietf.org/mail-archive/web/roll/current/msg03604.html
-=A0Avoid making the Trickle Timer much more than it was originally
designed to do:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03600.html
- Find a way to avoid restarting the exponential backoff game from start:
    - http://www.ietf.org/mail-archive/web/roll/current/msg03630.html

I would even go a little bit further by saying that the mode used for
sending DIOs=A0 (unicast/multicast) should also be dictated by a U flag
contained in the DIS, but let us see why later.

=A0The idea is to propose a way to achieve a quick connection to the
network without resetting the Trickle Timer of all the answering nodes
as the insertion of a new node should not be systematically detected
as an inconsistency.

=A0I think the following mechanism could allow reaching this double goal:
-=A0A DIS message can be sent in multicast mode without setting the C/R
flag (reset Trickle Timer), because this DIS does not imply
inconsistency.
-=A0The optional usage of some filters contained in the DIS message
could allow only a subset of the receivers to answer, thus drastically
reducing the 1-hop storm possibility.
-=A0In this case all answering nodes should answer as immediately as
possible in unicast mode to the DIS originator. If multicast mode is
used for DIOs in this case, some inconsistency might be detected at an
unexpected instant as a simple connection of a new device to the
network could trigger a control traffic storm:
    - If filters are used in the DIS, we can expect that the MAC Layer
will be able to deal=A0 with this controlled answer storm
    - If no filter is used, the answering node should set up a
temporary shorter exponential window based on the Trickle Timer
configured with specific parameters (that could be passed into the DIS
request). The Trickle Timer is then configured back with its default
parameters after the DIOs wave. The expected DIOs wave duration could
also be a parameter of the DIS in this case, which would mean
something like: I will listen for DIOs for XX seconds for instance.

Please, note that (according to my knowledge of the draft) this
specific mechanism does not go against any of the other mechanisms
already described.

=A0This is simply a new usage case which is triggered by a DIS sent:
-=A0multicast,
-=A0without Reset Trickle flag set.

Then the receivers of the DIS simply answer almost immediately and do
not modify their background activity in the existing and well-working
network which allows reaching the initial double goal of:
-=A0providing a quick connection process,
-=A0without changing the background activity of the existing and
well-working network, thus avoiding any energy loss.

=A0A cleaner alternative would be to use an additional flag requesting
the DIOs to be sent in unicast mode. Let us call it the U flag which
triggers multicast DIOs when reset and unicast DIOs when set.

The considered DIS message would then have the following specificities:
-=A0sent in multicast mode,
-=A0C/R flag is reset,
-=A0U flag is set,
-=A0Optionally it could embed (to be defined later):
    - Temporary Trickle Timer parameters,
    - Expected DIOs wave duration,
    - Smart filters for reducing the number of triggered DIOs

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From roger.alexander@ekasystems.com  Fri Apr 16 14:36:55 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB42C3A6BA4 for ; Fri, 16 Apr 2010 14:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Level: 
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-1.481,  BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDjVj8kYLWrs for ; Fri, 16 Apr 2010 14:36:54 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id C43A63A69B1 for ; Fri, 16 Apr 2010 14:33:36 -0700 (PDT)
Received: (qmail 59666 invoked from network); 16 Apr 2010 21:33:27 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp112.biz.mail.re2.yahoo.com with SMTP; 16 Apr 2010 14:33:26 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: IP3FGUwVM1lDaay_PgERI1rxjqDif1mXW5j_Of9gszMka_zdKNTPaLaZnc_v9_b7hdZgSvOCKM_0AaKhe0v7agVRLK2PLTmoDuUuVF0V9n4OVDPDYXndIz5zr1TAeSMXoWYeKwv9aHlhw1Z44XSUTFgRmkH6XsL6gIR0NCGu3CicmmN_g9sc7E082UnOdI1cSiFvsQF0BGBSHHml47Ykh2QEl0zFIi4kXLdfQ6TDjj6GGn2MgTTYn6O__tkyRm4gnmtV5YAmwnHPgpqw4Iua_ghZmOn2QYoCDpNBNn11q7B4_yLKxmRrhy.WEMPbyNJTN009MUaRTeiLikXIoKu0aKB8NT0NsF4CCDT1QvRyefMYQOHbMmCDAKJqwN.BaoI-
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Pascal Thubert \(pthubert\)'" , "'Navneet Agarwal \(navagar\)'" , "'JP Vasseur'" , 
References: <6A2A459175DABE4BB11DE2026AA50A5D01A38C5D@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01A38C5D@XMB-AMS-107.cisco.com>
Date: Fri, 16 Apr 2010 17:31:46 -0400
Message-ID: <00fe01caddac$37981e70$a6c85b50$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acra3YQmilVAN0aqSeq3ZEOdvie1dACixa1A
Content-Language: en-us
Cc: 'ROLL WG' 
Subject: Re: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back welcome)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 16 Apr 2010 21:36:56 -0000

Below is a quick summary aligned to Tim's concept of how the Path Control
bitmap associated with the DAO destination address can be used to limit fan
out and to identify the preferred path when nodes maintain multiple DAO
Parents.

Further details and examples can be provided as part of an larger
application domain note.

Roger   

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Tuesday, April 13, 2010 3:47 AM
> To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
> wintert@acm.org
> Cc: ROLL WG
> Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
> 
> 
> 
> Pascal
> 
> > One consequence of maintaining multiple DAO parents is the potential
> fan
> > out of routing paths. With path fan out a node may have multiple
> downward
> > next hop addresses for a given target destination address. Without
> some
> > path preference indication there is no information available if a
> storing node
> > (including the root) wishes to limit the number of downward next hops
> > maintained for a given address. It is thus desirable to have some
> means of
> > path control to limit fan out as well as a preference indication that
> can work in
> > conjunction with the hop-by-hop DAO exchanges.
> >
> > See the Figure below for an example in which nodes maintain two DAO
> > Parents each, where in the worst case the fan out that occurs after
> three
> > hops results in eight next hop downward paths from the DODAG root
> (LBR)
> > to a target node (41). Even with the hop-by-hop DAO mechanism it
> would
> be
> > desirable to be able to limit fan out as well as to identify path
> preference and
> > diversity at the root or other intermediate storing node.
> >
> >                     (------------LBR------------)
> >                     /    /   / |     | \    \   \
> >                    /    /   /  |     |  \    \   \
> >                   /    /   /   |     |   \    \   \
> >                  /    /   /    |     |    \    \   \
> >               (11) (12) (13) (14)   (15) (16) (17) (18)
> >                  \   |    |    /     \    |    |   /
> >                   \  |    |   /       \   |    |  /
> >                    \ |    |  /         \  |    | /
> >                   (21)   (22)           (23)  (24)
> >                       \    |            |    /
> >                        \   |            |   /
> >                         \  |            |  /
> >                          (31)          (32)
> >                              \        /
> >                               \      /
> >                                \    /
> >                                 (41)
> >
> 
> [Pascal] Your schema illustrates clearly that even if we fan out a lot,
> it does not mean that a router on the way down will have more feasible
> successors.
> 
> That's one thing that's important to remember, the properties of the
> DAG
> are not symmetrical, so even if we build it to get multiple feasible
> successors on the way up, that does not mean that on the reverse DAG to
> a target there are multiple successors at each hop towards that target.
> 
> In other words, the ROI of fanning out is not guaranteed if we do it
> blindly.
> 
> > A simple path control bitmap associated with the advertised
> Destination
> > Address can be included within the DAO to address the issue of path
> > preference as well as control of fan out. For a network of
> 'non-storing'
> > nodes the preference indication would be processed only at the root.
> 
> [Pascal] so far so good, but that will give you a blind mechanism.
> 
> > With the path control byte associated with each DAO destination
> address, a
> > node will be able to specify preference among DAO parent paths and
> can
> > convey limits on the number of downward paths. This is an opportunity
> for
> > nodes to further influence the downward paths that are established
> and
> > maintained. Consistent with the DV-based RPL operation this DAO path
> > control mechanism must operate hop-by-hop avoiding any requirement
> for
> > end-to-end path coordination. To avoid overloading this email thread
> I
> will
> > initiate a separate discussion on how a path control element may be
> included
> > within the DAO.
> >
> [Pascal] Too late, I just did :)
> 
> And if I remember, Tim's idea was to control the stretch of the fanout,
> by decrementing a counter as the path loses preference point.
> At the moment, we have a parent preference 0-lowest to 3 highest. So it
> is easy to decrement a counter by (3-pref) and not fan out when the
> counter reaches 0.
> Tim, could you elaborate on this?

A Path Control bit map will achieve an equivalent control mechanism whereby
at each node the number of bits that are set will determine the extent to
which the associated DAO Destination Address can be advertised to multiple
DAO Parents. If a DAO message destination address Path Control bitmap has 4
set bits, that address can be send along a maximum of 4 paths. For example,
at the originating node the DAO can be sent to two DAO Parents where the
Path Control bit map in the message sent to each DAO Parent will have two
set bits. If each parent then advertises to two DAO Parents a single bit is
set for each DAO message. Eventually with a single bit set in the Path
Control bit map, the DAO message can be advertised only to a single DAO
Parent. This mechanism achieves the effect of limiting the stretch of the
path fan out. Where multiple DAO messages are received at a common ancestor
the number of set bits in the respective Path Control fields are recombined
allowing for renewed advertising of the DAO message destination address to
multiple DAO Parents along the path. 

As the set Path Control bits are split and recombined as the DAO messages
are transferred to the root, their bit positions are maintained. This allows
bit positions to be ordered from low to high in terms of path preference.
Therefore when a DAO message is received in which the Path Control bitmap
has the highest preference bit set, that DAO message destination address is
always advertised to the preferred DAO Parent. Similarly, when a message is
received with multiple Path Control bits set, the DAO messages can be
distributed to DAO Parents according to parent preference. This will ensure
that at any common ancestor, including the root, a node is always able to
distinguish the preferred downward path. The ability to determine the
preferred downward path as well as to obtain an indication of path diversity
will allow the Path Control field to be used when resource limitations at a
node require a truncation of the number of downward paths that the node
maintain for a given destination address. 

> 
> Pascal



From roger.alexander@ekasystems.com  Fri Apr 16 14:45:13 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2917F3A68DA for ; Fri, 16 Apr 2010 14:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.266
X-Spam-Level: 
X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[AWL=-1.185,  BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4NbpWIEP3XK for ; Fri, 16 Apr 2010 14:45:03 -0700 (PDT)
Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 830773A67F8 for ; Fri, 16 Apr 2010 14:45:01 -0700 (PDT)
Received: (qmail 653 invoked from network); 16 Apr 2010 21:44:51 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp111.biz.mail.re2.yahoo.com with SMTP; 16 Apr 2010 14:44:51 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: RMJTX3QVM1kazDMZk9qdhA.rfECeiBrPd90gCjnZRwr5wv1fl7wFzxqKmt910qeR_OzSERBNpqRHtGsZhB4mWRHYwZrUVQR8JY2KRiiaL9b_7P6w9.LhtnL1BxtItcub6m576RtmxcE.0bwQ3LSFYf8eyE97l3Rp8TmzRn737ZZYn34HlMD12D.S.3sYQnAPw7oWIQsyJ.r90hRPx2gCOfUEZcXCCN7KoBa34zkPfE42FeZbzS.VktPEbuhCcpcR8mb5MbVJ.AJFHTxm_fEAK7d8gxtrU3aDATXOLhKzNSCS8b.1e1z.vdGZCFetEYxud36bOKaw0RBwWUjpId8OeZ0rhTACbqkj49gjE5C9uCrgZYFWhpvLmbYNx_H32f6t
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Reddy, Joseph'" , 
References: 
In-Reply-To: 
Date: Fri, 16 Apr 2010 17:43:11 -0400
Message-ID: <00ff01caddad$cfba3c50$6f2eb4f0$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01CADD8C.48A89C50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrahfZOKJ7+L8GhT0K9axsh+V7e5QBe9piw
Content-Language: en-us
Subject: Re: [Roll] Feedback from ZigBee interop event
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 16 Apr 2010 21:45:13 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0100_01CADD8C.48A89C50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Joseph,

 

Thanks for the feedback on the Alliance's interop event which highlights a
number of issues that do need clarification and some of which are still open
in the on-going RPL discussions.

 

A few of my takes below based on previously indicated positions.

 

Thanks.

 

Roger

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Reddy, Joseph
Sent: Monday, April 12, 2010 5:20 PM
To: roll@ietf.org
Subject: [Roll] Feedback from ZigBee interop event

 

 

Hi,

 

I would like to share some feedback from the recent interop event held by
the ZigBee Alliance that was attended by several 802.15.4 platform vendors.
At this event, the main focus was on testing TCP, RPL and 6lowpan protocols.


 

For the RPL protocol, the DAG formation and data transmission "up" towards
the root were tested successfully among the various platforms. In addition
to the feedback on the exiting spec ( see below ), the main request is to
ensure the spec is quickly updated with the routing/forwarding for
"downwards" paths so we can move forward with our testing. 

 

-Regards, Joseph

 

 

1. Need clarification on the Rank and DagRank. The root rank has value of 1
but not clear if that is just the integer part or not. 

 

2. In OF0, the values for minRankIncrease and maxRankIncrease take value of
256 which cannot be represented in the DoDAG config suboption ( which allows
only 1 byte ). This needs to be fixed in the spec. Also, re-consider if we
really need fractional part in the rank, it doesn't seem to be very useful.

 

3. Clarify the IP source address for DIS/DAO packets - should this be the
link local or global address ( or either ) ?

[Roger] In the more general context of RPL usage beyond HAN, this has to be
global.

 

4. Need clarification on flowlabel. Currently it is not possible to
implement as defined ( without layer violations ) since a node will need to
know if the next hop is the final destination and if the previous hop was
the originator of the packet...current implementations have removed flow
label validation 

 

5. Need clarification on the use of the destination prefix. How many of them
can be included in a DIO ? Is this intended to be the prefix of the 6lowpan
or is this a prefix that can be reached by the root node ( on the wired side
) ?

[Roger] As specified in the Section 3.5.1, the destination prefix is generic
in its definition and can be a prefix as well as complete IPv6 destination
address. With regard to the inclusion of multiple addresses, as stated
previously I am also interested in seeing the specification include optional
support for multiple addresses within the DAO message. 

 

6. Does RPL intend to define messages to allow neighboring nodes to exchange
bidirectional link quality estimates between themselves ?

[Roger] This should be an L2 (subnet) function and does not need to be
directly supported with RPL messages.

 

 

 

 


------=_NextPart_000_0100_01CADD8C.48A89C50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi Joseph,
    


     
    


    Thanks for the feedback on the Alliance’s interop =
event
which highlights a number of issues that do need clarification and some =
of
which are still open in the on-going RPL =
discussions.
    


     
    


    A few of my takes below based on previously indicated =
positions…
    


     
    


    Thanks.
    


     
    


    Roger
    


     
    


     
    


    


    


    


    From:=

roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of =
Reddy,
Joseph
    
Sent: Monday, April 12, 2010 5:20 PM
    
To: roll@ietf.org
    
Subject: [Roll] Feedback from ZigBee interop =
event
    


    


    


     
    


    


     
    


    


    


    Hi,
    


    


    


     =

    


    


    


    I
would like to share some feedback from the recent interop event held by =
the
ZigBee Alliance that was attended by several 802.15.4 platform vendors. =
At this
event, the main focus was on testing TCP, RPL and 6lowpan protocols. =

    


    


    


     =

    


    


    


    For
the RPL protocol, the DAG formation and data transmission "up"
towards the root were tested successfully among the various platforms. =
In
addition to the feedback on the exiting spec ( see below ), the main =
request is
to ensure the spec is quickly updated with the routing/forwarding for
"downwards" paths so we can move forward with our testing. =

    


    


    


     =

    


    


    


    -Regards,
Joseph
    


    


    


     =

    


    


    


     =

    


    


    


    1.
Need clarification on the Rank and DagRank. The root rank has value of 1 =
but
not clear if that is just the integer part or not. 
    


    


    


     =

    


    


    


    2.
In OF0, the values for minRankIncrease and maxRankIncrease take value of =
256
which cannot be represented in the DoDAG config suboption ( which allows =
only 1
byte ). This needs to be fixed in the spec. Also, re-consider if we =
really need
fractional part in the rank, it doesn’t seem to be very =
useful.
    


    


    


     =

    


    


    


    3.
Clarify the IP source address for DIS/DAO packets - should this be the =
link
local or global address ( or either ) ?
    


    [Roger] In the more general context of RPL usage beyond =
HAN,
this has to be global.
    


    


    


     =

    


    


    


    4.
Need clarification on flowlabel. Currently it is not possible to =
implement as
defined ( without layer violations ) since a node will need to know if =
the next
hop is the final destination and if the previous hop was the originator =
of the
packet…..current implementations have removed flow label =
validation 
    


    


    


     =

    


    


    


    5.
Need clarification on the use of the destination prefix. How many of =
them can
be included in a DIO ? Is this intended to be the prefix of the 6lowpan =
or is
this a prefix that can be reached by the root node ( on the wired side ) =
?
    


    [Roger] As specified in the Section 3.5.1, the =
destination
prefix is generic in its definition and can be a prefix as well as =
complete
IPv6 destination address. With regard to the inclusion of multiple =
addresses, as
stated previously I am also interested in seeing the specification =
include optional
support for multiple addresses within the DAO message. =

    


    


    


     =

    


    


    


    6.
Does RPL intend to define messages to allow neighboring nodes to =
exchange
bidirectional link quality estimates between themselves ?
    


    


    


    [Roger] This should be an L2 (subnet) function and does =
not need
to be directly supported with RPL messages.
    


    


    


     =

    


    


    


     =

    


    


    


     =

    


    


    


     =

    


    


    


    





------=_NextPart_000_0100_01CADD8C.48A89C50--


From gnawali@cs.stanford.edu  Fri Apr 16 15:36:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDA03A6877 for ; Fri, 16 Apr 2010 15:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.337
X-Spam-Level: 
X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4kRdSRNjkzM for ; Fri, 16 Apr 2010 15:36:58 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2E2E33A6A55 for ; Fri, 16 Apr 2010 15:36:53 -0700 (PDT)
Received: from mail-gx0-f217.google.com ([209.85.217.217]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O2u9W-00089h-0n for roll@ietf.org; Fri, 16 Apr 2010 15:36:46 -0700
Received: by gxk9 with SMTP id 9so1784569gxk.8 for ; Fri, 16 Apr 2010 15:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.26.13 with HTTP; Fri, 16 Apr 2010 15:36:25 -0700 (PDT)
In-Reply-To: <87pr2026ky.fsf@kelsey-ws.hq.ember.com>
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>    <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com> <87r5mg285n.fsf@kelsey-ws.hq.ember.com>   <87pr2026ky.fsf@kelsey-ws.hq.ember.com>
From: Omprakash Gnawali 
Date: Fri, 16 Apr 2010 15:36:25 -0700
Received: by 10.150.214.13 with SMTP id m13mr2506643ybg.134.1271457405137;  Fri, 16 Apr 2010 15:36:45 -0700 (PDT)
Message-ID: 
To: Richard Kelsey 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scan-Signature: 6b0537b5faa14548adc1759647fcb4de
Cc: roll@ietf.org
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 16 Apr 2010 22:36:59 -0000

On Thu, Apr 15, 2010 at 6:22 AM, Richard Kelsey
 wrote:
>> From: JP Vasseur 
>> Date: Thu, 15 Apr 2010 14:59:48 +0200
>>
>> There are several reson that I think are strongly advocating for
>> decoupling
>> the metrics from the OF:
>> 1) The number of OFs that we would have to define considering the number
>> of potential combinations of {metrics,constraints}
>> 2) That provides much more flexibility ... for example, you may want
>> to define
>> a simple OF and let the root choose (or even dynamically adapt the
>> metrics
>> and constraints to take into account). For the sale of illustration,
>> the root may
>> receive for feed-back suggesting to relax a constraint "on the fly",
>> which could
>> be done without having to support multiple OF on the node.
>
> JP,
>
> I agree with everything you say here. =A0But none of it
> requires that metric containers be self-describing. =A0Yes,
> there needs to be a separation between metrics and the OF.
> That interface does not need to be reflected in the packets.
> The OF and metric implementations live in the same layer on
> the same node. =A0They do not need to use IP to communicate.

It will be great to have some examples of those likely combinations to
make this discussion more concrete and to understand how to write one
general purpose OF. Low latency + Low ETX?

- om_p

From pal@cs.stanford.edu  Fri Apr 16 16:30:02 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F2E3A6861 for ; Fri, 16 Apr 2010 16:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level: 
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilOvIxNCPlm2 for ; Fri, 16 Apr 2010 16:30:01 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id AFD853A67E7 for ; Fri, 16 Apr 2010 16:30:01 -0700 (PDT)
Received: from dn0a210086.sunet ([10.33.0.134]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O2uyw-0007u9-Kj; Fri, 16 Apr 2010 16:29:54 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=windows-1252
From: Philip Levis 
In-Reply-To: 
Date: Fri, 16 Apr 2010 16:29:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F06E08C-622D-4209-A43D-D950B020C381@cs.stanford.edu>
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>  <672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com> <87r5mg285n.fsf@kelsey-ws.hq.ember.com>  <87pr2026ky.fsf@kelsey-ws.hq.ember.com> 
To: Omprakash Gnawali 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3
Cc: roll@ietf.org
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 16 Apr 2010 23:30:02 -0000

On Apr 16, 2010, at 3:36 PM, Omprakash Gnawali wrote:

> It will be great to have some examples of those likely combinations to
> make this discussion more concrete and to understand how to write one
> general purpose OF. Low latency + Low ETX?

Agreed.=20

=
http://research.microsoft.com/en-us/um/people/blampson/33-hints/webpage.ht=
ml

"Do one thing at a time, and do it well. An interface should capture the =
minimum essentials of an abstraction. Don=92t generalize; =
generalizations are generally wrong."

Phil=

From phoebus@ieee.org  Sat Apr 17 10:01:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B693A67BD for ; Sat, 17 Apr 2010 10:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.742
X-Spam-Level: 
X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYyYtGPPSjnT for ; Sat, 17 Apr 2010 10:01:12 -0700 (PDT)
Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 5A98A3A6812 for ; Sat, 17 Apr 2010 10:01:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id C901D156F0C for ; Sat, 17 Apr 2010 19:00:32 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gMW7SPr3wcYx for ; Sat, 17 Apr 2010 19:00:30 +0200 (CEST)
X-KTH-Auth: phoebus [130.237.50.16]
X-KTH-mail-from: phoebus@ieee.org
X-KTH-rcpt-to: roll@ietf.org
Received: from dhcp-50-16.s3.kth.se (dhcp-50-16.s3.kth.se [130.237.50.16]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 5241C15588C for ; Sat, 17 Apr 2010 19:00:29 +0200 (CEST)
Message-ID: <4BC9E92D.60104@ieee.org>
Date: Sat, 17 Apr 2010 19:00:29 +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.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "roll@ietf.org" 
References: <1745090C-E3F9-4D6F-846A-53950E508AE3@cisco.com>		<672F5FA9-8BD1-4252-970D-923147719C1B@cisco.com>	<87r5mg285n.fsf@kelsey-ws.hq.ember.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Roll] Decoupling Metrics and OF
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
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: Sat, 17 Apr 2010 17:01:14 -0000

JP,

I agree with Matteo
http://www.ietf.org/mail-archive/web/roll/current/msg03386.html
and Richard, that how the metrics are combined should be defined in the 
Objective Function and not in the metrics container.

Some of my opinions were expressed in an earlier email
http://www.ietf.org/mail-archive/web/roll/current/msg03212.html
(trying to link up the emails for those that are having trouble 
following the threads) but I will elaborate on it here below.

After all, what is an Objective Function?  It should not only describe 
how a link or node metric is calculated, but also how it is combined 
along the path(s) to get a path metric.  At the end of the day, you 
might want to compare such a path metric at a potential parent A with 
the path metric at a potential parent B to decide whether to add A or B 
to the parent set (among other rules for selecting parents).

Also, you may want to use a combination of operators to compute a single 
path metric that combined multiple types of link and node metrics.  One 
simple example is to take a weighted linear combination of two metrics 
(ex. w1*ETX + w2*latency, where w1 and w2 are constants).  There may be 
much better ways to combine metrics than this.  Trying to specify that 
now (in 2-bits, or n-bits) in the RPL metrics document will tie our 
hands later when a better idea of how to combine metrics arises.  Unless 
you want to deprecate and replace the RPL metrics RFC (when it becomes 
an RFC) each time a new way of combining metrics is proposed.

On the other hand, I don't see a problem with specifying the ways that 
different metrics can be combined in the RFCs for objective functions 
(so addition, max, min, multiply, etc. can be specified by n-bits + 
fields in a particular OCP object).  That might help limit the number of 
RFCs... there could be an RFC that tries to specify the different ways 
that various different metrics might be combined, and which gets 
deprecated by a later RFC when experimental evidence / experience 
suggests that there are other better ways to combine the metrics.

I'm trying to strike a balance between deprecating and replacing RFCs 
and limiting our options of combining metrics for objective functions.

As I indirectly indicated in another thread:
http://www.ietf.org/mail-archive/web/roll/current/msg03193.html
I see the Objective Function as something that tries to tie up some of 
the "loose ends" of the RPL specification.  They serve as "modules" that 
plug into RPL to tailor it to a particular application requirement.  I 
may have been a bit overzealous in my proposal of items that should be 
in the objective function, but maybe each of those items should be 
discussed ;).

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus


On 4/15/10 2:59 PM, JP Vasseur wrote:
>
> On Apr 15, 2010, at 2:48 PM, Richard Kelsey wrote:
>
>>> From: JP Vasseur
>>> Date: Thu, 15 Apr 2010 11:10:04 +0200
>>>
>>> Yes, we may have OF where specific handling of the metrics
>>> are required and must then be part of the OF itself. For
>>> many other ones, we could certainly use a generic OF and
>>> leave the metric out of it, relying on the semantic
>>> defined in the metric ID. We're in sync.
>>
>> Well, I'm not entirely in sync :-).
>>
>> I completely agree that we should define at least one
>> generic OF that does not depend on the details of the
>> metrics in use.
>
> OK.
>
>>
>> Where I disagree is with metric containers needing to
>> describe the properties of the metrics (additive, etc.).
>> For a node to make use of an OF and associated metrics, it
>> has to implement both the OF and the metrics.  While the OF
>> might be able to get away with only knowing that a metric is
>> additive, implementing the metric requires knowing what it
>> is.
>
> There are several reson that I think are strongly advocating for
> decoupling
> the metrics from the OF:
> 1) The number of OFs that we would have to define considering the number
> of potential combinations of {metrics,constraints}
> 2) That provides much more flexibility ... for example, you may want
> to define
> a simple OF and let the root choose (or even dynamically adapt the
> metrics
> and constraints to take into account). For the sale of illustration,
> the root may
> receive for feed-back suggesting to relax a constraint "on the fly",
> which could
> be done without having to support multiple OF on the node.
>
>> To participate in a DODAG that uses ETX, for example, a
>> node has to know how to calculate ETX.  It doesn't seem like
>> a stretch for the node to also know that ETX is additive.
>>
>>                               -Richard Kelsey
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From mcr@sandelman.ca  Sun Apr 18 20:20:58 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7BF3A68C7 for ; Sun, 18 Apr 2010 20:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.145
X-Spam-Level: ****
X-Spam-Status: No, score=4.145 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt+vQSn1zmPW for ; Sun, 18 Apr 2010 20:20:55 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0F7AE3A6817 for ; Sun, 18 Apr 2010 20:20:51 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [207.35.74.162]) by relay.sandelman.ca (Postfix) with ESMTPS id 14A17347D9 for ; Sun, 18 Apr 2010 23:20:43 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 812074E79D for ; Sun, 18 Apr 2010 23:20:42 -0400 (EDT)
From: Michael Richardson 
To: IETF ROLL 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Sun, 18 Apr 2010 23:20:42 -0400
Message-ID: <26442.1271647242@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] an initial review of security-framework-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 19 Apr 2010 03:20:58 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I read draft-ietf-roll-security-framework-00 today on the train to ARIN.
I understand that the security design team is "working", but I don't
really understand what they are working to solve yet.

I think this document was written prior to the WG adopting RPL (as a
presonal draft).  It's very generic, and non-specific to RPL.   I had a
number of very specific comments on the document, but I think that they
out-of-place, as I have in the end a few high-level comments.

It says "framework", but based upon my reading, it's more of a security
requirements --- it introduces this 'CIA' model, which is rather an
unfortunate acronum.   

Section 4 is supposed to Threats and Attacks, while section 5 covers
countermeasures.    I don't find the two sections follow this very well.

I find that this model is too focused on solutions rather than problems
as written.

What I was expecting to see was an analysis of RPL, of each of the
fundamental operations of RPL (from a network centric point of view),
with an analysis of what happens if the communication is "disclosed"
(confidentiality attack), if integrity fails, or if the message is
diverted/dropped (availability).   I would go further, and ask what
happens if the message is delayed (made to be late), or if it replayed. 

I also think that physical device compromise should be made completely
out-of-scope.  An "pwned" which is made to do malicious things is very
hard to detect, and may be comparable to a misconfigured device.  Since
a node can not tell the difference, if we need to be slightly mutually
suspicious, then we need to write that analysis, and not worry about
things like how to harden the device itself.  Rather, we have to worry,
in the design of the cryptography and protocol, to minimize how much
damage can occur when a device is misconfigured-and-or-pwned.

section 5.3.2) says:

       "Finally, if communication is sufficiently secured, only trusted
       nodes can receive and forward traffic which also lowers the risk
       of an overload attack. "

While I'm a major fan of layer-3 security, it seems that we should
clearly understand the use cases that forbid the above policy.  It seems
to be the best policy for many situations.  

When we understand the use cases for which the above policy is too
restrictive, then I think we can build the right security mechanisms.

I believe that the Home Automation scenario is likely where to crack
this nut.   I expect, when I invite people in to my home, to give them
access (from their personal devices) to be able access my network.  

(At a higher-level, I will authorize them to do things like turn on/off
 lights, order pizza, or look at my family photos... but that's higher
level)

At it's most simple, if you visit my automated home, you need to be able
to get past the layer-2 security easily, and you need to be able to
become a leaf on my network.

So, from a security point of view, if we can build layer-3 security that
does not permit some nodes to become core nodes, then we may have solved
95% of use cases.

I have a number of comments about diversity of routes, but I think they
are too specific at this time.

What happens to this document now?

- -- 
]       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. 





       




             


        



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8vMB4CLcPvd0N1lAQLK0AgAivNQ8kG+vBNvH1EJcxtuPz7scVRGhDCa
en4KAKfycjdjTlhqYPhLFfiBYd3PUu3tvaEfLw290jQVgjD9mbTbdfnd5eBRByOM
XUqIQvDo2V/8K2eQ2tWdg/4h1amUVYZkIkEQWP9WErP7Dfl+LqiacihOGNPisQHh
tw4bIjFKvtufYr3OjFlzkkEEL+H+4THRsLBetthHm0217CRRs4u8I8rQyF8BP5O8
bzqsZo92dxr5b71+/25ke5+bWeRG9eghXqQ+zoGP/dT5B9EU9++57xM8yULF7u0k
4ONz39ZlHvyY1j1Q1SCVusm0HdcDc+YLT9FPrOMcXb5uweVBhtKB9w==
=ugtG
-----END PGP SIGNATURE-----

From tzeta.tsao@ekasystems.com  Sun Apr 18 21:44:44 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3228C102 for ; Sun, 18 Apr 2010 21:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsTf3tIxkTXn for ; Sun, 18 Apr 2010 21:44:43 -0700 (PDT)
Received: from web303.biz.mail.mud.yahoo.com (web303.biz.mail.mud.yahoo.com [68.142.199.179]) by core3.amsl.com (Postfix) with SMTP id 8E0573A6A70 for ; Sun, 18 Apr 2010 21:44:43 -0700 (PDT)
Received: (qmail 91146 invoked by uid 60001); 19 Apr 2010 04:44:30 -0000
Message-ID: <20288.91137.qm@web303.biz.mail.mud.yahoo.com>
X-YMail-OSG: aL1YNmsVM1mHJaGNo31j234XCHU8Q.IDSpQcNbK27DuaoOL 631b_iBemhSrMlN8gzphXiH42YNwlUsAA33b4FO75XVad5Y0.ahuoG_DILDR 2UQppdq0sNOSDI_c7tou1.jitZBzBRZzMTiIPs9o4RKPYGcxWj8i_mOnD3R8 ByGIsjDmTg6.KkEpUReE.SX.lmocX2rlwifV9OucDTOYq0637.u96NXk1Dl6 vw7mk74iThVIZMiwio0gzOUYVNRg.ex71ZTLB6wEFbmFKZc5PPC8ljIBGf90 Eb4MYyCdqTxz7FdMUcwxTrVdBSt216XI-
Received: from [96.255.4.156] by web303.biz.mail.mud.yahoo.com via HTTP; Sun, 18 Apr 2010 21:44:29 PDT
X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964
Date: Sun, 18 Apr 2010 21:44:29 -0700 (PDT)
From: Tzeta Tsao 
To: IETF ROLL 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Roll]  an initial review of security-framework-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 19 Apr 2010 04:44:44 -0000

Hi Michael,


Thanks for your feedback.

Indeed, we did intend to put into perspective the cross-cutting nature of security in the context of a generic ROLL protocol. Still, for example, the transition of Section 4 to Section 5 could be improved.

But more importantly, I would also want to make sure that I understand you correctly. When you say you were expecting to see "an analysis of RPL", did you mean that the security framework draft should be specifically addressed to RPL?

Thanks,
Tzeta



----- Original Message ----
From: Michael Richardson 
To: IETF ROLL 
Sent: Sun, April 18, 2010 11:20:42 PM
Subject: [Roll] an initial review of security-framework-00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I read draft-ietf-roll-security-framework-00 today on the train to ARIN.
I understand that the security design team is "working", but I don't
really understand what they are working to solve yet.

I think this document was written prior to the WG adopting RPL (as a
presonal draft).  It's very generic, and non-specific to RPL.   I had a
number of very specific comments on the document, but I think that they
out-of-place, as I have in the end a few high-level comments.

It says "framework", but based upon my reading, it's more of a security
requirements --- it introduces this 'CIA' model, which is rather an
unfortunate acronum.  

Section 4 is supposed to Threats and Attacks, while section 5 covers
countermeasures.    I don't find the two sections follow this very well.

I find that this model is too focused on solutions rather than problems
as written.

What I was expecting to see was an analysis of RPL, of each of the
fundamental operations of RPL (from a network centric point of view),
with an analysis of what happens if the communication is "disclosed"
(confidentiality attack), if integrity fails, or if the message is
diverted/dropped (availability).   I would go further, and ask what
happens if the message is delayed (made to be late), or if it replayed. 

I also think that physical device compromise should be made completely
out-of-scope.  An "pwned" which is made to do malicious things is very
hard to detect, and may be comparable to a misconfigured device.  Since
a node can not tell the difference, if we need to be slightly mutually
suspicious, then we need to write that analysis, and not worry about
things like how to harden the device itself.  Rather, we have to worry,
in the design of the cryptography and protocol, to minimize how much
damage can occur when a device is misconfigured-and-or-pwned.

section 5.3.2) says:

       "Finally, if communication is sufficiently secured, only trusted
       nodes can receive and forward traffic which also lowers the risk
       of an overload attack. "

While I'm a major fan of layer-3 security, it seems that we should
clearly understand the use cases that forbid the above policy.  It seems
to be the best policy for many situations.  

When we understand the use cases for which the above policy is too
restrictive, then I think we can build the right security mechanisms.

I believe that the Home Automation scenario is likely where to crack
this nut.   I expect, when I invite people in to my home, to give them
access (from their personal devices) to be able access my network.  

(At a higher-level, I will authorize them to do things like turn on/off
lights, order pizza, or look at my family photos... but that's higher
level)

At it's most simple, if you visit my automated home, you need to be able
to get past the layer-2 security easily, and you need to be able to
become a leaf on my network.

So, from a security point of view, if we can build layer-3 security that
does not permit some nodes to become core nodes, then we may have solved
95% of use cases.

I have a number of comments about diversity of routes, but I think they
are too specific at this time.

What happens to this document now?

- -- 
]       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. 





      




            


        



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8vMB4CLcPvd0N1lAQLK0AgAivNQ8kG+vBNvH1EJcxtuPz7scVRGhDCa
en4KAKfycjdjTlhqYPhLFfiBYd3PUu3tvaEfLw290jQVgjD9mbTbdfnd5eBRByOM
XUqIQvDo2V/8K2eQ2tWdg/4h1amUVYZkIkEQWP9WErP7Dfl+LqiacihOGNPisQHh
tw4bIjFKvtufYr3OjFlzkkEEL+H+4THRsLBetthHm0217CRRs4u8I8rQyF8BP5O8
bzqsZo92dxr5b71+/25ke5+bWeRG9eghXqQ+zoGP/dT5B9EU9++57xM8yULF7u0k
4ONz39ZlHvyY1j1Q1SCVusm0HdcDc+YLT9FPrOMcXb5uweVBhtKB9w==
=ugtG
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From pthubert@cisco.com  Mon Apr 19 08:55:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EC828C297 for ; Mon, 19 Apr 2010 08:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.636
X-Spam-Level: 
X-Spam-Status: No, score=-7.636 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIuOD3gEElUA for ; Mon, 19 Apr 2010 08:55:06 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0420C28C3A0 for ; Mon, 19 Apr 2010 08:35:19 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,236,1270425600"; d="scan'208";a="185169199"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2010 15:35:10 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3JFYPAU005400; Mon, 19 Apr 2010 15:35:10 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 19 Apr 2010 17:35:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Apr 2010 17:35:04 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01B50F5B@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] DAO fan out
Thread-Index: Acrf1eBhE3gpj86EQv+LzaP9OWLJMA==
From: "Pascal Thubert (pthubert)" 
To: "Roger Alexander" , "Navneet Agarwal (navagar)" , "JP Vasseur" , 
X-OriginalArrivalTime: 19 Apr 2010 15:35:07.0226 (UTC) FILETIME=[E38E43A0:01CADFD5]
Cc: ROLL WG 
Subject: Re: [Roll] DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 19 Apr 2010 15:55:07 -0000

Hi Roger:

At high level I'm very positive on the mechanism .=20

What I'd wish to see from the list is more people:
- agreeing that the fan out MUST be solved
- that this is a simple and efficient solution=20
- that the solution can be incorporated in 08=20

Maybe what would help from you Roger is:
- a visual example on the mechanism as work (if you have a pdf
illustrating it?)
- some more explanation on the source route case (how the root can play
the same game recursively and obtain a good result as well)

Could you please so that for us?

Thanks a bunch,

Pascal


> -----Original Message-----
> From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
> Sent: Friday, April 16, 2010 11:32 PM
> To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
Vasseur';
> wintert@acm.org
> Cc: 'ROLL WG'
> Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
> welcome)
>=20
> Below is a quick summary aligned to Tim's concept of how the Path
Control
> bitmap associated with the DAO destination address can be used to
limit fan
> out and to identify the preferred path when nodes maintain multiple
DAO
> Parents.
>=20
> Further details and examples can be provided as part of an larger
> application domain note.
>=20
> Roger
>=20
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> > Sent: Tuesday, April 13, 2010 3:47 AM
> > To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
> > wintert@acm.org
> > Cc: ROLL WG
> > Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
> >
> >
> >
> > Pascal
> >
> > > One consequence of maintaining multiple DAO parents is the
potential
> > fan
> > > out of routing paths. With path fan out a node may have multiple
> > downward
> > > next hop addresses for a given target destination address. Without
> > some
> > > path preference indication there is no information available if a
> > storing node
> > > (including the root) wishes to limit the number of downward next
hops
> > > maintained for a given address. It is thus desirable to have some
> > means of
> > > path control to limit fan out as well as a preference indication
that
> > can work in
> > > conjunction with the hop-by-hop DAO exchanges.
> > >
> > > See the Figure below for an example in which nodes maintain two
DAO
> > > Parents each, where in the worst case the fan out that occurs
after
> > three
> > > hops results in eight next hop downward paths from the DODAG root
> > (LBR)
> > > to a target node (41). Even with the hop-by-hop DAO mechanism it
> > would
> > be
> > > desirable to be able to limit fan out as well as to identify path
> > preference and
> > > diversity at the root or other intermediate storing node.
> > >
> > >                     (------------LBR------------)
> > >                     /    /   / |     | \    \   \
> > >                    /    /   /  |     |  \    \   \
> > >                   /    /   /   |     |   \    \   \
> > >                  /    /   /    |     |    \    \   \
> > >               (11) (12) (13) (14)   (15) (16) (17) (18)
> > >                  \   |    |    /     \    |    |   /
> > >                   \  |    |   /       \   |    |  /
> > >                    \ |    |  /         \  |    | /
> > >                   (21)   (22)           (23)  (24)
> > >                       \    |            |    /
> > >                        \   |            |   /
> > >                         \  |            |  /
> > >                          (31)          (32)
> > >                              \        /
> > >                               \      /
> > >                                \    /
> > >                                 (41)
> > >
> >
> > [Pascal] Your schema illustrates clearly that even if we fan out a
lot,
> > it does not mean that a router on the way down will have more
feasible
> > successors.
> >
> > That's one thing that's important to remember, the properties of the
> > DAG
> > are not symmetrical, so even if we build it to get multiple feasible
> > successors on the way up, that does not mean that on the reverse DAG
to
> > a target there are multiple successors at each hop towards that
target.
> >
> > In other words, the ROI of fanning out is not guaranteed if we do it
> > blindly.
> >
> > > A simple path control bitmap associated with the advertised
> > Destination
> > > Address can be included within the DAO to address the issue of
path
> > > preference as well as control of fan out. For a network of
> > 'non-storing'
> > > nodes the preference indication would be processed only at the
root.
> >
> > [Pascal] so far so good, but that will give you a blind mechanism.
> >
> > > With the path control byte associated with each DAO destination
> > address, a
> > > node will be able to specify preference among DAO parent paths and
> > can
> > > convey limits on the number of downward paths. This is an
opportunity
> > for
> > > nodes to further influence the downward paths that are established
> > and
> > > maintained. Consistent with the DV-based RPL operation this DAO
path
> > > control mechanism must operate hop-by-hop avoiding any requirement
> > for
> > > end-to-end path coordination. To avoid overloading this email
thread
> > I
> > will
> > > initiate a separate discussion on how a path control element may
be
> > included
> > > within the DAO.
> > >
> > [Pascal] Too late, I just did :)
> >
> > And if I remember, Tim's idea was to control the stretch of the
fanout,
> > by decrementing a counter as the path loses preference point.
> > At the moment, we have a parent preference 0-lowest to 3 highest. So
it
> > is easy to decrement a counter by (3-pref) and not fan out when the
> > counter reaches 0.
> > Tim, could you elaborate on this?
>=20
> A Path Control bit map will achieve an equivalent control mechanism
> whereby
> at each node the number of bits that are set will determine the extent
to
> which the associated DAO Destination Address can be advertised to
multiple
> DAO Parents. If a DAO message destination address Path Control bitmap
has
> 4
> set bits, that address can be send along a maximum of 4 paths. For
example,
> at the originating node the DAO can be sent to two DAO Parents where
the
> Path Control bit map in the message sent to each DAO Parent will have
two
> set bits. If each parent then advertises to two DAO Parents a single
bit is
> set for each DAO message. Eventually with a single bit set in the Path
> Control bit map, the DAO message can be advertised only to a single
DAO
> Parent. This mechanism achieves the effect of limiting the stretch of
the
> path fan out. Where multiple DAO messages are received at a common
> ancestor
> the number of set bits in the respective Path Control fields are
recombined
> allowing for renewed advertising of the DAO message destination
address to
> multiple DAO Parents along the path.
>=20
> As the set Path Control bits are split and recombined as the DAO
messages
> are transferred to the root, their bit positions are maintained. This
allows
> bit positions to be ordered from low to high in terms of path
preference.
> Therefore when a DAO message is received in which the Path Control
bitmap
> has the highest preference bit set, that DAO message destination
address is
> always advertised to the preferred DAO Parent. Similarly, when a
message is
> received with multiple Path Control bits set, the DAO messages can be
> distributed to DAO Parents according to parent preference. This will
ensure
> that at any common ancestor, including the root, a node is always able
to
> distinguish the preferred downward path. The ability to determine the
> preferred downward path as well as to obtain an indication of path
diversity
> will allow the Path Control field to be used when resource limitations
at a
> node require a truncation of the number of downward paths that the
node
> maintain for a given destination address.
>=20
> >
> > Pascal
>=20


From mcr@sandelman.ca  Fri Apr 23 06:59:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45103A69BE for ; Fri, 23 Apr 2010 06:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.645
X-Spam-Level: *
X-Spam-Status: No, score=1.645 tagged_above=-999 required=5 tests=[BAYES_60=1,  HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73H1U0E3t760 for ; Fri, 23 Apr 2010 06:59:53 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id AF1073A69AE for ; Fri, 23 Apr 2010 06:59:53 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id DD43B3477B for ; Fri, 23 Apr 2010 09:59:42 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 053D74E7B9 for ; Fri, 23 Apr 2010 09:59:42 -0400 (EDT)
From: Michael Richardson 
To: IETF ROLL 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Fri, 23 Apr 2010 09:59:41 -0400
Message-ID: <7069.1272031181@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 23 Apr 2010 13:59:55 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


There is something which I thought I knew, and upon further
consideration, I realized I was wrong.

This is specifically what prefix a node (whether leaf or internal)
(auto-)configures for itself.
In a normal network, this would be done with RS/RA.

I'm unclear if RS/RA is the right thing --- if it is, then every
internal node needs to send out RAs.  When RPL was operating as a ND
option, I could imagine also including it in the RA messages, reducing
the number of messages that need to be sent.

Then I thought that the destination prefix from the DODAG root indicated
the prefix that this DODAG should operate with, but that's wrong --- the
destination prefix indicates connectivity, not self.

So my question is: how does a node get a non-link-local address?
One presumes that it needs such a thing in order to communicate with the
outside for any of the P2MP applications.

(I realize that 6lowpan has some answers, but it has two modes, and I'm
pretty sure that it can provide RA/RS functionality only in one mode)

- -- 
]       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. 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9GnzICLcPvd0N1lAQKppggApEM4CxkSoBiHfVgCfyfRcSWlNoKK35sZ
oSYmqLRX2eTucSD22/QqmwURXM+0Ygd6v8khCu/rNR+A+3h7dWO9v6b7Z+GDgWP0
9wZR8FrQn2tIvkEfnFGMHWxe8w7r1QbNRJBwj2GqdXtIDkvmO6vm5NRn6fglfn9a
FW7o9lmyKNArMgdtR2yF0DSkallDpeEWXeq1URKrLBTYXHjseQzPujfktVGHJ9xD
RDC45kfOEkdr6sGGPMgxcl+QkcA0ANrBz/1iY3GNTtSiobvRZoaJnM2L/rO4At08
yWeh+vqW4Ujs63UJcur0eZBW/B3RTiEBl+pqMBW96fauM47UR5vzkg==
=hQr6
-----END PGP SIGNATURE-----

From pthubert@cisco.com  Fri Apr 23 11:13:55 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F913A6A59 for ; Fri, 23 Apr 2010 11:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Level: 
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[AWL=0.350,  BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLx5km9zM4DW for ; Fri, 23 Apr 2010 11:13:53 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1DCE63A69A2 for ; Fri, 23 Apr 2010 11:13:53 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIOA0UurR7Hu/2dsb2JhbACcK3GkK4trjkCFCwQ
X-IronPort-AV: E=Sophos;i="4.52,263,1270425600"; d="scan'208";a="252216118"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2010 18:13:42 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3NIDgkJ016605; Fri, 23 Apr 2010 18:13:42 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 23 Apr 2010 20:13:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Apr 2010 20:13:35 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>
In-Reply-To: <7069.1272031181@marajade.sandelman.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: Acri7VPzC3KYLuiGRn+7wBYXRjCmhwAIqVhQ
References: <7069.1272031181@marajade.sandelman.ca>
From: "Pascal Thubert (pthubert)" 
To: "Michael Richardson" , "IETF ROLL" 
X-OriginalArrivalTime: 23 Apr 2010 18:13:41.0338 (UTC) FILETIME=[B40F8BA0:01CAE310]
Cc: Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 23 Apr 2010 18:13:55 -0000

Good question!

In fact we have the problem at 6LoWPAN, when wan a router safely
announce a prefix for autoconf.
An answer can be, as long as it is still tightly coupled with an
authoritative router that owns that prefix, the coupling insuring that
both routers are still in a same subnet.
Typically a RPL instance could tie together a subnet. We can really
easily extend the DAG Destination Prefix to mean either an external
prefix that is reachable through the root OR an internal prefix that the
root owns and that spreads over the DODAG. Here's proposed text for
this:

"

5.4.4.  Destination Prefix

   The Destination Prefix option format is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 3    |      option Length            |R|rsv|Prf| rsv =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Sequence    | Prefix Length |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 13: DAG Destination Prefix

   The Destination Prefix option is used in DIO to indicate that
   connectivity to the specified destination prefix is available from
   the DODAG root.  A RA (R) flag indicates whether the DODAG is part of
   the subnet where the prefix is deployed and influences the way the
   prefix may be presented to the hosts by RPL routers in RA messages.
   This may be useful in cases where more than one LBR is operating
   within the LLN and offering connectivity to different administrative
   domains, e.g. a home network and a utility network.  In such cases,
   upon observing the Destination Prefixes offered by a particular
   DODAG, a node MAY decide to join multiple DODAGs in support of a
   particular application.

   The option Length is coded as the length of the option in octets,
   excluding the Type and Length fields.

   Prf is the Route Preference as in [RFC4191].  The reserved fields
   MUST be set to zero on transmission and MUST be ignored on receipt.

   If the R flag is set, then the DODAG is part of the subnet where the
   prefix is deployed.  The prefix may be advertised as not onlink in RA
   messages for the purpose address autoconfiguration.  If the R flag is
   reset, then the prefix is exterior to the DODAG yet may be reached
   via the root.  The prefix may be advertised in RA messages for
   communicating default router preferences and more-specific routes
   from routers to hosts as prescribed in [RFC4191] with the preference
   in the Prf field.

   The Prefix Lifetime is a 32-bit unsigned integer representing the
   length of time in seconds (relative to the time the packet is sent)
   that the Destination Prefix is valid for route determination.  The
   lifetime is initially set by the node that owns the prefix and
   denotes the valid lifetime for that prefix (similar to
   AdvValidLifetime [RFC4861]).  The value might be reduced by the
   originator and/or en-route nodes that will not provide connectivity
   for the whole valid lifetime.  A value of all one bits (0xFFFFFFFF)
   represents infinity.  A value of all zero bits (0x00000000) indicates
   a loss of reachability.

   The Prefix Length is an 8-bit unsigned integer that indicates the
   number of leading bits in the destination prefix.

   The Destination Prefix contains Prefix Length significant bits of the
   destination prefix.  The remaining bits of the Destination Prefix, as
   required to complete the trailing octet, are set to 0.

   In the event that a DIO message may need to specify connectivity to
   more than one destination, the Destination Prefix option may be
   repeated.

"

What do you think?


Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Michael Richardson
> Sent: Friday, April 23, 2010 4:00 PM
> To: IETF ROLL
> Subject: [Roll] how does a node get an IP address
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> There is something which I thought I knew, and upon further
consideration, I
> realized I was wrong.
>=20
> This is specifically what prefix a node (whether leaf or internal)
(auto-
> )configures for itself.
> In a normal network, this would be done with RS/RA.
>=20
> I'm unclear if RS/RA is the right thing --- if it is, then every
internal node
> needs to send out RAs.  When RPL was operating as a ND option, I could
> imagine also including it in the RA messages, reducing the number of
> messages that need to be sent.
>=20
> Then I thought that the destination prefix from the DODAG root
indicated
> the prefix that this DODAG should operate with, but that's wrong ---
the
> destination prefix indicates connectivity, not self.
>=20
> So my question is: how does a node get a non-link-local address?
> One presumes that it needs such a thing in order to communicate with
the
> outside for any of the P2MP applications.
>=20
> (I realize that 6lowpan has some answers, but it has two modes, and
I'm
> pretty sure that it can provide RA/RS functionality only in one mode)
>=20
> - --
> ]       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.
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>=20
> iQEVAwUBS9GnzICLcPvd0N1lAQKppggApEM4CxkSoBiHfVgCfyfRcSWlNoKK35
> sZ
> oSYmqLRX2eTucSD22/QqmwURXM+0Ygd6v8khCu/rNR+A+3h7dWO9v6b7Z+
> GDgWP0
> 9wZR8FrQn2tIvkEfnFGMHWxe8w7r1QbNRJBwj2GqdXtIDkvmO6vm5NRn6fglf
> n9a
> FW7o9lmyKNArMgdtR2yF0DSkallDpeEWXeq1URKrLBTYXHjseQzPujfktVGHJ9
> xD
> RDC45kfOEkdr6sGGPMgxcl+QkcA0ANrBz/1iY3GNTtSiobvRZoaJnM2L/rO4At08
> yWeh+vqW4Ujs63UJcur0eZBW/B3RTiEBl+pqMBW96fauM47UR5vzkg=3D=3D
> =3DhQr6
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From mcr@sandelman.ca  Sun Apr 25 17:37:50 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E34D3A6A55 for ; Sun, 25 Apr 2010 17:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.627
X-Spam-Level: 
X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[AWL=-0.019,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19vgDlP6Q0xx for ; Sun, 25 Apr 2010 17:37:48 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id D6BF13A6A1D for ; Sun, 25 Apr 2010 17:37:48 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 9234D34715; Sun, 25 Apr 2010 20:37:36 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C18234E7D0; Sun, 25 Apr 2010 20:37:37 -0400 (EDT)
From: Michael Richardson 
To: "Pascal Thubert (pthubert)" 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Sun, 25 Apr 2010 20:37:37 -0400
Message-ID: <11818.1272242257@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: IETF ROLL , Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 00:37:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes:
    Pascal> Good question!

    Pascal> In fact we have the problem at 6LoWPAN, when wan a router

s/wan/can/ ??

    Pascal> safely announce a prefix for autoconf.  An answer can be, as
    Pascal> long as it is still tightly coupled with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.

So, what I think you are saying is that having RPL nodes sending out RAs
themselves is frought with issues, and there are some situations where
it is in fact the right answer?

But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and you
then provide a proposed format for it.

Before we discuss the solution, I'd like to get clear agreement from the
WG that I've properly understood the problem.

I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address 
   b) announcing routability information out of the DODAG.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbCRH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA==
=eFYy
-----END PGP SIGNATURE-----

From pthubert@cisco.com  Mon Apr 26 03:23:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A1D28C10A for ; Mon, 26 Apr 2010 03:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.661
X-Spam-Level: 
X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-3.662, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6YRBPJce-sx for ; Mon, 26 Apr 2010 03:23:48 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id ACA713A690B for ; Mon, 26 Apr 2010 03:21:01 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoBAGMG1UuQ/uCWiWdsb2JhbACcNxUBAQEKCxERBhymKItvjUKFDAQ
X-IronPort-AV: E=Sophos;i="4.52,272,1270425600";  d="scan'208";a="6190037"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 Apr 2010 09:43:50 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3QAKYAe021170; Mon, 26 Apr 2010 10:20:35 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 26 Apr 2010 12:20:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Apr 2010 12:20:31 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>
In-Reply-To: <11818.1272242257@marajade.sandelman.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address 
Thread-Index: Acrk2KzhbleNVqCYTg2kA1S0oEG5kgAT7Whw
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca>
From: "Pascal Thubert (pthubert)" 
To: 
X-OriginalArrivalTime: 26 Apr 2010 10:20:34.0598 (UTC) FILETIME=[1B7C0460:01CAE52A]
Cc: IETF ROLL , Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 10:23:56 -0000

Hi Michael:

You're right. So back to basics:

- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.

What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?

What do you think?

Pascal


> -----Original Message-----
> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
> Sent: Monday, April 26, 2010 2:38 AM
> To: Pascal Thubert (pthubert)
> Cc: IETF ROLL; Erik Nordmark
> Subject: Re: [Roll] how does a node get an IP address
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" =
>
> writes:
>     Pascal> Good question!
>=20
>     Pascal> In fact we have the problem at 6LoWPAN, when wan a router
>=20
> s/wan/can/ ??
>=20
>     Pascal> safely announce a prefix for autoconf.  An answer can be,
as
>     Pascal> long as it is still tightly coupled with an authoritative
>     Pascal> router that owns that prefix, the coupling insuring that
>     Pascal> both routers are still in a same subnet.  Typically a RPL
>     Pascal> instance could tie together a subnet.
>=20
> So, what I think you are saying is that having RPL nodes sending out
RAs
> themselves is frought with issues, and there are some situations where
> it is in fact the right answer?
>=20
> But, I think you are saying, in order to cover all situations more
> clearly, we are going to overload the Destination Prefix option, and
you
> then provide a proposed format for it.
>=20
> Before we discuss the solution, I'd like to get clear agreement from
the
> WG that I've properly understood the problem.
>=20
> I do wonder if adding the (R) flag is better than having a new option.
> It seems that there are really two distinct activities here:
>    a) configuring a local address
>    b) announcing routability information out of the DODAG.
>=20
> - --
> ]       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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>=20
> iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
> J
> ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
> oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
> RH
> hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
> VV+6L6J
> o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
> TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
> =3DeFYy
> -----END PGP SIGNATURE-----

From mcr@sandelman.ca  Mon Apr 26 05:58:16 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6B23A6A14 for ; Mon, 26 Apr 2010 05:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.631
X-Spam-Level: 
X-Spam-Status: No, score=0.631 tagged_above=-999 required=5 tests=[AWL=-0.016,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNkwxNp7OGri for ; Mon, 26 Apr 2010 05:58:15 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 52FEC3A6B5B for ; Mon, 26 Apr 2010 05:58:05 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id F022E34709; Mon, 26 Apr 2010 08:57:53 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 24C2E4E7D3; Mon, 26 Apr 2010 08:57:55 -0400 (EDT)
From: Michael Richardson 
To: "Pascal Thubert (pthubert)" 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 26 Apr 2010 08:57:55 -0400
Message-ID: <24252.1272286675@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: IETF ROLL , Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 12:58:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes:
    Pascal> Hi Michael:

    Pascal> You're right. So back to basics:

    Pascal> - we have a problem providing Route Information Option (RIO
    Pascal> defined in RFC 4191) and Prefix Information Option (PIO
    Pascal> defined in RFC 4861) in RAs sent out by RPL routers.

    Pascal> - we can expect that there are authoritative routers in the
    Pascal> RPL network that already know what to do there. We could
    Pascal> assert that they should be roots since roots are providing
    Pascal> such info already. 

    Pascal> - we figure ripples and trickles are well fit to propagate
    Pascal> the knowledge of those prefixes and the right to use it.

    Pascal> - we have something like a RIO in RPL today called the Destination
    Pascal> Prefix subOption in the DIO message.


    Pascal> What can we do from there
    Pascal> - overload existing DPO like I proposed. That's the minimum
    Pascal> change but lacks some info present in PIO like lifetimes.

    Pascal> - Define a new option for use in DIO that looks more like a PIO

I prefer this. The prefix lifetimes are important for renumbering.
Let's crib the entire PIO, pretty much as-is.

I'm agnostic about replacing the DestinationPrefix with a literal
RIO. It seems like a good symmetry though.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9WN0YCLcPvd0N1lAQJ0tgf/T3/AZRGc7tQ5RRj5O/iBFCy++BmON5to
C6g5FxAYHwMpj2jKtRqQXV5NNYUZPE2RK3egv8rZT1/QKSYLeMcFAytJDh23opNv
192lP8mkN8PFwYAWbcuJTpC5LZ/B5IdMpAmoOOp5xWaivo0j9BXvV4hXfEbOeAkQ
BYe/Ot8s6jgdTr6FGGuOUtkA3Sizdm8RxuT4n7EvXlDluSKsTJh5ynSIYw2VIPqm
Nt4GK34Q188G4CFXM6s+TPCrAxmCprFuOl7g3VhOCl+vW2x55v3TvuaTRrS8LZa+
wpi24AKyVlQ9DEYz1SC9ueDCLbaWPoYrk57Jo6QF7FmmZDHaS8RAEQ==
=lklj
-----END PGP SIGNATURE-----

From robert.cragie@gridmerge.com  Mon Apr 26 06:02:35 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358B13A6A73 for ; Mon, 26 Apr 2010 06:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAAclbDEpiTa for ; Mon, 26 Apr 2010 06:02:33 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 2E92B3A6BAC for ; Mon, 26 Apr 2010 06:02:32 -0700 (PDT)
Received: from client-86-29-253-126.pete.adsl.virginmedia.com ([86.29.253.126] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O6Nx4-0004Us-HU for roll@ietf.org; Mon, 26 Apr 2010 14:02:19 +0100
Message-ID: <4BD58ED9.8070401@gridmerge.com>
Date: Mon, 26 Apr 2010 14:02:17 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000808020208060104010700"
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 13:02:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms000808020208060104010700
Content-Type: multipart/alternative;
 boundary="------------050701070403010102040707"

This is a multi-part message in MIME format.
--------------050701070403010102040707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Michael, Pascal,

Good to see this being discussed! My preference would be:

Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.

This then makes DIO more a general purpose message with controlled=20
propagation based on DODAG. This then eliminates the need for some of=20
the more complex parts of ND for 6LRs/6LBRs which use RPL.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:
> Hi Michael:
>
> You're right. So back to basics:
>
> - we have a problem providing Route Information Option (RIO defined in
> RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RA=
s
> sent out by RPL routers.
> - we can expect that there are authoritative routers in the RPL network=

> that already know what to do there. We could assert that they should be=

> roots since roots are providing such info already.
> - we figure ripples and trickles are well fit to propagate the knowledg=
e
> of those prefixes and the right to use it.
> - we have something like a RIO in RPL today called the Destination
> Prefix subOption in the DIO message.
>
> What can we do from there
> - overload existing DPO like I proposed. That's the minimum change but
> lacks some info present in PIO like lifetimes.
> - Define a new option for use in DIO that looks more like a PIO
> - Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
> obsoleted by RIO.
> - other?
>
> What do you think?
>
> Pascal
>
>
>   =20
>> -----Original Message-----
>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
>> Sent: Monday, April 26, 2010 2:38 AM
>> To: Pascal Thubert (pthubert)
>> Cc: IETF ROLL; Erik Nordmark
>> Subject: Re: [Roll] how does a node get an IP address
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>     =20
>>>>>>> "Pascal" =3D=3D Pascal Thubert<(pthubert)">
>>>>>>>               =20
>> writes:
>>      Pascal>  Good question!
>>
>>      Pascal>  In fact we have the problem at 6LoWPAN, when wan a route=
r
>>
>> s/wan/can/ ??
>>
>>      Pascal>  safely announce a prefix for autoconf.  An answer can be=
,
>>     =20
> as
>   =20
>>      Pascal>  long as it is still tightly coupled with an authoritativ=
e
>>      Pascal>  router that owns that prefix, the coupling insuring that=

>>      Pascal>  both routers are still in a same subnet.  Typically a RP=
L
>>      Pascal>  instance could tie together a subnet.
>>
>> So, what I think you are saying is that having RPL nodes sending out
>>     =20
> RAs
>   =20
>> themselves is frought with issues, and there are some situations where=

>> it is in fact the right answer?
>>
>> But, I think you are saying, in order to cover all situations more
>> clearly, we are going to overload the Destination Prefix option, and
>>     =20
> you
>   =20
>> then provide a proposed format for it.
>>
>> Before we discuss the solution, I'd like to get clear agreement from
>>     =20
> the
>   =20
>> WG that I've properly understood the problem.
>>
>> I do wonder if adding the (R) flag is better than having a new option.=

>> It seems that there are really two distinct activities here:
>>     a) configuring a local address
>>     b) announcing routability information out of the DODAG.
>>
>> - --
>> ]       He who is tired of Weird Al is tired of life!           |
>>     =20
> firewalls  [
>   =20
>> ]   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.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Finger me for keys
>>
>> iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
>> J
>> ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
>> oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
>> RH
>> hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
>> VV+6L6J
>> o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
>> TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
>> =3DeFYy
>> -----END PGP SIGNATURE-----
>>     =20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>   =20

--------------050701070403010102040707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


Hi Michael, Pascal,
    

    
Good to see this being discussed! My preference would be:
    

    Allow DIO to transport existing PIO and RIO. Get rid of DP=
O  that's
obsoleted by RIO.
    
This then makes DIO more a general purpose message with controlled
propagation based on DODAG. This then eliminates the need for some of
the more complex parts of ND for 6LRs/6LBRs which use RPL.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
    http://www.gridmerge.com
    

    

    
On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:

    
  
    Hi Michael:

You're right. So back to basics:

- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.

What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?

What do you think?

Pascal


  
    
  
    
    
    -----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


    
    
    
    
      
    
        
    
          
    
            
    
              
    "Pascal" =3D=3D Pascal Thubert <(pthubert=
)" =
<pthubert@cisco.com>>
              
    
            
    
          
    
        
    
      
    
    
    
    
    writes:
    Pascal> Good question!

    Pascal> In fact we have the problem at 6LoWPAN, when wan a router

s/wan/can/ ??

    Pascal> safely announce a prefix for autoconf.  An answer can be,
    
    
  
    
  
    as
  
    
  
    
    
        Pascal> long as it is still tightly coupled wit=
h an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.

So, what I think you are saying is that having RPL nodes sending out
    
    
  
    
  
    RAs
  
    
  
    
    
    themselves is frought with issues, and there are some =
situations where
it is in fact the right answer?

But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and
    
    
  
    
  
    you
  
    
  
    
    
    then provide a proposed format for it.

Before we discuss the solution, I'd like to get clear agreement from
    
    
  
    
  
    the
  
    
  
    
    
    WG that I've properly understood the problem.

I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address
   b) announcing routability information out of the DODAG.

- --
]       He who is tired of Weird Al is tired of life!           |
    
    
  
    
  
    firewalls  [
  
    
  
    
    
    ]   Michael Richardson, Sandelman Software Works, Otta=
wa, ON    |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottaw=
a.on.ca/
|device driver[
   Kyoto Plus: watch the video
<http://www.youtube.com/watch?v=3Dkzx1ycLXQSE>
	               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
RH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
=3DeFYy
-----END PGP SIGNATURE-----
    
    
  
    
  
    _______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll

  
    

    



--------------050701070403010102040707--

--------------ms000808020208060104010700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MjYxMzAyMTdaMCMGCSqGSIb3DQEJBDEWBBRFMDqhIj7A0iJguZZvxzVFFvFp2jBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAIP6iuMTcDQQQQBwy8/scILnuRPThgF+2T2mw3ExxtjWuwJEhkXUT5+W/c14HpmaFUIU
l/VVL42Htxjy/U02o4cG/v6E9XelvSxp8CeL19QvJEinOKB7jMurqqiPuCPxfKoYT0U6Vpb8
GoVpiOgPY3I3kB8SwF8N+bKxG/dEMT6VyHzYC9h5b6K7qxx12TImcJ2GAo1Qkf9F4xX2qjde
SPCWkht2dQJoc8UndmkOku1KKQSIwOW3avcUCbq7kAAqjo5SdUv9Y/nZ5HzqpqShBjz3KOkq
QLUliyUcYEPz1zZd6v3vwjqbRbCQOrzJyRw0mB5aHLaLwlTS7TRaa6glwHcAAAAAAAA=
--------------ms000808020208060104010700--

From abr@sdesigns.dk  Mon Apr 26 06:18:32 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732033A6A83 for ; Mon, 26 Apr 2010 06:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.013
X-Spam-Level: 
X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.585,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvGvklqapJru for ; Mon, 26 Apr 2010 06:18:30 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 4ABBC3A6B1F for ; Mon, 26 Apr 2010 06:18:01 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAE542.DDCE2160"
Date: Mon, 26 Apr 2010 15:17:48 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local>
In-Reply-To: <4BD58ED9.8070401@gridmerge.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrlQLqbKrFsFTl4R7KRWv0ieTnTDgAAbZdg
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com>
From: "Anders Brandt" 
To: , 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 13:18:32 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAE542.DDCE2160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Just to be sure I understand you guys:
=20
Do you mean to mix up IP subnet/address assignment with the actual
routing protocol?
I would expect the IP address assignment should be agnostic whether mesh
under, RPL or RPLvX is the current routing engine?
=20
Thanks,
  Anders


________________________________

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Robert Cragie
	Sent: Monday, April 26, 2010 15:02
	To: roll@ietf.org
	Subject: Re: [Roll] how does a node get an IP address
=09
=09
	Hi Michael, Pascal,
=09
	Good to see this being discussed! My preference would be:
=09
	Allow DIO to transport existing PIO and RIO. Get rid of DPO
that's
	obsoleted by RIO.
	This then makes DIO more a general purpose message with
controlled propagation based on DODAG. This then eliminates the need for
some of the more complex parts of ND for 6LRs/6LBRs which use RPL.
=09
	Robert
=09

	Robert Cragie (Pacific Gas & Electric)

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888
	http://www.gridmerge.com =20


	On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:=20

		Hi Michael:
	=09
		You're right. So back to basics:
	=09
		- we have a problem providing Route Information Option
(RIO defined in
		RFC 4191) and Prefix Information Option (PIO defined in
RFC 4861) in RAs
		sent out by RPL routers.
		- we can expect that there are authoritative routers in
the RPL network
		that already know what to do there. We could assert that
they should be
		roots since roots are providing such info already.
		- we figure ripples and trickles are well fit to
propagate the knowledge
		of those prefixes and the right to use it.
		- we have something like a RIO in RPL today called the
Destination
		Prefix subOption in the DIO message.
	=09
		What can we do from there
		- overload existing DPO like I proposed. That's the
minimum change but
		lacks some info present in PIO like lifetimes.
		- Define a new option for use in DIO that looks more
like a PIO
		- Allow DIO to transport existing PIO and RIO. Get rid
of DPO  that's
		obsoleted by RIO.
		- other?
	=09
		What do you think?
	=09
		Pascal
	=09
	=09
		 =20

			-----Original Message-----
			From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
			Sent: Monday, April 26, 2010 2:38 AM
			To: Pascal Thubert (pthubert)
			Cc: IETF ROLL; Erik Nordmark
			Subject: Re: [Roll] how does a node get an IP
address
		=09
			-----BEGIN PGP SIGNED MESSAGE-----
			Hash: SHA1
		=09
		=09
			   =20

				"Pascal" =3D=3D Pascal Thubert <(pthubert)"
  >
				             =20

			writes:
			    Pascal> Good question!
		=09
			    Pascal> In fact we have the problem at
6LoWPAN, when wan a router
		=09
			s/wan/can/ ??
		=09
			    Pascal> safely announce a prefix for
autoconf.  An answer can be,
			   =20

		as
		 =20

			    Pascal> long as it is still tightly coupled
with an authoritative
			    Pascal> router that owns that prefix, the
coupling insuring that
			    Pascal> both routers are still in a same
subnet.  Typically a RPL
			    Pascal> instance could tie together a
subnet.
		=09
			So, what I think you are saying is that having
RPL nodes sending out
			   =20

		RAs
		 =20

			themselves is frought with issues, and there are
some situations where
			it is in fact the right answer?
		=09
			But, I think you are saying, in order to cover
all situations more
			clearly, we are going to overload the
Destination Prefix option, and
			   =20

		you
		 =20

			then provide a proposed format for it.
		=09
			Before we discuss the solution, I'd like to get
clear agreement from
			   =20

		the
		 =20

			WG that I've properly understood the problem.
		=09
			I do wonder if adding the (R) flag is better
than having a new option.
			It seems that there are really two distinct
activities here:
			   a) configuring a local address
			   b) announcing routability information out of
the DODAG.
		=09
			- --
			]       He who is tired of Weird Al is tired of
life!           |
			   =20

		firewalls  [
		 =20

			]   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
			
=20
				               then sign the petition.
			-----BEGIN PGP SIGNATURE-----
			Version: GnuPG v1.4.9 (GNU/Linux)
			Comment: Finger me for keys
		=09
=09
iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
			J
=09
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
=09
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
			RH
=09
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
			VV+6L6J
=09
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
=09
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
			=3DeFYy
			-----END PGP SIGNATURE-----
			   =20

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


------_=_NextPart_001_01CAE542.DDCE2160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







    Just to be sure I understand you =
guys:
    

     
    

    Do you mean to mix up IP subnet/address =
assignment with the=20
actual routing protocol?
    

    I would expect the IP address assignment should =
be agnostic=20
whether mesh under, RPL or RPLvX is the current routing=20
engine?
    

     
    

    Thanks,
    

      Anders

    

    
  
    
  
    
  From: roll-bounces@ietf.org=20
  [mailto:roll-bounces@ietf.org] On Behalf Of Robert=20
  Cragie
    Sent: Monday, April 26, 2010 15:02
    To:=20
  roll@ietf.org
    Subject: Re: [Roll] how does a node get an IP=20
  address

    
  
    Hi Michael, Pascal,

    Good to see this being =
discussed! My=20
  preference would be:
    Allow DIO to transport existing =
PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
    This then makes DIO more a general purpose =
message with=20
  controlled propagation based on DODAG. This then eliminates the need =
for some=20
  of the more complex parts of ND for 6LRs/6LBRs which use=20
RPL.

    Robert
    
  
    
  

  
    Robert Cragie (Pacific Gas & Electric)
    
  
    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, =
UK
    +44=20
  (0) 1924 910888
    http://www.gridmerge.com
    =

    On=20
  26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:=20
  
    Hi Michael:

You're right. So back to basics:

- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.

What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?

What do you think?

Pascal


  
    
    
    -----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

    writes:
    Pascal> Good question!

    Pascal> In fact we have the problem at 6LoWPAN, when wan a router

s/wan/can/ ??

    Pascal> safely announce a prefix for autoconf.  An answer can be,
    
    as
  
    
    
        Pascal> long as it =
is still tightly coupled with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.

So, what I think you are saying is that having RPL nodes sending out
    
    RAs
  
    
    
    themselves is frought with =
issues, and there are some situations where
it is in fact the right answer?

But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and
    
    you
  
    
    
    then provide a proposed =
format for it.

Before we discuss the solution, I'd like to get clear agreement from
    
    the
  
    
    
    WG that I've properly =
understood the problem.

I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address
   b) announcing routability information out of the DODAG.

- --
]       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.o=
n.ca/
|device driver[
   Kyoto Plus: watch the video
<http://www.yout=
ube.com/watch?v=3Dkzx1ycLXQSE>
	               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
RH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
=3DeFYy
-----END PGP SIGNATURE-----
    
    _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll

  
    

------_=_NextPart_001_01CAE542.DDCE2160--

From mcr@sandelman.ca  Mon Apr 26 06:43:39 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39933A6BB3 for ; Mon, 26 Apr 2010 06:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.633
X-Spam-Level: 
X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[AWL=-0.013,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r68YbaZhOgEV for ; Mon, 26 Apr 2010 06:43:38 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C367828C11C for ; Mon, 26 Apr 2010 06:43:25 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id F15AF34709; Mon, 26 Apr 2010 09:43:13 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 49A594E7D3; Mon, 26 Apr 2010 09:43:15 -0400 (EDT)
From: Michael Richardson 
To: "Anders Brandt" 
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 26 Apr 2010 09:43:15 -0400
Message-ID: <30465.1272289395@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 13:43:39 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Anders" == Anders Brandt  writes:
    Anders> Just to be sure I understand you guys:

    Anders> Do you mean to mix up IP subnet/address assignment with the actual
    Anders> routing protocol?

Yes, because the ability to reach the authoritative RS depends upon the
routing protocol.  

Otherwise, we are left with using link-local addresses for everything,
as that may be all that is valid.

- -- 
]       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. 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9WYcoCLcPvd0N1lAQIMgwf/dVQ4zDrERMFWIXmeMIgqcJPlA7c/d9it
uNCh6VyGrG1m2VX/A6GtM+IBOIQk8en5oUO6tjPxMwpDiUZBu1Jnd3q+b4Oo85JM
+fK/2zacoZFxHVFoBfHnVomJq5M4CHJKZz6I0HmbcruzaSfGlEWHTJPenq5ysxgm
KBWsWhgxMOGoreVntgeISPEIgXZb9pEuZSrvBnPw6W84FT8DhedS+jbeCE303Vmt
sE+suJ5hbqGjM4AvtXiujrulv1cy6GC4Pn8UUOcx9UWKRZ6jFcADi+Jg1+8nc9Zt
yc3HkortQtctKVmDtJjcCgLfyEO4X0HvRLIAjY1IRPRl7h1wAfMNvQ==
=r2ht
-----END PGP SIGNATURE-----

From daniel.gavelle@jennic.com  Mon Apr 26 07:04:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDE828C126 for ; Mon, 26 Apr 2010 07:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.746
X-Spam-Level: 
X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5CaSmvp-TFR for ; Mon, 26 Apr 2010 07:04:12 -0700 (PDT)
Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 2BD913A6358 for ; Mon, 26 Apr 2010 07:04:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 232619BE4FF; Mon, 26 Apr 2010 15:03:55 +0100 (BST)
Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT8RhY5m6u9p; Mon, 26 Apr 2010 15:03:55 +0100 (BST)
Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 0A701D6BB1; Mon, 26 Apr 2010 15:03:55 +0100 (BST)
Message-ID: <4BD59D4A.8030305@jennic.com>
Date: Mon, 26 Apr 2010 15:03:54 +0100
From: Daniel Gavelle 
Organization: Jennic Ltd.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Michael Richardson 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> <30465.1272289395@marajade.sandelman.ca>
In-Reply-To: <30465.1272289395@marajade.sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: daniel.gavelle@jennic.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 14:04:14 -0000

Isn't IP and subnet assignment replacing functionality that should be in 
ND?

The majority of ROLL implementations I know of at the moment are 
targeting 6LowPAN and there is a 6LowPAN ND draft in progress that 
covers subnet assignment and router discovery.

Daniel.


Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>>>>>> "Anders" == Anders Brandt  writes:
>     Anders> Just to be sure I understand you guys:
> 
>     Anders> Do you mean to mix up IP subnet/address assignment with the actual
>     Anders> routing protocol?
> 
> Yes, because the ability to reach the authoritative RS depends upon the
> routing protocol.  
> 
> Otherwise, we are left with using link-local addresses for everything,
> as that may be all that is valid.
> 
> - -- 
> ]       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. 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBS9WYcoCLcPvd0N1lAQIMgwf/dVQ4zDrERMFWIXmeMIgqcJPlA7c/d9it
> uNCh6VyGrG1m2VX/A6GtM+IBOIQk8en5oUO6tjPxMwpDiUZBu1Jnd3q+b4Oo85JM
> +fK/2zacoZFxHVFoBfHnVomJq5M4CHJKZz6I0HmbcruzaSfGlEWHTJPenq5ysxgm
> KBWsWhgxMOGoreVntgeISPEIgXZb9pEuZSrvBnPw6W84FT8DhedS+jbeCE303Vmt
> sE+suJ5hbqGjM4AvtXiujrulv1cy6GC4Pn8UUOcx9UWKRZ6jFcADi+Jg1+8nc9Zt
> yc3HkortQtctKVmDtJjcCgLfyEO4X0HvRLIAjY1IRPRl7h1wAfMNvQ==
> =r2ht
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

From robert.cragie@gridmerge.com  Mon Apr 26 07:12:21 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3543A6A26 for ; Mon, 26 Apr 2010 07:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uRKuF83D7HZ for ; Mon, 26 Apr 2010 07:12:19 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1CFD03A6BB5 for ; Mon, 26 Apr 2010 07:12:06 -0700 (PDT)
Received: from client-86-29-253-126.pete.adsl.virginmedia.com ([86.29.253.126] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O6P2O-00056A-VT; Mon, 26 Apr 2010 15:11:53 +0100
Message-ID: <4BD59F27.1020208@gridmerge.com>
Date: Mon, 26 Apr 2010 15:11:51 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Anders Brandt 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090900060505020207020009"
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Apr 2010 14:12:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms090900060505020207020009
Content-Type: multipart/alternative;
 boundary="------------070204050507060907070808"

This is a multi-part message in MIME format.
--------------070204050507060907070808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Not mix up as such but provide the option for it to be carried by=20
alternative means than RS/RA, which is (still) very 'on-link' centric.=20
If the routing protocol provides the ability to naturally disseminate=20
information, we should be able to use that.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 26/04/2010 2:17 PM, Anders Brandt wrote:
> Just to be sure I understand you guys:
> Do you mean to mix up IP subnet/address assignment with the actual=20
> routing protocol?
> I would expect the IP address assignment should be agnostic whether=20
> mesh under, RPL or RPLvX is the current routing engine?
> Thanks,
>   Anders
>
>     -------------------------------------------------------------------=
-----
>     *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
>     Behalf Of *Robert Cragie
>     *Sent:* Monday, April 26, 2010 15:02
>     *To:* roll@ietf.org
>     *Subject:* Re: [Roll] how does a node get an IP address
>
>     Hi Michael, Pascal,
>
>     Good to see this being discussed! My preference would be:
>
>     Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's=

>     obsoleted by RIO.
>
>     This then makes DIO more a general purpose message with controlled
>     propagation based on DODAG. This then eliminates the need for some
>     of the more complex parts of ND for 6LRs/6LBRs which use RPL.
>
>     Robert
>
>     Robert Cragie (Pacific Gas & Electric)
>
>     Gridmerge Ltd.
>     89 Greenfield Crescent,
>     Wakefield, WF4 4WA, UK
>     +44 (0) 1924 910888
>     http://www.gridmerge.com 
>
>
>     On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:
>>     Hi Michael:
>>
>>     You're right. So back to basics:
>>
>>     - we have a problem providing Route Information Option (RIO define=
d in
>>     RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) =
in RAs
>>     sent out by RPL routers.
>>     - we can expect that there are authoritative routers in the RPL ne=
twork
>>     that already know what to do there. We could assert that they shou=
ld be
>>     roots since roots are providing such info already.
>>     - we figure ripples and trickles are well fit to propagate the kno=
wledge
>>     of those prefixes and the right to use it.
>>     - we have something like a RIO in RPL today called the Destination=

>>     Prefix subOption in the DIO message.
>>
>>     What can we do from there
>>     - overload existing DPO like I proposed. That's the minimum change=
 but
>>     lacks some info present in PIO like lifetimes.
>>     - Define a new option for use in DIO that looks more like a PIO
>>     - Allow DIO to transport existing PIO and RIO. Get rid of DPO  tha=
t's
>>     obsoleted by RIO.
>>     - other?
>>
>>     What do you think?
>>
>>     Pascal
>>
>>
>>       =20
>>>     -----Original Message-----
>>>     From:mcr@sandelman.ca  [mailto:mcr@sandelman.ca]
>>>     Sent: Monday, April 26, 2010 2:38 AM
>>>     To: Pascal Thubert (pthubert)
>>>     Cc: IETF ROLL; Erik Nordmark
>>>     Subject: Re: [Roll] how does a node get an IP address
>>>
>>>     -----BEGIN PGP SIGNED MESSAGE-----
>>>     Hash: SHA1
>>>
>>>
>>>         =20
>>>>>>>>     "Pascal" =3D=3D Pascal Thubert<(pthubert)">
>>>>>>>>                   =20
>>>     writes:
>>>          Pascal>  Good question!
>>>
>>>          Pascal>  In fact we have the problem at 6LoWPAN, when wan a =
router
>>>
>>>     s/wan/can/ ??
>>>
>>>          Pascal>  safely announce a prefix for autoconf.  An answer c=
an be,
>>>         =20
>>     as
>>       =20
>>>          Pascal>  long as it is still tightly coupled with an authori=
tative
>>>          Pascal>  router that owns that prefix, the coupling insuring=
 that
>>>          Pascal>  both routers are still in a same subnet.  Typically=
 a RPL
>>>          Pascal>  instance could tie together a subnet.
>>>
>>>     So, what I think you are saying is that having RPL nodes sending =
out
>>>         =20
>>     RAs
>>       =20
>>>     themselves is frought with issues, and there are some situations =
where
>>>     it is in fact the right answer?
>>>
>>>     But, I think you are saying, in order to cover all situations mor=
e
>>>     clearly, we are going to overload the Destination Prefix option, =
and
>>>         =20
>>     you
>>       =20
>>>     then provide a proposed format for it.
>>>
>>>     Before we discuss the solution, I'd like to get clear agreement f=
rom
>>>         =20
>>     the
>>       =20
>>>     WG that I've properly understood the problem.
>>>
>>>     I do wonder if adding the (R) flag is better than having a new op=
tion.
>>>     It seems that there are really two distinct activities here:
>>>         a) configuring a local address
>>>         b) announcing routability information out of the DODAG.
>>>
>>>     - --
>>>     ]       He who is tired of Weird Al is tired of life!           |=

>>>         =20
>>     firewalls  [
>>       =20
>>>     ]   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.
>>>     -----BEGIN PGP SIGNATURE-----
>>>     Version: GnuPG v1.4.9 (GNU/Linux)
>>>     Comment: Finger me for keys
>>>
>>>     iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
>>>     J
>>>     ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
>>>     oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
>>>     RH
>>>     hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
>>>     VV+6L6J
>>>     o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
>>>     TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
>>>     =3DeFYy
>>>     -----END PGP SIGNATURE-----
>>>         =20
>>     _______________________________________________
>>     Roll mailing list
>>     Roll@ietf.org
>>     https://www.ietf.org/mailman/listinfo/roll
>>
>>       =20
>

--------------070204050507060907070808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


Not mix up as such but provide the option for it to be carried by
alternative means than RS/RA, which is (still) very 'on-link' centric.
If the routing protocol provides the ability to naturally disseminate
information, we should be able to use that.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 26/04/2010 2:17 PM, Anders Brandt wrote:

    
  
  
  
    Just to be sure I understand=
 you
guys:
    
  
     
    
  
    Do you mean to mix up IP
subnet/address assignment with the actual routing protocol?=

    
  
    I would expect the IP addres=
s
assignment should be agnostic whether mesh under, RPL or RPLvX is the
current routing engine?
    
  
     
    
  
    Thanks,
    
  
      Anders<=
/div>
  
    
  
    
    
    
    
     From:
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Beh=
alf Of Robert
Cragie
    
    Sent: Monday, April 26, 2010 15:02
    
    To: roll@ietf.org
    
    Subject: Re: [Roll] how does a node get an IP address
    
    
    
    
    
Hi Michael, Pascal,
    
    
    
Good to see this being discussed! My preference would be:
    
    
    Allow DIO to transport existing PIO and RIO. Get rid o=
f DPO  that's
obsoleted by RIO.
    
This then makes DIO more a general purpose message with controlled
propagation based on DODAG. This then eliminates the need for some of
the more complex parts of ND for 6LRs/6LBRs which use RPL.
    
    
    
Robert
    
    
    
    
    
    Robert Cragie (Pacific Gas & Electric)
    
    
    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
    http:/=
/www.gridmerge.com
    
    
    
    
    
On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:
    
    
      
    Hi Michael:

You're right. So back to basics:

- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.

What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?

What do you think?

Pascal


  
    
      
    
        
    -----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


    
    
        
    
          
    
            
    
              
    
                
    
                  
    "Pascal" =3D=3D Pascal Thubert <(pthu=
bert)" <pthubert@cisco.com>>
              
    
                
    
              
    
            
    
          
    
        
    
        
    writes:
    Pascal> Good question!

    Pascal> In fact we have the problem at 6LoWPAN, when wan a router

s/wan/can/ ??

    Pascal> safely announce a prefix for autoconf.  An answer can be,
    
    
      
    
      
    as
  
    
      
    
        
        Pascal> long as it is still tightly coupled=
 with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.

So, what I think you are saying is that having RPL nodes sending out
    
    
      
    
      
    RAs
  
    
      
    
        
    themselves is frought with issues, and there are s=
ome situations where
it is in fact the right answer?

But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and
    
    
      
    
      
    you
  
    
      
    
        
    then provide a proposed format for it.

Before we discuss the solution, I'd like to get clear agreement from
    
    
      
    
      
    the
  
    
      
    
        
    WG that I've properly understood the problem.

I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address
   b) announcing routability information out of the DODAG.

- --
]       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
<http://www.you=
tube.com/watch?v=3Dkzx1ycLXQSE>
	               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
RH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
=3DeFYy
-----END PGP SIGNATURE-----
    
    
      
    
      
    _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org=
/mailman/listinfo/roll

  
    
    
    
  
    

    



--------------070204050507060907070808--

--------------ms090900060505020207020009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MjYxNDExNTFaMCMGCSqGSIb3DQEJBDEWBBS7T5jONHxHKATni51tIyRsPlqb9zBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAI8kWrrtOyMueNt+agjl/8Uf+wIUd1YmXAd/4g7ZtYVb/n/Xg2tV0jKs1sPlcrjeYYlC
TpAx77cawf7nl51FevQVVdGRi1Pav8eoHNu7elfaYOEy4vuF4ob4lDNpIN1x8TlwLhhb9Ie4
7KO5PNsu8WIVXwn9QaWK5I5oMmjeZJsYzijaiABefQ+V6FRzkgaKoaWy4DkK8ODZLJEv0ozP
oXuN8lYZEsoqjcQPASQGa+jm3T2D7kco04FBR3P/bnnk14/W1F+bqQvRkq2DviVTIvqOmDr5
1skIkKdp+1PUOCZmjkZ7DgLsKTYI6ghUAcROL300BcWBHxtIoycD+il5B3EAAAAAAAA=
--------------ms090900060505020207020009--

From mcr@sandelman.ca  Mon Apr 26 07:15:53 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E03428C10C for ; Mon, 26 Apr 2010 07:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.634
X-Spam-Level: 
X-Spam-Status: No, score=0.634 tagged_above=-999 required=5 tests=[AWL=-0.012,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifQJNOjpJbdD for ; Mon, 26 Apr 2010 07:15:52 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E1CF43A69E3 for ; Mon, 26 Apr 2010 07:15:31 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 4398034709; Mon, 26 Apr 2010 10:15:20 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id BBB164E7D3; Mon, 26 Apr 2010 10:15:21 -0400 (EDT)
From: Michael Richardson 
To: daniel.gavelle@jennic.com
In-Reply-To: <4BD59D4A.8030305@jennic.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> <30465.1272289395@marajade.sandelman.ca> <4BD59D4A.8030305@jennic.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 26 Apr 2010 10:15:21 -0400
Message-ID: <2032.1272291321@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 14:15:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Daniel" == Daniel Gavelle  writes:
    Daniel> Isn't IP and subnet assignment replacing functionality that
    Daniel> should be in ND? 

    Daniel> The majority of ROLL implementations I know of at the moment
    Daniel> are targeting 6LowPAN and there is a 6LowPAN ND draft in
    Daniel> progress that covers subnet 
    Daniel> assignment and router discovery.

I am not targetting 6lowpan, nor does RPL make that assumption.

If you have working ND, then great.  Last I read, one mode of 6lowpan
won't have working ND until RPL finishes, and as far as I can see,
configuring an IP address is an important part of joining a DODAG.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9Wf+ICLcPvd0N1lAQKQ/gf/aEaqfCvOVsfX+t+Ay4EZnBTznLbkTp8n
PqSGPJwL4hvepoJTtsOypGkgPAUNfnUH/Awpum5Dnu3X4UwZapscERzpAvsxaFQP
iHcx/oOdbTkay/oManeCzFM6OvsH/+uemeD4xvMb7bkYTZYMEjN4J1N+TEiZnKTK
2DHa9cVN9N32DJ1Bbmow/7DIxkOmh/EBsbTqNmNdHTbXUJ3oL7CK0oe6v+t0zpOk
3RLen7pU2W4jc9ZdEluKNAENCr8ZmUj+VFABkg81S856lopX+y6ft4/oi6l7ml7H
JuiLOiJYi/IRQQs7qEU+h5I+SGZqNZmnZQvdlO/3i1YLcOWL2lkT1g==
=VoZm
-----END PGP SIGNATURE-----

From Michael.Cowan@us.elster.com  Mon Apr 26 12:10:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D563A6A1F for ; Mon, 26 Apr 2010 12:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huHxYI1hS5WV for ; Mon, 26 Apr 2010 12:10:24 -0700 (PDT)
Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id 2EBA43A68A4 for ; Mon, 26 Apr 2010 12:10:24 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Michael.Cowan@us.elster.com
X-Msg-Ref: server-2.tower-53.messagelabs.com!1272309008!48604762!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [206.182.155.20]
Received: (qmail 32370 invoked from network); 26 Apr 2010 19:10:12 -0000
Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-2.tower-53.messagelabs.com with SMTP; 26 Apr 2010 19:10:12 -0000
Auto-Submitted: auto-generated
From: Michael.Cowan@us.elster.com
To: roll@ietf.org
Message-ID: 
Date: Mon, 26 Apr 2010 15:10:16 -0400
X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 04/26/2010 03:06:07 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [Roll] AUTO: Michael Cowan is out of the office (returning 04/30/2010)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 19:10:26 -0000

I am out of the office until 04/30/2010.

Hello,

   I will be out of the office Apr 26th at 1:30PM through Apr 29nd
traveling on business, return to office Apr 30th in the morning.  I will be
checking email in the evening (will not have access to email during the
day) and if it's a emergency, please call my cell at 919-901-9126.

Thank You,
Michael



Note: This is an automated response to your message  "Roll Digest, Vol 27,
Issue 84" sent on 4/26/2010 3:00:09 PM.

This is the only notification you will receive while this person is away.


From jreddy@ti.com  Mon Apr 26 16:32:53 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5573A6C04 for ; Mon, 26 Apr 2010 16:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-jtPZWNry8b for ; Mon, 26 Apr 2010 16:32:53 -0700 (PDT)
Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id 153453A6BE0 for ; Mon, 26 Apr 2010 16:32:53 -0700 (PDT)
Received: from dlep36.itg.ti.com ([157.170.170.91]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id o3QNWeKu031868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Apr 2010 18:32:40 -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 o3QNWeEq011466 for ; Mon, 26 Apr 2010 18:32:40 -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 o3QNWe0v023970 for ; Mon, 26 Apr 2010 18:32:40 -0500 (CDT)
Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Mon, 26 Apr 2010 18:32:39 -0500
From: "Reddy, Joseph" 
To: "roll@ietf.org" 
Date: Mon, 26 Apr 2010 18:32:24 -0500
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrlcsVe9UZ1rFmXQIy4QezbsFY+GQAJWlbg
Message-ID: 
References: 
In-Reply-To: 
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] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Apr 2010 23:32:53 -0000

=20
Hi Michael,

I believe you need to have "working ND" to operate in an IPv6 network. Whet=
her that is 6lowpan-ND or classic-ND or some other version. I don't believe=
 RPL should try to solve the problem of configuing an IP address and perfor=
ming router discovery.=20

-Joseph

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

>>>>> "Daniel" =3D=3D Daniel Gavelle  writes:
    Daniel> Isn't IP and subnet assignment replacing functionality that
    Daniel> should be in ND?=20

    Daniel> The majority of ROLL implementations I know of at the moment
    Daniel> are targeting 6LowPAN and there is a 6LowPAN ND draft in
    Daniel> progress that covers subnet=20
    Daniel> assignment and router discovery.

>>>[Michael Richardson]

>>>I am not targetting 6lowpan, nor does RPL make that assumption.

>>>If you have working ND, then great.  Last I read, one mode of 6lowpan wo=
n't have working ND until RPL finishes, and as far as I can see, configurin=
g an IP address is an important part of joining a DODAG.





From samitac@ipinfusion.com  Mon Apr 26 17:19:45 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF56D3A6A77 for ; Mon, 26 Apr 2010 17:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.336
X-Spam-Level: 
X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nct3HR3LBJzx for ; Mon, 26 Apr 2010 17:19:44 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3F0E93A6A24 for ; Mon, 26 Apr 2010 17:19:44 -0700 (PDT)
Received: (qmail 47563 invoked from network); 27 Apr 2010 00:19:29 -0000
Received: from adsl-71-141-104-10.dsl.snfc21.pacbell.net (samitac@71.141.104.10 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Apr 2010 17:19:29 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: OKImro0VM1lcT3U9OF0kKpMkLw9g_WdfiCOrRNCt2cXK3VLrg6Cm53gJwHASiqwJASHJTGWjOByNmHXO2wnukvQR1b72j_ZCfhhJjdIS6qN5BrC4HUKcKEVd5ZuMg1HUVMx21Hiwr6Rqll1HPSnHG0E.8z5KB17rUGqe9_f9.XhWA4ktAradQL9SofSkwMND.DWJE5tFpuL0.TSLV400oydHGT073FSC31Mg9eXadvYmFFBSvCi7ZpkE2UImj.94niRE1ahO1pBXRMA6dS6xHybVit.vzrp4
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: , "'Michael Richardson'" 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local>	<30465.1272289395@marajade.sandelman.ca> <4BD59D4A.8030305@jennic.com>
In-Reply-To: <4BD59D4A.8030305@jennic.com>
Date: Mon, 26 Apr 2010 17:19:24 -0700
Message-ID: <0a9a01cae59f$4cb0b3d0$e6121b70$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrlSUsrV09u7nhGRcOtW5bFzT3P6wAVEDSg
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 00:19:45 -0000

Hi Daniel/Anders and all,


> 
> Isn't IP and subnet assignment replacing functionality that should be in
ND?
> 
> The majority of ROLL implementations I know of at the moment are targeting
> 6LowPAN and there is a 6LowPAN ND draft in progress that covers subnet
> assignment and router discovery.
> 

[SC>] 

Yes.  The network address-assignment will be done either through ND
auto-configuration or DHCPv6 typically.
Roll runs on route-over topology - thus in this case 6lowpan-nd has a
mechanism for disseminating a unique Ipv6 prefix across the 6lowpan network.

Note, 6LRs are nothing but forwarding nodes in ROLL network. 6LBR is the
entity which is responsible for Ipv6-address deligation and making sure that
the address assignment is reliable. 6LBRs are also responsible for
forwarding packets from one LLN to another.

So the idea is that once the addresses are assigned and neighbors' addresses
are known, these information may be conveyed to the routing protocol. Thus
RPL should be able to find out from neighbor cache information about the
reachability of nexthop routers.


Thanks,
-Samita

> 
> 
> Michael Richardson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >>>>>> "Anders" == Anders Brandt  writes:
> >     Anders> Just to be sure I understand you guys:
> >
> >     Anders> Do you mean to mix up IP subnet/address assignment with the
> actual
> >     Anders> routing protocol?
> >
> > Yes, because the ability to reach the authoritative RS depends upon
> > the routing protocol.
> >
> > Otherwise, we are left with using link-local addresses for everything,
> > as that may be all that is valid.
> >
> > - --
> > ]       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.
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> > Comment: Finger me for keys
> >
> > iQEVAwUBS9WYcoCLcPvd0N1lAQIMgwf/dVQ4zDrERMFWIXmeMIgqcJPlA7c/d9it
> > uNCh6VyGrG1m2VX/A6GtM+IBOIQk8en5oUO6tjPxMwpDiUZBu1Jnd3q+b4Oo85JM
> > +fK/2zacoZFxHVFoBfHnVomJq5M4CHJKZz6I0HmbcruzaSfGlEWHTJPenq5ysxgm
> > KBWsWhgxMOGoreVntgeISPEIgXZb9pEuZSrvBnPw6W84FT8DhedS+jbeCE303Vmt
> > sE+suJ5hbqGjM4AvtXiujrulv1cy6GC4Pn8UUOcx9UWKRZ6jFcADi+Jg1+8nc9Zt
> > yc3HkortQtctKVmDtJjcCgLfyEO4X0HvRLIAjY1IRPRl7h1wAfMNvQ==
> > =r2ht
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> >
> 
> --
> __________________________________________________
> Daniel Gavelle, Software Engineer
> Tel: +44 114 281 2655
> Fax: +44 114 281 2951
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371
> Registered In England http://www.jennic.com
> __________________________________________________
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll




From samitac@ipinfusion.com  Mon Apr 26 17:49:37 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04CC3A67FD for ; Mon, 26 Apr 2010 17:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.038
X-Spam-Level: 
X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.298,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, TRACKER_ID=2.003, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erCN6YOPvAIR for ; Mon, 26 Apr 2010 17:49:36 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 1C1B53A686E for ; Mon, 26 Apr 2010 17:49:35 -0700 (PDT)
Received: (qmail 78728 invoked from network); 27 Apr 2010 00:49:24 -0000
Received: from adsl-71-141-104-10.dsl.snfc21.pacbell.net (samitac@71.141.104.10 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Apr 2010 17:49:23 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: _RXiZykVM1ld5Q9Zw2o95zTT8uuCOVi.97pBB4eOCc_bTbkl22FciR5Hi.PGiAfxI7Rm29YfdDQrZTEts3qx0uum97PwlRAR.XBsBpTdbVtLkJ9DhdJjlmtOxkbFyRffDpttNftll.064A04dsQFHrnzogFUEUXskTTKRid7rDU2EGP4tCnz.1nq2TXjdFwNsx4EQRIO4y6awt4VGJp0Vzcg9OIcajOQKv5X1yO830M9jBCUEuKidpPtszJC2iMoRLEzfE80pFMeHpEhXfPW.R.CO9d2sGez
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: , "'Anders Brandt'" 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> <4BD59F27.1020208@gridmerge.com>
In-Reply-To: <4BD59F27.1020208@gridmerge.com>
Date: Mon, 26 Apr 2010 17:49:21 -0700
Message-ID: <0a9b01cae5a3$79d6a320$6d83e960$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A9C_01CAE568.CD77CB20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrlSm/U7APPVbHwRv+yrlSiDVpjHAAVPWqg
Content-Language: en-us
x-cr-hashedpuzzle: EwXi JGAf KPlo LyL3 NFVo PNVl PYwF QStn Q6bM Q8hs SmDL Thxq Xh+L dPl0 eOBh jlnq; 3; YQBiAHIAQABzAGQAZQBzAGkAZwBuAHMALgBkAGsAOwByAG8AYgBlAHIAdAAuAGMAcgBhAGcAaQBlAEAAZwByAGkAZABtAGUAcgBnAGUALgBjAG8AbQA7AHIAbwBsAGwAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8168E671-835F-4801-8F29-08137ADE34AC}; cwBhAG0AaQB0AGEAYwBAAGkAcABpAG4AZgB1AHMAaQBvAG4ALgBjAG8AbQA=; Tue, 27 Apr 2010 00:49:15 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAGgAbwB3ACAAZABvAGUAcwAgAGEAIABuAG8AZABlACAAZwBlAHQAIABhAG4AIABJAFAAIABhAGQAZAByAGUAcwBzAA==
x-cr-puzzleid: {8168E671-835F-4801-8F29-08137ADE34AC}
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 00:49:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0A9C_01CAE568.CD77CB20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Robert,

 

As per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be
off-link and in that case, the packets are always forwarded to the
default-router  and direct delivery from host-to-host are not done.
6lowpan-nd auto-configuration always assumes that the nodes are off-link and
use the default-router to be the forwarder.

When RPL or a routing protocol is running, the default-router functionality
will be unlikely  needed  if all nodes are running RPL code. However, the
initial address assignment/dissemination among all nodes are still possible
using 6lowpan-nd simple mechanism for address dissemination and address
auto-configuration. But one can decide to choose some other mechanism as
well such as dhcpv6, static configuration etc.

 

-Samita

 

 

 

Not mix up as such but provide the option for it to be carried by
alternative means than RS/RA, which is (still) very 'on-link' centric. If
the routing protocol provides the ability to naturally disseminate
information, we should be able to use that.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 26/04/2010 2:17 PM, Anders Brandt wrote: 

Just to be sure I understand you guys:

 

Do you mean to mix up IP subnet/address assignment with the actual routing
protocol?

I would expect the IP address assignment should be agnostic whether mesh
under, RPL or RPLvX is the current routing engine?

 

Thanks,

  Anders

 

  _____  

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: Monday, April 26, 2010 15:02
To: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address

Hi Michael, Pascal,

Good to see this being discussed! My preference would be:



Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.

This then makes DIO more a general purpose message with controlled
propagation based on DODAG. This then eliminates the need for some of the
more complex parts of ND for 6LRs/6LBRs which use RPL.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote: 

Hi Michael:
 
You're right. So back to basics:
 
- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.
 
What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?
 
What do you think?
 
Pascal
 
 
  

-----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
    

"Pascal" == Pascal Thubert <(pthubert)"  
>
              

writes:
    Pascal> Good question!
 
    Pascal> In fact we have the problem at 6LoWPAN, when wan a router
 
s/wan/can/ ??
 
    Pascal> safely announce a prefix for autoconf.  An answer can be,
    

as
  

    Pascal> long as it is still tightly coupled with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.
 
So, what I think you are saying is that having RPL nodes sending out
    

RAs
  

themselves is frought with issues, and there are some situations where
it is in fact the right answer?
 
But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and
    

you
  

then provide a proposed format for it.
 
Before we discuss the solution, I'd like to get clear agreement from
    

the
  

WG that I've properly understood the problem.
 
I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address
   b) announcing routability information out of the DODAG.
 
- --
]       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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys
 
iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
RH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA==
=eFYy
-----END PGP SIGNATURE-----
    

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


------=_NextPart_000_0A9C_01CAE568.CD77CB20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable














    


    Hi
Robert,
    


     =

    


    As
per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be =
off-link
and in that case, the packets are always forwarded to the =
default-router  and
direct delivery from host-to-host are not done. 6lowpan-nd =
auto-configuration
always assumes that the nodes are off-link and use the default-router to =
be the
forwarder.
    


    When
RPL or a routing protocol is running, the default-router functionality =
will be
unlikely  needed  if all nodes are running RPL code. However, =
the
initial address assignment/dissemination among all nodes are still =
possible
using 6lowpan-nd simple mechanism for address dissemination and address
auto-configuration. But one can decide to choose some other mechanism as =
well
such as dhcpv6, static configuration etc.
    


     =

    


    -Samita
    


     =

    


     =

    


    


     
    


    Not mix up as such but provide the option for it to =
be
carried by alternative means than RS/RA, which is (still) very 'on-link'
centric. If the routing protocol provides the ability to naturally =
disseminate
information, we should be able to use that.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 26/04/2010 2:17 PM, Anders Brandt wrote: 
    


    Just to be sure I understand you guys:
    


     
    


    Do you mean to mix up IP subnet/address assignment with the =
actual
routing protocol?
    


    I would expect the IP address assignment should be agnostic =
whether
mesh under, RPL or RPLvX is the current routing =
engine?
    


     
    


    Thanks,
    


      Anders
    


    =



     
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] =
On
Behalf Of Robert Cragie
    
Sent: Monday, April 26, 2010 15:02
    
To: roll@ietf.org
    
Subject: Re: [Roll] how does a node get an IP =
address
    


    Hi Michael, Pascal,
    

    
Good to see this being discussed! My preference would be:
    

    

    


    Allow DIO to transport existing PIO and RIO. Get rid of DPO  =
that's
    obsoleted by RIO.
    


    This then makes DIO more a general purpose message =
with
controlled propagation based on DODAG. This then eliminates the need for =
some
of the more complex parts of ND for 6LRs/6LBRs which use RPL.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi Michael:
     
    You're =
right. So back to =
basics:
     
    - we have a =
problem providing Route Information Option (RIO defined =
in
    RFC 4191) and Prefix Information Option (PIO =
defined in RFC 4861) in RAs
    sent out by RPL =
routers.
    - we can expect that there are =
authoritative routers in the RPL network
    that =
already know what to do there. We could assert that they should =
be
    roots since roots are providing such info =
already.
    - we figure ripples and trickles are well =
fit to propagate the knowledge
    of those prefixes =
and the right to use it.
    - we have something like a =
RIO in RPL today called the Destination
    Prefix =
subOption in the DIO =
message.
     
    What can we do =
from there
    - overload existing DPO like I proposed. =
That's the minimum change but
    lacks some info =
present in PIO like lifetimes.
    - Define a new =
option for use in DIO that looks more like a PIO
    - =
Allow DIO to transport existing PIO and RIO. Get rid of DPO  =
that's
    obsoleted by RIO.
    - =
other?
     
    What do you =
think?
     
    Pascal=

     
     
     =
 
    


    -----Original =
Message-----
    From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]<=
/pre>
    Sent: Monday, April 26, 2010 2:38 AM
    To: =
Pascal Thubert (pthubert)
    Cc: IETF ROLL; Erik =
Nordmark
    Subject: Re: [Roll] how does a node get an =
IP address
     
    -----BEGIN =
PGP SIGNED MESSAGE-----
    Hash: =
SHA1
     
     
        
    


    


    


    


    


    "Pascal" =
=3D=3D Pascal Thubert <(pthubert)" <pthubert@cisco.com>>
             &=
nbsp;    
    


    


    


    


    


    writes:
        Pascal> Good =
question!
     
      &n=
bsp; Pascal> In fact we have the problem at 6LoWPAN, when wan a =
router
     
    s/wan/can/ =
??
     
        =
Pascal> safely announce a prefix for autoconf.  An answer can =
be,
        =

    


    as
      
    


        =
Pascal> long as it is still tightly coupled with an =
authoritative
        Pascal> router =
that owns that prefix, the coupling insuring =
that
        Pascal> both routers are =
still in a same subnet.  Typically a =
RPL
        Pascal> instance could =
tie together a =
subnet.
     
    So, what I =
think you are saying is that having RPL nodes sending =
out
        =

    


    RAs
      
    


    themselves is =
frought with issues, and there are some situations =
where
    it is in fact the right =
answer?
     
    But, I think =
you are saying, in order to cover all situations =
more
    clearly, we are going to overload the =
Destination Prefix option, and
        =

    


    you
      
    


    then =
provide a proposed format for =
it.
     
    Before we discuss =
the solution, I'd like to get clear agreement =
from
        =

    


    the
      
    


    WG that =
I've properly understood the =
problem.
     
    I do wonder if =
adding the (R) flag is better than having a new =
option.
    It seems that there are really two distinct =
activities here:
       a) configuring a =
local address
       b) announcing =
routability information out of the =
DODAG.
     
    - =
--
    ]       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.o=
n.ca/
    |device =
driver[
       Kyoto Plus: watch the =
video
    <http://www.yout=
ube.com/watch?v=3Dkzx1ycLXQSE>
      &n=
bsp;    =
            &=
nbsp;  then sign the petition.
    -----BEGIN PGP =
SIGNATURE-----
    Version: GnuPG v1.4.9 =
(GNU/Linux)
    Comment: Finger me for =
keys
     
    iQEVAwUBS9TgUICLcPv=
d0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
    J<=
/o:p>
    ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR=
2GCxDVx
    oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+=
u/1GKpwUsacigkobbC
    RH
    hqlwzwBW3=
sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
    VV+=
6L6J
    o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53p=
d4aHmdgert9wYu8rE
    TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhg=
vW+aTQiSeQy8gHEJFFJA=3D=3D
    =3DeFYy
    <=
pre>-----END PGP SIGNATURE-----
        =

    


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


    


    





------=_NextPart_000_0A9C_01CAE568.CD77CB20--



From mcr@sandelman.ca  Mon Apr 26 18:08:34 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF793A6AC2 for ; Mon, 26 Apr 2010 18:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.636
X-Spam-Level: 
X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[AWL=-0.010,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGapYBSDQpdm for ; Mon, 26 Apr 2010 18:08:33 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0FB2A3A6AA3 for ; Mon, 26 Apr 2010 18:08:32 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id B978434739; Mon, 26 Apr 2010 21:08:20 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E8A924E799; Mon, 26 Apr 2010 21:08:21 -0400 (EDT)
From: Michael Richardson 
To: "Reddy, Joseph" 
In-Reply-To:  
References:   
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 26 Apr 2010 21:08:21 -0400
Message-ID: <29740.1272330501@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: "roll@ietf.org" 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 01:08:34 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Joseph" == Joseph Reddy  writes:
    Joseph> I believe you need to have "working ND" to operate in an
    Joseph> IPv6 network. Whether that is 6lowpan-ND or classic-ND or
    Joseph> some other version. I don't believe RPL should try to solve
    Joseph> the problem of configuing an IP address and performing
    Joseph> router discovery.

Then, what you are saying is either that:
      a) RPL must provide for multicast so that ND/DAD will work.
      b) RPL must always run on top of 6lowpan.

I don't object to a statement that 6lowpan is required.
In fact, life would be simpler if we just required parts of it
(at least the whiteboard parts).

I believe that RPL originally intended to work inside ND, and therefore
it made sense that you had "working ND" --- it no longer lives inside
ND, so the quesiton as to how ND works arises.

- -- 
]       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. 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9Y5BICLcPvd0N1lAQKakwgApeTYg0PEuUgrqnsEWhFHnmZnakFIfR57
PKU0m9CouglCpsiYFly6IPUSPU9mWtoD8wOnh1dIP45YeH6QRMiaZO+uJcAYUrpf
lLOCnzBkx+KkBwi/yKj5p/0XYkwJXKk5yyseF6tYmRTAADEl5xrbDR57Y9efNJ/f
n9GZhgAiF2/PglOgk+m9eHx/dOLMeIrXi7i+CLCAOUDcCSpEMXWhVjADUKZ/r+Q7
D5orCrdcO2DGRUKjKgZeXrak+iIjkSc3b4fScERKBdr7wCy6sJ/kBj5AFk2Pu5Wt
yXy4IIvyX40gqQEMjrie4zbF8HEcEkSUbonpplPwSNDQ/QxwzG8IHg==
=xQ3r
-----END PGP SIGNATURE-----

From pthubert@cisco.com  Tue Apr 27 05:18:58 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9053A672E for ; Tue, 27 Apr 2010 05:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.839
X-Spam-Level: 
X-Spam-Status: No, score=-8.839 tagged_above=-999 required=5 tests=[AWL=1.760,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIzN4Ds5X2xq for ; Tue, 27 Apr 2010 05:18:56 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 06EC93A6983 for ; Tue, 27 Apr 2010 05:18:56 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAE5z1kurR7Ht/2dsb2JhbACcS3GlMJoXhQ4E
X-IronPort-AV: E=Sophos;i="4.52,280,1270425600"; d="scan'208";a="121189295"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Apr 2010 12:18:43 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RCIKV8020092; Tue, 27 Apr 2010 12:18:43 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 27 Apr 2010 14:18:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Apr 2010 14:16:16 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01BCA179@XMB-AMS-107.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrlcsVe9UZ1rFmXQIy4QezbsFY+GQAJWlbgABrDqgA=
References:  
From: "Pascal Thubert (pthubert)" 
To: "Reddy, Joseph" , 
X-OriginalArrivalTime: 27 Apr 2010 12:18:37.0659 (UTC) FILETIME=[C3BB1AB0:01CAE603]
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 12:18:59 -0000

Hi Joseph:

I concur with Michael here;

6LowPAN ND has a very bad story (ot no story at all) to disseminate the
PIO. The idea is that Ra information gets propagated from a router to
the next.
But really, that does not tie a subnet together. RPL does.

Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Reddy, Joseph
> Sent: Tuesday, April 27, 2010 1:32 AM
> To: roll@ietf.org
> Subject: Re: [Roll] how does a node get an IP address
>=20
>=20
>=20
> Hi Michael,
>=20
> I believe you need to have "working ND" to operate in an IPv6 network.
> Whether that is 6lowpan-ND or classic-ND or some other version. I
don't
> believe RPL should try to solve the problem of configuing an IP
address and
> performing router discovery.
>=20
> -Joseph
>=20
>
------------------------------------------------------------------------
--------
>=20
> >>>>> "Daniel" =3D=3D Daniel Gavelle  =
writes:
>     Daniel> Isn't IP and subnet assignment replacing functionality
that
>     Daniel> should be in ND?
>=20
>     Daniel> The majority of ROLL implementations I know of at the
moment
>     Daniel> are targeting 6LowPAN and there is a 6LowPAN ND draft in
>     Daniel> progress that covers subnet
>     Daniel> assignment and router discovery.
>=20
> >>>[Michael Richardson]
>=20
> >>>I am not targetting 6lowpan, nor does RPL make that assumption.
>=20
> >>>If you have working ND, then great.  Last I read, one mode of
6lowpan
> won't have working ND until RPL finishes, and as far as I can see,
configuring
> an IP address is an important part of joining a DODAG.
>=20
>=20
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From pthubert@cisco.com  Tue Apr 27 05:19:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50413A68F3 for ; Tue, 27 Apr 2010 05:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.894
X-Spam-Level: 
X-Spam-Status: No, score=-7.894 tagged_above=-999 required=5 tests=[AWL=0.701,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, TRACKER_ID=2.003]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYJn2nv8OkJX for ; Tue, 27 Apr 2010 05:18:58 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E3C033A697D for ; Tue, 27 Apr 2010 05:18:56 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYFAE5z1kurR7Ht/2dsb2JhbACBP5sMcaUwi3KOJYUOBA
X-IronPort-AV: E=Sophos;i="4.52,280,1270425600";  d="scan'208,217";a="121189305"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Apr 2010 12:18:44 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RCIKVA020092; Tue, 27 Apr 2010 12:18:44 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 27 Apr 2010 14:18:38 +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_01CAE603.C3C953B3"
Date: Tue, 27 Apr 2010 14:18:32 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>
In-Reply-To: <0a9b01cae5a3$79d6a320$6d83e960$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrlSm/U7APPVbHwRv+yrlSiDVpjHAAVPWqgABkKmOA=
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com>
From: "Pascal Thubert (pthubert)" 
To: "Samita Chakrabarti" , , "Anders Brandt" 
X-OriginalArrivalTime: 27 Apr 2010 12:18:38.0097 (UTC) FILETIME=[C3FDF010:01CAE603]
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 12:19:10 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAE603.C3C953B3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Samita:

=20

It does not appear that you're answering the right question.=20

=20

The question here is that the authoritative routers need to disseminate
the PIO (and the RIO) to all routers in the subnet.

Neither the 6loWPAN ND nor your ND simple has a good story for this.

=20

Pascal

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Samita Chakrabarti
Sent: Tuesday, April 27, 2010 2:49 AM
To: robert.cragie@gridmerge.com; 'Anders Brandt'
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address

=20

Hi Robert,

=20

As per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be
off-link and in that case, the packets are always forwarded to the
default-router  and direct delivery from host-to-host are not done.
6lowpan-nd auto-configuration always assumes that the nodes are off-link
and use the default-router to be the forwarder.

When RPL or a routing protocol is running, the default-router
functionality will be unlikely  needed  if all nodes are running RPL
code. However, the initial address assignment/dissemination among all
nodes are still possible using 6lowpan-nd simple mechanism for address
dissemination and address auto-configuration. But one can decide to
choose some other mechanism as well such as dhcpv6, static configuration
etc.

=20

-Samita

=20

=20

=20

Not mix up as such but provide the option for it to be carried by
alternative means than RS/RA, which is (still) very 'on-link' centric.
If the routing protocol provides the ability to naturally disseminate
information, we should be able to use that.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com =20


On 26/04/2010 2:17 PM, Anders Brandt wrote:=20

Just to be sure I understand you guys:

=20

Do you mean to mix up IP subnet/address assignment with the actual
routing protocol?

I would expect the IP address assignment should be agnostic whether mesh
under, RPL or RPLvX is the current routing engine?

=20

Thanks,

  Anders

	=20

________________________________

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of Robert Cragie
	Sent: Monday, April 26, 2010 15:02
	To: roll@ietf.org
	Subject: Re: [Roll] how does a node get an IP address

	Hi Michael, Pascal,
=09
	Good to see this being discussed! My preference would be:

	Allow DIO to transport existing PIO and RIO. Get rid of DPO
that's
	obsoleted by RIO.

	This then makes DIO more a general purpose message with
controlled propagation based on DODAG. This then eliminates the need for
some of the more complex parts of ND for 6LRs/6LBRs which use RPL.
=09
	Robert

	Robert Cragie (Pacific Gas & Electric)

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888
	http://www.gridmerge.com =20

=09
	On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:=20

	Hi Michael:
	=20
	You're right. So back to basics:
	=20
	- we have a problem providing Route Information Option (RIO
defined in
	RFC 4191) and Prefix Information Option (PIO defined in RFC
4861) in RAs
	sent out by RPL routers.
	- we can expect that there are authoritative routers in the RPL
network
	that already know what to do there. We could assert that they
should be
	roots since roots are providing such info already.
	- we figure ripples and trickles are well fit to propagate the
knowledge
	of those prefixes and the right to use it.
	- we have something like a RIO in RPL today called the
Destination
	Prefix subOption in the DIO message.
	=20
	What can we do from there
	- overload existing DPO like I proposed. That's the minimum
change but
	lacks some info present in PIO like lifetimes.
	- Define a new option for use in DIO that looks more like a PIO
	- Allow DIO to transport existing PIO and RIO. Get rid of DPO
that's
	obsoleted by RIO.
	- other?
	=20
	What do you think?
	=20
	Pascal
	=20
	=20
	 =20

		-----Original Message-----
		From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
		Sent: Monday, April 26, 2010 2:38 AM
		To: Pascal Thubert (pthubert)
		Cc: IETF ROLL; Erik Nordmark
		Subject: Re: [Roll] how does a node get an IP address
		=20
		-----BEGIN PGP SIGNED MESSAGE-----
		Hash: SHA1
		=20
		=20
		   =20

				"Pascal" =3D=3D Pascal Thubert <(pthubert)"
  >
				             =20

		writes:
		    Pascal> Good question!
		=20
		    Pascal> In fact we have the problem at 6LoWPAN, when
wan a router
		=20
		s/wan/can/ ??
		=20
		    Pascal> safely announce a prefix for autoconf.  An
answer can be,
		   =20

	as
	 =20

		    Pascal> long as it is still tightly coupled with an
authoritative
		    Pascal> router that owns that prefix, the coupling
insuring that
		    Pascal> both routers are still in a same subnet.
Typically a RPL
		    Pascal> instance could tie together a subnet.
		=20
		So, what I think you are saying is that having RPL nodes
sending out
		   =20

	RAs
	 =20

		themselves is frought with issues, and there are some
situations where
		it is in fact the right answer?
		=20
		But, I think you are saying, in order to cover all
situations more
		clearly, we are going to overload the Destination Prefix
option, and
		   =20

	you
	 =20

		then provide a proposed format for it.
		=20
		Before we discuss the solution, I'd like to get clear
agreement from
		   =20

	the
	 =20

		WG that I've properly understood the problem.
		=20
		I do wonder if adding the (R) flag is better than having
a new option.
		It seems that there are really two distinct activities
here:
		   a) configuring a local address
		   b) announcing routability information out of the
DODAG.
		=20
		- --
		]       He who is tired of Weird Al is tired of life!
|
		   =20

	firewalls  [
	 =20

		]   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
		
=20
		                      then sign the petition.
		-----BEGIN PGP SIGNATURE-----
		Version: GnuPG v1.4.9 (GNU/Linux)
		Comment: Finger me for keys
		=20
=09
iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
		J
=09
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
=09
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
		RH
=09
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
		VV+6L6J
=09
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
		TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
		=3DeFYy
		-----END PGP SIGNATURE-----
		   =20

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


------_=_NextPart_001_01CAE603.C3C953B3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Hi Samita:
     
    It does not appear that you’re answering the right question. =

     
    The question here is that the authoritative routers need to =
disseminate the PIO (and the RIO) to all routers in the =
subnet.
    Neither the 6loWPAN ND nor your ND simple has a good story for =
this.
     
    Pascal
     
    From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of Samita Chakrabarti
    Sent: Tuesday, April 27, 2010 2:49 =
AM
    To: robert.cragie@gridmerge.com; 'Anders =
Brandt'
    Cc: roll@ietf.org
    Subject: Re: [Roll] how =
does a node get an IP address
     
    Hi =
Robert,
     =

    As per =
rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be =
off-link and in that case, the packets are always forwarded to the =
default-router  and direct delivery from host-to-host are not done. =
6lowpan-nd auto-configuration always assumes that the nodes are off-link =
and use the default-router to be the forwarder.
    When RPL =
or a routing protocol is running, the default-router functionality will =
be unlikely  needed  if all nodes are running RPL code. =
However, the initial address assignment/dissemination among all nodes =
are still possible using 6lowpan-nd simple mechanism for address =
dissemination and address auto-configuration. But one can decide to =
choose some other mechanism as well such as dhcpv6, static configuration =
etc.
     =

    -Samita
     =

     =

     
    Not mix up =
as such but provide the option for it to be carried by alternative means =
than RS/RA, which is (still) very 'on-link' centric. If the routing =
protocol provides the ability to naturally disseminate information, we =
should be able to use that.

    Robert
    Robert Cragie (Pacific Gas & =
Electric)
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888
    http://www.gridmerge.com

    On 26/04/2010 2:17 PM, Anders Brandt =
wrote: 
    Ju=
st to be sure I understand you guys:
     
    Do=
 you mean to mix up IP subnet/address assignment with the actual routing =
protocol?
    I =
would expect the IP address assignment should be agnostic whether mesh =
under, RPL or RPLvX is the current routing =
engine?
     
    Th=
anks,
    &n=
bsp; Anders
     
    From:=
 =
roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf Of Robert Cragie
    Sent: Monday, April 26, 2010 =
15:02
    To: roll@ietf.org
    Subject: Re: =
[Roll] how does a node get an IP address
    Hi Michael, =
Pascal,

    Good to see this being discussed! My preference would =
be:
    Allow DIO to transport existing PIO and RIO. Get =
rid of DPO  that's
    obsoleted by =
RIO.
    This then makes DIO more a =
general purpose message with controlled propagation based on DODAG. This =
then eliminates the need for some of the more complex parts of ND for =
6LRs/6LBRs which use RPL.

    Robert
    Robert Cragie (Pacific Gas & =
Electric)
    Gridmerge Ltd.
    89 Greenfield =
Crescent,
    Wakefield, WF4 4WA, UK
    +44 (0) 1924 910888
    http://www.gridmerge.com

    On 26/04/2010 11:20 AM, Pascal =
Thubert (pthubert) wrote: 
    Hi =
Michael:
     
    You're right. =
So back to basics:
     
    - we =
have a problem providing Route Information Option (RIO defined =
in
    RFC 4191) and Prefix Information Option (PIO =
defined in RFC 4861) in RAs
    sent out by RPL =
routers.
    - we can expect that there are =
authoritative routers in the RPL network
    that =
already know what to do there. We could assert that they should =
be
    roots since roots are providing such info =
already.
    - we figure ripples and trickles are well =
fit to propagate the knowledge
    of those prefixes =
and the right to use it.
    - we have something like a =
RIO in RPL today called the Destination
    Prefix =
subOption in the DIO =
message.
     
    What can we do =
from there
    - overload existing DPO like I proposed. =
That's the minimum change but
    lacks some info =
present in PIO like lifetimes.
    - Define a new =
option for use in DIO that looks more like a PIO
    - =
Allow DIO to transport existing PIO and RIO. Get rid of DPO  =
that's
    obsoleted by RIO.
    - =
other?
     
    What do you =
think?
     
    Pascal=

     
     
     =
 
    -----Original =
Message-----
    From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]<=
/pre>
    Sent: Monday, April 26, 2010 2:38 AM
    To: =
Pascal Thubert (pthubert)
    Cc: IETF ROLL; Erik =
Nordmark
    Subject: Re: [Roll] how does a node get an =
IP address
     
    -----BEGIN =
PGP SIGNED MESSAGE-----
    Hash: =
SHA1
     
     
        
    "Pascal" =
=3D=3D Pascal Thubert <(pthubert)" <pthubert@cisco.com>>
             &=
nbsp;    =

    writes:
        Pascal> =
Good =
question!
     
      &n=
bsp; Pascal> In fact we have the problem at 6LoWPAN, when wan a =
router
     
    s/wan/can/ =
??
     
        =
Pascal> safely announce a prefix for autoconf.  An answer can =
be,
        =

    as
      =

        =
Pascal> long as it is still tightly coupled with an =
authoritative
        Pascal> router =
that owns that prefix, the coupling insuring =
that
        Pascal> both routers are =
still in a same subnet.  Typically a =
RPL
        Pascal> instance could =
tie together a =
subnet.
     
    So, what I =
think you are saying is that having RPL nodes sending =
out
        =

    RAs
      =

    themselves is =
frought with issues, and there are some situations =
where
    it is in fact the right =
answer?
     
    But, I think =
you are saying, in order to cover all situations =
more
    clearly, we are going to overload the =
Destination Prefix option, and
        =

    you
      =

    then provide a =
proposed format for =
it.
     
    Before we discuss =
the solution, I'd like to get clear agreement =
from
        =

    the
      =

    WG that I've =
properly understood the =
problem.
     
    I do wonder if =
adding the (R) flag is better than having a new =
option.
    It seems that there are really two distinct =
activities here:
       a) configuring a =
local address
       b) announcing =
routability information out of the =
DODAG.
     
    - =
--
    ]       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.o=
n.ca/
    |device =
driver[
       Kyoto Plus: watch the =
video
    <http://www.yout=
ube.com/watch?v=3Dkzx1ycLXQSE>
      &n=
bsp;    =
            &=
nbsp;  then sign the petition.
    -----BEGIN PGP =
SIGNATURE-----
    Version: GnuPG v1.4.9 =
(GNU/Linux)
    Comment: Finger me for =
keys
     
    iQEVAwUBS9TgUICLcPv=
d0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
    J<=
/o:p>
    ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR=
2GCxDVx
    oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+=
u/1GKpwUsacigkobbC
    RH
    hqlwzwBW3=
sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
    VV+=
6L6J
    o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53p=
d4aHmdgert9wYu8rE
    TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhg=
vW+aTQiSeQy8gHEJFFJA=3D=3D
    =3DeFYy
    <=
pre>-----END PGP SIGNATURE-----
        =

    ______________________________________=
_________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
     
      
    
------_=_NextPart_001_01CAE603.C3C953B3--

From pthubert@cisco.com  Tue Apr 27 05:22:24 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5C13A699A for ; Tue, 27 Apr 2010 05:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.918
X-Spam-Level: 
X-Spam-Status: No, score=-8.918 tagged_above=-999 required=5 tests=[AWL=1.681,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsrB47GnQVMr for ; Tue, 27 Apr 2010 05:22:22 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AD72B3A6939 for ; Tue, 27 Apr 2010 05:22:11 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArwGAAN01kurRN+K/2dsb2JhbACQPIwPcaUZi3KOJYUOBA
X-IronPort-AV: E=Sophos;i="4.52,280,1270425600"; d="scan'208";a="188975118"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2010 12:21:58 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3RCLfCS012292; Tue, 27 Apr 2010 12:21:58 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 27 Apr 2010 14:21:52 +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, 27 Apr 2010 14:21:46 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01BCA188@XMB-AMS-107.cisco.com>
In-Reply-To: <24252.1272286675@marajade.sandelman.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address 
Thread-Index: AcrlQCBmL/ieMXezQuWlLMJhgomccQAw+7Mg
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <24252.1272286675@marajade.sandelman.ca>
From: "Pascal Thubert (pthubert)" 
To: 
X-OriginalArrivalTime: 27 Apr 2010 12:21:52.0254 (UTC) FILETIME=[37B7F1E0:01CAE604]
Cc: IETF ROLL , Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 12:22:25 -0000

OK then,=20

I'll add my vote to yours and Robert's to transport the RIO and PIO as
the exist and remove the DPsO that's obsoleted by the RIO.
Anybody else?

Pascal


> -----Original Message-----
> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
> Sent: Monday, April 26, 2010 2:58 PM
> To: Pascal Thubert (pthubert)
> Cc: IETF ROLL; Erik Nordmark; Zach Shelby
> Subject: Re: [Roll] how does a node get an IP address
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" =
>
> writes:
>     Pascal> Hi Michael:
>=20
>     Pascal> You're right. So back to basics:
>=20
>     Pascal> - we have a problem providing Route Information Option
(RIO
>     Pascal> defined in RFC 4191) and Prefix Information Option (PIO
>     Pascal> defined in RFC 4861) in RAs sent out by RPL routers.
>=20
>     Pascal> - we can expect that there are authoritative routers in
the
>     Pascal> RPL network that already know what to do there. We could
>     Pascal> assert that they should be roots since roots are providing
>     Pascal> such info already.
>=20
>     Pascal> - we figure ripples and trickles are well fit to propagate
>     Pascal> the knowledge of those prefixes and the right to use it.
>=20
>     Pascal> - we have something like a RIO in RPL today called the
Destination
>     Pascal> Prefix subOption in the DIO message.
>=20
>=20
>     Pascal> What can we do from there
>     Pascal> - overload existing DPO like I proposed. That's the
minimum
>     Pascal> change but lacks some info present in PIO like lifetimes.
>=20
>     Pascal> - Define a new option for use in DIO that looks more like
a PIO
>=20
> I prefer this. The prefix lifetimes are important for renumbering.
> Let's crib the entire PIO, pretty much as-is.
>=20
> I'm agnostic about replacing the DestinationPrefix with a literal RIO.
It seems
> like a good symmetry though.
>=20
> - --
> ]       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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>=20
> iQEVAwUBS9WN0YCLcPvd0N1lAQJ0tgf/T3/AZRGc7tQ5RRj5O/iBFCy++BmON5
> to
> C6g5FxAYHwMpj2jKtRqQXV5NNYUZPE2RK3egv8rZT1/QKSYLeMcFAytJDh23o
> pNv
> 192lP8mkN8PFwYAWbcuJTpC5LZ/B5IdMpAmoOOp5xWaivo0j9BXvV4hXfEbO
> eAkQ
> BYe/Ot8s6jgdTr6FGGuOUtkA3Sizdm8RxuT4n7EvXlDluSKsTJh5ynSIYw2VIPqm
> Nt4GK34Q188G4CFXM6s+TPCrAxmCprFuOl7g3VhOCl+vW2x55v3TvuaTRrS8LZ
> a+
> wpi24AKyVlQ9DEYz1SC9ueDCLbaWPoYrk57Jo6QF7FmmZDHaS8RAEQ=3D=3D
> =3Dlklj
> -----END PGP SIGNATURE-----

From gregory.detal@uclouvain.be  Tue Apr 27 05:43:28 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C063A6992 for ; Tue, 27 Apr 2010 05:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H4xKuIitjbn for ; Tue, 27 Apr 2010 05:43:27 -0700 (PDT)
Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 4D4463A6975 for ; Tue, 27 Apr 2010 05:43:27 -0700 (PDT)
Received: from deneb.dhcp.info.ucl.ac.be (deneb.dhcp.info.ucl.ac.be [130.104.228.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gdetal@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C6D29ECB82; Tue, 27 Apr 2010 14:41:35 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 smtp2.sgsi.ucl.ac.be C6D29ECB82
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1272372095; bh=20tqIlpOTGhWe5a032sTt4lYy9uyy4Y5519xmsRVM1k=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:Cc:To:Mime-Version; b=O0sB13m/oZfu7Nu5qGv07PqbgNCLnBz9n8NOwk0kSjQaJ4fSIH3fUBqGIA7bP3wGJ 9HrlhH54/3oz+wOBSoCfjQaaGIDyCn65Xqd0Rln8dJFq/M5P3kr4lgbyxTqskdofwt 6OarX51SMqOyhC+n+y9Bj1YPA/CfhtHlY3p7V+6Q=
From: Gregory Detal 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Apr 2010 14:41:35 +0200
Message-Id: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be>
To: IETF ROLL 
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
X-Virus-Scanned: clamav-milter 0.96-exp at smtp-2.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: C6D29ECB82.00000
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: gregory.detal@uclouvain.be
X-SGSI-Spam-Status: No
Cc: Olivier Bonaventure , =?iso-8859-1?Q?Pierre_Fran=E7ois?= 
Subject: [Roll] RPL clarification questions
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 12:43:28 -0000

Dear all,

I'm currently working on RPL for my PhD thesis and have read the last =
draft.
I came across two uncertainties:

1) What is the meaning of the DAG sequence number increment based on =
events?
I have some issues understanding section 12.1.4. It says that DAG =
sequence number can be incremented based on events triggering. However:
- I have never found any documentation on such events ? What are the =
events triggering a seqnum increment by an RPL node ? Are you thinking =
about cases where, for example, poisoning is happening in conjunction =
with a mobility event ?
- The DODAG root is the node in charge of incrementing this seqnum. How =
is it ensured that the node will be aware of the event triggering this =
operation, assuming that there is no more "connection" between the event =
location and the root itself ?=09

2) How is the rank actually computed?
Could you confirm that a node advertises in the DIO message its own =
rank, and the direct children of that node in the DODAG compute their =
own rank as parent.rank + OF(parent.metric) ?

Best regards,
Gregory.=

From mcr@sandelman.ca  Tue Apr 27 06:44:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B873A6880 for ; Tue, 27 Apr 2010 06:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.145
X-Spam-Level: *
X-Spam-Status: No, score=1.145 tagged_above=-999 required=5 tests=[AWL=0.499,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLkAs-dfRLJo for ; Tue, 27 Apr 2010 06:44:09 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 52EE43A69F5 for ; Tue, 27 Apr 2010 06:43:27 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C63ED34702; Tue, 27 Apr 2010 09:43:15 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id ECD7C4E7B9; Tue, 27 Apr 2010 09:43:14 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 09:43:14 -0400
Message-ID: <7666.1272375794@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 13:44:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


{I never saw Samita's email on the list, only in reply}

    Samita> Hi Robert,

 

    Samita> As per rfc4861, 4862, while RS/RA are on-link. RS , the
    Samita> prefix could be off-link and in that case, the packets are
    Samita> always forwarded to the default-router and direct delivery
    Samita> from host-to-host are not done.  6lowpan-nd
    Samita> auto-configuration always assumes that the nodes are
    Samita> off-link and use the default-router to be the forwarder.

    Samita> When RPL or a routing protocol is running, the
    Samita> default-router functionality will be unlikely needed if all
    Samita> nodes are running RPL code. However, the initial address
    Samita> assignment/dissemination among all nodes are still possible
    Samita> using 6lowpan-nd simple mechanism for address dissemination
    Samita> and address auto-configuration. But one can decide to choose
    Samita> some other mechanism as well such as dhcpv6, static
    Samita> configuration etc.

As Pascal said, you are answering the wrong question.
The question is, rephrased against above:
    a) where does the default router come from?
    b) or more to the point, where does the contents of the RA come
       from?

You can't do stateful or stateless dhcpv6 until you have seen the RA,
since dhcpv6 is essentially unicast.

As for static cofniguration, let's not talk about that.  If you can do
that, then you don't need RPL at all.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9bp8YCLcPvd0N1lAQKvYQgAky7m2oxanZAxyC7luyH8Dhu1svqRFyLJ
8XZ9X2TEYOGcx1WE8YA0o7DspWwqXXk9JyqrSQsopQcrn2ESmKwnBvZhOaAESueT
h6oYnPcuPdhldsK9Ebo9c5BhTyYaXL/9HsMdNoBWesNqQncqxUsmCOexUjQncmKJ
JputFDtCFxWrXiH2Dmukoj5MBsP27aptqPw//39u9+aXCosaXgqT5w1/UwIorRB6
kEQ2i/pm3FChbGXhwEucn4BRa9NzmKXAkvTluHLZ6VlIlBVzFZ9Xgz8qindIq9pO
hMGjsJWRx1WFk8GrpSJz9jEbxbv88W8g4WwIJY/FQ5EFUdoJ0i6ASw==
=9cwE
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Tue Apr 27 06:47:50 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD713A6A66 for ; Tue, 27 Apr 2010 06:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.103
X-Spam-Level: *
X-Spam-Status: No, score=1.103 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV27AaeiMzwS for ; Tue, 27 Apr 2010 06:47:49 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 15CD728C0EB for ; Tue, 27 Apr 2010 06:47:30 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 1ACFD34707; Tue, 27 Apr 2010 09:47:18 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 3FE394E7B9; Tue, 27 Apr 2010 09:47:17 -0400 (EDT)
From: Michael Richardson 
To: "IETF ROLL" 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BCA188@XMB-AMS-107.cisco.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <24252.1272286675@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BCA188@XMB-AMS-107.cisco.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 09:47:17 -0400
Message-ID: <7930.1272376037@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: Erik Nordmark 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 13:47:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes:
    Pascal> I'll add my vote to yours and Robert's to transport the RIO
    Pascal> and PIO as the exist and remove the DPsO that's obsoleted by
    Pascal> the RIO.  Anybody else?

Does it reference the DIO/RIO by:
     value     -- copy & paste text + packet format?
     reference -- to a specific RFCxxxx (RFC4861)
     std ref   -- to a specific STDxxxx (alas, but RFC4861 isn't full standard yet)

The point is: as RIO/PIO is revised, does RPL automatically include
those updates?

My preference is (std) reference, and then copy&paste the current packet
format from RFC4861 as informative text.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9bq44CLcPvd0N1lAQIm8Af/Ql+tG7S+woJVc/HViM1iDMDkZd2dyooz
JSflhMjl1OlUiDTwEzyaKpmAYiVg/X1zOg6Lhnz079+LSqRf96ZAJ4xK3yOhzNLA
CIHGfdwTF31k3hPT25SE1xgY1wcREYdTBFE2BnEg0oqymDLGqIrh/xAQP0uXirr8
D1Xk1YnR8LVh/6MEm5hfPpve6bv3mgNZNdNf/VueDnCju1djWMoBXrCCHfoRjzhL
BFABXcsVFgIs9F1f7UXvr0QMEdcFca+u9VppqwvF7brZJg41wbti83F7Q6B4de3m
fgK1vzCBRCrPSa7jL5iUbCi0MvWdejMOQOKCGyDzMJAuENkMQyswbQ==
=UhhR
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Tue Apr 27 06:57:06 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB2E3A6AF8 for ; Tue, 27 Apr 2010 06:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.181
X-Spam-Level: *
X-Spam-Status: No, score=1.181 tagged_above=-999 required=5 tests=[AWL=-0.065,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334,  J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sByax1L1QNif for ; Tue, 27 Apr 2010 06:57:06 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0381A3A68FA for ; Tue, 27 Apr 2010 06:56:59 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 538BB34702; Tue, 27 Apr 2010 09:56:46 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 704224E7B9; Tue, 27 Apr 2010 09:56:45 -0400 (EDT)
From: Michael Richardson 
To: IETF ROLL 
In-Reply-To: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be> 
References: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 09:56:45 -0400
Message-ID: <8572.1272376605@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: Olivier Bonaventure 
Subject: Re: [Roll] RPL clarification questions
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 13:57:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Gregory" == Gregory Detal  writes:
    Gregory> 1) What is the meaning of the DAG sequence number increment
    Gregory> based on events?  I have some issues understanding section
    Gregory> 12.1.4. It says that DAG sequence number can be incremented
    Gregory> based on events triggering. However: - I have never found
    Gregory> any documentation on such events ? What are the events
    Gregory> triggering a seqnum increment by an RPL node ? Are you
    Gregory> thinking about cases where, for example, poisoning is
    Gregory> happening in conjunction with a mobility event ?  - The
    Gregory> DODAG root is the node in charge of incrementing this

Let's say the DODAG root looses it's (up)link.
It would send out new messages with a new sequence number, indicating it
is is no longer grounded.

    Gregory> 2) How is the rank actually computed?  Could you confirm
    Gregory> that a node advertises in the DIO message its own rank, and
    Gregory> the direct children of that node in the DODAG compute their
    Gregory> own rank as parent.rank + OF(parent.metric) ?

Yes.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9btHICLcPvd0N1lAQJrswf+N9UJc473S7XVnCA/dT1Zvwnq59pTBg8B
IZ63esUNyck1V4YdBmeRpOeC4sRFP8ZzQF+BZGjzkkqmzwUfw2n3qIXPG1n7Tl99
RZv+kSmDQ1MyoZBH7YeCZxghoo9GtExV4bMvzaviWo/KbdJPiFMRrrdE68qAQyDL
DhLVeCw2Wt14+SAg4nJZIw6piUeDGECOUI62Cm1AbMLoWx9V1I1QLUIhkwp8rh/B
19nWg3zUC3Gh9lXvmMHllBBUh+9lLCYCxIEDJW5t9kmNnIrPjC4UMnPPkCfnyLpj
JX+CMBFqh7yT68cKAjV59TKZOsbvF5w9qAJC0U4DQ5fZl2vLIw3uuw==
=XRIn
-----END PGP SIGNATURE-----

From richard.kelsey@ember.com  Tue Apr 27 06:59:21 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB493A69F5 for ; Tue, 27 Apr 2010 06:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.168
X-Spam-Level: 
X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U95RQ9Ait58 for ; Tue, 27 Apr 2010 06:59:20 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id EE4E83A6A47 for ; Tue, 27 Apr 2010 06:59:19 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Apr 2010 10:02:19 -0400
Date: Tue, 27 Apr 2010 09:54:40 -0400
Message-Id: <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com>
To: "Pascal Thubert (pthubert)" 
In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> (pthubert@cisco.com)
From: Richard Kelsey 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>
X-OriginalArrivalTime: 27 Apr 2010 14:02:19.0936 (UTC) FILETIME=[407F3A00:01CAE612]
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 13:59:21 -0000

> Date: Tue, 27 Apr 2010 14:18:32 +0200
> From: "Pascal Thubert (pthubert)" 
>
> The question here is that the authoritative routers need to disseminate
> the PIO (and the RIO) to all routers in the subnet.

How do other routing protocols (OSPF, IS-IS, AODV, OLSR)
handle this?  I understand that multi-hop subnets are a
problem for ND, but I don't see how the routing protocol is
affected.
                              -Richard Kelsey

From gregory.detal@uclouvain.be  Tue Apr 27 07:31:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527B23A69B7 for ; Tue, 27 Apr 2010 07:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level: 
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkHARj76OHUz for ; Tue, 27 Apr 2010 07:31:41 -0700 (PDT)
Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id D17CC28C26E for ; Tue, 27 Apr 2010 07:26:56 -0700 (PDT)
Received: from deneb.dhcp.info.ucl.ac.be (deneb.dhcp.info.ucl.ac.be [130.104.228.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gdetal@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id BB03CE993D; Tue, 27 Apr 2010 16:21:01 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be BB03CE993D
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1272378061; bh=TSWWJKC4iFeOepVzHrd8weZ7O36dUQUwjmkw0nNpGcs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gjanyF12O6Jm9du0zl9RKKcRjO/VDDN4o45tfdVNcB8p9VHCxrLkUJGuIYPUwfsHH nkmDOaL+ji5x67v5rKo0pAIIun3kCypDzkkjzTEvxsFvg9QSMr7vSBpzGsyGvCswp1 nEt0VSn0s/JuD3NYf+ce3Jcvb77smiX+SMZxPQwE=
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Gregory Detal 
In-Reply-To: <8572.1272376605@marajade.sandelman.ca>
Date: Tue, 27 Apr 2010 16:21:00 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5C403BB5-5911-4CE0-916F-D5894C9D259E@uclouvain.be>
References: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be> <8572.1272376605@marajade.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1078)
X-Virus-Scanned: clamav-milter 0.96-exp at smtp-1.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: BB03CE993D.00000
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: gregory.detal@uclouvain.be
X-SGSI-Spam-Status: No
Cc: IETF ROLL , Olivier Bonaventure 
Subject: Re: [Roll] RPL clarification questions
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 14:31:42 -0000

Michael,

Thank you for your answer.

On 27 Apr 2010, at 15:56, Michael Richardson wrote:

> Let's say the DODAG root looses it's (up)link.
> It would send out new messages with a new sequence number, indicating it
> is is no longer grounded.


Ok, so events are only linked to DODAG root and not any other RPL node ?

Gregory.


From mcr@sandelman.ca  Tue Apr 27 07:43:04 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DDD28C117 for ; Tue, 27 Apr 2010 07:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.898
X-Spam-Level: 
X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=0.252,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mo9e2Rjmk7Y for ; Tue, 27 Apr 2010 07:43:03 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 28B8728C0EB for ; Tue, 27 Apr 2010 07:39:00 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E5947346FD; Tue, 27 Apr 2010 10:38:48 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 62C1C4E7CC; Tue, 27 Apr 2010 10:38:47 -0400 (EDT)
From: Michael Richardson 
To: Richard Kelsey 
In-Reply-To: <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 10:38:47 -0400
Message-ID: <11301.1272379127@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 14:43:04 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Richard" == Richard Kelsey  writes:
    >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
    >> (pthubert)" 
    >> 
    >> The question here is that the authoritative routers need to
    >> disseminate the PIO (and the RIO) to all routers in the subnet.

    Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR)

I can only speak for OSPF and ISIS.
Neither deal with multi-hop subnets or with any kind of address
assignment.  Both were written when multicast was very new.

My reading of AODV is that it does not deal with address assignment at
all.  It also does not promise in RFC3561 to deal with multicast. (Maybe
subsequent enhancements do?) 

    Richard> handle this?  I understand that multi-hop subnets are a
    Richard> problem for ND, but I don't see how the routing protocol is
    Richard> affected.  -Richard Kelsey

RPL either requires 6lowpan, or it doesn't.
If it doesn't, then it has to provide for ND to work, or for another
protocol to replace it.

- -- 
]       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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9b29YCLcPvd0N1lAQI6Kwf/XGZPrjoGGHZAaEUNC1JzX3rEjXf4atgt
YJNXQJwRvTl288GzRYS1ta+ntr1SGVFdNlpRuMmDhJCfDXAni6Kemao7qJbt2PIp
KlkGCRTGuvuwtuspZnshhXAnkDuF86/lDgFIecjzHU3HTkOHMNaMS2OJy8irAFrU
1sdUamtjC97r1XBxBq4NmCgx34FVCbeFAR/Ba+mj0DkdwWv/cEZk2yelogDZQb/g
L0XW7cDEU9t2dG2QMB+ON7Vq1xituxqMKjh2lFVpQFNBZuENO2sbEI8J68hVIsJM
+H5VKVOvJ8ENPPwQxGsuyi+EcTFsTQso3YKBvxcXYRK4LB63IIU80A==
=IQig
-----END PGP SIGNATURE-----

From mcr@sandelman.ca  Tue Apr 27 08:12:41 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488203A6B70 for ; Tue, 27 Apr 2010 08:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.847
X-Spam-Level: 
X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c6b6azlwBFJ for ; Tue, 27 Apr 2010 08:12:40 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9FED13A6B95 for ; Tue, 27 Apr 2010 08:05:45 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 28C1C346FD; Tue, 27 Apr 2010 11:05:33 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 88F4C4E7CC; Tue, 27 Apr 2010 11:05:32 -0400 (EDT)
From: Michael Richardson 
To: Gregory Detal 
In-Reply-To: <5C403BB5-5911-4CE0-916F-D5894C9D259E@uclouvain.be> 
References: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be> <8572.1272376605@marajade.sandelman.ca> <5C403BB5-5911-4CE0-916F-D5894C9D259E@uclouvain.be> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 11:05:32 -0400
Message-ID: <13285.1272380732@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: IETF ROLL , Olivier Bonaventure 
Subject: Re: [Roll] RPL clarification questions
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 15:12:41 -0000

>>>>> "Gregory" == Gregory Detal  writes:
    >> Let's say the DODAG root looses it's (up)link.  It would send out
    >> new messages with a new sequence number, indicating it is is no
    >> longer grounded.

    Gregory> Ok, so events are only linked to DODAG root and not any
    Gregory> other RPL node ?

I think that only the root can increment the sequence number.
I'm not sure what another node would do that had an "event"...

-- 
]       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 richard.kelsey@ember.com  Tue Apr 27 08:37:24 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24ABC28C24E for ; Tue, 27 Apr 2010 08:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Level: 
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.573,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxw3O+JRvH+X for ; Tue, 27 Apr 2010 08:37:23 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 99BFF3A6BBE for ; Tue, 27 Apr 2010 08:31:57 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Apr 2010 11:34:57 -0400
Date: Tue, 27 Apr 2010 11:27:18 -0400
Message-Id: <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
To: Michael Richardson 
In-reply-to: <11301.1272379127@marajade.sandelman.ca> (message from Michael Richardson on Tue, 27 Apr 2010 10:38:47 -0400)
From: Richard Kelsey 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> <11301.1272379127@marajade.sandelman.ca>
X-OriginalArrivalTime: 27 Apr 2010 15:34:57.0911 (UTC) FILETIME=[314EE870:01CAE61F]
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 15:37:24 -0000

> From: Michael Richardson 
> Date: Tue, 27 Apr 2010 10:38:47 -0400
> 
> >>>>> "Richard" == Richard Kelsey  writes:
>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
>     >> (pthubert)" 
>     >> 
>     >> The question here is that the authoritative routers need to
>     >> disseminate the PIO (and the RIO) to all routers in the subnet.
> 
>     Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR)
> 
> I can only speak for OSPF and ISIS.
> Neither deal with multi-hop subnets or with any kind of address
> assignment.

Why should RPL be any different?  Yes, it will be run on
multi-hop subnets, but I still do not see how this affects
the routing.

> Both were written when multicast was very new.

I am not sure how RPL's handling of multicast matters here.
While RPL is required to route multi-hop multicasts, ND
uses link-local multicasts, which do not require routing.

> Richard> I understand that multi-hop subnets are a
> Richard> problem for ND, but I don't see how the routing protocol is
> Richard> affected.
> 
> RPL either requires 6lowpan, or it doesn't.

RPL should work fine with ordinary ND.  Why would it require
6lowpan?

> If it doesn't, then it has to provide for ND to work, or
> for another protocol to replace it.

ND works fine, using link-local, one-hop multicasts.  RPL
need not be involved.

If someone wants to run RPL on a node that uses neither
ordinary ND or 6lowpan's version, then they will need some
third variety of ND.  I do not see why this is an issue for
RPL to address.  It seems quite out of scope.

                              -Richard Kelsey

From joakime@sics.se  Tue Apr 27 08:58:04 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F153A6BA5 for ; Tue, 27 Apr 2010 08:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiGxihaTn8zv for ; Tue, 27 Apr 2010 08:58:03 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id F120C3A6C71 for ; Tue, 27 Apr 2010 08:54:58 -0700 (PDT)
Received: from [192.168.1.144] (c-2d1de455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.29.45]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 970FC40116; Tue, 27 Apr 2010 17:54:45 +0200 (CEST)
Message-ID: <4BD708CE.7040603@sics.se>
Date: Tue, 27 Apr 2010 17:54:54 +0200
From: Joakim Eriksson 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com>	<0a9b01cae5a3$79d6a320$6d83e960$@com>	<6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>	<87d3xl0zmn.fsf@kelsey-ws.hq.ember.com>	<11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
In-Reply-To: <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 15:58:04 -0000

Richard Kelsey skrev 2010-04-27 17:27:
>> From: Michael Richardson
>> Date: Tue, 27 Apr 2010 10:38:47 -0400
>>
>>>>>>> "Richard" == Richard Kelsey  writes:
>>      >>  Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
>>      >>  (pthubert)"
>>      >>
>>      >>  The question here is that the authoritative routers need to
>>      >>  disseminate the PIO (and the RIO) to all routers in the subnet.
>>
>>      Richard>  How do other routing protocols (OSPF, IS-IS, AODV, OLSR)
>>
>> I can only speak for OSPF and ISIS.
>> Neither deal with multi-hop subnets or with any kind of address
>> assignment.
>
> Why should RPL be any different?  Yes, it will be run on
> multi-hop subnets, but I still do not see how this affects
> the routing.

If anyone would have a fairly "static" network with very few
sideways movements in the DAG it would be possible to do some
kind of prefix-based routing if RPL would assign the prefixes/
addresses. This would make it very light-weight when it comes
to routing tables, but very messy when nodes move between parents.
I am not sure that this is the case in any of the link-layers
that have been discussed for RPL so far (PLC, 802.15.4).


Best regards,
-- Joakim Eriksson, SICS


>> Both were written when multicast was very new.
>
> I am not sure how RPL's handling of multicast matters here.
> While RPL is required to route multi-hop multicasts, ND
> uses link-local multicasts, which do not require routing.
>
>> Richard>  I understand that multi-hop subnets are a
>> Richard>  problem for ND, but I don't see how the routing protocol is
>> Richard>  affected.
>>
>> RPL either requires 6lowpan, or it doesn't.
>
> RPL should work fine with ordinary ND.  Why would it require
> 6lowpan?
>
>> If it doesn't, then it has to provide for ND to work, or
>> for another protocol to replace it.
>
> ND works fine, using link-local, one-hop multicasts.  RPL
> need not be involved.
>
> If someone wants to run RPL on a node that uses neither
> ordinary ND or 6lowpan's version, then they will need some
> third variety of ND.  I do not see why this is an issue for
> RPL to address.  It seems quite out of scope.
>
>                                -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From mcr@sandelman.ca  Tue Apr 27 09:08:25 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E708F3A68A2 for ; Tue, 27 Apr 2010 09:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.814
X-Spam-Level: 
X-Spam-Status: No, score=0.814 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuT+x-XO9sB4 for ; Tue, 27 Apr 2010 09:08:21 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4E2EE3A63EC for ; Tue, 27 Apr 2010 09:07:34 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 605FD34730; Tue, 27 Apr 2010 12:07:22 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 9FA384E7CC; Tue, 27 Apr 2010 12:07:21 -0400 (EDT)
From: Michael Richardson 
To: Richard Kelsey 
In-Reply-To: <87bpd429wp.fsf@kelsey-ws.hq.ember.com> 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> <11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Tue, 27 Apr 2010 12:07:21 -0400
Message-ID: <17517.1272384441@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 16:08:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Richard" == Richard Kelsey  writes:
    Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR)

    >> I can only speak for OSPF and ISIS.  Neither deal with multi-hop
    >> subnets or with any kind of address assignment.

    Richard> Why should RPL be any different?  Yes, it will be run on
    Richard> multi-hop subnets, but I still do not see how this affects
    Richard> the routing.

    >> Both were written when multicast was very new.

    Richard> I am not sure how RPL's handling of multicast matters here.
    Richard> While RPL is required to route multi-hop multicasts, ND
    Richard> uses link-local multicasts, which do not require routing.

Yes, that's true.

So, one answer is that all RPL intermediate nodes are required to
process RA/RS messages in order that all messages can be resolved as
one-hop multicast.

    Richard> If someone wants to run RPL on a node that uses neither
    Richard> ordinary ND or 6lowpan's version, then they will need some
    Richard> third variety of ND.  I do not see why this is an issue for
    Richard> RPL to address.  It seems quite out of scope.

"out of scope" is an acceptable answer.

- -- 
]       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. 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS9cLtoCLcPvd0N1lAQIPTQf8CUVJwAOlCbuRtCFiX8FAM7pcWhdx/FaR
QZjbvmEWdPztm/c9wVpLCxeFRFmJVGv8OXJYg1A0NMGjUF/I/bjD5FG55kbDkzD4
bigXOWZbjKsxw9za+lXkenHysTYRJsAYbGdtcH+HlVRbEoBofzeaaoS2NkB5qc7m
1286Jt88SDv+1LxJKDqRrrB5TPKUCdThABFN+4oVHdwUtzMe7+I5PSD1X6A0C0kE
jQm6W6jkQbUs1kLSoDHkHvKbYZ0VJED0HI45SKaJJn55q9+cwBNnZkD/8DFopqXo
kMSFPLF8CUjX/p/Ljyb77YyQmCl2UZ4KwNxx46IercMRIsssyuMYbQ==
=VezP
-----END PGP SIGNATURE-----

From pal@cs.stanford.edu  Tue Apr 27 09:12:41 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873BD3A6868 for ; Tue, 27 Apr 2010 09:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.227
X-Spam-Level: 
X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka3CfYpS-A1d for ; Tue, 27 Apr 2010 09:12:40 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 149773A6950 for ; Tue, 27 Apr 2010 09:11:38 -0700 (PDT)
Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O6nNd-00072Y-Iw; Tue, 27 Apr 2010 09:11:25 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <8572.1272376605@marajade.sandelman.ca>
Date: Tue, 27 Apr 2010 08:09:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <68F2508E-9C7D-4B52-9284-15D55143DBC5@cs.stanford.edu>
References: <1D340D23-E501-4EDA-8D6B-B817BD0CEB28@uclouvain.be> <8572.1272376605@marajade.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5
Cc: IETF ROLL , Olivier Bonaventure 
Subject: Re: [Roll] RPL clarification questions
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 16:12:41 -0000

On Apr 27, 2010, at 6:56 AM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
>>>>>> "Gregory" =3D=3D Gregory Detal  =
writes:
>    Gregory> 1) What is the meaning of the DAG sequence number =
increment
>    Gregory> based on events?  I have some issues understanding section
>    Gregory> 12.1.4. It says that DAG sequence number can be =
incremented
>    Gregory> based on events triggering. However: - I have never found
>    Gregory> any documentation on such events ? What are the events
>    Gregory> triggering a seqnum increment by an RPL node ? Are you
>    Gregory> thinking about cases where, for example, poisoning is
>    Gregory> happening in conjunction with a mobility event ?  - The
>    Gregory> DODAG root is the node in charge of incrementing this
>=20
> Let's say the DODAG root looses it's (up)link.
> It would send out new messages with a new sequence number, indicating =
it
> is is no longer grounded.

This is one example use.

More generally, incrementing the sequence number is a mechanism for the =
DODAG root to force the DODAG to reform. There are many reasons one =
might use this mechanism, and we don't want to specify them all. As =
nodes can't always move 100% freely within a DODAG (the max rank =
increase configuration parameter), sequence numbers allow RPL to =
serialize topology changes.

Phil=

From richard.kelsey@ember.com  Tue Apr 27 10:14:56 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B483A69FE for ; Tue, 27 Apr 2010 10:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r194MSUUKJ84 for ; Tue, 27 Apr 2010 10:14:55 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4C6F43A69E3 for ; Tue, 27 Apr 2010 10:14:55 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Apr 2010 13:17:55 -0400
Date: Tue, 27 Apr 2010 13:10:14 -0400
Message-Id: <87aaso2555.fsf@kelsey-ws.hq.ember.com>
To: "Pascal Thubert (pthubert)" 
In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01A3894D@XMB-AMS-107.cisco.com> (pthubert@cisco.com)
From: Richard Kelsey 
References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01A3894D@XMB-AMS-107.cisco.com>
X-OriginalArrivalTime: 27 Apr 2010 17:17:55.0474 (UTC) FILETIME=[936C3720:01CAE62D]
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 17:14:56 -0000

> Date: Mon, 12 Apr 2010 15:39:05 +0200
> From: "Pascal Thubert (pthubert)" 
> 
> Following up on this proposal and Jonathan's answers, I've been trying
> to formulate how the parents up the DAG know that they need to
> participate to the source route and send their own DAO indicating their
> own parents.
> 
> As discussed earlier, one option is that all routers in the network do
> send DAOs with their parents, so we're all set.

Right.

> But that falls short in
> a number of cases, including P2P where we only want to trace back the
> path between A and B. 

Are there other cases?  I have been waiting for the P2P proposal
to see if this need to be addressed there.

> Or, we ask the destination to send uncast a DAO to each of its DAO
> parent. So each parent knows that it has to send its own DAO and so on
> recursively; as soon as a router has at least one child that is a source
> route destination then it must send its own DAO information.

Before trying to address the issue we need to when and
where it arises.
                                  -Richard Kelsey

From robert.cragie@gridmerge.com  Tue Apr 27 11:46:35 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C41928C1DC for ; Tue, 27 Apr 2010 11:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oila8uQvoMiW for ; Tue, 27 Apr 2010 11:46:34 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id B47173A6B5F for ; Tue, 27 Apr 2010 11:45:46 -0700 (PDT)
Received: from client-82-27-2-50.pete.adsl.virginmedia.com ([82.27.2.50] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O6pmj-0003oJ-VP for roll@ietf.org; Tue, 27 Apr 2010 19:45:30 +0100
Message-ID: <4BD730C7.70403@gridmerge.com>
Date: Tue, 27 Apr 2010 19:45:27 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com>	<0a9b01cae5a3$79d6a320$6d83e960$@com>	<6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>	<87d3xl0zmn.fsf@kelsey-ws.hq.ember.com>	<11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
In-Reply-To: <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090107000104060401060309"
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Apr 2010 18:46:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms090107000104060401060309
Content-Type: multipart/alternative;
 boundary="------------040503070808080803030702"

This is a multi-part message in MIME format.
--------------040503070808080803030702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

See comment below

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 27/04/2010 4:27 PM, Richard Kelsey wrote:
>>
>>      >>  (pthubert)"
>>      >>
>>      >>  The question here is that the authoritative routers need to
>>      >>  disseminate the PIO (and the RIO) to all routers in the subne=
t.
>>
>>      Richard>  How do other routing protocols (OSPF, IS-IS, AODV, OLSR=
)
>>
>> I can only speak for OSPF and ISIS.
>> Neither deal with multi-hop subnets or with any kind of address
>> assignment.
>>     =20
> Why should RPL be any different?  Yes, it will be run on
> multi-hop subnets, but I still do not see how this affects
> the routing.
>
>   =20
>> Both were written when multicast was very new.
>>     =20
> I am not sure how RPL's handling of multicast matters here.
> While RPL is required to route multi-hop multicasts, ND
> uses link-local multicasts, which do not require routing.
>   =20
But that is one problem with ND as it stands. It is aimed at the=20
general single border router with hosts all being one hop away, so a=20
link-local multicast will reach all the hosts. A host (or another=20
router) joining a 6lowpan or any network with the concept of routers=20
with a single interface forwarding packets out on the same interface is=20
not going to be able to see the border router which is in control of the =

prefix, therefore this information has to be 'multicast' to all the=20
nodes. Considering a DIO in RPL, it is effectlvely multicast to all=20
nodes in the network. It is also periodically broadcast. So if this=20
mechanism is available, it is logical to use it to disseminate=20
information throughout the network as opposed to trying to cobble=20
together some alternative relay mechanism. In this way, a joining node=20
could use unicast RS/RA as specified in 6lowpan ND and get the=20
information it needs from its friendly neighborhood local router, as it=20
will have already got it. Indeed, the dynamic bootstrapping of the=20
network may itself propagate the information assuming the first node up=20
is the border router, as the nodes will bootstrap forming a tree away=20
from the border router. However, this can't be assumed.


--------------040503070808080803030702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


See comment below
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 27/04/2010 4:27 PM, Richard Kelsey wrote:

    
  
     
    
    
        >> (pthubert)" <pthubert@cisco.com>
    >>=20
    >> The question here is that the authoritative routers need to
    >> disseminate the PIO (and the RIO) to all routers in the subn=
et.

    Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR)

I can only speak for OSPF and ISIS.
Neither deal with multi-hop subnets or with any kind of address
assignment.
    
    
  
    
  
    Why should RPL be any different?  Yes, it will be run on
multi-hop subnets, but I still do not see how this affects
the routing.

  
    
  
    
    
    Both were written when multicast was very new.
    
    
  
    
  
    I am not sure how RPL's handling of multicast matters here.
While RPL is required to route multi-hop multicasts, ND
uses link-local multicasts, which do not require routing.
  
    

    
<RCC>But that is one problem with ND as it stands. It is aimed at
the general single border router with hosts all being one hop away, so
a link-local multicast will reach all the hosts. A host (or another
router) joining a 6lowpan or any network with the concept of routers
with a single interface forwarding packets out on the same interface is
not going to be able to see the border router which is in control of
the prefix, therefore this information has to be 'multicast' to all the
nodes. Considering a DIO in RPL, it is effectlvely multicast to all
nodes in the network. It is also periodically broadcast. So if this
mechanism is available, it is logical to use it to disseminate
information throughout the network as opposed to trying to cobble
together some alternative relay mechanism. In this way, a joining node
could use unicast RS/RA as specified in 6lowpan ND and get the
information it needs from its friendly neighborhood local router, as it
will have already got it. Indeed, the dynamic bootstrapping of the
network may itself propagate the information assuming the first node up
is the border router, as the nodes will bootstrap forming a tree away
from the border router. However, this can't be assumed.</RCC>
    

    



--------------040503070808080803030702--

--------------ms090107000104060401060309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MjcxODQ1MjdaMCMGCSqGSIb3DQEJBDEWBBS4TE9OuJafHp5a32oS/eYGTvjE0jBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAIh9Go6Y6llXDp3jVuli1G699Ga07klkHcSAzo7LF8LR/jDTEo/Zqu2U0uFTzU4u6ely
hszg8DPzw6jZOcUaxWa0MzJXFph7F3osPOrPdKAZ03UEM8WaHUdazF+VXA5ccvudYhzwseUr
a+3PUDQ3QiragBzAfRkfBvIZXkCAtrtRL99IZyZ2rb+49aXpNMuDfdLxaUHkz7niK2TgCN/V
wnO3mYUhmRXiLtQmihQVTGQzk8sJeB5EelYYeOfNQUzirTCfKsyjLyGOCiN+Zb7/XQKvGbI0
QKL1UoG0RRS75JdkKzohTZkRPsKzYoa0AtvochqSQXjnK2hj3c/gr/20x0wAAAAAAAA=
--------------ms090107000104060401060309--

From roger.alexander@ekasystems.com  Tue Apr 27 14:13:22 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5453A68BA for ; Tue, 27 Apr 2010 14:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.464
X-Spam-Level: 
X-Spam-Status: No, score=0.464 tagged_above=-999 required=5 tests=[AWL=-0.987,  BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyXY-8EFcCQA for ; Tue, 27 Apr 2010 14:13:20 -0700 (PDT)
Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 6C6663A687F for ; Tue, 27 Apr 2010 14:13:19 -0700 (PDT)
Received: (qmail 15707 invoked from network); 27 Apr 2010 21:13:04 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 27 Apr 2010 14:13:02 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: gOGaaCkVM1nISpqqu.Fn2FSXo4DG_q6ohJbFzRC0yk9w1o32jRtqM2offmVFYQrPDcvkD4bdLwaIjcm9YPQpo1lK8GFcvPTYTQJXUsHLLUrwNzj8nyz285vvahqy8UjwrmKkYorCZ1_udlDjqy2Caasj9nkN9tDdyt7Y03QlVOsNn40sb9xC7HhI1gdeq71t6AKddcHhL5chc6cHu1_IAnnupxQavXZOg324G5ko4TjIKNMrwyzV1aNgdLa7QpiFqe2nommyAxcwoWNgPOBcx5RErWkC9r46axnNucrH.1qFWxnfDui9nVqOJ6Ie42WdnssyIpVKcGt.mvERmr2Pc9BkDa5xWkZHTW9OAjrcNP9GXSupYVQDqTBVYZetfdg-
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Pascal Thubert \(pthubert\)'" , "'Navneet Agarwal \(navagar\)'" , "'JP Vasseur'" , , "'Tzeta Tsao'" 
References: <6A2A459175DABE4BB11DE2026AA50A5D01B50F5B@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01B50F5B@XMB-AMS-107.cisco.com>
Date: Tue, 27 Apr 2010 17:11:00 -0400
Message-ID: <01f601cae64e$23853350$6a8f99f0$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_01F7_01CAE62C.9C739350"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrf1eBhE3gpj86EQv+LzaP9OWLJMAADyKdQ
Content-Language: en-us
Cc: 'ROLL WG' 
Subject: Re: [Roll] DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 21:13:22 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_01F7_01CAE62C.9C739350
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Pascal,

Please find attached an expanded note on the DAO fan out control and path
prioritization mechanism.

Roger

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Monday, April 19, 2010 11:35 AM
> To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
> wintert@acm.org
> Cc: ROLL WG
> Subject: RE: [Roll] DAO fan out
> 
> Hi Roger:
> 
> At high level I'm very positive on the mechanism .
> 
> What I'd wish to see from the list is more people:
> - agreeing that the fan out MUST be solved

For large scale networks it is important to have some mechanism to bound
downward paths once nodes can maintain multiple DAO parents. It will be up
to the WG of course but after having introduced multiple DAO parents,
leaving paths unconstrained introduces a potentially uncontrolled element of
the protocol that can affect scalability; as networks become larger the
potential vulnerability increases. What is being recommended is a 1-byte
information element per DAO Destination Address. While incurring some
additional overhead path control can be disabled (bitmap set to all zeros)
for networks in which only a single DAO parent per node is maintained or
that not wish to implement constraints on path fan out or to differentiate
preferred downward paths.

> - that this is a simple and efficient solution

Yes it would be good to get feedback from others on any concerns they may
have.

> - that the solution can be incorporated in 08
> 
> Maybe what would help from you Roger is:
> - a visual example on the mechanism as work (if you have a pdf
> illustrating it?)

Note plus a few examples attached (pdf and MS Word).

> - some more explanation on the source route case (how the root can play
> the same game recursively and obtain a good result as well)

Based on the current -07 source route specification, non-storing nodes will
follow the same operation as storing nodes in using the Path Control byte to
determine the number and selection of DAO parents through which the reverse
route stack is built. 

If the source route specification is changed to the more recent proposal
from Richard, the Path Control byte can still apply to the advertised DAO
Destination Address and will be associated with each of the selected DAO
Parents communicated to the root. As in the case of storing nodes, each DAO
Destination Address will have a different Path Control byte for each
selected DAO Parent. For the source route case the root will be able to use
the Path Control preference associated with each selected DAO Parent to
recursively determine the preferred downward path to a given target address.
That is, at the root, the preferred downward path to a given target address
begins with the target's preferred DAO parent as given by the Path Control
byte. From that preferred DAO Parent the link to the next preferred DAO
ancestor is added until the complete preferred path is derived. The root
will also be capable of deriving all the potential path combinations to a
target node. 

As I currently understand the new proposal it is not clear that non storing
nodes have any ability to control path fan out (and the consequently
increased reverse route processing at the root) when nodes maintain multiple
DAO Parents.
   
> 
> Could you please so that for us?
> 
> Thanks a bunch,
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
> > Sent: Friday, April 16, 2010 11:32 PM
> > To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
> Vasseur';
> > wintert@acm.org
> > Cc: 'ROLL WG'
> > Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
> > welcome)
> >
> > Below is a quick summary aligned to Tim's concept of how the Path
> Control
> > bitmap associated with the DAO destination address can be used to
> limit fan
> > out and to identify the preferred path when nodes maintain multiple
> DAO
> > Parents.
> >
> > Further details and examples can be provided as part of an larger
> > application domain note.
> >
> > Roger
> >
> > > -----Original Message-----
> > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> > > Sent: Tuesday, April 13, 2010 3:47 AM
> > > To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
> > > wintert@acm.org
> > > Cc: ROLL WG
> > > Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
> > >
> > >
> > >
> > > Pascal
> > >
> > > > One consequence of maintaining multiple DAO parents is the
> potential
> > > fan
> > > > out of routing paths. With path fan out a node may have multiple
> > > downward
> > > > next hop addresses for a given target destination address.
> Without
> > > some
> > > > path preference indication there is no information available if a
> > > storing node
> > > > (including the root) wishes to limit the number of downward next
> hops
> > > > maintained for a given address. It is thus desirable to have some
> > > means of
> > > > path control to limit fan out as well as a preference indication
> that
> > > can work in
> > > > conjunction with the hop-by-hop DAO exchanges.
> > > >
> > > > See the Figure below for an example in which nodes maintain two
> DAO
> > > > Parents each, where in the worst case the fan out that occurs
> after
> > > three
> > > > hops results in eight next hop downward paths from the DODAG root
> > > (LBR)
> > > > to a target node (41). Even with the hop-by-hop DAO mechanism it
> > > would
> > > be
> > > > desirable to be able to limit fan out as well as to identify path
> > > preference and
> > > > diversity at the root or other intermediate storing node.
> > > >
> > > >                     (------------LBR------------)
> > > >                     /    /   / |     | \    \   \
> > > >                    /    /   /  |     |  \    \   \
> > > >                   /    /   /   |     |   \    \   \
> > > >                  /    /   /    |     |    \    \   \
> > > >               (11) (12) (13) (14)   (15) (16) (17) (18)
> > > >                  \   |    |    /     \    |    |   /
> > > >                   \  |    |   /       \   |    |  /
> > > >                    \ |    |  /         \  |    | /
> > > >                   (21)   (22)           (23)  (24)
> > > >                       \    |            |    /
> > > >                        \   |            |   /
> > > >                         \  |            |  /
> > > >                          (31)          (32)
> > > >                              \        /
> > > >                               \      /
> > > >                                \    /
> > > >                                 (41)
> > > >
> > >
> > > [Pascal] Your schema illustrates clearly that even if we fan out a
> lot,
> > > it does not mean that a router on the way down will have more
> feasible
> > > successors.
> > >
> > > That's one thing that's important to remember, the properties of
> the
> > > DAG
> > > are not symmetrical, so even if we build it to get multiple
> feasible
> > > successors on the way up, that does not mean that on the reverse
> DAG
> to
> > > a target there are multiple successors at each hop towards that
> target.
> > >
> > > In other words, the ROI of fanning out is not guaranteed if we do
> it
> > > blindly.
> > >
> > > > A simple path control bitmap associated with the advertised
> > > Destination
> > > > Address can be included within the DAO to address the issue of
> path
> > > > preference as well as control of fan out. For a network of
> > > 'non-storing'
> > > > nodes the preference indication would be processed only at the
> root.
> > >
> > > [Pascal] so far so good, but that will give you a blind mechanism.
> > >
> > > > With the path control byte associated with each DAO destination
> > > address, a
> > > > node will be able to specify preference among DAO parent paths
> and
> > > can
> > > > convey limits on the number of downward paths. This is an
> opportunity
> > > for
> > > > nodes to further influence the downward paths that are
> established
> > > and
> > > > maintained. Consistent with the DV-based RPL operation this DAO
> path
> > > > control mechanism must operate hop-by-hop avoiding any
> requirement
> > > for
> > > > end-to-end path coordination. To avoid overloading this email
> thread
> > > I
> > > will
> > > > initiate a separate discussion on how a path control element may
> be
> > > included
> > > > within the DAO.
> > > >
> > > [Pascal] Too late, I just did :)
> > >
> > > And if I remember, Tim's idea was to control the stretch of the
> fanout,
> > > by decrementing a counter as the path loses preference point.
> > > At the moment, we have a parent preference 0-lowest to 3 highest.
> So
> it
> > > is easy to decrement a counter by (3-pref) and not fan out when the
> > > counter reaches 0.
> > > Tim, could you elaborate on this?
> >
> > A Path Control bit map will achieve an equivalent control mechanism
> > whereby
> > at each node the number of bits that are set will determine the
> extent
> to
> > which the associated DAO Destination Address can be advertised to
> multiple
> > DAO Parents. If a DAO message destination address Path Control bitmap
> has
> > 4
> > set bits, that address can be send along a maximum of 4 paths. For
> example,
> > at the originating node the DAO can be sent to two DAO Parents where
> the
> > Path Control bit map in the message sent to each DAO Parent will have
> two
> > set bits. If each parent then advertises to two DAO Parents a single
> bit is
> > set for each DAO message. Eventually with a single bit set in the
> Path
> > Control bit map, the DAO message can be advertised only to a single
> DAO
> > Parent. This mechanism achieves the effect of limiting the stretch of
> the
> > path fan out. Where multiple DAO messages are received at a common
> > ancestor
> > the number of set bits in the respective Path Control fields are
> recombined
> > allowing for renewed advertising of the DAO message destination
> address to
> > multiple DAO Parents along the path.
> >
> > As the set Path Control bits are split and recombined as the DAO
> messages
> > are transferred to the root, their bit positions are maintained. This
> allows
> > bit positions to be ordered from low to high in terms of path
> preference.
> > Therefore when a DAO message is received in which the Path Control
> bitmap
> > has the highest preference bit set, that DAO message destination
> address is
> > always advertised to the preferred DAO Parent. Similarly, when a
> message is
> > received with multiple Path Control bits set, the DAO messages can be
> > distributed to DAO Parents according to parent preference. This will
> ensure
> > that at any common ancestor, including the root, a node is always
> able
> to
> > distinguish the preferred downward path. The ability to determine the
> > preferred downward path as well as to obtain an indication of path
> diversity
> > will allow the Path Control field to be used when resource
> limitations
> at a
> > node require a truncation of the number of downward paths that the
> node
> > maintain for a given destination address.
> >
> > >
> > > Pascal
> >

------=_NextPart_000_01F7_01CAE62C.9C739350
Content-Type: application/pdf;
	name="RPL-Path Control_RA-01.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="RPL-Path Control_RA-01.pdf"

JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nO1d2W8jtxmHatmWLMG21t7N5thUabuNtI24w2OGnB4vBYoCQV8S+G3Tp7QJ
UCALxP3j+u+VHGnIb2Z+4lCHt1k3uw8mhvz43QePGf04z5hQ88z9rxvf/nDx+ms9//7fF9Xj+dd/
3TTuv7/48UIxXhSFrh7Q9rc/zP98ZwHNnHOWqfnddxe86uBzLea5YHkxv/vh4s1isFxlLM/KnPPF
L5arnHGpc704WWom7WzlYrjkzGQqF7T7dJkxrWQm9eJsaZjRsjSL86VkRc5VuRjZZ4URpViMlytu
WdE5X3zzdpmzIlOFWEz8yAA9tVOarNCioCO/uV+uSlZII/LFpZ2LlbnkskH11XJlmFTSAgZar5cF
MzIv1WLmWyMLz3mRM2Gbf7/7shJPybhw0lGFZMpJ/O4fFxbm7l9N4SknsHXnyHWuVGHmK17B+Id/
ubv46sJyy7NSGqtBqW3LzslynVmqK9Vt703SJ7calKwULYXqzDLpFGolU5FumfLjDKv5mm866SSS
iXXvG6fgwj7OuLD6z1ihpSq5Faq0hOSKW63bfl2Y3Olt5WaQWWnVrpg2XDu12/5cCqNpc+yawlge
nWItmLYiUHQEmYzgxbNNlk5ymRLWYCzpUujCGYmVVWZkl+xCFQ2sl4EYgvXK2puQSpRkqj62r62t
SWeYFumKW/IKTcFnlpLMk7LiimWWUkIfHurs3aqES0vg+nmpcmkWT5aCaSvlvCahsvGaAiLim+VK
WF5KWRAOAq5bOJJKiLD41Dmc4UbJxbPKYaS0cjK1uXzgvDTXUlIYbEPPlysrgJK3tDGzCDTjWhFa
va4dqw7p2qv2iH1czW3syUzLV4pSWrEFZ7E+nltX+NvF3SvnAjbuZVm5iYBVa+hbA9869a0z3zoH
rdA78q2xb1lZ1M0JQVKZU2YK2h8mmkYJI5PfV01hXQV2vw140JQE92WjW5Q2TJNnA0DZGeLmBFAR
2D4B0hsHYDRwGqUhrsCOnDbNysxtNC2L2syv4DyesMDqKUBzheR5DeREuglB04Bn5h8+iVtSoJLq
yPG12jBm06Bz44q7G0DqOZBmQHULxiEJXwIuR4jgUWAysDaDXHR7zwD9iGpq7hMw4y0QL7Ilohxs
dIAXZKfXAB+lEfE6RFTE1YYiFhVe19xvIH/AiZHOrwFZszgnbxGWMONT33rmWx8QzEVma1lZts3b
RXTHDRHULcAe6B0DQY3BOKTVMREo4Os54uvDqA0i+75FWO4JYR7LOZgbxrvQfQMYvAQCG6CkcQYm
DNMES5gE4Bswd8MU9o/s1Aa75o2tEWVcRMOB5uTRHGRPH0XCem33MDMErOdERl119xYoMVu5RPwm
zzNAqIOAR2AgRoMKtKBxZO698gdePAQSHQIs6RYW96pUH/gYWH6IOJ8gd4YeeY+aQWQTAPMRJBuU
S6lm1JP/GuEMBCcsqJ600VOhXYM5Z2jgc8AtWmJsic6enQMzQ9dIadIBJWaY5wWgESUGgu9T6ilO
wvbP5249VpD12Hr3pKiq0MV/NvsSJgwgGy71rgVdzoXNmjcweiBrvgaCf4K0BrWB66IgMBAdeqwo
QLcF79ZsTV2JssyL9DostZoNEL8kkROUsITsAeCK1t4eep4YwPYqlMPAbqQ7A8DXgS5UmgZ8I0Ah
rFFgqiJ20OMlvTFoCBhHJhwv4mAun6YOhPnh2AvFjwMSnKPq1jNAdu+agoieuGgrQjWD0+qho9Nn
yKbvkSpQrR4vbdACnJRIp2AalMR6pDkGHBDX36OChPtNeG0E0CBJjCHdHvhXcdNH1KaWX3Troxue
jrUJsteWhceyQ5zrCVQPFxngGuDXMF2AxIgKpGNJD5ED3XbaDjUrSaXnz2uycNYklDv722xID5Y5
k8IUysbGlWa8LIxyD0vBhMk3sUuQU76ctSMTmbp52pOzTEtjbJWqWJmpTFmjV4xzk+e2jFdM5iJz
WUUynWtLgVVHyTIh8rKK2YwXupDWkARThSjc0YFgRsiczvOJO8QwquTVfn7d77IxK6QqjJWaOyDk
XBFEQ3dcIKWFW4dtN1Yaq7LuUEKTy72GldwWSk+XtiF1oQklV+5gIct0aVwIyRk3WSbp05PqIFGI
jBOJXHqcgfogOQJCaD61JGkhuW7KxiUNUYeE118LopeVMMzmHDtEb5zKeh3LjaXcYpMWsMjNlme5
cCRs5iSWIDgzrYM/ipK7I5PaFk6qY9pMcWfZtkOW2rhCULCCc6GqY9pcKsmtw9ZSGFkpcG6VSEDG
QR5hoFs6W/ZyoXOrDpccueZ09jB0uj5I0so4xdcHt2TW6gy40Nrq42oprA+oajfFqtPwojpvruc/
rxM7Scxr3xOVezm2fxONgSgZoqV/ankGo9kURWSUzV7GZwwgPdt2vfV03dqrmoxXAGhymjPA8n2f
crJu9VWT3dSM68r43g0J9njvI61mIOvw+Flfcj1GV5DJa43edAbzYt1KLU3hPuoMpVe0N5Rcr2Ei
wAL1FODbYclbt+YIS/yAEJsH2Ewg5ATUwY0+I9AxyeOTs64nvA9naPGasOcoe6tP1Cej+MCsK/n4
NvYEyPFFnMYBFHhfgO8KAB274rVFCHB9mtk/8MJV/m8TLfQMpYbUzdX4/Q20GzQFDoErBOCoPYcZ
qXpshF+AZnfzPHBPHOulO/khSXACmKK5IHpjBYW77Yib92LoFnrqtZhmiFxfi4nvtZ8iLLuRvR4H
tnNg4sKb2qlJk6a4rkMgiFNkqXtd1ohReBtPEDDR0GDRY+ifA3rx9Zz4kQhSbGqBREqAkNsCszdE
Fl2Da3uWqG5LIouK1xlDINyRN/XkRco9WnxAj0LZadxOgdLgrbYhkAm6wYG8un1TqmnpfVvj3ywA
wmC4KMPA3a4leIhPt+PHFU2uRZnzAi5IYWTFa9i+aza757fjH1bgPDkFokKH0O3qxTkNXjZGN2q3
Zoq102yJSHXrFYWOMhPPoyPkNDMqqe6MPUdu9wBh+ybKtsX0KUEH1ngoAP4OuE8P2XAFgTSDJBbf
Nt6yxu/xiri24sEgeZsGLfxoMRqv7ZEXEjRftECcU0CbgFvj8Wu+wSlwGQawUA8fAwn0XUgFTrHl
MKYrlX0upMaW1UPI1bEvAsG9uUAsusAD772lx/dtzrDyY1iYNmS819G4+GGUulRhfBBEEK6QZmAg
B9wi/eMQ5pE89T4TL3zDrXoUCVeE/kBgC0lThHssppN07Rym76YXUkXsGuZhm9Tx6BeEfYuwxF1s
Wxxr11NUhj0JAa0O4ytZWByjJRPaU9pS1IOVBbKDlINUZ9tb7AXkg4Qt4+1ugF8nQMVxevRuRURp
jrZExaYVywc9yzK0tzqLUoju4p+TWRI3IBC64AY4bRy6WiDw1QFewZRZn4zPBVu/cGlTR+fejXQH
nqvNiDeNRNI+hBe6Gts6h2+8CkZWdfG1+nmvrCKOeQ/0RcMEcKOd1urbGXhJiQAWh15Yi98h7LsI
Amq31EO9k3bt1gTu2bfep4KK5ayeXJqSGJupNF4Bw0XTTseAa2ft24YiRtDjwbvfLz3SCRtdIKVe
U43XCHA7b0JnBGab+o5Qz2X/xlIqvhcXL7sx+EPcBw1zx96UPJLXpx7lww3hXW6G1s1Yyui4gc8Z
7sSwvq3VJe5dt4Ah7N4Kiw4BWx4J7j5Gi6zWwnrsafI0D0bh67ZlNKqGR2MBcnckfSCxceoQThBw
vrsY8j3GtWzhEZhAqhYJkkMU/4AmQIBTVbuPMTwWE0hXfIBIRJI69UOawO6q3ccY1lWRrq9ZL6oa
YbV+Qivo98hC9rGLRCS7T/1uLOQhbaVbN3dCCFpy/aQMJpSHZAsf7uYHcAhTQJA4Hr07GhZHg7iF
8xgyD4CGMOXu5P4egnQNBwL/IVDWKVV/8oZ1nDC8h59jkN3D4kGcHJnCPoiuQclHZjCppvOABrPH
Oiqdk3dqMPIxFjeptnJ0C9ljmbUPJ+/AQjpB471dAYV8GuqSnqoGYkHz4ErnHdgALKcCNfFqKs4T
Laseiw0cPQwf4m7HN4F96pz/N9Umx8/3U7UdhT7OI4xkJPuUhj8lzdJK4vGeR+yBJKSskOR60/mD
sbIKwIEcXBU80ijbfOXqYCTrb2Klb9AdtCEOgX/WU5qempe8+zR20LZ0D/DPGttHY326O2iPP5nC
R6q7/wESehc/3KClmbFVIS7cFxxblyKP9Krbp6D7j76FX3701B30Iam+i5IeC3qrEb2pHEgMdKG7
cPTbzx7Jn6JywN+YOeTK2IDIs4tlyzWx2Ete+DsRPTczd3snz7Xgx2uP+GXA+odhwreZ/BZ4Wf1m
SvUJt8R/S6ksFp5DgPDrFpaOuZJqXti/cn7/z4vv9vtpH1F9xVBUv20x8veji/U3DZWar4z75lPr
+nT9CziSOR49iwP3fSYtFF+88i0rPiFZXnJNup22N82h7576ZyP/7Mw/m/nWS9/rtLB5OPAPx3HU
I986ASDX/tkJmbpuTdu9QpWEgc3AvNCE2jPAyzQukgByCcQUQMZYEOtW5uza978Fghr6Z+cAzQv/
7AmgO8BeBnxrRxC6cF8k2/j6hEzTVfQQqDyg+wLwHGQzAwoKOK6BSgM2Ii/b7GK5BUqDdhVY+agz
TUYNC6l8i/7oPWphMiaFc0Kz+cTMOSDoZVSnSIxTwGDoPQHKeAFwDIAcTohyu3iRz03avVI2VdVF
MkC6CJxcrp9lvEFrq7fByQSY1RBy7HXbCQbK/a5YxCMbvCD2CS+h+5Tou+tewcyhs0+JOdTdX6TG
zDA3ksmTOFeEiEnU/qi9dAm7BY6Pwgd0yTEg9pwQ03C0tVhX68y2eeMoqLVu3XjwzwAVs2jAOkVW
dAnMd4RUiQJk0MslwDwDU18BDUDlTzrE0qiIUgJKmMEozwEEEhzhGCEJtKJ4RJzuORGIr5m+uvgv
2aKlumVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozNjk4CmVuZG9iagoyNyAwIG9iago8PC9MZW5n
dGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXelv3MYVh2zrWhnS6vCR
OklXbYMsg+yYM7wTIG3TBAGKfomhb04/JU2AAAkQ9/8HOiTFmUfOj2+GuytVdgTDwIjLud59zDz+
toiFShdx/a9rfP/L7OWrYvHTf2fN48Wrb64bb36a/TZLhczzvGge0Pb3vyy+vNIdy4WUIk4XVz/O
ZPODXBRqkSmR5YurX2avlzvRKhZZXGVSLh9Eq0zIpMiK5cOoEIkerVo+iqQo4zRT9OfdKBZFmsRJ
sdyLSlEWSVUu96NE5JlMq+WBfpaXqlLLw2gl9VaKTC6/+zXKRB6nuVoemTdt78d6yDLOC5XTN797
E60qkSelypbHeixRZYlMeqs+iValSNJEd7RrnUe5KJOsSpenpnWg+0uZZ0Lp5r+v/tmApxJS1dBJ
80SkNcSvfpgtz6Krn/vAS2uAtT8e1D+u0rxcrGTTxzx8+UrFtku8yIu4gfMPDZxzkZVSlhqMiX6a
Z2XvWSriLC1zvdxMFXrBql2gUnZApTfXrXDhzidr/Lc/v9b4q+Eep7IGiv4hqYpSY22lRC6lShu4
ZxpoUmNNiVIlWUr7zGtUlzLXGDzReKmqotDNs6gSSZlotNUPr8Hfe1UpTbZ6F4cNTpSKZYu1vChk
anslZNbH0SoRlSrSskZ2h6vDqIatLHD/3qz21f1rrMp0UW+krKGySnKNp3pZLWDeqwk7jqtCT9y1
dsCzh6b1CLx3alp7oIVG1jRtX1xJjfhYw+mYneXAtA5HV6hSRXqcm9aJnWQfdLYDXphW/Z6qNA/C
xdj3zsh4ZhILL41FDrB75FfTux0yKWmXI7DYDwC8CGTRfHa1pw15JHEuKsMnR2BAsis7IMIU2SmC
LFnYGXzRTLOH+vxhDfrMYy3Zk6re5+p6o1rmiUy1u70gsHC774Jnp2yPY7BE+8zu6oDuz+z6AIDn
lB0b06ALEkJZBB08XfIMH0z9/NCwM2L4M37ZiBot+iAJPgLUj2C8axeGpNw56PIILHsO0WLfM5OQ
Jc7BiJDH7HJOweBTRK2HYcjsttc+eDYHq4RoOAILRtK9h3azic0ZuNYXmIHNJC/MQ6ss3wfLfhp1
+gLxLxTQhOqfgxH/wnLjqe2MWLSH9kCxjTSn3cwhYJneZgA5Q6RjBe3Sk08/s/v3oc1D6k9ZaTyC
TQBSpLbIz0iS0N2YLaKfkVA5QyuDUv8cTePRDz0B6rYQeUGewvaPu4d90gLmwQHovC2b1aX1HfDe
KdJbEAefgjXMwYjnoLUH9YNnwrXUB9nNCIOo0uF8Xr74rF6XSKGUQnxGbMZdFtDT7RrK62CStnOt
PcZMwlYVhJttrPF0wK6fWpG8CP8IiYQWsrW3gbQxNmBZTUDtNmA9IZggbjwh0Blddt08CvVQ5mic
Nw2yMkmFH/RA6uALUtceTfLJOnTdtRBZBxtSZ+TZ7dpMXq+HPhw3mjD3DNzkMf5GkoWicMeQPdI3
UEevpQjD/IwDJAA8Xv0ZvzAslgGrIDsCKUVo/o/4kUBbeznFQt9i7Bw82yRUReBzAia5REYl8qrs
tnbBrxeGUTCNskYDMoCtRjlFW/EEVGCcyOf/s2w2wlzuz9iRgNLPZZSRLgBFmKU40nnILwfaxCP+
qEsnE5SYmYZKcA+joHDeJaAfiO3naI87DfSvp/jX7OoTau7udIFkEl5XaRND7l7NRKLKPNW+1qoQ
ssrLVBNdViltLmbXnUnoXmYi70fu6dAyEaqjgHkT7k7SvNTwSYWUZVZnPuokipRpvS3dlHGWaN+u
jnGnlX6DPm4grEQhc9pvz8Tbn0SVSFVWZdrjW5mUy7O6nSRVXtB3yWL0sJWIle6oyUyJNFd5SloP
bcC/NoH09FXeW8oeis2rUpS96Px3S0AzR4C2kCq3+MtZtt0HrRNKOMBrOwUE+Jgnux0jErGoZi1Y
pMoOjUhEob4tBXXO0Qqvd1WbDmSDFhIoig69fwRQC/o5kIiPwXueQBDvdZHV2BEvQGsPmfJTNHFr
Y3v9SiiNrYUyQqMuAUATPlR/Q3cMAReFiXhj9GMEUegFDNVJzTs2KWVHvAS7t6OcI0Vu0Yrijg/I
BjaKsSEuAkjrMVFYUoqw8u4ATH3QIftjghljZrkE40B7GFkiHlr0UtuYHXAMNmyXtws2rFhR+Rj0
VWAOux8Slttnu/TzqsP3vjCtzwB8jpHo4feJuAOZYtAB481FZO8R5YCU1gdg1ftgQF4oPSHTuVyC
bPxTR2eNybEnYA0IXjiS2s6S4awQbyEcR17N0FE7n3KCMsYTnLd7WAF6GWF0EOQI5vQ5AC4OIPKq
wQIARTv7NpKzBboIRB/BYu0C8eUe+RlABdlLMOry0rSoinLpniorAD5i6URA8FwCQPLUTjU+sIx9
Kp8lTY+E9XIIbwhbMCNkQiPqTywofDpzo3SxjbBjPuMzIuNGaN92gjzes4mBYL8A04wYniDa6DsI
Eb4ZV2pwSSsaDgFKG+mjSzCdJ9ToqoWe7fhXIAAP4VY6teCV64DVscvjYR6cdXQHQklH3gblPVoo
9UPPzUDi/9ywDk7jgCNHI9kbusbxhBaOewHhGJy5cIL8Y4wz4XSduyt6uM7lHHzMjhc72zsWB4xR
rxeB8TaEMjzZxwQFXV7RP1z9bIOF+s+PZ9dRLDd0uI3WF2v0Bay0/dbkSYgRcktbuTE45IYxh5Hi
MQ1099FTtF2kzIbEX9WHzZn9bJe4IZnkaGcFeFGAZyV4VoFnn6FJPgcv/u1ObMV09u2la03bSp+6
9VY48n7b8NPaV3pTowK/lenbI/q/m5Za45lZ5jqd351JbmWF9plL8W8r4NgBb5r0041GmazIQiPz
X5oWMW2RkwadL3TE8AbtkfQ2rIYXDSF8fTX7diYzVS1kWVQLlS3U4s1/Zj8G3DGkKd3ukmFSqJqs
0rS8vmmo0aJN6OtZsnRbs5SDWd4nsxTb2kuZDmbZsbPk8bb2UsWDWZ6QWQxe8k1n0WqQTPIau9Yf
0djB9RKyrF1CseFGU5kNlnDLNu8EnmtFZFqfz9i6QXzHFMPbOcm9bXBztkHL9wvZ3jWXeam5tyi0
iFKF/t+KgAlX0ZEsKLQgUKXI020IAs7ysOk+m854Zlr2xDKNYMM4FhSXyCywY76AawwUW5vkKR+g
kxAo+hhse1jg8WepbQzvz2DoZ6CvhiZ3EMJzlpQ3Ntc5s8LfzfVlsILUyr3TeYcnuVcst+B0btuk
umWf88Yn6TJawyRu8CShXrGVyPCGGTowhW4sjDvFw6i5bb3d8fN+qzvXcy/0385J7oX+faRxw8VY
idtLiIeeDTgzcv+xkfvBCfGn6HhauHluOtuzgf8YLKxunYJh7K+XprVvBD9SC88A9cOQ6xGCnbXZ
X4Kx77Tk37bNg86z/65tnjsDht+nzfP89gT/PenfVdIfb71LpO/S4725/zZNcm/uv8MxHpvot+Hy
S7RtdH/De8y9a1pTuXeTAxwzpa0BrG7gKOkdI44AglnWh2pbYmkBsfW74B+CX78C6KW3iUAwzHfl
umuFxt6+QtcGxi6LunCAFxWWYFvkegK+I0pS/i9f1QcOumydUsoILVO/oHePv33Bqrlle2C6o+sG
t12fPEtkUx9ZVGmu4iYVKBKVZEW5MM8KtVBl0dRHqBODMdiPm/saufyE8N7L+Lk/B9/Y5/OKO2AY
V9xQNiMS6lPwMzcMnc5XmAMctvdcUIAJOHwnx+0cXmQP36tpNKdKRSoTN1ZAD2+BfaGVBV+dtIug
F15AlGVIEf0qS72TNSPXP1UsyqxoeCipqoypDbDJ/e81LlfsIbq/ZPE9XgOndnHWKqE5JmuHtbQg
gV2gafiiDvhmspNPzycwHeAGH88BwsehNsCSOwB2nhS2vRKKXOsvPSjiDkdOqpAGTi3gEmlDBipa
/mk1TL/gNZ/5h1SDZkeqBt0+phc8wXaQ7kI2hEWxr8gjQwAb3kulIoO/DMbf5n9he/vrCvsxEFKJ
FrDP/1WjIfANq+nVmgPX5e4Uhyv1817VXXB0hSoqL9MgCYOqJ6GqETyZIu2OSsKOnMKCQIdVmIaU
0VWScRdp5oHVdfqoV1ovS2LyjSp4l1oQ5sP1OJs98ijy4ILUZ2QLgHHWKUQaUAtznNFhGatpOrYp
WPWrYZzRgnPQ9ppUTzUIKaAmHYXbe+hFYHNgQx/6jnyRcasgzrftg47VTkN8AEt0Q/jSRGogA1Ap
iCvGWC3g/nqGOOHYDA2lrufYKHdkE3vmuHqiR+5B2TQ38yCddgbnmWRvIXLkS8BA7kGIQtY8kgbz
cFJmDXHKmSiHvsvrWcRlcwfUI4YU9a6AgOU/xXLCg2K6mYlMRlyvFjBL+G1/1hnCyX+eOh65aoPG
UiZ9LwER+/ZqH7gvepS67XyMONWjFaDJ2po1/Qq+PbMGEGJAeGJYw9cXnuDOXaOPhlBngootRMgI
LFPqswx38MhD8FQGgEAyVzkFf68GyXwKWp6r1or1IVbz20638aEpn28P6NUVwCM2AwTViNMB7DNe
xvK6F9UmP0SCHClJd+J8pObZ1oihm4aiHLAFrpKGVsbv5i7c5UBuMVFpSMTRIL1XsSB1zGc70Ocy
UDAKf4vL3Ss1tJHTjiI9PFf7quYPiatfzKmGSOt9Q2OXP+MIK2bxsapdAp3QmBdfbXMkzIGIkOUe
So9A8pAhkRCaUJweAMAnFYdCo3a/H0ad942EBk2fmWlo/myCEeaJDqFjq5bR+Ct1CJQ0FWeWjlN6
Q25eL6MHGDL0IqDPY7J9kUAO95ieu5zWpfdH73/Ksr6Rbm7VT80SyyITeTklSxx+OAAdIcGVwgGW
fElEFyOITXEAB3AkKjfMV7D2Oi1I8E3wWoDQtab6MWiFey0j9faB4MSfxABaxxMmDfU+qVNpZtm0
QviQ0VCtbFV/MLxqPqagWcL5eqWv8L77Xuj5Gn8mBAguT0FylFNEHOMp1s8H3SzhoWTn12Dig1Az
3C4BRgj5j5vx4A7/gCTgBiwkAKNOkBIAadM9+2KLQoIP/3H8wqcbkTBAtIZtI6wtEH3CyKs7DZ8v
vW2XCB+PM7PwlZiRkIZ19qd701ikItsHMgyWICyGQj/ChOKrNAoAdNRN8Gd4PmWcb7al1p2DseNG
o6pE3jMaJ32p6cNtfKnpgR45LpKypB8/0sSRiiSJ9SS7USUKlciCfFDpj1EptGtLv+2kTcZMyDKO
E9r5uf69itM4JW+eR4kosiL3f6FJo7USmYzLgqyCrJLMSb4cZb/m9CLSaM4K6flsE1ePfjtiiiVJ
KqWAPAuP3PR1az8ETn0xoMD5r0rZA2q8vLrgd+L5sC33sYb+HbTgOAHSViMJR+6TTfSCKBDn/Ecd
/B/DclVPYL4Lntq/iLpIBX/EZdoBG7fsOrL8+bLVdgvotivipo2Uy8QPHdf8gqMY4BaEnSVUbPhY
FgTBUPxkDRuDj5p8AAYcB1KLAO7yG7x1wOfTEb7DP5uO3Hvvd9NdpvPyQFNG7NvZ/wB3C7QgZW5k
c3RyZWFtCmVuZG9iagoyOCAwIG9iago0MTE5CmVuZG9iagozNCAwIG9iago8PC9MZW5ndGggMzUg
MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztnduLHMcVh1lp9ja7aDWrxchRBCPs
4BnjbfV9eiDEYJI4BL9E7JvkJ4cYAjJY+f8h3dszXdXdX59TfZmVTIJeSrNdXVWnzvV3TlX/uvS9
MF76xb9946f389dvNsuf/zO//3n55vtd48PP81/nsRekabq5/8Fu//R++d1d3jFbBoHnx8u7f82D
+z8Ey024TEIvSZd37+dvV0frW99L/G0SBKtH69vEC6JNslk9Xm+8KH/bdjVbB17mx0lo//l47Xub
OPKjzepknXnZJtpmq9N15KVJEG9XZ/lvaRZuw9X5+jbIl7JJgtW7X9aJl/pxGq4uqidN78v8lZmf
bsLUfvLdh/Xt1kujLExWT/J3edskCqLarK/Wt5kXxVHe0cz16Tr1sijZxqtF1TrL+wdBmnhh3vzx
7u/35Nl6QVhQJ04jLy4ofvfP+erZ+u7fdeLFBcHKP54Vf7yN02x5G9z3qX58/SaIl/ly/azo4i/T
TeSFxZ/f5nPP6en7201OkX1rUbVmVetp1bqsWqdV65uqdQQ9TqpWTsD2axb58tOcaFlqPXkKrXN6
zwUMfVy1ru0u1TBHMLUrmNkRvIf+OrOeqwYx638MXawVmDk8Mb1n0OeVSG+i0zP47dL6rWC2yE+9
7Y6H3nZRtprXJayK5vqian1etX4Pz31GpCMGRNbJpbD9ykug7NE69XPdEm2LFd/ulpxLnZfs5OAM
1mVoJu/l9Yj1P7OWWq3fWpbVNMNciKQvRTqMQ5t6HyzyVOOgQBGrFw+G21wLsiwTKSxeNjoGNxYX
a7FcSaIos99OAvBKpMp1gz5F66XVoy0KCyQEbdIM3v0c5vDIUXhsXWX00jNxpQt4j9msY6QXMEKH
bCnSg7QgTXlmUbL9HIkeshlrIdDvr8TxDEUNd9xU0sOzrgYhC9UUwj1BStm5BCItYDI2k/0CfXrS
oZAcWukXQBvzHPEdmq8rEB1mVdDvrrzqbk6qQa6Bxi7mJMydt/RjmhNXE3sDe2rrLJBuM7DZ3lPx
NUeVOPAWgMw9IXJ/gOX1MD/gIar2x7Rkx6LD/rRpdi2PbbN6WySOaJQZSrpZOBmRP8J8ZIZ6YUZx
d0Zk8rAvYjGDIh9yiGEY4wZ+U4RYNja21gbeJT35B1EKyfkzg5xQPHAND/4OXoPyQdJ1Q3GD0qdG
O0cpdjdgimC3xePcIpnVWQzZyFCQ4qUFoL0ku6RpY4XRNSXdJtlQHV1KuqOOfgFrcdPRhSkYp6PN
1AoeK12jPiECLKeHjm5ISuEcuQcJbjtYU/BtVn8C87ok6pFaOhEJJbPtNVobkqxOt7N0jjRvTJGJ
z4Dezj6abRItTijGyocIs+XdD/P8/1/NdwP+ML/7+u3qa1Fp4MJldIvUvrXvHVAVBA8y0ENRi3HJ
kOWOlBB1srAM5NDVdUU3nTqbLl/Ju2XDie0HT0WHzCY3AF3dUWJ9hsdAppk1BaNaelOuRxAMbDBS
XMd6he2ZD7M+Ist0+A/tsevWp9laoCd1iAgBeADFtcPHlY2trLs4oq2voW4X85lJLtsQHTcEIJZ3
iQhFbrXpQqa9tnEDonxyEtyhm/ZzGlNY2sQ5P9KRfChaddj4yJokiB9KQx1CKt27U1g2BXmntLFk
dCkdZSnvlxUPT896ZjfE7EkNVaomRgG97JsQIsfkrAa5gQf7uxm4uUqSpvTDBiDEJKdTp5peKLp9
EDDVliP2jDSzAzKuWh2SSM3smL/KXqICrbiYkNZ82vJixvvWYnNQaC/h3cTcyrRrsHUjwUSUKjRI
F1hdhkIaWF0N8lDxkbWbpGwUN7oWwkACT843HcPL6Tnzli+Iic1+yJqMlAabZEVptclt42APpTUk
QTkArt0RPBLDAYY5g/eQO0VgB0eb1SBait09F6k4ROOD8Ab1ZrScCZKf9Wyk3UV0l0iPDAqyISjm
KJtUAmhzjorbnf9atf7k3GrLDj33bm3m9b2oMI0yv4L5axbRuW5GYer+xT2jgmQa5AZjTrkIgqTp
m0OwdBlmfCSWrscZxNKu7i2XmUkQck3fw6KmM0qmM/gFY13Z9szYjWZXdkh1iuIpHgBWkRGfnraq
Lj+qxynJz6KSnyHQ+5eiYmN/q+Hz1bGmQ5QPtCWog8nBG52KyWv+FvCCnBKv+1tl7KH5W87oleyO
EIebvsTrPYCF/rmKIU5BNUrNA4Cm8QWGIBKUXmsCbM0+Zqtdw3mLUhQfyd6qvQQpHseUqfxq1zwJ
Lg+TIgdIx7qXqLjCT9NrCtuQiKkiWQqbuFhhMqasmSttBq5gBtR5Kkd4mvoDn8uwgjPy7Y4ptoWD
0UURJJkOJ5Az99PxoKyEelgX91SwRIKRmWDxYMmQzG2775msHl3PCxy4dsA12ziVwR0ThauWov8U
wf53zKf9oz2xJrMX5SZd5YxopuUDVTKURtHH82YNzKoofSkqXob45X21ZA1O37dsNB1i+aG134X1
UjRwL9y8WZI/yGfHFISmWcsxCwNGgf+gUg/ckAcoy3fWIe5nTcjvfrHehzwftYClIyPqJlM2A42q
YNZCNPCynOsKaA5soEVfTrXQwHKyhR6QqjZKdyHG/zfWFGBezggZJSYZMAKXEaMVgibPgSR0dHVG
o3Sn5yn5hqsc41Trcgjep7Mgthi6sBha9ZSM2bkujPbRQomPobMaX4lF2+PqVnA8KGbpoDIcTex/
oImR7v5aTPNAJMpjFZ1t5qY69fgpxDhOGrSOKmPsThpbAzRk1Wgz+LiDSgQmDtAkSmbcLlppS80V
rlqEccaonh1TFN6kU0VLUwLsOXRXtDCEZrO6IioD7PcBjgqLqcU++HspKYy/D1LcZTTSx1GthlHY
mnLa71akNbRKnTZfuxfqSOX3NhzyfzRN8894KLOLdIqSyCGn6w/h9NcJWAgQWyzwm3RYrhQgd+3h
eASDNhsP2A9QcD0AODc4TcG5OOOFya/pUvPiYtUiUzwU5ww890uPtJVytyi4e++KaXPB5upOGVex
9DFozVy/jDoy8OWeHGto9EJWxmXHNMmWTI3NG+KBy0+hdO7Veu+STZhFV4SnP9bPqoThc1QlthZv
rceVz05gsbJsDRhkkF/gqgmczdSw7FGb0TgZJ5UeKxMbeUKTBMCx8qCT63NVFwio15DMlqMsyEWl
XxIlD5qdGRkalq1Bhx0klYpF5u43vSmB+oVI0Gvg9aZ7XJ7/cLR/I3M4tP4+mFbz3iLetskshbPD
e8ijXcDVw1M8dT9LS/25OLTNoEQtKh0FEzUUSeME7ziglJhKcrQm0wodlAWpB0BE8WzrUlrKz8A6
/X0hwAHIDIpdE92KFAOi0ltUlfuWDfSPrGFtboxW9jJEe4yDk3tpj/KNbZkYedgJ5tDDwwPiHSAX
4ZzNHWZLnBn/ddXqLov5nJaAWp8UDkktMQ8lBBFIU/w21+JhKr1FazJGQA8hYhNlbI5hgScwNgko
H7AXj9K4HrCntOg5DaJEkVgF7soldfelT7mmnKM9bHG2RA82R+2/klo5lWPKIed62r9d0CAOLkhL
pg6R+8CxpWrnkSeOtfiXOEbUj67mn/bNPh8JBbXC/RWflmP3m6koqHfRgiotYjfDOFaWThanixe6
/raAFnH3pZLVbpEb5tjJB4YUQy/nrZ2z/kPu6Wd9N6Z2TbupFrZETrfRdC3BpokZNe96db0Cvz0T
D5gtLCqBtVRKDgfpUTFpOaoupeNWYT2bT5t8AkP1lwBr7lewXC5H/hb6OKdrH/qrK7UVglwgF/AK
ZexZSVxR/ITumr1hjvbkhGIEtc5HZcH8D+VngXzzJaEwLr7stLsv9WideFGYpXFhbDZesE2zeLVc
J9vQC7Ok/EZREFrfcEq8/WeIlu1XB8XnhnbLfJS/2d9EWVZo5iwfJPSDYgdiL4r8fJDj9dbbhFFQ
rD30sjBKYqvP83Xsbf3YjwsibT0/DJNtrq+LTxvF2yBL7J/x2cX9t6Iy348KhbD1ksDPdmwaepsg
TfJhd8uzPpl0G2Ze8VmlcL8G2RxOrF246k2uYep3/K7rUueheb4S+J4oz6edK646u1vRNm3Mq2XA
g7JGHK1CeCGHZvLAN/IgA2rMSW+paR8yOvL1YM423R3EEY9CYqmcYj/OYWK26TqHSdKN7Wgf+DwU
CDLXQLVJYbtYEKuNXnb7z/aq2/yv1YiZA2+uqpE80AB7gH66AZLhop3xkXqwOtG1Gj3qlnUF3tQu
D1yp2SfOK20DXQxhbRJeWi/rcg6Iqs43FRMq0BXpMPeb7drS0XGf94i81gFOXZKLa4oKetgHynxQ
jo9sBlGUis3Vg2m9K7u6UYB6UcCDfa3QMBRIMlmeUWdBpyt4F28JVyrjJ0sjmBdWo3SD0PVz2I0d
bNbUENivpsD+B6/XL6SGWUlObXSCxsJdM12FONO4VVcVk7jfYd5f00gxxWQ6x70QS3SqaOh69FFK
jRp9IC474LthrvGVduExKVhyU5xvfHHy8ApRUQoCD+hdnTQ5vU5Q2SJbWOfu5YWcyBfCuR5UOIbZ
UBaGrlHpOPvea1uaIoH0BA4m6ec57uWEpvgp3iDeABWrzyutdh9bKj+9VICHrvCYmRHxnmtKl7lM
RJ0VjLjp99e/iYHnFGSkug5OlCLa4/PgIgTckVyFOZownIiHTIFJBK06XQqBMEYl9NP5K0jskini
09adY30vSmHZuzDqe5iudVkckkrG4zEtwVUDkqW7qCQGdxDvKNa9jFJkemCc1SgMcu5bCnjytJKY
A3yRzLywLTBs8V2r0M3Ioy4xHfnZsMOe4BZ1wp+r1t/Mcr6rfnwEXVzC0IKrx30Uvr4LJVe73/4w
yi1vhA5dQJjmjRAjkDS1eVqTVBn9lSvGVMvgzNRsGUpPTbcMQ0IapYriYSyDqPuJKt0fo6p/mNL5
217SGT6/TwH7uJOJjXxKPfAfkNklDWzrmracMPgl1iMj7dC3cS/5oqyr7H9eVoKiHbf/mCENW4l9
SzYSeKHlEZCn53VuhcgYjrqizdZR8mZYYVqcs+1fdGVHX53piy48dRiUtH9OqiTTQaU2IahqbPJj
Rd0fW6gnVbpYFtFrx9qev9zN/5H/+y8CQED0ZW5kc3RyZWFtCmVuZG9iagozNSAwIG9iagozODEz
CmVuZG9iagozOSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz
dHJlYW0KeJztXetvHLcRh2y9ThL0stLIsZ2emgbZC3L0kvvuwwUM1AYCf6mhb3Y/JWiAAi4Q9f8H
SmrvyNnd3w65e3eqrBYGDOJ2yRnOiz8Oh6tfp7FQ6TQ2/5aNnz4dvHxfTH/598Htz9P3bxeNm18O
fj1IhczzvLj9gbZ/+jR9fa07llMpRZxOr/9xIG8fyGmhppkSWT69/nTwIdqazWORxVUmZfRoNs+E
TIqsiB7PCpHo0apoeyZFGaeZoo93ZrEo0iROimh3VoqySKoy2pslIs9kWkX7+re8VJWKJrO51FMp
Mhl9/NcsE3mc5io6tG+63kd6yDLOC5XTNz/ezOaVyJNSZdGxHktUWSKTBtcns3kpkjTRHR2vp7Nc
lElWpdGZbe3r/lLmmVC6+ffrH2/FUwmpjHTSPBGpkfj1zwfRxez6n03hpUZg9cN983Ce5uV0Lm/7
2B9fvpfpVE83Lk2XeJoXiVDm8YdIGnnGcVVEP9jWlm09sa1z25rYlhbHsnkU+iL88VALINdiK3NC
+8K2zmxr27Z2wG/1eypV5DdC5dRR2QZz3QX0jnVLVVr7HSrD5nKO3jwGTDx2ves+SdnTZ8/HBjfD
HfLUGFwS56Ja2NEHoszHRMpgWr8BE0SdXY/vADMNM7JUzsCbe2DEq4YclPa8nPCg3bTb5ZzOJY91
zEkqI4X5QgzaG0W28I+xVtjXAyn9GEx1n4rHsrsPBH7Gjn3R6mG8A6vIEjnlzbYp+rZ3oFm5p0fI
Bd0EXLiBNk1sEE11B4y4C8beIuwgQ+dcA42869g6AkT2WSJQsIjKCaIS7PpHYEQUnrz+cAhovwid
F1olzgDf26AHNSxgRMTRPeJphyrjERMgHup3g7RZu0SolZ3xqxISFH3Pdnb2fQLiJZLJBXiPZ2GP
XSzgnBjB+41oqynY9uNveMdz0t4Fc+4PkW2dubk4G7sM95jXYLIo0O0BNs7AU4TTEONbhAZSB1Zc
l8P22tX0F0o50JAbkKy7gkBPpuAMeCUZcrfFbstBb9rdDcDinRo7XldQ2O+6HoM9kBVej/lzSsfW
z+JsHsTd6qXGV1ssNxPoMW7Ir8J9x7dAD9Y/dQpgcMhcr9x0+DjJr7En1nkIPRjJh0DO2nnQey0v
Wz4GBgBXSYxOW0C0tTkZjk4x0AlzHt+eC+3nVkRlPO5AUzhrKKH2Hqp0j/2jTR5aOxCwQoss3HRB
+6cmZaf9FzDDCezS51DG/t1vdHoAyKD5tfRf23/4ZhcAhuDIctLm0Zj/FeiN7A2zw8fgrvW3ojEz
KxSCEK8Dcj2AiifZg7a9l9RXsd3rB3XSKnZ5LqX/f3dw/b1JDGYiUWWeRk9n80LIKi9TPbWsUkKV
WZ0+k4qkFzOxzJBNu+NKkwlbSPeRHjkukrI0oK/URFQsjfmnIkliTWRnVolCJdJIV4lSJVka/XZW
Cm3VpbbBVEhZZpmJE5mQZRwntPOlfl7FaZySN5/MElFkhZ5K6IDPZyaLl1b6d2MCMhYyzpLbjIYo
tCi0HkxaU0pKEM+GdK9JVWWxJCVv86cLWZLU4VyVwqQXlUkCt9DtD8g2Ech0hqZAOJ4Am0HmekpM
HcHbHTCiixMoQvtCJ6Li+Jnb1gsb6SY2Qp2DHs9s63vbeo5WsteA7SsgxF2EIYKXgZeBMYHuP7oR
CscYy5ebAERBCCPwMY0aiaWCdA/DUngqaO0LNVoaPEkT70oFxOyYGLZSGfNFKxVBw2hWEEscWTdw
M+B3rCRDy6MKaEVH/B4P8f0YPB2gja4f4CQ5Cz8GZMm7+qNJchBCkEdsky7UnWqUegn4ilGoQSH+
63DP2cAZAi+d7oDkYMiT8T4H43R2AE2MS90OKMZxi5YkgnH5IEnhJQiDaMMORTZpO55xHWQoKAvl
cR205ZoA1zkF7/mOJ/CWmlMbMgQSOPhYewXm7AmCUENrS4Bs1Issu0NO4trDPLG+4Tik2Vg24Pft
TWrXgNZ2gmZF03/8IcMcUCSRdc86h+vyChmAQ1UooD7yqLfrHD2ZLjZ7iAyBX39955C9yzw3mdrU
8z5T70nXohgFNDsi74HiA5Gk4wem125Qsx0LW+m+8FzSRR/rC4u/AZN0/kfzlCwY4HNkXW8xBn/E
Sjr4HHKEwVNUaxlbTwIGxy7e3v2IskZSXkTpWXR6lghV3hsAtYM2BX3wst/5FjwYp8Hn+2AhQqpu
K6GvQqGnQIk9Z0dQAh5NT6zDwCCGqoicEZ6AHj3RjNt6OGafINmt6KtgmF0UPl2fKY6ZHgzkZvEC
zIw/QMUxsTsHl4t5alvPyXt2WsjbPMcvHWBoDByjgUD4OeK4iwYrcJ6FjBklpc9471hp7e0pjesa
OMT9dLFCGT8P8XAoDRbUoICalLWl1IuCD0qzWRavyyC8jEofetInnDoHFBoBSW0DxvB+rynRvnRU
8I7tuDGVek1wA/J1fAREQbf2hRGQjVopjKD8bANFAhR1AwgeekAotBO3NPF6gy7D7zr6Fpx20QHK
CB8hItS1PB7TAzOdQ3IGshrKRBEs2EVRLDu1LoMAHCUzaB/XrmvbVKBsrTO71mkw9OyKlEeePds1
ducBM9P86slbgg9bWSI+YIIjQe0xeI86xP89TuOpoXGDosIBHknzpz7QzEIPtWmlUvM94zLI+2Fx
jr+AuXYYtJziZC4gErql22mHv1ZpDrJLtMm4bLMjZbbAYAu9vzPH8991TueF54D+d5s5oL/z4/lv
zLWfRFZl9Ht7V4icrz8zB/EyL/JEK3F5Eu/G0RqpND8qKzUgVyLN1e3gtUwUmfXioF3LtVDLXZ3W
RqkZ01JIRJbneown4DctfWW4WYxJ5KykKNOmoClJaa5pLSV9oceTqZnmF0aH2jUqc+NKv5JURalD
v5ZhJrWZfKlVImWeGAlmokiMA9kbUHtWbI5799tT1/xqJrWotN1pAZqiBJVnhIb7TZu5ErmUKiU/
Tpz4TXlEobRyC0Jn37LoJkD6uBd1EFteyTp0zwnNPVQSkeSNggjPEgczd2jr5k9sdFcNBwDQgRZ/
RoL20XsgVjSyGSBpjyIWf3blyY99jPiNHTo3g0tpAQZfpfJ3B8zZk5DxXOeAMkEra3i5AVgdhxdZ
DLgfMmzBbeoPXdEZDqNgah3pL2SVbSXwO8ujofIUjN2boenPRkL/pIcux0CMnt34szaXBhb44WOH
oR74CPtw9k9PHkDsQPbvOVb13Ufii7YCzpyYHD68++BNfAVnO49Ba8xRFDqn4Pcu4cekR4BKO4IY
HxpzvtKbGWxvRD/OQG9KkQ21HpFetEVhXOgUCIC/ysRXTryxrVfAf16Rp65l2XqFBIH6vB0i5E6Y
e8OO3deq3QeySJpvB9xLeEAVE8OTF3RhZOt8QsXgc2BQlj9khRiRYAxOfrYxS12Nwd1Q3EfSCz8E
4kynJ3kLIk8PnOiS3rLu4wNV7CVQiqo8vjMGbHWnjczMd9HH9R1+5t6/ljVXHs9lqw3mc8KTWUAO
7tAAXz7nXCT4oPCShW20TAkAHaipQV8RYBQEI4Pnppb7EoS3hhdmDz0VFx7EEHr/2oPd6QUH0IUG
l23QiQcmbXxtPAUBE4oE0Y3Sfb8imMd6aw+CWPjWftkqVqlyGlXm0PUWfPxu+XL1hMKN6AAQunwx
oCBu+HX7/+7mBO6jUZq5zid3ZXPXLWBfw1vOBhRsWSL48TpaXzoi7stPXwQPszEOX7bN4EEpPhlO
BEFD1ELv4b6BM0nhgIPFkI3g/05NIHw7u8pG26d5MPlVNL9BGxjBIbKGcLEPzoP05RP6FrPPMryE
G9Rg5x2X4OHUgDzCY1vDI+CYmFPbVrE8WY5uL5zP618+UxMZYxiBRIZrYpPRZz0c+mylG30CPlxw
zwzG4U2cdUWbDtgnh114OsVwMoIng2YLxynJOKA37FMNZ/cPsEvXcGDnPzrOOtj33hvWusLwHfj5
SpEIz2TNHOJwd+8i0Rh0wGMChA5429mgxfjeW2kDtDGLwUpZ4QQRbnEeLprmXX3t5rbSntOz+6Q+
dAcRqhODFvnxd59v5sat0zkSNcIFkAoaByOoO7BrCNMcNzxK4+dE4VpfEvezNYa1h/lVHHD9tuAD
Hd1Wcj8ztG/4UMm3BsCStejWF/8Dp9IT/wcrNwlmDLXCUIbm1fL1v4AjRhAZg3nvU7Sgmaf7Exju
WotorXSrqxdHbGwqc1QAj+HIA1Ve83tcKxNRVZX5nHYlIomv8//1NIaIT2Mr5dk9nR+oxkwLQ4dV
kEx4Xoidig/dDMaNfaXLweJ+wFZwx0RoNRVKMnY2pNGymKhRcrZsjak4W7a+Bk//ZFuuShd+iyf0
T7DAj9fypdukCP1bMOIhmCj6VggqhKclyiC7EP53mJzq1qMVD8r6M1vk2rjiiKpc+XLNMfcJwDWB
cZ95bWymKnPN155qW8uPwSD8N4MQkOUTWehPVzhqL5BYPVWOW70vtq7mrV4OyXxMEtc9ghts4bey
yIck6jFNhTe6OXTGMg7Lo+FdDXQztedyHbhZ4vlS4PAPUpF9SXBFbLOOvv1ZmCvAA/w+0Ir3IILv
Jq52nwRdnWE+Ktbnur5cryXjvQnGjY2P7petfaQFdIEDf7zXdg794gpf0u014LDibvy5noEfc29+
XhkF0uCPhvddMmn/SUzvRyb/en3wN/3vP93IA1BlbmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjM1
MDAKZW5kb2JqCjQ0IDAgb2JqCjw8L0xlbmd0aCA0NSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+
CnN0cmVhbQp4nO1d64/cthHH+Z67d7jbe6Q+O3W6QVtYSrM6UW/1CQRIAxT5UmO/2f2UIAEKuEDS
/x8ouVqRI+mnISXtXepN4C9jrcgZzoszw6Huh2UYRMkyVP9q4Jv384c3+fL7/843j5dvvtoCP34/
/2GeBCLLsnzzgMLfvF9+sZYDi6UQQZgs19/NxeYHscyjZRoFabZcv5+/9Q78VRikYZkK4T3zV2kg
4jzNvUM/D2I5W+kd+SIowiSN6M/HfhjkSRzGuXfiF0GRx2XhnfpxkKUiKb0z+SwrojLyZv5KyKXk
qfDe/cdPgyxMssg712+a0RdyyiLM8iijb7770V+VQRYXUepdyrmCMo1F3KD6yl8VQZzEcqChdeFn
QRGnZeJda+hMjhciS4NIgv9a/2PDnjIQkeJOksVBoji+/nbufeSv/91kXqIYVv14pn5cJVmxXInN
GP3w4Y1IlnK5YaGGhMssj4NI/fxWUiH5GYal4lcXutDQSw0daGimIcmYGlxo6FRDVxq6xINXIpNc
KzIpgC4aMvkJmOioNSRKIm+ln+VmGt+geWDXddPAEpVS+t4rgO8a8GlmkEgV6aOxOeaQvKdHVy/G
BV4qmfsCs7S7GPTiyUbf4jALyq0avaWDKU80ZZdACNc8jQQ8ILhr6Jj8atg3TOwKWm3ElYrMC6jY
a/ABobkAWA78LJSeKC4Vc1Zb7kgbDdKt1dwA5GSNUBBGtU/ZRXysoRca+jV471dmDTe8HAwNF71i
UFZDXjQkfm7Q3IPRz6AW11YDuWOove1X/GqFnBIfEmr04Nfaak749SO/dwrWB434AlhNjxmynm2G
0PAe4goP0WhuAc+gOl40XqysBr5oln1JhWSxkGOW07eI0+PsvYJ67B0oFbb37ox5e0ZlIQ9gyIXB
ws+YNWesLATNeIN4cjl8MVR/9OAjbSHmRdcgAK3quYaEhj4C9mEWSt2IJusFi26SbuQGixEBliT2
ZV3Pi/ySRkIdk8VKXoNlTXJXnwKjRwylbkITfjfcRZGHd9pKTiERQH3J6D79razkEHIcWQ6Pxbox
s2bSsxeMl8IMRV89bG5R1qsprs7hCLB0gZW4huyRSbWNIPuggQkK8egCLEaDPKrx1gMcqpuzDsDU
90jPvtCQ2aSNJkDl+Zu2mSvwKw0fDH9oaFZDL1tSUDZzxiohjJ6gE0L4GItTJrOrUBjbUddmekwU
MM+SvI7ZC0AUjtlcQ02nX5mM1elrLNTrO8dgM7AGM5GxBJQNu3KiJ00FQhiVp9aGstPstLIU6HJ7
YktQQnDeLDtUKltxLyywngR5M2QqaCuYvGtyakE3DY0G57P8rsGaClVc5+2DpAoFcPKT9g8y9x/h
3JoXxskh/+oc+W7lpUyE0gNCX/teuTUL971SY0GbJcozsIu4a/2u7MPUE5EtIOtBGxbNObpGgZMP
4Ll4DzgmjdJIcB7V5WZ7q1cmgQiEARelusdMoqLiySVYggkpiG6Yh8hukeYgPl0BPs1gpIgKKXeA
hjZTNpsHcssLtIU7BAWVlfQUZGroUyQGnIex7vaiTaSyDWu9pkuPe1TIFoYNkt/yYZaZ0cj6jmcZ
1mYQpBrWn8MVNJhTWYrVh7pXuKCvh9VmFFU570L8AQVNESZtSPfaRraOT2xVYLvir+fy/6/n68+k
GnhAptcAuavfXID5iK5BtVvwgeUr8My8195o1bKpRhs+g7qq0d6+wKdyDOcsWTjLc05PzOTXyDEY
GpE9mO1uTLzf9QvY+7KlhOHlYafjsr4JpxUzYcxv8Q588eUxat2IZUAG/Obb70iVjTjLwGF9TqlX
w2k5nt7iGk5rsDISq2ftEs4fFNDqMlekwLWwdiW17e+6GuweBrNmcgQQW85ze2qQaDEDLIXfJXji
jsGza3YElSrYQ0dHvcpQkMbcuVaKmseslZ18BhbqdNDTfJFPMjp8UFaCVHAGmAj1xFaM7loJDoj5
irEldDZE/AF4vEYnBbCTYUf9VZRpq41YLOIRUy+XRKmlCjdo2Tx/2ubWSr2uCHvY5AF3iNQ2YfFR
dHvTWMyYBRh9QAgDynerjQIFlS4FzJb8CLV0M+KaCywbr7t8uzqEE0JXk8C5YbdCgVNDeAY5YuMY
G920luAelBnPxOdXTsFG39ZxbtBYc4munfAFRue9w9aNA86Bdn68TU80ulaCzzaAAv9dQ3+dABGJ
f2WwIEEjGzttQJWV4LIR8Mm2mMliOVAarj2K/Am85QgE9h049Cd1Jm/T3TQd2GJiDh1sMVRtOa4s
uUaWw5+R0Z29Hd0o03m8rV3KhUtOYAo/vKbDR5rUSAaX2ZsL7a+AHyAW26qeYxo/+7a+fivhq6KP
XQqlmJt2A52Ne6ETeTxEo8U9Y+dXQ7RaiPICGJyjJdqSQiQEbtOh0SPwBzCORsrhnuiCsLZ/Ucqr
dPyiSJJtwNnVdvnD5u5AFJrrBlGirn+sv94UgqW1BGkhROE98+MgzbK0kA7ePEuCME021KVRHhRx
VN1tiCIynwiK+nLDsotOqKsjpswYB5nU2E1JLg/yUkRqlfKVuMwL1YmRBmEspEI/lw+zSHnwez8N
8li112yvZcRSOFFQRHFa3cCoaDXPXhjwlb+Kg1AkmVABWBHEURSKCk0qJAs/UXc9tpdNrvwokpyR
i12o3wuRlRGZVUq8vuxx45dBkYs8Jz8fbi6jhInIyHqO/VUUZEJEyeYyShonsfB+o26dJFmRCDL8
pS+CSEixmmWqN4WkKA9zPAbObpDPzILNmDPJTCGyOLG9SJZLOEdQIto/9iUPRJSlhMXm2bEv1I2Y
vJRjKzWiV1pWsVLcrY/ua0lv25l7e3kNDYhngY9GAe0toHABaIB1SXzXBBXPkUsxhKHDEuowcVmv
S5pT+txEw2f9ozqzOBdNd+VdN1SeAbrI6pFUUWJjOYLGJ+ZkE2368spAmjH/AkBmMqMglvNsdGKP
dml8WAmTbTTROUCIQmKMxszIB+ausSch+wppNgpd0NEoCV1QMvIIFcCuWeBaiWu/3tg2jK1mOaYW
fLJpy6v7zKJUQUeLB7CGiEJW3Hfu5jewcoEwjj+6hOnt9ri+snhyXG/ZtEaEyyMqgcRFodTAzP17
NKMhsXIrzfP6RhMp4CUqwjb9S5XtDyitOTbvOV/xHNcB0UWDGyC4evLnaFWE4ShThZ7IuXXhnYey
ceTmkXGaecwxOLqX+CXa3/GElpQ/BBxwParnbxEMaAMDXtlSFmNO4ZT5DGgUrKG+6x/tq57Trn/0
nIkgXpxo+3E+hoS1jBLIhj+PmdahMK2d+E98DzoKQ5sWUFXMLNENCVCwslvaR50Z7Vw6Nlw7RS86
N7a7369uYlZW03O9esIhprt3AfU4vqf7vhMbNFr5dIBwAIh+agjIaThkGBNBSCPBP+8Cem6QoLq3
bZpHo/ChrQt7Jfh4OBLbEO69ZMpK0OB0OBvSEe/tnwq4SpEgmSL4R1QBMthVtGOUYV9UwF3wZoQj
EtepH1MFhot2jDJUca2MRLYHMJvznlX1hGZAH5CGjNELRyTDp34aDXlMXelmPh0XglLm/yuFGXN8
Dcfgj4fwePi7lnAIrhSwgrdeJgKjRyRoA263OqbMjVz2Q1Os3bjhEXaOhwz3WJOCzknh7nCGcC1L
8Z6pzjROTVCdEeH0cDY4Jzs8rYg1rqqzvwozhj+DFWZ4JDQxz3dMjVz9YmpZnS0urmucH6SG9H6P
rgLRvg+xoHn4z6s9jYoM/zoUvyYaju1L9jzGh+zEaT+NCgynobMh7L1oqZD3ULQ/Z4HufL/86QRK
I42frxTNQ+bztAp84l2X3H7Dl+D3XnjNr21NRhKVZTqk/j+pbA4H/yInNzk1O15sEptUvLYM/kVi
YyRmk92kkwBnCvdUdj8BEvp1HNNf1vMpeMV2D3zNajfdiJ+AX/+sIfpxqRq6NcTZPy5VQT1NtjWE
e2w1FtRkew4WakjkPyglyDON5C/gRVu3k2OdgW+mhLdmUEdZzlaVd/jh0o7MGu2Oti51b1N/2iis
7u5Wmvs7sGJbr2uXUvMMNaEadZ2B9+AVCDPhwEstzc9gwy9x9vXStYeYK9yIDZYvOfDVIqePnbU+
gn0AuAh/Rp1/6CvOkovcNSf4aaPjFrubStLHRUcXBDogXfv8X/rdzx/0OGWNxeaVYXOquQtVsJI5
BVDP94I4l4muHuG/2TL84ju6FNJxNNUX20CvPeqkPWispf35A+uVGIDFcleIXnECd0M6d5yUSe3q
UwiOf3XB8pddplwMsH1TfNu7K0TK7wpfruf/lP/+BxidZV5lbmRzdHJlYW0KZW5kb2JqCjQ1IDAg
b2JqCjMyMTkKZW5kb2JqCjQ5IDAgb2JqCjw8L0xlbmd0aCA1MCAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nO1c2W/bNhhHm8ZJnCD3ml7b3BVDpWJmRFLnrocBa7BhLwv81uypwwoM
aIFm/z8w0bJJyvqJIiU5hxPkIR8kk9998BPJz6OAsHAUiL858P7j8PQ8GX34bzh9PDo/mwGXH4af
hyGhcRwn0wc6/P7j6JdJPjAdUUqCcDT5Z0inL+goYaOIkSgeTT4O33kP/HFAoiCLKPUe+uOIUJ5E
ibfmJ4Tns2XeI5+SNAgjpr9e9wOShDzgiTfwU5ImPEu9DZ+TOKJh5m3mz+KUZczb8sc0ZyWJqHfx
yY9IHIQx87blL9XonXzKNIgTFuu/vLj0xxmJecoibzefi2QRp7xE9Z4/TgkPeT5Q0brvxyTlURZ6
BxLazMdTGkeE5eBfk9+n4skIZUI6YcxJKCQ++XvoPfYn/5aFFwqBFS83xctxGKejMZ2OkQ9Pz2k4
ytkNUjEkGMUJJ0y8FmLO5RkEWXKN0JjGuczSuNM0YwkxCEkk+HUf0IlCQuXDL6ynWRqFp7qEhX3l
1hPl+v9jOHmzQhbA3ZE8sZwa/Q6PteQEDY7cxdCG/gVbWK4JvJXQzw2QJEs9vPCNY86sNQ+Y76L5
JdqANjhqIUQTpElTA8+mRsCDJE8IRRp5ME0jxZPxLFLc2kxhbxlKK53Ud7U2ogcPd0Ztf7eCFtLG
LiyR2Mr1qi2kfwoVVFhITLJZLfqu7Ebi9Xj2/sYajCogcaQ8BcPhmBgOMeNJ3NEQMxrELZwn1eYB
o+GYzJ3c7+GQquHAwT8oyirF7I03LPMPbQP3Nfr58iJR6CyQniMRS5djMG1KNkmmdd3bRlS9WAz6
3VvESqsyFYxWPCOTQcZjr4Gqydjr52zFopFthOrdtuxjVadegXM0MgsE9wWudIW9RBNQqViVNA0F
EcSC5sFF0tXaAKLLXIiZedIrslWxgTZBoucF9DJNwNblFcRvpmrfdsy5ptd6wdGLbptysyUrkOwz
d+Vya8IQZFc+6GXNXSgaWiDpVvhff7TQe0o3JzBctRZRilRJtbF8WBorYzVYkYOrkBVVHgtZn0hY
lkVNTtsJCW8afK8nOz2lgcuXgk4d9IbBK6oxAeHSoUslY9/xMbLSVN041411HxKtxb3CVnDFSFSK
JbA9VVmH5v9eDzOShvPdHxee/PGWhLYltCehAwk9AoSojwhfgbc/SuiVhA4ldKSIPJYPN4zoLj6B
1zsS2pTQQKNfYvkWzLgNGFUkKrrWwFiqPZNIfgI/VHRtAarXkJ08BtTsGKl5DZjX5LWjMVpduqgh
G4ipp0AiSGeKPaWe3fpVT7Ezbf5lWe5OmhqrMFJlP1+CiTXmHhhlpJhTZr1tlOUhEsIReP0KsH4E
0BXPyhl+XZtPOTFiCjEgGF1M8QMwty4aiUXxjNwbed6xGlxwz1Ms7ItLMHrL/PoYoEZWegQm1Lja
AdPsSuiZpbUg7veR6AaAmv2aaVgW0bhBP8+Rv73QfhgHjEQ8q+scoJCB1AuDAtQLsvhdo6BeKh6+
M8fvgXFGSI7eewWLOrSwPESodxvmnkNabkVzQ9kquvfU6A0gcOgcyPkPwbN9IMYjo8OUcgLIN1BQ
yJpnHJbdfwCE0rT1Ae0lKDd7CqehiMZLjTKJRtdrg6/AFOkeF5AJIKEpFR9rOIAamiJ4HVnlzPJc
Qk8VkhdgwiNA61S2RWbRxKxkv43HAGbWgZwGAPeDSvoT1tUxQMwhHB+qrlITKSw/a+FNOZaRQsut
yIyU1pUZleuhwlFUlFGh9xkScpN11/jOfM+Ebl1zCBlXyUmBcFEsRCEF2z8QGRL4AECLiIXzKKWe
SIgqJGo3P9Jvub4vfEdpYwOMUILXaj9U5DY5/4J9CsdpcBdkTppW0HJjSxNi1XNqshYIywpq8IgG
71bepn9eacj/cPaB9J59wK0uC2BvDvmmaQVooryvRSFaY+irwqqjIMt9KV0GcXK0uEwo4lt1mnKi
W1zI9P+hsG7vztxpoC8oBaMK3+wp2jTbwGlaBDVc9JX1UktD6aFEsw3QtC1BFk0VGAK21QbXcehr
uFhwnS/C0KPXN6jxhCY3rH+E9+DyRvmoS31TuI/D+qdDVVM5JyG8JwCiNy8UXXZdm4o1heVLpCJl
E9BHYYWCJK/XJUB4LuuFxVYArksanAKXK3PIXK2gzKIxXRPCqh5VKT7Ksd42RZlLvl2k1Uo1U05H
U7oLn2iqZlBQRJJqqmGQ30JDMkdX6+WPeQd9U30082FKo0pLdm5iRUv29JwF6swxC8UZcHl8NJ8h
pTT1HvqcRHEcpXk2qj4b+RFLCWfF+WbGtOmo+B5RHC0aVbFRcXx8ztuxOKCd61nY9jghSUaZEEf+
E54lqcg2EQk4zc3gJH8YM6H7J35EEs68PX92NJvnxstIyngU5gjnpKpnTxX40s8IT3mYqdFUdAEj
ktI4Y/l6JyAJo2kgFts0IJTFkThbLjhlAdXfq0lFfg9y7miskb7ujxmJKWXh9Ox5xENOtTF54clJ
xpIwFfY0PzmuYdLGa/Rpv52LQc35Tc4c42GaabRr00yFGdFMF/BJPgmlMQ+9r33KCEumjBU61c+Y
j7kwIrvMDWMOMvYD4CkwiOGvQ9IB8OehOYS+Dmkkwl6YvmySaA4AWyi0ua8JtDY0ligSwD4SBeok
ICpQEYNUtA5myampBim8epJ02beMAM9NIRP0I0uR0pQ0lbJQhoepoH6Pn225YNtpadX5B/kOrTDs
zEskYNynAiZnNq9DH7QfoUvqn2KAk8O+RE2zXeVvT2bgLt/FVXMb7V98Y9tFgZ/sGj6m9f+N3CUK
VsWjB0GJRu9L1nmJg2fPoRZbD9cA8SW5Gtumtp9PFz1Z+MsLhMTJlQs3gWtX9LVTL3Jbddfl6IZz
IQi57WGQRcvos0uPvgVYHFj2ytsTVmoL0/31OQvQah/haXFXju2VCeh3eOO882G8FoeMbPcn10y9
IopvcUFOF3X3rnhdT85isDeBVVG8++0m3BaJ7dS9K976oNBdNoE2irdE4j71Mk3AXbVtjOFWXny0
svfYNN5eY0tkb7fXqCFgHa/fXqMGr9bJT1tXWkIosI1LRiTWZ6HcL6qxp/92p5xu8uhgAi1q2jb0
G03APLiJ/gXFz7bWrURjwV4czhbgXoh0tGVLC0CDMf1Vvd/yhtItvSjmNyPixLyj0Ez1/VUwTkjc
r2GBnLRZo7RYXN81heqqXZpCrReiPSn0/raO5lZKtwJseVq8111d3ry/aeUmKO/+ppU7qqf7m1Zu
t8aadNepQ25N4Yrq7hqQtLsfpcd7UVSr+Q7ei/J6Ubq/ToZ/5n//A2WgpgxlbmRzdHJlYW0KZW5k
b2JqCjUwIDAgb2JqCjI0ODEKZW5kb2JqCjU0IDAgb2JqCjw8L0xlbmd0aCA1NSAwIFIvRmlsdGVy
IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO2dW2/jxhWAocQXWTYcy94km6YpZCRByGBF8y4xbfMQ
oF20yEsWftv0KUUDFFgD2f5/oKQkzgzFj2eGlGxslGBfZoeaOWfOfS7n+JdZGMTpLKz+1Y2f3kzu
Xi1mP/9vsuqevXq5abz9efLLJA2iPM8Xqw6z/dOb2Xf35cDlLIqCMJ3d/2cSrT5Es0U8y+Igy2f3
byavvZE/D4MsLLIo8t7z51kQJYts4b3vL4KknK3wjvwoWIZpFpufj/0wWKRJmCy8E38ZLBdJsfRO
/STIsygtvHHZly/jIvbO/HlULmWRRd6PD34W5GGax965+qUefVFOuQzzRZybv/zxrT8vgjxZxpl3
Wc4VFFkSJQ2sP/DnyyBJk3KgxvXKz4NlkhWpN1WtcTk+ivIsiMvmv+7/uSJPEURxRZ00T4K0ovj9
vyfex/79f5vESyuCrT+Oq4/zNF/O5tFqjOq8exWls3K54bIaEs7yRRLEq8+j6nM5WVb+9/vJ/dev
vS8qAodhsSH1qnWkWlPoG6nWNfTdwNfPVesMflfSLcpLIi5zo1NPeAwTloxp//Bk1YrTuJyx7rsw
fqegnMDcIxhSESQuSllAMhBBnmkg1x0TbhbwFkaf6dGb78nS/H4JsI+BtAZ1jmCwSdpK+pIwD4qN
UL02iDMl2tFiiBKIgx483uLaGp6C8qUobMbc5qqqtcw3i5lvpL9aEcncM9U6BTxvoM8AeuFIXpNW
amlTWLmW13Mgb5dotomvgHwEVKPBeuqvAC1c8pT06BRmvAXJvGhJeNX7B5IfD4afA8VkC/UNSPgI
Zj7ViJ0CEAPZC4BMRD6iwQMUSUvqiQzlgah8BjiazMrD0gMnRUN1imCZrilFtDVW8wFMeQHENVA7
hxVewgrH5mC1mjGsZgrzEPXWIyrv0GGPFRTStxOYO/Rr93ACOBAv5xpIoEH7qnmnWs9NdCrubOzZ
95UL/6rpwb8GfEnG0edc02fkMRlFk+Qgc+imifwWJK8MdMmAEK0JDOlpk581txUUG0Pr1sLkpxp9
J1Jcz/0ZQJkCskinI7BxSEbDLsg2Z41YFXyg3lt0/JqM3JlBXFE8rldalUUm6S+BKEcoCY11k3Hb
aE4z0qEw0EDOXb3rlkW7kSVkYlydxKfKuH2i+v5IukmBAVr5B2XcSFU6iKPAyNTJQWvu9ODnSvpY
N/syYwGA78S4wLQYCi2to86ejSh7BX1nBEWOLZtbr7XCfKr6WAos+nAMeGtq09bsMXQE3PAYKC9H
sxdKH2ijYegDB6loTWp9QL9DSjIml2jxfg+EpKsV2C3qByeyU/xPO9MjGEHS3d4Jd0n/LcwohwOm
HFg04hFcdX8bL4YifbxyrRLslDXB5aCt6abWKuGgO/VniOXJ8bEp27INlYvo5dAEHHEP+iCej5j8
AKtl83eSVHeccCgoNHcAcz/fYlblJeQDP3O7ZdWPney/K1VsThSMLOlohzxqY12rB4ujgsKutW41
N0kth2E0NbPPaTGIrjapTqd0lX7IHkODthCPbMIlaEeHZZL3huSteu0XanzAVFqOMFoevtKQITFK
hw/vUKB4czSpjSBFA1fwlY5N9IhjaMmH+aa+UxDTL6ao9KfjJBGgUJjZjCTWCtQjSIPjd/mAsOGc
QX/ILxAWzgcuzwx4bf3RyN4YEwLt+p9Bk11D5XnUCAe3iBY3s4/A512wLiYWXZ7miERYNgQnSlHo
HKNDZcCE2baP2iRsoVjpyZCY6zlM/h5aRMcDLtu2gU6a8aJKvs48w2D5An8JYM782tFYjg+s53UW
vZGv22RP4q5fV/BDQVhkB1K1hKuo5vbF9B9wfWPfiq61Rt6KSg7CgTrn5kTiERdJPklkj0uZttqw
w5K1pv9JOo2YkumXL7yaQNYqY7lCN87r2O9bVMbiYORzB9QeYqbNUYtXUa7SoZ9D0MWh5Xipi79r
jbmC36H7vJWPhPGC1SQTbPhteyDJ1o8JW/NSUQrIcCMu3+Y724bNdV8UZd72O4ZaNr3V053V7V91
6TeCJT91C8S0f0tvtmJsKSD8eR+tjzWQSHV+6DzNnjFsbC8rWTgodlPMZwFiGyL9jseKK0mhL+tP
hmwA1ofHeFfejbZjo12n3onxf1etb42WGvwtfm63jDMj3fnSGVm6odySEAphfpUS4y4neoQIhFk4
gG/Adc1CshVIB1drQPbDfSltieHf6XjfNxZ1WLI1RKIcgew2dW9r5EyGXYTMNqItWq0nau+8wOhQ
05B7ywMdHJPjEBmOfMmFQ+hGDxmPo5cDkCz6I/mNZQgc3enBfzYGC9JUX5e8U9K0H/MzwDLsJ0Cy
ALFZBjWY7JQM2WbZ9CyHEg/vPVSlIUMiHgoE6JcUtFpkQEbWNuJQOC9TYU+c7x+PDFgJboHdVVli
/OGwm163WAIMi0PPocXT7LCUf4iAF/J7dhlrM4Y5FC4PUfneYcNTm/O0Px2S3xxHO2yWqxC4knUv
K3FmqAnvN8ZF52NH+aum4GOcHKrRpLY20P1b4obtJZFuEEt/FScGTwykI52sbu7d78stI1uRU2gO
3mxUl+d7BBIXRdbnKHiAQ7YM/p1PbnyqHjnoPuezEHfuOA8+UI5VrZ18pXOEy8wTl/KY7rzDl8ot
KVfxd6f6JEDMnADaZrV2t5tja0rY31tti7r1J/j6F9XS1Xf0a60bja5cCkVPuP+KLuewUI2ixkt+
JMp3Gu4kFl+oyRcif4U+W7KqpMtmsoX4PI/oYK3b0v7hKenLJ8ABkhHK6rzsNkZ1PR6v+Y5NQ8P3
nETNU2jpEbeuQmy+igQZ4HpJEjXXT8WbsUgr9SFCtHQfK6vEB8wVtdTgYM0DkyCLHCXHuD5UvQJN
eB+oarxOptR5lBp6tC+nJRoPVV+sOptvs22LWr8qzrvcL3KDMngo/YdEksr60Hwj43eUs2ChKCUP
TUHKG1oFaTIWdlVYbBfSodpC+AJXE0BOfjPTFOBZ8YC6ZlQah6zPVLT5ZhUSsMZUtkmWHGvqk5jo
NQJqNx9Qt1JXuCoTiIH19X3X0/9txuwpTYFzBEUmfAZ95Jl0tv0tfEUgdueyvS91rhxAE1JSAF5Y
fKd0xJL+0yeZYxtt2uNcAa5DE0m3OWVNzQTayZkH25nfzQpGI1jzCTncuHMPpwXphfFrmra9HleZ
sZX7tCTXoD9of6Y4vG06FhFnl5D1w2R7srG7FVhpGH812mb9a/Vhm+9qeMXyLKYJBh65VMbraWsV
FFdjSyGuJd0Qvbz52Tn/sV/OlIt5rFtUmKqxU3YUMorn25nEls1F1y62K4l/rTI9tpU72N6bbRQr
laDEZlR6lBQqSWXGS22VOQVkjTJNg4puSIQwU8FEDjkUOV67FDnNDG2aQ8Gj+oGlvHnucMhtNGSZ
IFG3hPYd9XDatozSH6lwG9aqs5SaGvntghTXNLghrGKkJ0tUO8+80hncVhEXqCzIC0LSzEiUtiqm
y3A8nqItq1xfokFHgPICoFAZFR2FWQo79Kp4hCI5eBfdRKlHNSWIPSzFirsPRyoV+VKGYkk5b9qk
7Yrp8gYBFVEPQbsvlS2rNKRPDNim1JMcW+0WC5LoDquNvNYQawSIr2S2jnobf6ZA604aGH+Y4G/3
kx/Kf/8H/Fj7s2VuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKMjcyMwplbmRvYmoKNCAwIG9iago8
PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS
Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250
IDI1IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFn
ZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl
czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzMSAwIFIKL0ZvbnQgMzIgMCBSCj4+
Ci9Db250ZW50cyAyNyAwIFIKPj4KZW5kb2JqCjMzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv
eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT
ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzNiAwIFIKL0ZvbnQgMzcgMCBSCj4+Ci9Db250ZW50
cyAzNCAwIFIKPj4KZW5kb2JqCjM4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYx
MiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv
VGV4dF0KL0V4dEdTdGF0ZSA0MSAwIFIKL0ZvbnQgNDIgMCBSCj4+Ci9Db250ZW50cyAzOSAwIFIK
Pj4KZW5kb2JqCjQzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S
b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4
dEdTdGF0ZSA0NiAwIFIKL0ZvbnQgNDcgMCBSCj4+Ci9Db250ZW50cyA0NCAwIFIKPj4KZW5kb2Jq
CjQ4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q
YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1
MSAwIFIKL0ZvbnQgNTIgMCBSCj4+Ci9Db250ZW50cyA0OSAwIFIKPj4KZW5kb2JqCjUzIDAgb2Jq
Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw
IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1NiAwIFIKL0Zv
bnQgNTcgMCBSCj4+Ci9Db250ZW50cyA1NCAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUg
L1BhZ2VzIC9LaWRzIFsKNCAwIFIKMjYgMCBSCjMzIDAgUgozOCAwIFIKNDMgMCBSCjQ4IDAgUgo1
MyAwIFIKXSAvQ291bnQgNwo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdl
cyAzIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVuZG9i
agoyNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SMjIKMjIgMCBSL1Ix
MgoxMiAwIFIvUjE0CjE0IDAgUi9SMTYKMTYgMCBSL1IxOAoxOCAwIFIvUjIwCjIwIDAgUi9SOAo4
IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjMxIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjMy
IDAgb2JqCjw8L1IyMgoyMiAwIFIvUjI5CjI5IDAgUi9SMTIKMTIgMCBSL1IxNAoxNCAwIFIvUjIw
CjIwIDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjM2IDAgb2JqCjw8L1I3CjcgMCBS
Pj4KZW5kb2JqCjM3IDAgb2JqCjw8L1IxMgoxMiAwIFIvUjE0CjE0IDAgUi9SOAo4IDAgUi9SMTAK
MTAgMCBSPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjQyIDAgb2JqCjw8
L1IyMgoyMiAwIFIvUjEyCjEyIDAgUi9SMTQKMTQgMCBSL1IyMAoyMCAwIFIvUjgKOCAwIFIvUjEw
CjEwIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NyAwIG9iago8
PC9SMjIKMjIgMCBSL1IxNAoxNCAwIFIvUjIwCjIwIDAgUi9SOAo4IDAgUj4+CmVuZG9iago1MSAw
IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MiAwIG9iago8PC9SMjIKMjIgMCBSL1IxNAoxNCAw
IFIvUjIwCjIwIDAgUi9SOAo4IDAgUj4+CmVuZG9iago1NiAwIG9iago8PC9SNwo3IDAgUj4+CmVu
ZG9iago1NyAwIG9iago8PC9SMTQKMTQgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjIyIDAgb2JqCjw8
L0Jhc2VGb250L1FFR01KTytIZWx2ZXRpY2EtT2JsaXF1ZS9Gb250RGVzY3JpcHRvciAyMyAwIFIv
VHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzWwoyNzhdCi9FbmNvZGlu
Zy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoyOSAwIG9iago8PC9CYXNl
Rm9udC9RRUdNSk8rQ291cmllci9Gb250RGVzY3JpcHRvciAzMCAwIFIvVHlwZS9Gb250Ci9GaXJz
dENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzWwo2MDBdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp
bmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMiAwIG9iago8PC9CYXNlRm9udC9RRUdNSk8rSGVs
dmV0aWNhLUJvbGQvRm9udERlc2NyaXB0b3IgMTMgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDMy
L0xhc3RDaGFyIDMyL1dpZHRoc1sKMjc4XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5
cGUvVHlwZTE+PgplbmRvYmoKMTQgMCBvYmoKPDwvQmFzZUZvbnQvSFdOREpSK0x1Y2lkYUNvbnNv
bGUvRm9udERlc2NyaXB0b3IgMTUgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIg
NzMvV2lkdGhzWyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYw
MyA2MDMgNjAzIDYwMwo2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAz
IDYwMyA2MDMgNjAzIDYwMyA2MDMKNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMg
NjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzCjYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2
MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMwo2MDMgNjAzIDYwMyA2MDMgNjAzIDYw
MyA2MDMgNjAzIDYwMyA2MDNdCi9FbmNvZGluZyA2NyAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVu
ZG9iago2NyAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2Rp
bmcvRGlmZmVyZW5jZXNbCjEvc3BhY2UvVC9oL2UvZi9vL2wvdy9pL24vZy90L3MvZC91L2MKL3Iv
YS9tL3AvUi9QL0wvcGVyaW9kL0EvY29tbWEvRC9PL3YvY29sb24vcXVvdGVsZWZ0L3F1b3Rlcmln
aHQKL2Ivei94L1cvay9HL0MvRi9vbmUvSS9qL3kvcGFyZW5sZWZ0L2ZvdXIvcGFyZW5yaWdodC9O
Ci9CL2h5cGhlbi9zbGFzaC9iYXIvYmFja3NsYXNoL3R3by90aHJlZS9maXZlL3NpeC9zZXZlbi9l
aWdodC9FL2VuZGFzaC96ZXJvL3EvbmluZQovcGx1cy9TL1YvTS9IL2JyYWNrZXRsZWZ0L2JyYWNr
ZXRyaWdodC9VL3VuZGVyc2NvcmVdPj4KZW5kb2JqCjE2IDAgb2JqCjw8L0Jhc2VGb250L0hYSkNF
RCtTeW1ib2wvRm9udERlc2NyaXB0b3IgMTcgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDE4My9M
YXN0Q2hhciAxODMvV2lkdGhzWyA0NjBdCi9FbmNvZGluZyA2OCAwIFIvU3VidHlwZS9UeXBlMT4+
CmVuZG9iago2OCAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5j
b2RpbmcvRGlmZmVyZW5jZXNbCjE4My9idWxsZXRdPj4KZW5kb2JqCjE4IDAgb2JqCjw8L0Jhc2VG
b250L1FFR01KTytIZWx2ZXRpY2EvRm9udERlc2NyaXB0b3IgMTkgMCBSL1R5cGUvRm9udAovRmly
c3RDaGFyIDMyL0xhc3RDaGFyIDMyL1dpZHRoc1sKMjc4XQovRW5jb2RpbmcvV2luQW5zaUVuY29k
aW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNjkgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAzNTk+PnN0cmVhbQp4nF2SPW7DMAxGd5/CNzApK3ICBFzSJUOLou0FHJkOPEQ2HGfo
7cufpkOHL8CLRFlP+JrT+eVcpq1u3tc5f/JWj1MZVr7PjzVzfeHrVCoM9TDl7ZfsN9/6pWpOr/3y
9b1wLRt4dH7rb9x8pIP9gz6T54HvS5957cuVqyMAHceRKi7Dv6U2+sRlfG5F8kCLJBjIA4EVW/LA
DhQjeSDZ5h15oIuKiTyQ9oodeSDY7J48EJPigTyQ7EM9eSCOihfyQLdTzOSB2CoO5IFkm5k8kGx1
JA8knUV5C40cFRTFFd3XUFzRfJPeCsUVzbc1FFc032hHiSu6rwqiuKL7DoriiubbqS+KK5pvyori
qgmAekkUV3RfWxVXNN90UBRXNN/UKYormm/Ut0JxRfc1BXFF8+30ZHlsiygYimsw36iXDOIazDcG
68ezCFoV7dyzYnV+rCuXzYppxdPCTYX/urvMi07VkuoHMZS9tgplbmRzdHJlYW0KZW5kb2JqCjIw
IDAgb2JqCjw8L0Jhc2VGb250L1FUUEpPWitDYW1icmlhLEl0YWxpYy9Gb250RGVzY3JpcHRvciAy
MSAwIFIvVG9Vbmljb2RlIDY5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDM0
L1dpZHRoc1sgNTI4IDE5OSA1NTUgNTI2IDM0NSA1MzAgMjIwIDUyNyA1MzUgNjIyIDUzNSA1NDAg
NTA3IDQzMyA0NTcKNDA3IDUyOCAyOTIgNTI4IDU2OCA0NDkgNzk5IDUyNyAyNjcgNTAwIDUyMyAy
NzEgNTIyIDY3MSA1MjEgMzgyCjUyOCA3OTIgNTk2XQovRW5jb2RpbmcgNzAgMCBSL1N1YnR5cGUv
VHJ1ZVR5cGU+PgplbmRvYmoKNzAgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2Rpbmcv
V2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2c4ODcvZzQ4NC9nMTkvZzEzMS9nMTUwL2cx
MzgvZzMvZzkvZzE0NC9nMTgvZzE1MS9nNi9nMTQ1L2cxMzMvZzEzNS9nMTQ4Ci9nODg4L2cxMzYv
Zzg5Mi9nOC9nMTU0L2cxNDMvZzE0Ni9nMTQyL2c1MTQvZzE1L2cxMzkvZzEzNy9nMTcvZzEzMi9n
MTQ5L2c4ODkKL2cxNi9nNV0+PgplbmRvYmoKNzEgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAyNDk+PnN0cmVhbQp4nF2RTW7DIBBG9z4FN/DgH5xK0WySTRaNqrYXwDBELIIRcRa9
fTxM3UUXD+kBg4Zv2tPlfElxVe1HWdwXrSrE5As9lmdxpGa6xdToTvno1l+rq7vb3LSnd5u/fzKp
7QIF8au9U/s56bqjpcYtnh7ZOio23ag5AuAxBGwo+X9H2kjFHParGgUYO9y0QwFGYO1RgMGxDihA
51lHFMBoVoMCTAPrhAKYA+sBBejqy28owNCzWhTABNYZBTDE6lCAqTbpUQBTuyIUYKy1AQUYuCu9
ZaFrGz3URPavczic8h6qcs9SKK11FDVqjjgm+ptWXjJXqY3mBUu2hA8KZW5kc3RyZWFtCmVuZG9i
ago4IDAgb2JqCjw8L0Jhc2VGb250L1lCV0JKRCtDYWxpYnJpL0ZvbnREZXNjcmlwdG9yIDkgMCBS
L1RvVW5pY29kZSA3MSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMS9MYXN0Q2hhciAyMy9XaWR0
aHNbIDU0MyA1MTcgNDIwIDMwNiA0NzkgMzM1IDUyNSAyMjYgNTMzIDUyNyA1MjUgMzQ5IDIyOSA0
OTggNTc5CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDddCi9FbmNvZGluZyA3MiAwIFIv
U3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago3MiAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VF
bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjEvZzkwL2c4Ny9nNjIvZzg4Mi9n
MjU4L2c0MTAvZzM0Ni9nMy9nMTgvZzM4MS9nMzc0L2czOTYvZzM2Ny9nODkwL2c0L2cxMDA0Ci9n
MTAwNS9nMTAwNi9nMTAwNy9nMTAwOC9nMTAwOS9nMTAxMC9nMTAxMV0+PgplbmRvYmoKNzMgMCBv
YmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNTY+PnN0cmVhbQp4nF2STW6DQAxG95yC
G2DPTIZEirxJN1m0qtpegAwmYhFAhCx6+/qn6aKLh/RlxsHPuDmdX87TuNXN+zqXT97qYZz6le/z
Yy1cX/g6ThWGuh/L9pvsWW7dUjWn1275+l64lgs8eH7rbtx8tNF+Qa8pc8/3pSu8dtOVqyMAHYeB
Kp76f0cxesVleF5FciAiSQzkwA40RnIg22kiB9qkcUcO5L3GTA4Eq23JgXTQuCcH2qjxQA60O40d
OZAtXsiBPGgs5EC22p4cyPbPTA5k62ogB9pWIsosFGmj1yiuaL6ZNYormm+2y+KK7ls0iiu6rxqh
uKL5Jn0Riiuab9LhoLii+2rPKK7ovkGjuKL5BnuvuKL72qm4ovtak+KK7ps1iiuaYLTLIocmmHQa
MuxjMIWoXQVpP5hC0kkGaT+4wt4W4vnldTd0yZ47VZfHuvK02SbapumGjRP/LesyL1pVC9UPMN+5
+wplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjw8L0Jhc2VGb250L0NVVVFBRitDYW1icmlhLEJv
bGQvRm9udERlc2NyaXB0b3IgMTEgMCBSL1RvVW5pY29kZSA3MyAwIFIvVHlwZS9Gb250Ci9GaXJz
dENoYXIgMS9MYXN0Q2hhciAzNi9XaWR0aHNbIDU5MiA2MTQgNTM1IDM2NSA1OTcgMjIwIDM1MCA0
NTkgNTk3IDUzMSA1NjkgNDY5IDMxNCA1OTcgNzk4Cjg0NiA2MDQgNTIwIDMwOCA1OTcgNzA1IDY1
MiA2OTUgNDYxIDIzMiA1OTEgODkwIDMyNiA1OTIgNTkyIDU3Mwo1OTIgNTkyIDU5MiA1NzggNTI1
XQovRW5jb2RpbmcgNzQgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKNzQgMCBvYmoKPDwv
VHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwox
L2c4ODMvZzE5L2cxMzEvZzE1MC9nMTM4L2czL2cxMi9nMTQ5L2cxNTEvZzEzNS9nMTQ1L2cxMzMv
ZzEzOS9nMTM0L2cxNTMvZzE2Ci9nMTQ0L2cxMzcvZzE0Mi9nMTQ2L2c3L2c0L2cxOC9nMTQ4L2c0
ODQvZzEzMi9nMTQzL2cxMzYvZzg4NC9nODg1L2c2L2c4ODYKL2c4ODcvZzg4OC9nOC9nMTU0XT4+
CmVuZG9iagoyMyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1FFR01KTytI
ZWx2ZXRpY2EtT2JsaXF1ZS9Gb250QkJveFswIDAgMTAwMCAxMDAwXS9GbGFncyA2NTU2OQovQXNj
ZW50IDAKL0NhcEhlaWdodCAwCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0F2
Z1dpZHRoIDI3OAovTWF4V2lkdGggMjc4Ci9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9zcGFj
ZSkvRm9udEZpbGUzIDU4IDAgUj4+CmVuZG9iago1OCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNv
ZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAyNDc+PnN0cmVhbQp4nGNkYGFiYGRkFPJIzSlLLclM
TtT1T8rJLCxNBYkq/5Bm/CHD9EOWWZbBZ84b3m4e5m4elnnfJwh9bxH83sj/vU6AgZmRsWLKQuf8
gsqizPSMEgWN0KBwTW1tHYSIoaWlpUJSJUxGwSW1ODM9T0ENyChLzckvyE3NK7FWcAaqzsnJTFZI
z6ksyChWSExJSU0BaQtLzEnNVnDLzMksKMgvU9Bw1lQwMjAw1AUSRn6ZuUmlxQrBiXnFCj4KQanp
pTmJRQqeJYlAg1DkGBgYGBWAmIGJkZGF/fsqPiAqWfRjwfzvvvN9FrHd5HrMfXMCDw8DAwBhr1c3
CmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt
ZS9RRUdNSk8rQ291cmllci9Gb250QkJveFswIDAgMTAwMCAxMDAwXS9GbGFncyA2NTU2OQovQXNj
ZW50IDAKL0NhcEhlaWdodCAwCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0F2
Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAwCi9NaXNzaW5nV2lkdGggNjAwCi9DaGFyU2V0KC9zcGFj
ZSkvRm9udEZpbGUzIDU5IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNv
ZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAyMzU+PnN0cmVhbQp4nGNkYGFiYGRk5HDOLy3KTC0C
sdV+SDP+kGH6Icssy+Bgksfbw8PYzcPczcOy4HuT0Pcywe/F/N8LBBiYGRkremc55xdUFmWmZ5Qo
aIQGhWtqa+sgRAwtLS0VkiphMgouqcWZ6XkKakBGWWpOfkFual6JtYIzUHVOTmayQnpOZUFGsUJi
SkpqCkhbWGJOaraCW2ZOZkFBfpmChrOmgpGBgaEukDDyy8xNKi1W8M3Py1fwUQhKTS/NSSxCEWRg
YGBUAGIGJkZGFvYfb/iAqHz+D9P534Xmz5/Pto1rC/c2Hp4tPLwMDAB+alBjCmVuZHN0cmVhbQpl
bmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9RRUdNSk8rSGVs
dmV0aWNhLUJvbGQvRm9udEJCb3hbMCAwIDEwMDAgMTAwMF0vRmxhZ3MgNjU1NjkKL0FzY2VudCAw
Ci9DYXBIZWlnaHQgMAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9BdmdXaWR0
aCAyNzgKL01heFdpZHRoIDI3OAovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvc3BhY2UpL0Zv
bnRGaWxlMyA2MCAwIFI+PgplbmRvYmoKNjAgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9T
dWJ0eXBlL1R5cGUxQy9MZW5ndGggMjQxPj5zdHJlYW0KeJxjZGBhYmBkZOT3SM0pSy3JTE7UdcrP
SQEJKf+QZvwhw/RDllmWwWfOC95uHuZuHpZl35uFvpcLfi/h/14owMDMyFjRNd05v6CyKDM9o0RB
IzQoXFNbWwchYmhpaamQVAmTUXBJLc5Mz1NQAzLKUnPyC3JT80qsFZyBqnNyMpMV0nMqCzKKFRJT
UlJTQNrCEnNSsxXcMnMyCwryyxQ0nDUVjAwMDHWBhJFfZm5SabFCcGJesYKPAsjZKCIMDAyMCkDM
wMTIyML+fRUfEJUs+rFh/nfb+dGL2L5zcX1X5P7ONYWH57viVB5eBgYACdZUNwplbmRzdHJlYW0K
ZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSFdOREpSK0x1
Y2lkYUNvbnNvbGUvRm9udEJCb3hbMCAtMjA1IDYwMiA3ODNdL0ZsYWdzIDYKL0FzY2VudCA3ODMK
L0NhcEhlaWdodCA2NDEKL0Rlc2NlbnQgLTIwNQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQ0Ci9N
aXNzaW5nV2lkdGggNjAyCi9YSGVpZ2h0IDU0MQovRm9udEZpbGUyIDYxIDAgUj4+CmVuZG9iago2
MSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMTMxMjAvTGVuZ3RoIDgzODM+
PnN0cmVhbQp4nO16e3wTVfr3c86ZaybJTCZN0rRAWkq5FbaFUq6RjtKC3Cs3LRAVsWhBBAQqF1+o
IIhFBTSAsuuKN5RFQMHluq8itqhYVxbBl10r6oLL/nBZwF3FhWZ4nzNJafH1935+/+7nszmZyWSS
Oec5z+37fc4MEADwQDUwKBs5Or87OK9urXA3bvL0STOT3/MLAEj95Ko5WQOODa/BEw24/XPKzHum
/+KWwwx/O4LfW99z3/wpyf+zHgDta++tmHT32zP8AwAKFTzZ8148obUT38b/X8Dv7e6dPmdearw5
eO6B+2ZMnpT83ulHALHn9EnzZgp9ySUAmoYns+6fNL0i+XtBI/8+c8bsOcnv3f/qfH+gYmbw+JB7
8P84PtgAV7/G7Qxun4tMbCv0F8aJH4jnpDypxJ5rT4Q6OApx2CuVwfarqZf4AZyUSshNV/+HL3gM
XkgdHYZLYg/YCq/DfngN9gm5ECYvwUnoDpdoBNaRmbAQJtNN9LR9AlaQjuRGPPsK9IVNsJVWwluQ
h9dOtPfCQzAMZsAi2AuPwmnYAovpBqkELpGOwkb6MAyhf2IMe76RdIRLsAJeo5JdhjP4GCphLcx7
M6J3ycmqqSktuy07O7O0pLxrl6GjbistyczOLu/KVYX2lsrsMgDhU/5VOMrPXPci/AzdAPOgDZSC
CBQMCMI6/OVTnCUDYg3McN0dGT8sJ1Ks5ER0b07E486JaK78iEvyREQhN8JofkRVohEC+RFZyo9M
vmu8HpvwlX77vK/0eRPG6MPNjfoN5h6SZfXTo+YFvV/fr/TRpj9yixGOlBgb9QcCR/W7jDv1O4yv
9Nvwcxx+jsGtP259jbf0XvjZvZBfr+uFxhI9gN/9uPmMPcSyMnXT+LVumGZEbzWz1czW1a2FiDRD
el5i3clechWUoaNve4O8QZ4sX/YEP6xuXT57Nsn7f1/wM+fyUA+Uq4wdFXEHMkC2L9uXizsC9Gji
fjoqsU2EK2AJ1ahLUm6fEG6Q8jDGOljpmXKaJ09u5xE8w2GYPFxye+ShLoN5jZPnElEoThQnYt0K
SDvwGZAbEPiHKNxg77cnkedJqX3F/gvJIKJ9oh31kPlkHvW0W1FkT7J3YruzCK0Wt0+wec5Y+Vab
XkDS5ExPOznPGc6Nww3ryEjLEWNNQ8b8ycGKkkPHyUDya+x4PxFJhn3GvizltUv8w37UXpH4Bw6J
wowgw8jGIu4r49CHFqKva9DdCsjMdFEqglgMgqxqpkAh6Da4jkuryj9Lr48m6nGaxT6zT340Ee1W
gEoryvYV+rID2T7axu5NPlhLPrj2sdbuzTV43H6HJtDbVehqmRaMlEaIoIwYCNVCOzHoqs5w+h/A
+8/4ICNalUiH4nOJDNRjUc9ikoN9G+T4FJ+wkHS035nsfakr6bjTHo+SH6URAehOtKG5m5hQxkQQ
jM+Mz1Ap3Qr8RdmBo+wXNBKPOzKg0bkMDCKWZpERaPkREBRaDp7A6zKcKfnIcQzvjhjmOMpQtP8K
tAnGrOWGYdTNbgGR3EJxqAS+URvdClSSQ4QVjfe+wp6R8n7cKo/GmJtx9XNhsngO9eqHflbnIqlE
oqLbZQTcGUauu7Ox3P2YobhNEA1T0lSf1/QZrIBRlmZ8FjvXkLhmWbEtN2lhd77vkOUzsnGjlWfs
c8R/5gzx2+fOcEntE7lkE7mbTCav2BPs5+xf2ePjtIrOSTyeqOGz2ItWjqM0KvSwQmNFIjBRklFp
Ao4tGxT1GHQ127khaiQacGaJqHHgyAGUohCtLBbloi32kpX2XFpGVsaFxeUL9l5+NY69v4bqvIS9
h2GmVVLFqoTlbLkgBNJ8IYFJpEeoJDQmdHdoTuiRkNR00ieBl4RQANX0aqEwCU+VFkg1EvP5JI1k
GCdrGxKxWvQzRw9RPOhD+I5vMbh2xCVDJ+lZ1KN9Tlu5qGdh92AgTdKJJGcHXlvwXfmeJ6pWHdrz
xkeXHlgx5q/5NLb1bxfKd+97cNW920Z88du5v1888kTdVpT/LNoqU/w7tIPxVp82mkszXa5wDjNz
xDQzrA1sM67Nh23+q43QRnK5XBIMzBovlfumSgulBb4an5zlk1r5fEHI5UKfO5aI8ejALRmc/Avf
dSvoVRQs7M4lzSNFeNDreqFFwZcm5LQ9++F9y19+7607+yyd333kovvWv/bSq4e+tL8nve1vv31K
3jbwleXrXnwyu9uIhfc8eMvWPjuf//GhafYXH3/H/Q0tjOgILsweZVaX8Z5pnoWelZg6BMltqoSA
AILg0rQKbba2RBM0pkguv+BmEPQ2G/730QON0QbjQKw5yA1ufx7npNBXGMjxEYz0E4n1tHJvXV3i
EfIeWbmJrW+8NY5eEaEbeax5UZsSShKEvlYrxdQHeZgZED0Bt2uINF6iHtMn6Sa4gqHmcWvR42tx
0MbihFHVkI7xm5vUlpHdVnaySxYE0iCnLfFunrLgOXtEbiHdlbhAJFJg/+3IXGXzTf/7aTJUoAdf
t6vtH08dtv+JGnnRicC/QwCyYazVw8WI1MpUlDRv0PSKzEzTMvyd/T0jw/Qh4Yn6+HBVZHlEJZox
I7w4TMMRCW3atlnCxIGGmCNik025WkgALUh9aEHTkY5ijGZ3Z92TpkVfDwrmm5X765d+su07+/JH
F6+SKJEX/Pb+lWvnL1jzK3HX5uH2Afvzt+1/HDxl/4lUk/vIDLLn8sP74i+8v23N6x+hZ36IVi1F
XWrQ08oAQRH9kus2YaqwQKgRBEFRRK0ExJYp+hiqz0hasPEApqbs/sRPMEkHZGAkbE49QIoSxeyh
Ajunx8ZGMppm7d1U1thgj8L8thH1NQKjOA0i0Bm2W/Pby4QDpNvUImlyoHOWktt5QuQe1z1ZFZ2r
MhbkLs+oyTU6Z7mYpyMEIqw1HRgakjUuVN56VOeKUGXr+7LmeqpCyzzLQ+6Wf6IdW3sEQ8wwDTHX
FLW2fmWUp6OfjvJ7jNYhw/ATfzDPmc5APh2eCo3v+Tul+RDPA6E+fON5IHWEeZK0L+qRCqU2JMBj
qX2Rkctt4ERdPrlmlBD57eEz7+760E7sfNy+cPTjq2TR755bPOvZv9B3F1ZUzH+ftY8f2Hz41Wf+
/Nx9+5fsu3hqF3HdtmFb9fMrKl567OyCFyfOmFr++Dz0r7Wor7GoL+5fI6186Zp/oW+J6GOaz5/t
7xu5SR8YHqWPCy+I1ERUny8iQdjQUq7lzPFcbcOBxE88y0kWGCjoU0U9gB+iZ7X1t702n/Z/2XfX
3vqlR7ZdJNJHF227zr4yd9v9j6+bP/+p5/TNg5FetnubeN49RdrbD9txe419s7ho39MvHtq2ZstH
yH8cPBT6O/ynq5VmwQiiiCMEymSERoEIQSUFjUkrRFPshqMyx8cURtonSEcW5J+NZ5N4ScGN19eJ
vF8XPGgNVMVO6gA6yDWBjKMVdC5dRlVVFFyCIsmySzAQ8GQDk4aqmKLkQkiiRBLwUooHhAqywIC5
QeOwzg19Q35DugMK0WIHE3iCkkUjIfP3sVq+EQ4KpJDksGzmz2ZucrmOXP7D/MSuhbvIsW9FdjlB
brTfIcdpBWd/HBdvQ2m9mK0iELP69JOLWw+VR7YeK41RKqQpiiLr5urIxgiNRIg3YBIp3fTC/MzH
zMcymeAzVV8m6CHk11mOtkqcVFFrODhwzaKxBKZ/EkOalOVLk2TM9LIX5SvMcsDA14QKe8mvycFf
riQVlSXb3n27lDy54YuJO957+uInN4vM/uyBV3IG2z88M65PLj1xcvqwxtyyaQ89hRliytWvhaVI
EgLQ22qTycIyJlhF9puUCEapMdZgGsd/wycGg81Z4lxDLJXLuGC5Uk4WOKkrxBMaz7SF3XsJSw9t
t39v15A5pMtvDh56/X37Kml7umZ/x0GYpfJIPpnX97cT7IY/n7ZP3ox2X4KaXIaaVMGEoVbXJwwi
UQxQKrlMgLCQ4e0kdPJWeud7JcGH0O91GflQAGVog6D/uniPNWvumtYMrrAOhVk9fQYqaglZSqtX
3nr12GOTScb5E43PiCzxjH3qjRl3xL8iCnGf4TNGZxQqUR4NbrBaiaYyUAEioP1UFEdCpYiq8Tz+
Ld3dbLgYol1DbUPT6FX5HIiS5Da5nWCTE3fR3okPaL3I4vbCuN2fs0us40BY4cy9mxXAsRREWxwK
B6J8HEhxqwFN3uFwKyfWW/Z/ia1J9KCTE8/xvgfGE19iz8PRupVo3TCMsoqWyCTTHw7Rgeo4lXpN
jyfdZGa6rJomEaWxEtUMD1qaGJKvLHBnoDqwMSAEMhw6Gautb5lhOHTFIEZaWNuXgxTvmh8I5Sl7
f1048iLZ9eFb9mf2SscRhL86Rj9lf+Emo+OJ1y3yAHJldAauB1SG0N/ReZEVwlLCRZAqSwqAbAgK
MM1oqiYcW3NtRxNNsZzUBWoDNyT9vngdjRw6lPgabfsJ7XY5QfsnDvIxtuIYuc4YUSuiCJg2VOSx
IGuqynks1rpvwAE4gnVvyrSDHNPWIqtA46IOavGdZLQcFrnqt2KR9yqbZ79KyuPs83i8Mdex6kmH
UTHsKctyE4nhKAIzIF1q9phzjrOkBA+crKM7RXZljXP17fjv2Xi1DlOsG8eyuYx6mItpRNOAJJUi
UhcL0jDL1Yq0eexxt+Jxay7KRFnR5UJF774aNuJcjiBxCxrXI2IS/Ypri2uTXNNBQJQB0x5XXg6W
Izm+28+RDEoCl16g9peb7K+oyBrPsuDlhDC88SDrcOXwNXvJqMuJVrcSNobdzeawlarI/Iqiqn5K
GVMVKlIuLX5qUiErEIkIqlYIoZaWRJ+O1XLfak7NsuCkZWiSjJsVpYrvo8PpC7sS23GejRPYC5cT
7PXGMZg/+qOnx9HTNQhBiZUX0DMCuXrnQIU+NTBXXxBQAibDVKwSyQcmMd2+xbAKdcMgPb2Flc8d
i51rqpz8TVUT+rg/zUQMLepBEU/7k662jduntm1/enTnpk1vvbVp0066BJU33X7a/tiut58m00mP
Rvs88TVeIT77PMe106n8xuu5m6xcUejpLfWWG5XGfGOlgRyJO7uZDHqfDm7u62nXR32iRdTztNY9
hGRFyM4Jk8IsHweA0+SFL+84aL9vn1u9kKxe/0atyDqOuXD4L3aYLiTpVVNQij0oxU4Hr0LwgjW9
JkAM1XAZmuHOUrNcWVqWu0AtcBVoBW5LtVxY6roNQRVdISlNDbh6qEN9E3xV6hzXcvUR12HVo+KV
mltSPUQ33Z5BmD2COAMEDLemMpfXFZZ8+UjIQPfibNKvR7hYIgnJ3A1T2TLqeADH4yiJzWoxScR1
tD3OM4V0e8g9X926b/lz5NB5e9qOe5/f9/jv5ossd/h7y3cOT+yhwcRZuuXxB2eM4nH0MvoFL4Lb
Qo11a3ftJu2uIFJfMdJB6ZNRYg7OGOcaZU4hUzOmZc7PWJi53PVYRk2m7lIVt5iRGWrTRgy5BT2b
mdlymqmTa+ehxN3fCJGQ2L+NL5TT7MnHOP5U1aY3VZh9rtHOa2ccsomZMwupWIQKDtXMLRKSc8sn
vyAOD2Xf/XGz/f3djy6aR0L2qfOb7H8RaetT2+554ZG6Z789vlX4ZsuYtwaX53fpdNfZHccHvVc1
e9KQcf0KBm+o3sqXVzHfg7DXYVGjrWKJmgz9CkRDzBLLxGpxtbhRfEM8In4lugzRwlMzUycP4ElV
xIo+C+tBrMYIUKogeWqIzUoYx2KzuAfWppZt+JKNZPuFjbjNiMevrOHjPova7oPjmpBvhQaK40Sq
giSi5jRDoYaBkfcTtHZ4eS0Pt0JfkppioKfJUjYWQ8/WPbz6meWv95lvn714BtPP9/W7d/+BSYnQ
xcovEadNHM+L83wPx5NgmlVazUgum8mqGZNokLanPel4GCdNpgtgLpst1cCjzI2VgyhRgwBhfJVT
wLQs4cWY+CUBM5NC5CaqmN5EFWt5JZsiiRz1eDlLClUMdwq29wjZQF56zWYonsAaLyc4V8J+33Uy
92armgker6xIIogiEOS2mIBUpnnCLNPTSevsbqf31fq4u+tDYCAtlUo1FJiOlcZqU2EKrZAqtIVQ
RWdLc7UF7ge9c/WVsJwulZZpNe5l+i5hr2e39xvWQREU2a15JJHpALpbw/mpiosYLuLyEYNPJ5by
v+S7Tzg/P/367I8plhX6U43lYPvkndd+xfa+vYu+su7Tz96kOxCWPmOZjReFNoikFxM6r9N/Z58Q
cqU89LHWli6Y1C2ZMEyiY8UxoDQvaDqM34FJ8jtaaZfwy+TR8X8dd1BuCPbxqLM6lm35yTBwh1gH
dg9jcAsT6S0ktUgWS62SFRL2Z2eVjHfxI1952WqfYEFHhjaWLpmym5lkGAowlkkoQzSRgGYhHMRm
wcR6FKGEr7PFpTy++gRX7xOO8gVd8O9GbBCcdcCoEQUjihcG0NOFo/F4HLPniqvnhF8L45Dpd4Rx
Vi+WZqR11LPSeusFaVbaAr1Gf1Z3KUPatqWmxzTVsNmmg0lZpThfpK2ChgpZ7Xy6OKiTUeUsWByo
TTTgxM4da0xm9aov0tG1kEtj4dmjXT/ScnnHCY1eIfyN+ZzEgQliwM4da98lXX5YMKVqy+6jez7Z
0rmvP8+cXPjUqH72tHvHPbx03W+WbP59bPZdd24e+vKHdp+7BrmqskiQmJ+PvBPnsvXqGWEyas4L
6TDCyn8r/b30Y+mn0wXiDt4gqj5TYx6gg5UhaeXK+LSpaaLim5FG0sDDdMzl4RYLG9GokeTcH3BN
F+McQhjCzpqGgXjZQfYnV2JwMlvrVh3be7yxfvuCbt0eW7Zk1TevPu2WeiUGnbZP/WB/Z++IP0oy
49/8nlQf4b7xEko4ErUdgEIrE4sSFYsSFjTaGz2MRwxBK0iWJen/TVnyk6IkWfj2EkZu32aftj9G
xul9ffu7K3Z89Md3Vu3MiSIHNYhGuvR4pfSr9+q+HMARezGOX5TS0I1WpzBplV6isXQCbjcWbirQ
4A2MefGy9NK0sWk0zQeSIVEpzBlzrCEadVIbvg1nCTS7yCnGDSQSXD/MkclAkdjM1cf2OEqpq6t5
xFFK/TekzQ/ES4bHaeW/jrNfxE9/Yj98hMv0BMo0BHXic6yWt85HTBOBlypB1I+O+sn19PSUesZ6
FqRVq5Lp94Db5/eglsIt1gsaErUt1xeTdUqqiksuFgSyzezuvUg2t5okDPl4i/1X+1OS/eXXxxOt
gmTe828nMqn7+6qn80pIFnEnyEC03qlie9UwsrcVaf+bJi7/plSC1hth/YJrJkuaKVVLYho1fawY
zYnupRn+Mv8iuUYW/OBDbxHyeUUVbFFRRes5y4/VcuApxmI9tZaY7WBk0rCtCU8vPK2Qjse+27jq
qSfXz6dy4l9sTXz26Q/yflU4e/WKeOMMrr2F9kShp3AromM7lKpoHSFhqVVGqcFam17Vp+TcoFAs
iPRhQmnWbcLYrIrg7KDkN0TJyMjyAWiGRrVctG79uYba2qYll+LUDZReQWRhvZptXFTIa3XEMeK7
5n7HAm8+Q6LqQ9/u+9z+6PkNe3sPX2hf3kA+X/bkw6sXzdpur900lHSt/ZpkXkCKP2jtQ42//PT4
qKUsl2xZ99XhLe+icnahVtuiT/pgkJU7W1gqUMMS7pSI2xuVVBdQJHNDQPAZBnySZLdmc3Tw8pQv
jjqMq9jIOJHxQZJc+wI9C7PCSK6djOPbVbfiLCmqGxmLvyjl2f760/aaRJi+uXja8URfrkWsoJyc
izwe2lsBubfUBwmGAlTqrYoG5cZ3GSdj9YljDmPlwZi8z8OKCgO0N1/+P3mJ/SZ+5aDY4xK/uQtx
O8YWYY86cuNCq802Qny9/X0UU1WY6dXBQ4zefiTECkhESuNd875T6neoenKx1xkkDU1AcKD4hvWL
YnYJffj9Pz5Jyi7Za14ZuPh1tireKCb+S/o/fFwCx1GbL+O4LlhmqQj+30pnZSrtufo3KyqJkswE
SVZUhzIohozfEboFRRQU4pZxuoKkMNlVhrShRJfzZSoDkl6s77SWRLcW/aWqNpaepLrHaos56oaa
+AR+RGXFiJLevKKexW3BqUU28R2vIx8ct0fTDPsHG6S8Rg9yrVBiC188SFWxKRu0tgzUvhuoo3oD
tSlhwNQ7qm9SPC2zY7RSXI+oi9fGcNZVDopVWoNnuom/n8uV2U9UiaKHgHr76jrJ14v1xfoqXdBB
CfbVQyQ/tDhEQ8Ai6AEkCwrAgjKYCdWQLDIR23Ces5xYbdqjm+Fsz0WNRNLLAjxiC5Nw1uRqyU9J
9sW2Lp79dGf53senTNya0e726VszOnSenSf0rz99+vTaTY3fMH+5dT4xgJ6fOfSxKYnSpkjAWRg8
EuawRxjVLXanSBRPVOTJWTHUIcCM5kjwtYyE2p+PhP82ELgkLcOAQiVm4kocn9ebltV1lDxKo0Xu
vmape4gZo6MEyTQl1W0CU32gEz3g3J4rYxuZwNKTayrX7tGR62/StVj+p5XnsYo0/36eV5Hnn9y4
8UncwgheaCySb//B/tG+ZP8hfvJQ3cmTdYdO8ljaac915OKoNcTK87OhHsoRnSgc08HbBOlCC0A3
eNoNX5cpmkC9KcH5kwZMYXqYXMP0ndcwPYXo9lzxw/priJ64TDekIJ3CDJQtF2XTMQP3sdplhks8
ozzMNDVVV0I3iAwhz2CecGlgbICiwhSiZLQA0yZRCLpNc54t7NUMpUJuXROWSpHcFJgK/S/3orde
Q9SH7AspOCWkB1+hcXxogNX2AbYs5UOq29EXZtN8FAE44+EK8jWX485KX4wvwxWfa2jyn+yUj/ty
ipJOTXrUrUuUz4p3aTdrS4x7UNiuX++qXJS4Abvbj/4TwbGx0rJupG5Pa9PduvUQdbxaEZ4brlGX
hV3h9FZBRZU0LSi1EiJeP2IUMyNshUSafvG16i9BsL+Wnt1iSak2Ce+pW50/LT9jzTcS81O3PJr4
UYTwGx+o2f3fvDrvuf2fXvqy/tnD771w38NP/2vFg/Zn+7vsmDxpyB3R0rLD8RfzN/YbcdMthbcW
LJu6YTfOZgnOZoSoYyz0t7J0nFi+UCwIumy6lWKXFEBi4gXRbRiqLKYWXJoeCIgmV9WKU+ie5L8O
xBcGOLCnBUMOcRsRr7m4zb5I9EPkazsSal+yZOF8krH1InXHz56NJ47FBmZ0bYWSvIGStBL6o01v
tjo8zkgyK1DMCsxQFPQvTG8RfaS+XWe6y/hEJvJ1mQHjclZyUbE5MaDDIXnDxJAsUXv5hFZ1K761
6+tG3M4zw5WDyNdm0jOJkdXTPqOHUIb+/G45yiDBdOvm5LoYL0vFfsJAOkGYD/OFlbBMWkuV68tR
KhCFl6MznWOnIuXl+UyRNRWmTiWXH2v42cK0ZV3a/zCpJHO2292F/o0b2JQrB7FL584KSqXDK9ai
aon8pDSl6PKa16UHpUw5rOVCe9qedVbytE7uIujJ+ij9sFAdBiXSAG0iTBBHa9OwRL1bewjmYoG6
QK3S5rsfg2V0OatRlzsFantelnqxLhWuL0ybqtKWXpny1Z8sSP6kJj16aNdq+u47u9nG9X88+A79
FKe2jZ5v/CebceUg69J4DFLYtgTnqMFha11AyHBRkalqgGWKYTWg5bI8sZNaxPqJfdRSNlQcrI5l
E8RydSqpYNPECrlSrdAWkLnsf4lz5QXqA1oNWcaeEJfJNeoS7Rs5l7g0l0pVWRBE1VCYwgyKShNk
l0BBUTUkQCKjCnEJsqBqTNRUARmLoWQpBfhnD+WwScGNVuSkoLbp5iPHyVq+NfOCc0o0Khu4S5qV
G9V556gkRuL2/ZdIF+J/z15FfvmD/aH9Cc2lYXsGWZP4a+JP5Hl7EuphLGbaXzq2nmTdoCJ7kSW3
KgF/ZMOruDQmKz3dg12l7nLXWPdUcZproWuue6XLpbhUSXRLmlygEe1mH8gDDada5btYatU4FHWq
huRCnRDl7AvTSTFJ+p6X5DxZNnNK725273oymUx5M/GFteNle2785gfvFbyNn7KuV3qtmoUSrkBL
DUEJVZhoRYJEMVF9zBSUoKzyI6Ra+aSAlBFGUnc/eO0SS69tqE0uY+Cp38omoaZkJIwElGMOQcGi
eHqHHCZ7rjb2Jr3L+Tq9c/caa4QV9P3EKLY+0Zv+Kc6C8XjjWb4CQSP2CbrTWYFItzwwjLiZaSCv
oSAYDkQX8/gv9NFIPLXowGWnEWEI3ZB8cujmn3lyaAU7SCMLFzpPDuFhAvtXINcKWNIIYSS4MfRG
gJwlF8hMVqszjGOxxAG+WuLcHw1IciHmP4MmZrgX2iekvMmeP9gn3iKvXN9bjuW3YCQmXbc8ArOH
kCVQgffVEDvgVJ6pJ6B6pR6Awr5IR3ZwsvcIf/xpAn/OL/CzbSgsw7YL/gw/kgDpRuaRV6lMK+k2
+h0mshrkXNXC1pZNFMQKcbN4UeogjZG2SF/IptO6yUvlD5WwMhHbcbVMfVytdXldS1LtZVet6y/Y
rriuaJO0Hdp37qh7jftzT9SzyPOq55TX8t7ufRdp03D9l/opI9tYYXzs033jffVmmfmC+Q22q/8O
zR9Itaj/rv+0/7T/tH/v5jwfTVNPTKdh/uePS2fgxm+vsF5Dbx48auT4YbcMuXXcoNsGji0pG11U
mO9rp3foXt561+7S2IS+Izq375TWZfhELeTulmuYdxQHgunhjMyOO/xjWnl79inI62/1vgn+PV8C
7HD2AtfPhcFXr+Ke8D3whwf5+novRJebYTCMgpEwHobBLTAEboVxMAhug4EwFkqgDEZDERRCPvig
HbKXDtAdob014tFuKEV2NwH6wgjoDO2hE+q/CwyHiU4F7oZukIuc34Q7oBhRLIjVbxgyIBM6olR+
GAOtsCLuCX2Qg+UhP7egN9zkSIa8AxsgV/cCDJs7ufLuSVkDZtw/e8Z9FXweZDWIoPwPNfCT/12A
C1evO5F60l44SpIP2f/kRcohjm0cOQ5HcRsKM2AvvAZnYQbxwovwIWyEteR4y4bz3gtTYAmcgEuo
izhsddpJuB2P+8NpbHvgZdTEszg7I9nI71Dr/F/8tQI/X4LF8AT+fyFqeSt+Hsd9DI8rYSeO3AP2
Y/9vYG9uPDsWr0D28+/QuKS8OXqCZKz+f16OOSx4843t++7Qo9+DljTmZt+C1vzzzfv1ZQB2mXBU
KsOv7ibz/V8XVvlfCmVuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3Jp
cHRvci9Gb250TmFtZS9IWEpDRUQrU3ltYm9sL0ZvbnRCQm94WzAgMCA0MTAgNTE4XS9GbGFncyA2
NTU2OAovQXNjZW50IDUxOAovQ2FwSGVpZ2h0IDUxOAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAw
Ci9TdGVtViA2MQovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgvYnVsbGV0KS9Gb250RmlsZTMg
NjIgMCBSPj4KZW5kb2JqCjYyIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9U
eXBlMUMvTGVuZ3RoIDQyND4+c3RyZWFtCnicjZHNalNBFMdnkqigaf0AV7b0uCh+EC64EGm7kopB
CDU0lNKdk3vPTQYmM8PMCe0tuHVzxY27iNa3EF/Al0jfIbjqdOfchBqX7s7M//zP73xw1qgxzvmN
XjHqG1WFSXjAw1otrNXLMiRhcm2ddb59WQnrTVY262Wz8Tn8uhe+3w1fb4fJHVav/Kf8I/95sH8I
PZPTsXDYgl1jCycHQ4JnW1svoF9A1BPoIQINEXKpEHbfdo/e7LXhcXvvANqo0QkF3XFfyRQ6MkXt
8QnkxoFaPCA1OpMkjfYJvPQgwFtMZTThSYq2Elpg0Y2k9zEG6WHghCbMgAxInapxVuHjf240gXUm
6qOoxFJd48mnTlqCSOy+er3okYaCKq6XUQaTx8zMpOMRRv+VRkJqD4QnVHH6CJn0VokicmMp6+S8
hbGXerCkt8DhQLhMoZ/XrbaynA/+mVpYq4q518yz/vIleVR50iOhs1gJFkf00Fku/z+OwhjjPxgj
VuO88fDi02p4Fz6c8Yv3YXJ/c3vn0eZ0ezabTn/Pds6fbqxePj+7Xt4sbzH2BymryRgKZW5kc3Ry
ZWFtCmVuZG9iagoxOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1FFR01K
TytIZWx2ZXRpY2EvRm9udEJCb3hbMCAwIDEwMDAgMTAwMF0vRmxhZ3MgNjU1NjkKL0FzY2VudCAw
Ci9DYXBIZWlnaHQgMAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9BdmdXaWR0
aCAyNzgKL01heFdpZHRoIDI3OAovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvc3BhY2UpL0Zv
bnRGaWxlMyA2MyAwIFI+PgplbmRvYmoKNjMgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9T
dWJ0eXBlL1R5cGUxQy9MZW5ndGggMjM3Pj5zdHJlYW0KeJxjZGBhYmBkZOTySM0pSy3JTE4E8ZR/
SDP+kGH6Icssy+Az5xlvNw9zNw/Lou+NQt9LBb8X8X/PF2BgZmSs6J3lnF9QWZSZnlGioBEaFK6p
ra2DEDG0tLRUSKqEySi4pBZnpucpqAEZZak5+QW5qXkl1grOQNU5OZnJCuk5lQUZxQqJKSmpKSBt
YYk5qdkKbpk5mQUF+WUKGs6aCkYGBoa6QMLILzM3qbRYITgxr1jBRyEoNb00J7EIRZCBgYFRAYgZ
mBgZWdi/r+IDopJFPxbM/+4732cR202ue9w3J/DwPJjCw8vAAAAOilL3CmVuZHN0cmVhbQplbmRv
YmoKMjEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9RVFBKT1orQ2FtYnJp
YSxJdGFsaWMvRm9udEJCb3hbLTEzMCAtMjE4IDgxNSA3MDFdL0ZsYWdzIDQKL0FzY2VudCA3MDEK
L0NhcEhlaWdodCA3MDEKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTIyCi9N
aXNzaW5nV2lkdGggNjU4Ci9Gb250RmlsZTIgNjQgMCBSPj4KZW5kb2JqCjY0IDAgb2JqCjw8L0Zp
bHRlci9GbGF0ZURlY29kZQovTGVuZ3RoMSAyMTA2MC9MZW5ndGggOTM3Nj4+c3RyZWFtCnic7XwJ
fBvVnf+bebrv+7YsaSxbtmRLsnwpvia27DhxDtuxiWQ7iRTbiXOSkBASCIlpMAkOFEzJQcK2gULC
BihjKDRQ/pByLd0SttstlF4LpXSXHrShLW3ZJPL+3khy7BD+tIV++t/9R6P35l3z5r3v756RjSiE
kBKNIIw6Fi0OliP+0/wAZFcMrE9tzNSbTkH20sDWLa6KdzrKoPwjhGjXyo2r1m//zYmroXwOIcWs
Veu2r8yM1/0eIZ9teCg1+NaJ92FslwIaq4ahQZWSHkdIXQP1guH1W7ZlxsfIIn6x7sqBVKZeq0FI
zK1Pbdso+nfldhjfD42uDan1Q9n17SX1jVdu3pKpd/6Kr181tPHJbz3wcxi/AyG8VXgrkiEk7EEa
5Bf2IylCAjOUsx/8dKY8eWbyH0ieKSOU7iK58AASQulsbrToeqTB9ZNn6LeQZvLo5O+Rlm+uI1n6
ejTjk746V5Jkk4AHER1D44iMXYo2okVw7oEUQJ/0ee4TR1zq83/Qk4jjSxPoQXQ/+iJffhhm++q0
UYnseRHqRttQLzoKa1qJktCyCc2dGpWEcWE4ECTZVOsz6F30jwhRv6B+con77+Hv/Bz6EpqPhlCD
8LfC36I7YSVfQu1oN+Bw4fMqn79Bp9AqvrTzoplWoQWQt8GKCF43wio5dDvMuQddjQ5AfQ+6ClD9
MTqF1qEvoCOw/mfRvegGdAc6InqCp9rvhBNISc8CakqACltRU/qN9HOTZ9j48mVL+/t6E/Ge7q4F
89vnzW2b0xprbprNNjbU19XOitZUV1VWRMrDoWBZacBfUuwrKvQWMB63K9+Z57DbrBazyWjQ67Qa
tUqpkMukErFIKMA0hQKUhbM0x1vWcNbmJKdgYozGxSkWnlkQ5JDO7ma0rkgwUZodxQn9HNK3c4aO
+ARiaxKcyH/xkIUc9mp+64aLF9hdLZzAC19mXmqQ83XF3YzmdftUfwKu4WzNcbfbztFe+M6FLvjO
S7kGOU0HtLvtmZa5HOqIk3Ry8u0aaEQ17gTkXXHOmasmEpda5JMgJ6cuWuZCakwzobA2xzhkmECK
tzlkJMPO1ACt6jifHxaigRI/GwpylOG3HKXnKOMCWPLMW5DL3qq5BAYtg2uYlsHVgOhg8gKmZzKI
ul1jrrGuuDYCRX7R7dzLnfEJuayZaR6SQQPiG9CETA4tctIAU2ycoBQNFF+gFS2zJmgkUQJ8OrLc
FpLWcOy+JBSYGOAGPfoLPScnT90yvQvBZbmSPlPKLIITNXPizCJcqzk2xaF9ronAqbFbTmrQiqRf
McgMpvrjHE7BgAmEvS3D3ZyjvaMXmuBWkJLDLkLuGJ8R4rlahl1jUCdjk5AzMUL0Ge2Dw0NJwiZU
kolBn7Q5vsd9ys7p4NzCaf2cEoYpr33HjsdaLKtdpDo2tsfFHYXlTut1kxyYwAJLH2th4G4wWcua
JkKS4BTZeG6cO8gTh92XcnEjK9ZkeC91S47/3WMaTvEHN1AH6ANX8hdmoRxMriFLXpMi22xZ4xrb
N8Rv9RZ+a8CvrpY1MZLIhcD9qAeu7o23DDMtF24IG4cC9l58rdvNWf3kwrGxFrLE1CCsPrNk6Liw
fiITdj8F62nm2G7+hLp5GsAd2VQskW3KDugll5GeZCyRcGfoDkM5sXePsIxxjZEZxV7O4Ne4X4C+
U6WB9q54S8zO756jm+P171ns70G5vWOqmbLAmLHge/YMRu2LmfbODBcM57Jkd0aA6SnKw9DseH7W
0xb76Uy5P97KtCbHxloZV+tYcix1cnJkBePSMGMTCsXYxpakixd/Ctqf2mfnWm9JcJrkMDWLpxCZ
zkV4r7WrndN39hFStbqGUxnF0ci4a+xu7dSYjo/rzsoccD/IAJG5Mc2vYG0K0E52VytRNSdBQ9g5
TQ0RWVhQTxxkYoDnXz4DWVkMk9uJ1OCEt2X14ixYwJlZ5iE6sDPbCpO43USe9p1k0QqocCOd8Uzd
hVbYH0Vs0A90TJKeU7keYw/pGcn1TF2eZIBulvbFn8Df03l7TMvoXNEgjz+vege5U92wxz/VcJKa
LOn1zXFsp7Ml2o5JSeYHVVbHmf38hQQT0JhjGsb1bYbT+Dlhc/yUvS7h0mhB1VEwps1PJAg06reZ
b1JEjyKDhqPqOMpE2hHoVV69Y3MNdE4xkqtlLJnltOnbyhqDweFL7w3GaBjYnj0zXqtjyA5f4dVb
Vmt7W4lc2d2ZEfMSnIroZk71Kz6D9dqb4y7QRCC5nXzB1eIaJsTmXMkYrxIS9unNJyffSsaICoQl
kyH2LItDnoF2Jq+VBv5cRh8BRr/hlsTwLJiFLYEduCrhtry0dMezKNXYsxJF7jWXbGVm/xSKuTFA
fBA8NxeyfdMCjGqzvJe4FOTt3TNq027G99VMaYbuONfqz02eqc/x26dX2y7qnpvrBvVxvf1aYkZo
1DTBUHs7J1hq7+Le+JPg6Lr2dscfpSm6OdmUmCiAvviTLoRYvpUmraSRVFykgtopmO1RWsKPtz/J
IjTC9wr4Br4+cJJCfJsk10ahgZN0pk2Ta6OhTZBpY/m2jFfRYhkGCOIMEH2QYzviOxLDY8kEARuZ
MgwInM00II5mGiYoWqTgZMxQEydnmkh7I2lvzLSLSLuYaQL2B+FwEVEfSzIg/qCA48hOJQgLE3ah
va6Tk5OgQU+D5nVzIm8/JFCwUn/CBVw8D8bNISkJzXO4kYEUWQdhU0x0+dyBBCeZmhCGzOWkMIM0
OwOMaOWvIVYALhoAZk0xfBGaQThGElzCT24aX00mcLnAH2pjZnGiwsycwkJyo2BiTMeU8+ZE5OVk
3j3kJIW1EUXIt9ihCjdLZEASK2DlAwx0DSRdgLYADSwGZhQUkq/MnmkZAqsuKBzik8ye7UQZCZIr
ZZy0jNgqMV+Wl8GE8BUnEpnF87U92QFwbw0nhxUVToMyewGgA11zyVrguweWSoZ+g0zTeRJ1MdtA
Bsmi+ZnE0M0pvXNToHAy18uhhanJXQxzSfgmMscLmVYx2bmCd2i7T04eZ7a7p31KAwxY5zhhTGQH
H5JFibGLG7g+UJySi1uVfPPYmER56QsyeEmUU2dohCEQN4sPp6MISV86nzj/krQTbUHWyYMXwha8
jYzB34NYR4h2IDFIggYFSWxF3zQ5CXSh2M433zKZHd99DbLrdpjs1+2w/ut3oLz1GsjWb4Rs3ZWQ
rd1gsq/dsOsq25arDUbHqjWQrVwN2dCwwT40PLrJZt1surbZ6t4OCYzHY0ec7iicWdPdLibqel2h
ir7xDOXi5Moo+2IgDF2nHntMr+eHeM7Y86Jnx2l/7E97x/e+f2j80PvCk+9T0gHLwD8NYNeAUk2G
PTYn38sPLz7k8Uarv0gd2E/7LQeLS6Lmg5RmfyMb/f5+6r1f0H72FwZzlH3ZYCA3Yfsn4C43jwr9
I7to/w27KP/OXUL/ud20/6ZR7H9jF7Vr1Ju/d5Ty74F0IwzbDUkyKq1GzWxYqonaq42WKqOx0qir
MKojRkW5URo2ikJGHDSiMuNsPyWmJEhNCSkRUlGYEkCZomikQo0UBQlDEiIWzqRHCAQTIw0kF5Rd
cA5BTwjKISizkN6Eq2SUkl3X3OAuLFL5itTqkpCPLvGrAn61h1EVMGpnvsqVr0ZCjZBWa7QKqUyu
EIklCiwQKhBFK0R4MN+JfPlydbualqNaFMNb8IPoh2qRHMmxXF2LaqUJ3Cfdio+gI9K71N9Hiicp
FaVmdWo7lae0iG1Ko8as1AkMSvQMpUJBiuxFhW6jVGyhIFBXUuerK6wrqPPUueqcdfY6S52xTlen
rpPWiepwHarriHRTnK4dtXc3cXoKzoubuIi//SR2dXHl/nZO2tEXn6CozyeglaP3gvbu5gR7QWF3
Q1zQ2xc/SVlJ9ygwP2DBtSdHb034/XncIPEWRvISXDkp3J6XAL+uvJOzM03+iz+bM/mWq2fU/Zu5
khYu0JLifC1JrpCJ8WMuupTKnKY1oy2kRhq2ZEdnpuMsXCPs7eJ7T0jJJju6mojz284Nguvq7OhL
cjamCfxQqFV19IFL04TI45hnILtJ2I18KIBCqAKlWL3BoPKIRCoU8PtDKoslVMEGARvWHkIRTYSO
5Ml9CJX49YZyg1+OI6WlVaFI8LQuGtSZo6eDcERJhoJLT9t+bCPtp7XR4I9f1Ua1EaiEQ1RlRQNd
3YArKwoZj4oWM5VVVZFyJ200QEWFjUazkamktG4tSXS1yFRSYC60q2c3uEIFVmmy7ubm1oEGh7qg
LuAqNIp1t1Pnzotw6lwN9Z8mk7ekssgajESZ9i5DQbnzc86yvEhrcWFDfWupO1Dkc4g23HNP+h3B
4bMrBX/8r4dg2wijEkDgWWEPcqJSFEU/AVva3BNnmyp2YmzfxXq9tepoaVmgTBMow2oULS2N4ug4
W2qSlo77QoESUwkuGTexJuOxmAmXhaQhHBqXslLZsZgUWYJ+ZLNoFrzn16KIpXFaxQ99NlLUoShE
kOaIZs+pU1odFSWt0eB74ZCdLf1b3CwcSlAmE4GacQMNqvVVQIaianc5aRSJveWELmU04xFjbIqU
V5HuQobBu5YOtt/7ncPpZnlhoc1kOmEqq5BTvznweM/RL6Z/Mbyro9HrnLt80ZL2TeMLYwfvXxm5
MvU4/XXvzUtWffna8rDIHmoZwPTgrHAhDjde27/7+Qq/o6Z9ZYu/vdKMz//x/FrB/Ie2ze6tAjtx
/eQZwVHhEFDldJYSMr3ejpB8J2tHRPWGVMY20GEaaoTCKkz5RnxCLBxnfQKDBXoMan2+nlZhvXnE
rMKqcdasR5ZGsnuCxyvLly2N+i+qhiiCTiRImNPOP6v5G9wjQWGmkOd34HMe2OoIFokYT2FhZUV1
Ve4AQTAJjtYlJX1D3XfeuKJi7VXtG1eEkvUrnxnc8ZW4TGFzl1e1zJ7fem9f3xFhefr969YPfP1s
+uzqL99VujaZfsdhWfX8zW2x7oHrhtZ2zY8EK0yAKOHvl4G/w1R5FtFSnVarvk+jQTbGfZ+Hvo+l
PGCgi60ymxSOAC5W6ygj1rFSRZvOqiYWrAKKapnMiq3jrCxcIBsPhajwSDh0LBaWYuk4G8ZqN6XC
7oIC77FYgQ3bxtkCXRYUYD/NC4BCtkIwyXEk9Lzkhy/0AhWyUkBFgpEI6Q6+F9ECUYA0kbCdVf49
FkXIViZg3DhLMaaiDIM0uEFMoDZdggQvtySxxmArKkg/ddWzgdry/L7eHonS4PK+PEL5AvXlZeGS
VPzczTn5CZXLhT3p022dRXrJ+d9bauvTI9UVVpXo/LNKV6SjK31sSmrqg14cztLxCaBjiGrM0vHK
kuLiovt8Pgttu4+1Wi0WNfKEsJvWubFaXZxfHCz+UvEjxc8Wi4pDyKfxuXxHfZxPKMU+j4doDhZ5
AFGPWeYZl4aQVWN1WUest1uFKmwFzjYdi5nd2A3cjSVymfxYTEawyyiXC6ABSAQ3OGWhI6BqXsiQ
UwtfIB5BdRohu//eS0tQKiKEJrN4hgr8CKVphqG2iSUigy8sTw9NU3z4ppakQGUktH7lmq8HZpV7
+1JxoZ4pe4FinCX15nxGIwjP1Hrp03M6fUDptyyN89O9Da0OeYai+Me85dmXpWiR/T7W4XCJDEYs
VCuUimMxJUYOSokdTqcRG8edrBMdizn57WYVfI6RyfZDvC3R8VYEkHb8NVMkMphkQQGDLAZIwGAD
u1dmIJApgHmp2+WFbrvd+Pofmhe0NHlSQ+ceze24rMdJWDYsMfh6kufCtpat8fQ1JE4Av0G0B/Zb
j36Q3e9ClzvfXefOd9bXG8slYqlIajWbkNEmktrAEWgsJy8ZCt1wVODyemc+K9W15eeX0tSs2tpZ
x2JWdy1WabR+QWlZadmxWGmGC3TIHLU0RiK8vYvqomAYI5Ep9ZI1s+YIX54yuxHgVKgAaMynu0+C
ymAmEgGLTXFYNSMSiSkGY0Z0cVcWaL1wPlWbgfRBpaS0Up7emOG4UZtPlRetSUfXJ+2GwsKkVkY6
75VPp8XQVcKeLNx/qm1xlHpz7Ef3XbO3amDpeS39a0p59ivp+fPnuS70Ytq/0EdIda4qQx3hnUCd
KnQsS51okUJSUlbqD/pFYn9QUFJSk6dWKTRyOPJxnlxR4hdYqMoq7C0sBA1biE0Si9ViPRaz5ACK
RnNAgW8YmnJ0ciTIqnst0QqOv3i6BMUDzVCFRYyI/hhYKZM5UqWbqgvvzED8y73pH1X6lKIqZ1yq
+CiejZQkmi+XRC2tYjWvqDPgnn0N9x6+K5L+yc3pTSULCy4F5AcPbKmnHGuoWndvIa+3abRj8jeC
74FHo0N+tCyLrFWwU68vde9kldICXDDOSvWIyCZ5SJH1JDInghmcifIEjDSfMDhB8W4cTQsyfoWu
gaY04MqJcgfvemQ8Ddyy4/HUmm+m07fe8rUr5u565A1q4ZtVoZpINDzLX2q3bdrY2znYcUXQIRxK
vnD7kfT16Z/dvO4bu3dRtelH+9NbqXKdyR+e37t5277RdXffVd18xz+8PQp7JTbqVuAhBmKJr2X3
WiHcyRYXlztCckVQocgLYodcmt2IlDEFS5lSXDrOsIznWIzBBrPJDM7tBX0+zY/VEhmzZcqhj3jN
RHQ/i4kBRBKLEN+sCF/KUFCgDXmvGHxk+ufX3DUQ/vzvTqyMsVKx8COWgqK2719eUbehpyG2V9jj
XbB14YEfDQvSPygORAyXsBLn55Svvv2KnhXF+Py9gGb35Pv43/FpZEcRdE8WzWC+UoHkDho7sFxe
Wbyb1QONkcfqwZ79rFWjVAQ0ARw4yGpMMunxmMzIq/kMf8DuIlMl0FwZx1c3pQwBQedfP1mCqjZf
kMEi3reFSA+Mhwnz0gfOryDn+8IXN/Wzd6lkZbOl6bcblcmHkhu2BxI7vpxs2OiQipoWlMxfOGeW
K9qc39xVEazW4X1NmvOJutnGYq8wfFZwy+eOHUh+4+EbF+alJ4rrmIVz7I0r7zi+aHiVo31u8+4E
YLdg8gx+Q3gAsAujU1nsCg27gRMjtEOlRAqwvQpMKyh+Z0ilDGj5rWo1EGW8xWqlyjbksfFA2EyU
iSZ7b8zt1z8dA4LIBfMyjR0Nn9XkiWpxEZXVYGCHzXyYADEcZjwZxMFAC3Lh9M/7WQqLtJEmxflZ
nDJ1omf99trVN9y2aFQtE7Z0VFyxoDFkrZ0dWnpVmzU8WyO4xrosr8RDV0jPxwSf23Ls4LofcJtq
qHWljY5Frb4FG249OHt4uP7WOzcT+71k8jd4O34FudC3sojO1mrzJeh+lys/X3Iji8yUAptdjhGH
AAv2sw6NlvV427QuteZKzS7NbRqBGrJJDdaDo2xQYuVB1mCaUmGa74ILsslmPe2/EEudBlwz/htx
I3knEnAt+0zvkKBIuCsCQXfSwJvV5izn6niUzWL6TdoY9A/ds1LtrQ/2jc6rX/bshvEDHYdfvbrj
mrIw/cr8mOee9Pf3lsyrym+ZVz+cfOi+tRR6LqlTvA1c2AVc+DmQYAdoxtezmDU4EDJpRwsKAqYb
WakhD+cdYNWGfAOdhw0GlUBVhIv2syoNYl3eNoDaccZBy7FDIIA45yAruGg7F3ZD7OOUtzvNbmij
vNcd/hvdKOFVAXxlNHmow3OlwJ3hyKpqb4OQZ0qRCJfN27u3a9FV7QUL7v7Bddu3p7+RfknRtbT/
QFe6pH/fYFOROlrTumfVP3Uu80US17Wt/eD5tSuGT5yoa129vGPxOUrvLquud9e3DD0IXJj+XXo2
fkB4N/grOUTd4DA47HaVSKTyeVEBUqtMyFSAVWrt8Zja92uv2kEe9QKjkDNrtzraHCSMdLhYqwu7
QNNRAggYD7ECx0yDmgkL/f7GBedf8Gcszp5TuRgVIpsXIQG0ss/2PgkzQbSo2sS73XqGmB7Ci2Yx
/wQBHElxRMykPdec2B5gzJayyuZoxPyt7Yqwz2rQV/74wRVziuKq0kC0I2qx/sz0H9qjT3fJ4hJH
4/YBPBoRavMqZ3/1cc2JaHnD9avXDyF68jbA823g0SBqQr/KIjonr8BZ4FAq5JXOgkowNDG9YDQQ
YMHaFLqkmrZCZwlyBYOaEmeexhG1RnE0Yy5CGgjeiLkoEWPxfrbkon1ebDOIPANfwSnHsFkhzxik
jD9e9re6I8E5ozvpmebKTAyZmPeYgBKuygpg5fLc80piwlbqbfJ16wdu7G8pUKWOJddvnzW8+45F
jRuj/eywXGELOjxl/q1HVqdvirVTqyJDm9nSnD2ru8JcWpLX3tI6/tqjePTa+w5d+cZXNtc4C5o0
aX954+5fJVa1NPaU/aimP7K79dDYq/MvGDaifxeAzXoSbFoA3ZZ7kiP0eTBFlantCqXKplJpbFiN
AsCNyKiwS/IlWHKQzddYzMdjFmSjiJWZiUzE/1GvHDC3/YVzJNxufc7G08Ql5z2kGcYq65+bzPj+
9Es7VcZQtHhgw2x938MUJZcKeGv1kGLZiXhq0NAtkxj9Qepc9aaytvrYvl3x9CLBNeWlheqMnWoX
XH/V2tVsb/puf4U+36MVgp5dghAdEsYQRhZ0IItNyEIJkEBFQ/iLBVhJD7AbMaXGb2JajZdjWoqx
5QS4y8djJrVCfjymyHk3ROMt+BlRcJuW2t7jLfueTKQIyHj+2mkgWmGqcxiIs3DxENGhsomyVrnI
UBKSpv/5oFKmBS/y97XC2HPPnX0iEtQ4PTphmL53Vos5z6WhK6VZTqArgBOMaF52t3qKVmDwN42G
4zEjmuGuTTkosH7Vx49IUBFqan0ZChJv98Pa9Dl+cZL0yxQtkwhMxZUK4YGzg6Gwll+aYEcg4COv
hHAF8REginwTfIQm9Ex2ZY0u7EZwFGKPJyRVWMD4xEJ1wdpgsKIWh3BdPbaLilm2GBcfZFnNrBPR
aM3xWFQd8uj1uuMxvTHrsUdykDbaMjYoai6fYt4s6+pyUSWh1KebOQE4iS/w7gyyZbn8EpXpPI+f
pZY81L98wNCt5UlLuL68qii1ptnQ9/BmozpS5Uutm63re/iQUKstDiveqWlS9D+xNDlI/0kllly3
NcPjbSU8yFlpYG+8YWm6nTq3NOFqq5+9d3dvehH9oLnX6chX40pp+rzg5tH1KEMF/DxQIYD2Z6lQ
5hPO0BR60BQUkXLKaDth4aVbPU3c0UVOKEHnY5SF/S+f5mJ98VHwyMuILOr4kfSLuxTmcEVJas1c
wxRcP402K1Y80ZcaVEp4gKlz4a3BOQ2zbxhdPhOUc4Kx0bWrC3rcOTBBXywGT/YpwMeAPBdicvVu
h6PAuJsFJYIt+1lkkufj/P2sXIP+bzH5JwxOCD2ZJ/y8e0SYSUVTvH+kyzhHNHXXkQfVeqb01q+t
3vyFJmvB2LfTb/b1rzgU704MH0lov/Llus7VnUNfWBA/OJAYuvPVtVThhtUcVb9t3fqvpJ8G+/2n
dBd+B/biQTXo69m91Nh2s6HQLKmhusCD9AjJ9FgqER+PSeweV7ELBGI/6zJVGyLmCI4cZM0a/Qmt
VnM8plWjGbJwwXoSn69xOv2nBzrez2LqhHmacrzADbqpUKdI/5FY53WZkFdM3zqvz7HEk1/LxTvx
eTJhc1fkigUNYWstGxnY2qSfCFVkdVa8u26KPSh1NuyZRZVX1tgXzvHNX3fbwabVq1oO3ZnMSdNO
QNiBvprjFdn9rFQqkRh0tJ6Cw4wN6IRDg5XKk5Pvsg6DuQ1JNVLagKWiERHEIaxI47AfjznUBuOU
AT2dCUDIY2ptJAK4zHwFErQBtE98BrOCXhebpzmQWYnLqvfP17Uqlj+enBsOrZJ4CopWrqlUgYgZ
db6QHL/4B8HunfK3Kqo6btnaRoRqWZgHDTCZnITIRsdrmH/JxYLm+4G/jV50fyDg96tuyssrE9/k
dcvlNowCycDGwEhAoMCBYtDHGO9nizVqU76J1mGTTmfDtv2sblrEMfVqJrcZ8Ni05IFFRu7K+WiQ
jwmB/QKf6T0SVMbL5nmRfytKXMOi6oiJCC2PGol2MoDSd8o7e4LzA845bGph790r4ne1BReK+5Yk
Bp1sbeNCf9fBoft3ltH/1tvJNJd665v8s6/tWLabtRne6O9LzPXHGnz++X3Vi69l/a8Cn+0ETFWC
x5Bz6olFg9ButNMf2CkIGfV6iVFn0po0EqlUa8IStRaiba2OlYLXITX+mtWpEQmGkcuJsR3bD7J4
egiXi98gwsjtl5oRzwCuaOkm8uKZ+dQzQ1SYdaiz8UtE7Ba7cS4wpL/cdbR3zbBux355bUvQ5xyr
pupN6eeSvspI2VDdyYGhdasaF9IQ5XjrVyz741B6x70d9Y1z2gChUUDoffw0RNNXZxEqsCotKpVa
jy2WACUswC4VQiXHY0hts0okeUDB4zFzzs2JgERAQWN5gRe1XKBBHtX8eVcl9O6pBy4QmkU++ryr
Kveo+S6qdpfKGK7wD27kbbxIE2Tl6bdZZerx/tSgXNYtE4ca8NNpXHNl2ZyG5lt3LqEePd9jjztK
GEH4LG+ynJ0BaiBQoSstID/amfweaKFHYe9+9GwuSqPdArlNpkVaj1tgtcnMRWYaSm45lG0CmQly
MyoqKtWaabnVIzCi4hKc73LlH4+51BKpGRsNvC9onPY6Y8bTeoIQJJAK/uXIqUySnJJkc/6B4V8+
c4ISic1ODOoI8+EU4FdUVV1UhkHI9CTOIi/jHn3uu0u9gYKCIvmH+yyL5jmleYw8/VP9D7+7PK/A
7ffJPxwNxwtUrJzKw/v+5Z9/GF/s1YKXdIexvaei0GBzisLhX770ZmxOkRGH03tKkzUBS7WEvEUl
f4D0AXoXIgXtExSNuBFKhxp5Nz8SrgYX/YPIM5F3330XRl5BvYKfpTtgZB6rxhRNYURraPoMDUUU
PL10E28Og2HKDcu999xX8/B86pUbib24Eih1hXAI5aNNWUo5rTabzu5AOgdWm+y2kNUqsYtFUokU
S7/ESixoWoxKItRv6qL8+1P+9SkRSf2fdxH5dYdo6om1oDrnZInERWAERGI6pStJrVSfb1B391Z7
bIqjUqnTaFuzuog625Kn0VHuLsZXpMVz5wpUFk9NDf1aSbnGaY00dFDSq9ke4MEPYGe/hZ35p94R
Ba1pm00vE90vFnvGWL2+1C8rViqRyeYccZqw6TDrFIslIzIkARzvmrFqoisu6N+cgs++vYxmHgQQ
9Z73KeZLeHNv6slD52o+qCFwMJmfWvBuZuagW7zFNodZt3TeuTOyWV8/elOkL+lbHu/a7bvBv+kb
yRW3zXV5SpYsfOy/UkclaqevKP2j0PA7h3ZV9t+0pa67b0XvqVL/7M0ts9dWsolFR9/aDVygnzwj
oAGrcvRG7jdFSmlhYaA8jVDA6tmn1UrHAoEKqz1tY21WZWFRUSEuPMwWCUxFh0MhJBgRBHHwMCsQ
W22mEZMTOw+zJuu0J0ano9MeHk37iQ8vuTZN9p17Dkjy+6wooFn0Gd4oQVXnfrpFnkplf1d0wVjy
zMfkfuolElOS4o1Pr5y9ZUmk7Z591I4b23Y/M9L/neayzaINawY/v2jfvkH99qe2hFf0JHcEBAtO
BYudDanm/tu2VcnzDm1Y/MDW+mLnd1cm4yfWrlsXl7Rt2NHY1b9sGXjz44C0E5B2oWp0IvdkxOV2
iPf5fFH3eVaXX5CHSjAcR1iMCxx5dnsezjvC2sXKAlxwmFVaZzrtZHPTXgkBfhd8/vMv8a8r3Z9+
ygSV40Hi3RKfgufQgmqzWITE2JBFkH/iN3VQOxfeubD75k5m/tYvDfaOxgMKrav44OuUYNwrO5P+
x0TTlesXfW7ui57ZzU6XRiWTiUQSMf3tUHDugXVzvnBDqmb25sO9HYs2LNn0r8fX66vD2vRPz6a/
MD6+6qmrf6N0GIwalU5vtrKRzA93b8gdVBv1PvU+/Rp+5sIhqBIKhROiItGr/7sP8TqJSfKI5BFp
QkbJXpcPyH9IDoVP8UvldcqfqO5Q3aF2qF/SLNG8Rg7ttsvH5eP/sePWT3GcuHxcPv5/OHRm3cP6
FeQwKP8nHmCvafJ3NvAxgG9MPiuQCC3k/0LHg6+h3kF6tBsdQGPQK0W3Ix06CP3jaBTtQXfibWgv
3gFe9WF0G7oDfZ6mkRrtQzcjLboR7cfbkQYJIXYa5P9mQEDuc8YzOQk5RfJMXPWZ3APxs+lgLzSU
RAgC8+bU+hVXrU4F5m5JrVs9QO5N3Q4jJZf4XwuX+lw07gw6MzmjIYMZEsbQM7lEPQ/NkAQvohJB
J7qeT7dAufpjUhCViK5APuEy5BN8iHYINkHb5fQ/N1WiboEfLcDXoCV8egB10UvSvxeUTd4uaEAL
aD9aMpU8aIFoEC0RtEFSocWC6skPScJNcB1wL/082gl9o7mED02+cTldTpfT5XQ5fXyiDiHB3yOB
I3PF5XQ5XU6X0+X0vyTNQldO/gFiU3KQ/7iHPyFmJDEhRd82wT3y1HJ13QdIngkin/yPQ/XkfOpD
xazziXSDtFN8GOJUKR+rwue/AVNNek0KZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8L1R5cGUv
Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvWUJXQkpEK0NhbGlicmkvRm9udEJCb3hbLTIgLTE3OCA1
NjEgNjgwXS9GbGFncyA0Ci9Bc2NlbnQgNjgwCi9DYXBIZWlnaHQgNjgwCi9EZXNjZW50IC0xNzgK
L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDg0Ci9NaXNzaW5nV2lkdGggNTA2Ci9Gb250RmlsZTIgNjUg
MCBSPj4KZW5kb2JqCjY1IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovTGVuZ3RoMSAyNjIy
OC9MZW5ndGggMTA1MzM+PnN0cmVhbQp4nO19CXxU1dn+OXNn32cyM1kmyUwymUlCNshCFiAZskEI
AUIYTAKBhLALAgFkR9S6RakLat1Fq6KiMBm24IoWtdWiVq22tbXa1latKO5rku8599zDVmu/r//2
9339/5ibZ57nvPecM/e855z3vneCkVBCiIVsIRKZMrmloJDIr+m17K17addyXo5cgbebus9d5d+9
7cBX0L8lRGOcv3zB0s8/bzJDv0OIIWnBknXzef2iaYQk9iyc1zX3D5nuKkLmj4Zx5EIYLLtM0DY1
yhkLl65aq3zeLbBtXrKsu4uXJ/6UEP3hpV1rl2dRyYJzWTD6z+laOk+pz8qJy5etXMXL85PZ+eU9
85YPvffnN1F/PLo3EaK7jZDBbeTk1xSymKzEeLeQi8lWso08Tl4nc8iFUDeS7eQech+JkifIz8hr
5F/4GlynWUrM0gGiJXGEDH09dHTwHqBfYz3Jsg2lOLX/hGXIPvTBabYPBrcN2Qf7tU5ilNtaVC/B
+gkdGPpaVcXKQyNZWXUJtE1u8ZHutsHdgztO80EzaSczyEzSQTpJF8Y/lywki+CZs8kSspScI5fO
wbkFeJ+P0mzU6kYtpk/UWkaWAz1kFVlNzsWxHHqlUmLnVsjl1WQNjrVkHVlPNpCNZJPyvka2bMSZ
9XJ5LbCZnIeZOZ9cICvB3HIh+QG5CLN2CbmUXPa9pcuOq15yObkC8/xDcuXf1VtPKV2F42pyDdbD
teQ6cj25AeviZnLLadYfyfabyG3kdqwZdu46WG6XFTv7CHma7CO7yG6yX/ZlN7zGPSL8Ml/24XL4
YCNGeOFJV8z9t+a4tzZj7GxsvcpI18J+wUktzlX8yGpeiJq8Fz4PrJdNp3niKoyB6xMj4qXr5PGf
sJ7sle+zCn/ccpJnbpZLTJ1u/Xv6enIrduAdeGdeZepOaK5ul/XJ9tuO190ul39M7iJ3Yy52yEow
t9wDvYPci719P9lJHsBxQp+sOO8iD8ozFyV9JEb2kL2Yyf3kAOmX7d937rvsexR77LjlIHmIPIwV
8hg5hEjzJA5heRS2xxXrYdnGy0+Sn6DMavHS0+QZRKhnyXPk5+QF8hRKz8vvP0XpRfISeZm8Ri1Q
vyDv4n0AIOFxc2fP6pg5o72tNTKtZWrzlMmTmiY2TmgYP66+rramemy4qnLM6FEV5WWlI0sK8vNy
s0LBjEC6L8HlsNssJqNBr9Nq1JKKkty6QH2nPxrqjKpDgfHj81g50AVD10mGzqgfpvpT60T9nXI1
/6k1w6g5/7SaYV4zfLwmtftHk9F5uf66gD96pDbg76ftza3QW2sDbf7oUVk3yVodkgsWFNLS0MJf
l7Cw1h+lnf66aP25C3vrOmvRX5/JWBOomWfMyyV9RhOkCSqaFVjeR7MqqSxUWXUVfSqit7CPjUrB
uq650SnNrXW13rS0NtlGauS+otqaqE7uy7+IXTO53N+Xe6j3in47mdOZY54bmNs1szUqdaFRr1TX
23tJ1JETzQ7URrPX/ykBQ54XzQ3U1kVzAuiscerxD6BRTdAe8Pd+RnDxgaPvn2rpUizaoP0zwiQb
4nE34bzQBNeGK8T40tLYtVzeHyZzUIhuaW7lZT+Z442RcEFOW1TVyc4cEmfcEXZmizhzvHlnII1N
VV2n8nPuwoToljn+vFx4X/4J4gfn/VEp1DmneyHjrnm9gdpa7rdprdFwLUS4SxlrXd/wAtTv6sQg
FjE3NLdGCwLLo65ANa8Ag5/NwaKWVrmJ0izqqomSzm6lVbSgrpZdl7+ut7OWXyDrK9DcepAUDb3Z
V+z37ikixaSNXUfUU4NJCdX1ts6dH/V1eudifc73t3rTouE2uK8t0Dqvjc1SwB7NfhMflyZ/otwK
YzuttqjMRq4L6v2tKq/UxmYLBn893gLVo3HCjumSi2xGq0f7W6mXiGr4FKUGU6f0g4IUrBnPTkms
ac14b1pbGn99zyV5lWvSBKP6k/qyw3D8mvjn/N1L47XZBWX76+bVnnSBp3SqUS5Q6e27r1PFfKF8
MFro2XSOF6ekIHYubCp0I5vYLCb4o2SKvzUwL9AWwBoKT2llY2O+lue3sSXQ2NzeKs+2skqmnVLi
58t4KUrScFoUVDVYg/U5XjGtcnmcXD5eHH/a6QZx2t+rDzS29LLOA0qHxI8dhEFrQw1dl5c5i7E1
6xHdAvVdAb/dX9/b1T+0ZU5vXzjcu7yuc2EF6yPQMLc30NI62itf69TWTd717KOcpJE2TqvOy0Xs
qe4L0Eub+8L00pb21oN25LiXTmuNqaiqprO6rS8D51oP+hHcZauKWZmRFfyswHqaioJeru89GCZk
i3xWLRvkcnc/JbJNL2yUdPeruM0ubCrY1NwWlm3shUlKWAgXI9zW+eey6dnYtrC3s41tLuLBVOKH
RmmgkkRVgco+qtKao8bAvOqoKVDN7FXMXsXtWmbXYWFQD4VzWEzq7QwgTmFBtRIv5UtRYl36+4eG
prWmHfEebUvDUpsJtLdGDTmI/ZrgBNQbx9AJ87jolu4udh0k0sra6oIN3W1YtqJDVGmIGtCDQekB
NerlNmw5olE35gYTKLffgkJ0S1u0LYd9aOuiNnk526NkfKAC08771ITYBxW09ToDhfLexFYwBi9h
ZMC1kZZWbvGiiA9r407SmXHl3QGc6u70w9tq0t2Cpc5jqdHLLfMQEtWheTKMXuUkYcOSgiaLMWrI
R4f4YdqUz7akJqhra+MXL5cuUSrgs+1RE64odJIrlQbwDk41sGvBzyW4VFb1CdZNcz+ZGliLyMIu
Wu5Jh9NRS7ChC8GftzfBEigTjfUsRpiUPg5zq46N3Ay/S8Fp/UM7AuvSTnrl5QbYzYEtTOI9iIVN
2npPN0Rn5OTl6k+3WmRzb6/e8t0NuL/0luPMjP463DVQEc/AWjJI6GHjpG9HDF5h2M8sJ7+k55hF
3YUsT4cMUYf9YCcFBE+jgYShIcwOjRkkf7/qB3sNCXQCxIVCXCDE+UJsEeI8ITYLsUmIjUJsEGK9
EOuEWCvEGiHOFWK1EKuEWCnECiGWC7FMiHOEWCrEEiHOFmKxEIuEWCjEAiHmCzFPiLlCdAsxR4gu
ITqFmC3ELCE6hJgpxAwh2oVoE6JViLOEmC5ERIhpQrQIMVWIZiGmCDFZiElCNAkxUYhGISYI0SDE
eCHGCVEvRJ0QtULUCFEtxFghwkJUCVEpxBghRgsxSogKIcqFKBOiVIiRQpQIUSxEkRCFQowQYrgQ
BULkC5EnRK4QOUIMEyJbiCwhMoUICREUIkOIgBDpQqQJ4RfCJ0SqEClCJAvhFSJJiEQhEoSIF8Ij
hFsIlxBxQjiFcAhhF8ImhFUIixBmIUxCGIUwCKEXQieEVgiNEGohJCFUQlAhiCLokBCDQgwI8a0Q
3wjxtRBfCfGlEF8I8bkQnwnxqRCfCPGxEB8JcUyID4X4QIijQrwvxF+FeE+Id4V4R4i/CPFnId4W
4k9C/FGIPwjxlhBvCvF7Id4Q4ndC/FaI14X4jRC/FuJXQrwmxKtC/FKIV4R4WYiXhPiFEC8K8YIQ
zwtxRIifC/GcEM8K8TMhfirEM0I8LcRTQhwW4idCPCnEE0IcEuJxIR4T4lEhHhHiYSEeEuKgEP1C
HBBivxD7hNgrxB4hYkL0CREVYrcQu4R4UIgHhNgpxP1C3CfEvULsEOIeIe4W4i4hfizEnULcIcR2
IW4X4jYhbhXiFiFuFuImIW4U4gYhfiTE9UJcJ8S1QmwT4hohrhbiKiGuFOKHQmwV4gohLheiV4jL
hLhUiEuEuFiIi4QQaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8V
aQ8VaQ8VaQ/tEULkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1Tk
P1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1SkPVSkPVSk
PVRkO1RkO1RkO1RkO1RkO1RkO1RkO1RkO1RkO7RmDxPImmOplT7kzLFUN+gCXjo/lloB2sJL53Ha
HEs1gzbx0kZOGzit57QuljIWtDaWUgNaw+lcTqv5uVW8tJJTDzeuiKVUg5ZzWsbpHF5lKaclnM6O
JdeBFnNaxGkhpwWc5seSa0HzeGkup25Oczh1cerkNJvTLN6ug5dmcprBqZ1TG6dWTmdxms4pwmka
pxZOUzk1c5rCaTKnSZyaOE3k1MhpQszbAGrgND7mnQAax6k+5m0E1cW8E0G1nGo4VfNzY3m7MKcq
3q6S0xhOo3nNUZwqePNyTmWcSjmN5FTCOyvmVMR7KeQ0gtNw3lkBp3zeLo9TLqccTsM4ZXPK4pTJ
uw5xCvI+MzgFOKXzrtM4+Xk7H6dUTimckjl5OSXFkiaBEjklxJImg+I5ebjRzcnFjXGcnJwc/Jyd
k40brZwsnMz8nImTkZOBn9Nz0nHSxhKngDSxxGaQmpPEjSpeopyITHSI06BchQ7w0recvuH0NT/3
FS99yekLTp9z+iyWMA30aSyhBfQJL33M6SNOx/i5D3npA05HOb3Pz/2V03vc+C6ndzj9hdOfeZW3
eelPvPRHXvoDp7c4vcnP/Z7TG9z4O06/5fQ6p9/wKr/mpV9xei0Wfxbo1Vj8dNAvOb3CjS9zeonT
Lzi9yKu8wOl5bjzC6eecnuP0LK/yM04/5cZnOD3N6SlOhzn9hNd8kpee4HSI0+P83GOcHuXGRzg9
zOkhTgc59fOaB3hpP6d9nPZy2hPzVIFiMc8MUB+nKKfdnHZxepDTA5x2cro/5kG8pvfxXu7ltIOf
u4fT3Zzu4vRjTndyuoPTdk63885u473cyukWfu5mTjdxupHTDbzBj3jpek7XcbqWn9vGe7mG09X8
3FWcruT0Q05bOV3Ba17OS72cLuN0KadLOF0cc3eBLoq554B+wOnCmHs+6AJO58fcEdCWmBvBmJ4X
c48Ebea0iTffyNtt4LQ+5p4LWsebr+W0htO5nFZzWsVpJe+6hzdfwWl5zN0NWsY7O4fXXMppCaez
OS3mtIi3W8hpAb+y+bz5PE5zec1uTnM4dXHq5DSb0yw+6A5+ZTM5zeCDbuddt/EPauV0Fr/c6fyD
IryXaZxaOE3l1BxzhUFTYi72CZNjLra8J8VcF4KaYq480ERepZHThJgLeQFt4KXxnMZxY33MtRlU
F3NdAqqNuc4D1cRcW0DVMWc9aCynMKcqTpUxJ+7vdAwvjY452kCjOFXEHGxplHMqiznGgUpjjlbQ
yJijHVTCzxVzKoo5ckGFvOaImIMNbHjMwfZmAad83jyPf0Iupxze2TBO2byzLE6ZnEKcgjEH81IG
pwDvM533mcY78/NefJxSebsUTsmcvJySOCXG7B2ghJh9Fig+Zp8N8nByc3JxiuPk5A0cvIGdG22c
rJwsnMy8ponXNHKjgZOek46TltfU8JpqbpQ4qThRTiQ8ZJvjYxi0dfsGbHN930J/A3wNfAXbl7B9
AXwOfAZ8CvsnwMc49xHKx4APgQ+Ao7C/D/wV595D+V3gHeAvwJ+tC3xvWxf6/gT8EfgD8BZsb4J/
D7wB/A7l34JfB34D/Br4leVs32uWEb5Xwb+0LPG9Ygn5XgZegv6FJcf3IvAC8DzOH4Ht55alvueg
n4X+GfRPLYt9z1gW+Z62LPQ9ZVngO4y2P0F/TwJPAOGhQ3h/HHgMeNS8wveIucf3sHml7yHzKt9B
oB84APt+YB/O7cW5PbDFgD4gCuw2rfPtMq33PWja6HvAtMm307TZdz9wH3AvsAO4B7jblOe7C/xj
4E60uQO83XS273bo26BvBW6Bvhl93YS+bkRfN8D2I+B64DrgWmAbcA3aXY3+rjJO8l1pnOz7oXGB
b6vxbt8Vxh2+i6Sg7wdSme9CWua7ILIlcv7OLZHzIpsim3duipg2UdMm76bGTRs27dz0+qZwk9a4
MbI+smHn+si6yJrI2p1rIufuXB1Rr3atXrVa+nQ13bma1q6mw1dTFVltX+1fLZlXRXoiK3f2REjP
lJ4tPdEe9ahoz5s9KtJDjf1Dh/b0eFPrweGNPRZ7/YrIssjyncsi58xfGlmMy1pUtiCycOeCyPyy
uZF5O+dGusvmRLrKOiOzyzois3Z2RGaWtUdm7GyPtJW1Rs5C/ell0yKRndMiLWXNkak7myOTyyZF
JsHeVNYYmbizMTKhbHykYef4yLiy+kgdhkyS7cn+ZMnOLmBSMq6EeGn1cG/Y+6b3mFdNvFHvIa/k
tCX5klTZtkRaMzmRLks8L/HKRMmW8EKCKpyQnVtvi38h/vfxH8ar48Lx2fn1xGP3+D2Sm43N0zSt
XuaqWs4jSuSxNnkCoXqbm9rcPreqzuemxPGm45hDcj9uf8GustmozTZkU4VtqG6z+qwq9jZklcLW
EaX1NovPomJvQxbJE7bAwnrMNE+ZVm8z+UyqSJVpskkVNlXV1IdNecPriUT9lBJqB0l61N1L3b56
6RHKfo2jIZRe1TetJSensV9PpjZG9VNmROml0WALew83t0e1l0ZJpH1Gax+lP2zro6qaaVEX+2Wv
XL5o61aSUt0YTWlpjUnbt6dUtzVGtzAdDst6iGmCKm05s1auXpmTs2oW3matXJUj/6BEV7NSDjOy
n5WrUGbHarlMcr73xauBZq/Ea5ViW/X9jf6vv+j/9gX857/6CPs3CmOHVD8gc1UXAhcA5wNbgPOA
zcAmYCOwAVgPrAPWAmuAc4HVwCpgJbACWA4sA84BlgJLgLOBxcAiYCGwAJgPzAPmAt3AHKAL6ARm
A7OADmAmMANoB9qAVuAsYDoQAaYBLcBUoBmYAkwGJgFNwESgEZgANADjgXFAPVAH1AI1QDUwFggD
VUAlMAYYDYwCKoByoAwoBUYCJUAxUAQUAiOA4UABkA/kAblADjAMyAaygEwgBASBDCAApANpgB/w
AalACpAMeIEkIBFIAOIBD+AGXEAc4AQcgB2wAVbAApgBE2AEDIAe0AFaQAOoxw7hXQJUAAUImUth
o4PAAPAt8A3wNfAV8CXwBfA58BnwKfAJ8DHwEXAM+BD4ADgKvA/8FXgPeBd4B/gL8GfgbeBPwB+B
PwBvAW8CvwfeAH4H/BZ4HfgN8GvgV8BrwKvAL4FXgJeBl4BfAC8CLwDPA0eAnwPPAc8CPwN+CjwD
PA08BRwGfgI8CTwBHAIeBx4DHgUeAR4GHgIOAv3AAWA/sA/YC+wBYkAfEAV2A7uAB4EHgJ3A/cB9
wL3ADuAe4G7gLuDHwJ3AHcB24HbgNuBW4BbgZuAm4EbgBuBHwPXAdcC1wDbgGuBq4CrgSuCHwFbg
CuByoBe4DLgUuAS4GLiIzB27hWL/U+x/iv1Psf8p9j/F/qfY/xT7n2L/U+x/iv1Psf8p9j/F/qfY
/xT7n2L/U+x/2gMgBlDEAIoYQBEDKGIARQygiAEUMYAiBlDEAIoYQBEDKGIARQygiAEUMYAiBlDE
AIoYQBEDKGIARQygiAEUMYAiBlDEAIoYQBEDKGIARQygiAEUMYBi/1Psf4r9T7H3KfY+xd6n2PsU
e59i71PsfYq9T7H3Kfb+/3Yc/g9/tf1vX8B/+Cth9iyWYZLBldJLGiuRiI6UkyYyicx4hFiwpj2k
gu7b566t1efpHsN6VRE/VrweKWlN2KZWWQ4kJVUFDpRot0qOBjy4763SbUUsrxp4Y+D5goE3jjrL
C47Sgt+99cZb9o+ed5QXFL31ylsjhlNHmkOGy6rS6VzaQHq+qiQzNLKoqLBSVVIcCqRbVbKteGRp
pVRUmKqSXMJSqWJlKr30bbs0eUCr2hyoml6kSU2yuSxajSo5wZk3OmhvmREcnZ+ik3RaSaPXZZVW
pzcuqUv/jc6R4vakOPV6Z4rHneLQDbyusX79scb6TY16yTfXStpRM6sypBuMepVaq+1PTUgcNiqt
Ybotzq42xdkdHr3O6TBn1c4cuNidzPpIdrt5XwNNcEtg6Gv1Zo2LpJMQufUgyRh6Z6/ZTicG+hUR
6h86ttcEYRICT1bHwklMBe3s3SK/m+X3cBYNstO5JtqUEQgFPzWbzAnpKQGjhXrUZmK2m1W7A48H
XghIAXPA7EyZ6oxoIqSqqspZXl5Q0NHhiC93QDqK7EcLHUXweE4Hn29k60GPRyu7PFNKk6xSID0U
GllKuZ/jdQEpTb1aT+1Bny8YZ1AvG/jzYskYF0hOCdqonsbUlsTMVP+wJKt6A/09fXKMx2tVSzqz
gY4a/JnBYlBrrF6POmay6iVJbzNtHdjA/rVa19AxtVmTipU1Z08yGZUDn+yx0ybwsT02md/fY5H5
gz1mmd/Zg4HnPIbkxkoSaAFJIyGaG4trUT9Mh5ESMpzm9xmmY5m9cpSBFrwlD87+6uERw4Muq/ak
paJ1K0uHLSq3K1XF1hgbqtqs0uhd4dkbGjY/d2VTy/W/OK9scXu9V6+R1HqT3lo4ecXk6VvnlpZ0
XzWjaWVzsU1n1EoH7AlOqys70zvtro9uvePb3TPd/mFea1yS05UcZ8gsyKy7+ImNGx49b2yoIKR1
pGLkDxAiNWJVJJHxB4mbD9utDFtmi8yfs2G7lWG72b/KIQbbVHc/zenTTiNVR6towRE+RHl8qkBa
eqjEoewFtyON7ZBGNfw/cDg+W+9KT0hMc+npi2xCGl3eOIMvU71Lb9ZpNDqz/ps7DI5kghX7wNDX
0jPY88kkm6zty9Aqs6JVLk+rXJ5WuTytcnlaXF443pGSgLopdht7M1voxBQ/zqWwX28RR7CfGvdo
teZAPzXtcTeb2cpUQsEr8jDsfDCFWJhsNAGH2N6O4pFFGI1aV5zPzGyupGfCax5cu80Ql5bIRjUs
ibqHNS1aOjF736izOnJvv3nSgvoMaVvXLeeMHswXY1Tfn5Wui6+aue6syYuLrQNfZY3rVkasNmHE
I0ktuTqcas93lOpx1aVsFKXyKErZqEoTmLFfVXQgO4xidpWDuQLKobjGobjGobjGobjGwX7tlZxv
76f6/cvDNByOHwMP7Etrjld2J3NCx9FysV4LX8nhAltVmVh5W+ZLf+MST3yqxFayLlWKj/N4aHEo
MxRSPKQ2aV0ZqUlpLpN6jTuvctqolcJZ2fE0bsTYpMaVkzID1TPL/cV5Wa5VVv3gQO2UxKqiq++t
7a72JenhL7XBbqYjis+qCgz8+rgTd2X6NJKlbPqymrELJle4rDmjJ40Y/GNGinTRxEXxOu3gxLRR
U+DVmUNHpSrpWVJEwiQa9tuqfdUF1ZLJEF9shm+K7XBUMfNosd2GyFbcT78IW0lmpo1QM2GeJxXM
nahawdxoUdjEeS9rU9Gv0oddjvinSLG9WDXqUDElxbS4OH/ssH7qDdteTKfp6eqU9/InjPmtuUlN
CrBhuKcd7H3FrA4RIQ7nzOooL+CrrxAun9URdLFYGAqVlGhPRI2ikmIeLxSLWt5mOh5BPEWFI0ul
KnuyN8lnHXV187iVzXmVq+5dtNEzYlL5mK6GEWa92aDWeaunzy/uunRa6K6ttXOrfW1Txi4bk2A2
Y1eY26vqg/Xzx05cPiFYXzylxJsSSNHbE22JKUmBlLjcyOZph+PzqrLrW6prEUFuxC7drllBCsm6
vVXFdFic4pw4dhthzolTFmGcsijj+umX4fhUkxE2E3O+iTnfJDvfxM4ZSRinSOqwRCxU7YG8CRn1
iRM1E9n6ZG6jBQU5J21SeKkjeGItMr9odSctThGDRo6UWdqud/oTEv1OfUJ+w/DKjbUoJib443S6
OG4ed1VD+4aJaYmIsWoWaFW2plm1Ga2RgcuFRVMmr0i8Dbzd2DBm/mVdhPuBVsIPbhI+UBU/OX5Z
vESUERPFA0RxDRGuIeyf/xnt9fLglCVw6nCUq6eVp19m4t9eDRGzgbVeSK4N25x2Ng/sTZkYOUjE
KUHixHwcnx9l4jAH3lST3S7mh20CPl3yTOH8AWWK2ASFjXkThiVmNIg5cpZXHT0+RyKSsllit/Z/
PFHufzRRWmdyvCfFrpv4o6Z/MFHSD/QmgyQZTPo1kcmYp04WY9sRDd6Ah+JIJrk3nFyVTbOcNNtB
QxYaMtOQnoZ0dJhEs1U0VbnhpCoOA7/JHJaqpAGpisNS+1XGcGqBkRpdLDq7mLtcflR0OVHLxXzm
ekhlJGTo0AEbaVqOaUpkvw+xTcD9R9WnaWI3ULisQ3FZQYe4lXaIFz0tvdQVn5ovSG9UrHywZ9nd
54wsX/nASnDpLm/l4skNi2rTvFWLJ49fXOunb59z8OLG6s17e8ATwBsbLphTXjz7gqYJF3SVF8+6
gK8e1Q45UnbvXV5CQzZladiUkdrEwrUpa8fG1oqThOOwGMIOvLFhkyRjPw2GDTkTQja3v8HNVgVu
IGyIhzGs47uWnpT4fNdCkDM+rWqHSmvQ6+NTMtyJw0sqAqcvg+DYivIUS1pGilktUWmOJ9VhMBj0
rvyJpQPRv10IF46szbRJeqPRYPWy/ZI29KFqqfpBUkFm7s0mjkCeMtd5ygDzFA/kKWshT/FEHhu4
Od6SdzQwPsVyNH78iH6q7tPxqTzChlqk3EKPHC6Ub51qPjrEchHCxTjldzxk4JbqEcmfaqne7s/O
j6+fG07ZbHNq9Bb9JrH1/8Lit9P2l9Jx8RnJLr3GoFHPSEm3Ww3aIG6kKqs/Iy7JoXsVSS9um2YI
R1Jchn/Q2DHbYDRorAls3HV0rypfNYbYiHUv0ZmO4qaEaz7C8h2tnLzxPEelync6Bmc58aJ36i0G
Df0qM9UXCqVqHUmEDn01uE1NhhKIhdj2EZ3xXfVkUvUd3XjUxO74dozD6XRIP7E7Bl8N+FMD6el+
7MazsRsf1fhJMRlPbjxIJgwdCsfbVE2dE2jO6io6v4rWVNHiKppRRav6VTVhlzk52by+hC4uoY0l
tKKE5pTQEpzYj03lx7DYDrXxQHsA3ZDhZmruH/o6bETBXDE0fLgm1E9JLK6ttp+6+zSziXInxkXn
dLySk9PR8Za835zsJiwrTF5HjrJS1cqt9pSUXccfTMSO1Ikd+WjxkntWNG+cOSZod+ZPXnPPOcGJ
4VyrTq2iOpPBFBrZVNRxcSRbShrbNH3EoqvaQrviR7ZXByfUVSWlVc2qCs+qTKE/jty+riFrwpLe
u2a13H/b5QtGG2xOk8UWZ3Um2fVWh3Xilvtm2lITbOXzLuusmF2dYYn3Oc/ftShvePM8FunGw7fP
aNIQ6XLIe+HE08JcUIS5PParnyBzeh49KYB5WABjQd/FEmdXAlMPq9h/3ePnW8GvbBXwe2yr+JWt
An5nPzjDT9l/uxA2GP1kOFIvSX6eNKBFgXGyUYU5elEuGe1spthFsFkiRmLMy/WyXzfbWlie3qeZ
Ls+Sw0nZoyO2VEdOBybn5LsLC5U53xMr1SfFSrX0TMHS6Pnrd8zPGb4kumUDOGr15oxuGh5ZPMaT
Onbe+LLImKwEg6r3us/7us6674vt134h8wNdN50bKU2ccsUjS65+bktFRs2snouw5HbhCep2TTzJ
J2+HMzJSaUYKzUimAS/NSKIZiTSUQEPxNFv2vdMPtw1nI7Uwdw+nhLmWZCuxJVtxaLYSe7IVh4K/
ZDEnmz3YWFMTWKMEE3s3OZQFD35lD/p0sF8Q8gcBYT+kPADA9Wix3UEdcc5+WrUnMDUbd28df34r
rBo4wm5A8usI0tCij2T5lOxZkkOP34k6lMc7xb9pDp1WG5JDWmmQ7wS3Q/5C5Hat0aIbmKkzm7Ra
g0VPrV/HxVs1ktZkoMPUZmeCM8Hv1L6ntxo0tXFJdp3OnhTnTHIYpF9dZ1RbUuMdCXaz9nFJraZq
nUn7zZUGBBx4uwfevgVruhL5jSV7JM1JpdkpNJRKw/0idISph61ij/y85GFu8mAZ7i8K4iDliq/L
H1KdR0zcOSY4K2xiOY6jrNzvL8fiy99f5NHmt9jL+2mW8BBuYUcd5QUgBAvcxY6w5SgvQNlHHfR0
55TGVUqnJepaHuvZt0ryM/EtGoPNMFBiddt0ktFm/uasReXO5JIpxXKarjMhWmj0CaPazh41a2tH
vmfcxcuOqIr0NpNmghPP8zp7qseVGh9vocaZ16ydk5PTVJGenpWud6a6bR671Z0RSCiZub6ucsOV
u3teNTjl+90CxIRr4L9WqjmIVOhQOJm5rJ2O0MMpI9jGHyH7bQTz24h+VUnYOKklNGlSAu7wcPE7
4RCqhPx4C8MaCktWL2vpZS29cksva+lVlqwXnt9H9DznxbMS9rdVWZpWZbVb2cTFYRqso8Iojgqz
TgpGUXnpKks4bGTGUY5RDs9IPLCGjQ0tuZ/4/ZqGFg+KSoRgYbzcjimSowTWMpumnFdyxCNsPOzM
gmcuu8i0RWTXshtVIY/c8pSdeNQSlu+aRHeqJF1Tuer+s8euaK2w6bWS1WIoaVlWWz23Nj2nZV3T
BsyVTmuyGlZUL2rITCpuLqnomlhoxMRKKq0+riKyLNx+6Yw8f2X7qJplU/JoT9uV80vdKT6r1ZXi
zkj2B/3plZHC0tZwOraHOy7RpksPt5VmNYz0BbICGpvXY4t3WOMwz/nTVo8bs6i53KTSlUw5G7F/
OJ4DXta4yDDEpW/CFcF8Gsqjmbk0I5NmhGgwmYa8NCAHqGACDcbTkIeG3DTkoiE70j6aoaEZaprj
pXK0cvJoledJgPCwIOZRJpHxAcydJzk/394/9G04BTXsbPvZ2Yqws8cHO7uJ2NlTiP1hlQNZt5rH
KjVuAGz7qdn2M+K0Wj28INObL0+wOifNbjemTTVG5OQRu67oaGEhuwewKVRyq5xCR9ER5XsasQNP
e1GeV4nc8vjWpCdilYcGaJr0sst5jd7FU8uB98x2i0alNeroS5q41NzUtBGp9msc7sE7VIMz6A66
PC00eEzkltSutacmxKUmxlskJ57CJORqhm+fDqjeHahgO24edtz1Gisi1hNhS2YpzRwpP2RIcsTa
zwNWqRKVSuWvXtnXPA/BU1lwfRasWWxfZFknFy4rPK9QKvzuL7YeUhXhAeOdPcq9dB/LgsJ4pMMj
B3sGj0vAxskNm3MrPvWzbyM0uc0Jp2ydjqNs6xTkUPuryo453PEK3zzcucy7J3YLv7We2BzsOwrx
5ZiczKYpD9zS9fVb+paMXjJtpE2rUUl6k844bNyi8TXLm/MzmzdOH9MaSk7wpajG6G1Gjcs5mBJo
GL7snmXldPvCO5dVOBITrGZHktPhdegTU5L8tQsmVM6u8pmTgipbmt+AIJiRNXidRlXS1Ts0JHJJ
lRZPMMzz3dgDu+F5H3ntIHEgdhkdaXSiw25XvhA79Yuyd5T75JfyWlyFTMlB7f2ilZ21siut7Eor
+bTJZKYTV9vZxpG/kUTjNDGzaSwjlW/I4F/tZWHQrdyRT3yZyvsEv7kPbdwaRz/N25PUbJK/lCyU
gxhuyfIsIMeR171CcvTS0eNfkacpzxbyrWW3pDFoB/M1tviMpPSQQ6Wl7w1si4vTGK0G1cdWt0mr
PuxM8SZav3nebDNIWkucRT0hKyMO9xU8Wcn/kfYd/KAF33M88G86vv6fHqqV7JBSzxz/0uPIf9ah
bv5vH9eefGiCpxx7vu/Q5n7Pce+Z48xx5viPOZ477Xj///ahu+n//dA3GdSGu4w3mDrMTnOS+eD/
vwdh34LxvzzjIpLME4mWlMnZYTxpJ2eRSqmHquhNtB3nnXQTPZdeQZdJ64lael86Kn0gfSgdkz6S
PpY+IWoyCe3U7G/TEHIsHvkmOUbZO8rsr6/+z3ojcjsnrk9F2B/L0RFS07Vk0ZyeRfwMoVcRDdH/
N/8c6mn1jpFjQ6cYlL++o7aeAH0BfAcJ/FOoJV3/SZA6yAP/bqjTT0LrGZzB/11IvyQzz+DfB3Ux
ufFfDfrq38f3ti0j7f8sVM+SG/8p7CJpZ3AGZ3AGZ3AGZ/AvxkpS932Qvh36+gz+eeD5+Ox/wTGe
7CI9ZAEZTuah1M3+7O0/eI5nz+lU4+uL7n5otm30ZySRP9g//NeNP2f8ROb4um9HDK407Gf/HxZi
kL87wOu/AI3eNJYKZW5kc3RyZWFtCmVuZG9iagoxMSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlw
dG9yL0ZvbnROYW1lL0NVVVFBRitDYW1icmlhLEJvbGQvRm9udEJCb3hbLTMgLTIxOCA4NTkgNzAx
XS9GbGFncyA0Ci9Bc2NlbnQgNzAxCi9DYXBIZWlnaHQgNzAxCi9EZXNjZW50IC0yMTgKL0l0YWxp
Y0FuZ2xlIDAKL1N0ZW1WIDEyOAovTWlzc2luZ1dpZHRoIDY1OAovRm9udEZpbGUyIDY2IDAgUj4+
CmVuZG9iago2NiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMjE5MzYvTGVu
Z3RoIDEwMDU2Pj5zdHJlYW0KeJztfHl8VNX1+L3vzr6+2SeZmWQmb5Ykk8wkmeyE5DGZhISwJIFA
hrAkMEBARJClCrIoQSRgVSg2opXaBVpq9dFqxfarxRaxi/Rjq7XVbmi136r1V7StXxQy+Z77Ziab
uPX7++P3/X2YN/e8e8/dzz3n3HPunQRhhJAW7UIEtc+ZGy5D4me6F8D85df2rU+lm8sB/GL5lk3u
me+2nYf47xFimleuX3Xtc79NQB0C5TXTVq29cWWqvCWBUIG/f0Vf4pWXCl5GqOsGQFb2A0LfoN6G
kL4f0t7+azfdkO7vJhjEy2uvW96XStcfQEj+jWv7blgvf59phPKQRu51fdeuSJeXAMhZf93GTal0
VzfNX3/9ivXPt9/2Nyj/IELSx6SDSAfvLsSioAiRpIzC1IecT8VHLox8icJUHKFkZyo+8SPbjlgy
deQCA7VGvgwlDB8u8+GPIh3ocNF29Ef0ExH9BaA3pcAQ2o+mol604WMb+den6WniB9fjSlyMveir
aB8uwR5sRwfS+DKcjx4aLbgDbUbPofvRfegutBH1AzO8i86jWyBnGVo3WoqOLwoPQgvF6aT60OEQ
+ifwQecVBvACehZKGCH/ObQE3YBmo7uhr9+jVyGvF70JfYyNtWgUDsI4vgzv2yF8T8xcBulbRZyA
EtA7QifQ9WjGxM5kTyIFswnW52ZYl/PoRUBtRl2ofrSHWlyIc9A3gO6vwcjuZiTo9/gDdBr6uIB1
gPkezPg8/iNaSGQwyrvRBbQFxv375G+Tf6C8wMcTS5csXtSzMN7dNa9z1sy2Ga0t05tjjdFpfEP9
1LoptTXVVZUV5ZGy0pJwqLgoWFiQH/D7vFyex52b43I6srPsNqvFbDIaWL1Oq1GrlAq5TCohDEZF
2C7YG7ub1ghZjb2ChotxrFvQzL4wKywgo8PDGdyRcLw4XUqQBgVkahPM7d0nEV8dF2TByUVmC8TH
vuuByrMc7iZB4oMvN6MvIeR3dns49kXHaH4c6gjZjd0ej0NgfPBthSz4zuhzJwS2HfAeRwrTKqD2
bhpOjbxaDUhU7YkD7OwWcjLJePxKg3wcBOr0pGHOxoPsSU1WY0xA5pNI86qALLTYhWpY4DohPwgD
YSEmtobCAja/K2CTgC2zYMgTu6DVzldfgQZNiTVcU2I1UDTRO0bTCymKetyD7sHObkMEouKg24Sf
dHSfVKsaucYVKkAgEYFOqtSAUVMENLH+JNbUYzHCaJpqTzJIoQXyGelwm2hYI/D7eyHCxYBukGMa
yzk1cvrA+CwE1TIxUyqWGoQgaxTkqUG4Vwt8n4D2u08WnR48cIpFy3qDmgSX6FvULZA+KHASEV9T
/zzB2da+EFDQFYTefjdd7pgI6OK5m/rdg5CmZXsBcjG66BPwif4VvZRNcC8XgzxlY/dez2mHYIR3
k2AICloopt36moMMNtlXu2lycHCvW/gyDHdcrodCYAI7DH2wiYPeoLGmNVG6JOHRZRO5sTUhLg6/
v88t7Fq2JsV7fQcy/O8ZZAXNex5YHVgfqClWTJMy0buGDnlNH51m0xr34P4V4lQPiFMDfnU3rYnR
QCsC96MuqL2wu6mfaxrrECYOEeKbXNfjEbKCtOLgYBMdYl8CRp8aMmSMjZ/KhCOIYTyNAj9PfKF5
4hpAj3xfLJ5GpQsspNVoTm8sHvek1h2KCnLfXmmIcw/SFuU+wRxkPWcg73RxUVtnd1PMIc5eYBq7
p75td7wN8bb2UTS2Q5nB8NuOFI3a5nJtHSku6M+A3nkpAWZGVx6KpsuLrZ6zO86l4ou6m7nm3sHB
Zs7dPNg72HdqZNcyzs1ygyc1msH1Tb1uUfwx4L+/3yE0H4gLbG8/rhVXiDbnprzX3NkmmDp66FI1
u/v7UoqjgfNUOzyG0TLtH5WdljngfpABKnOD7N9gbBrQTg53M1U1p0BDOAS2moosDKirG2Riuci/
IgBZmQuNO6jUkLivafXcNLGAM9PMQ3VgRxoLjXg8VJ72n+LRMkgIuzq6U2k3Wub4DuLDQVjHXppz
OpNj6aI5uzI5o9V7OVg3e9vcT+Dv8bw9aOCM7pqwSH9R9SaE0/NgjherBUV1eulNjd3EwaRjjIPQ
mCoIqqxOsAXFipQmoDEHWc79HCewQUHa2H3aURd3swZQdRjKtASpBIFGfY77KaZ6FJlZAdcJ2Erx
CPSqqN6JrRoyRxnJ3TTYm+a08dNKbwaJ/ivPDcqwHEzPkSpvMHJ0hs+K6i2ttX3NVK4cnlSJGXFB
R3WzoPubCGC8jsZuN2gikNwOMeJucvfTxRbcvTFRJcQd49GnRs73xqgKhCHTIo40iwNMkXYirxUX
fVpG3wWMfvOBeH8ttMIXwgzcFdCtKC3zutNUqnakJYr21UqnMjF/lIqZMrD4IHgeoST7p3Zg1Gz7
2/Erkbxt3oTUuM7EvOpRzTCvW2gOZhpPpacHHeOTLZOyWzPZoD62O7bSbYRB0ZMcvq3jJI9vm7uw
+3GwiN23zev+DoOZxt5o/KQX8rofd4MNJGIZiqVImnDTBGrD0Np3GIVY3vE4j9AuMVciIsT08lMY
iThFBofR8lNMCsdmcAzgJCkcL+JSVkWTvR9I0M3BoicEvr37pnj/YG+cEhtZUwwInM3VI4Hh6k9i
RqYRVNyKqKDmohTfQPENKbyM4uVcFNgfhMNNRX2wlwPxBwXcjRw4TlmYsgvjc58aGQENeg40r0eQ
+RZBAAWrDMbdwMUzoNx0GnoBPV3YtbyPjoOyKaG6vHV5XFCMNghFWgUltKBMtwAlmsU6dBeASsuB
Wfs4MQpoEI5dcSEepJ12r6YNuN1gD7VwtYLMn2pT6qcdheODRq5M3E5kPkHl20tfShgbVYQixgFJ
6CyeIpJcAyNfzkHW8l43UFuCls8FZpT46VflSGFWwK4u8a8Qg8qRzkQpCVJrVYIyRPcquRhXh6BB
+Mrj8dTgxdTedAHomxXUMCL/OFKmKwB1IKuVjgW+e2GotOhTtJmOU6iTuwFkkA5abEkO2YLW19oH
CidVXw0YrjpTGdpSiCjaxpkUVk5nrhEN2nmnRo5zN3rGfYqLONiduyljIgfYkDyKD05GCD2gOBWT
sVoRPTio0F65QopeCu3omyLdTatjxaITAh7tkWQNQmrV5YvJhOoExYz/kE0UQ55Ht4GP1YukIBAs
CiPweMmXR0bAP8ePIzfOeURpxzPcp7ArE3FmIrZMxJqJGDMRQyaiz0S0mYgqE1FmIopMRJaJSDMR
CT8ixi6J8AMRvinC10T4ZxG+IsI/ivC3InxehOdE+KwIfyrCn4jwrAjPiPBHIjwtwidEeFKED4vw
gAj3i3BQhPtEeKsI94hwQIS7RXiLCG8W4S4R7hThDhFuF2GHCNtF2CrCFgr/dN5qc77wawDbbrI6
tt2U9ctfQXwL3/s5eF27HsDa6wBcs87quGbdzuuzN202W5yr1gBYuRrAin6zY0X/ng3ZWRutWxuz
PDdCkD9je4b5z7/i4KbvYtuTOPBi75Prn9z1pOSeI0yQP4KXHsJ3HWSCsK3z7FsOV41yuX35M8uJ
e7lWX0ORRdNzfTXsiRU7au4f4nLtX/QX1nxxCAdbhvDdh5kge7iBr3npMFYLDmFAINO0WI6lwFZB
LEu/Jem3lG8dRMH9EPZBGNwjC968Ewe375AGdwzk5d62Bwf3QhjYIw3uhuCostgrLZYKi7Hcoo9Y
NGUWZalFVmIhYQsKWU5hN7+rsd7jD+jyA3p9Ic6/OBK8+L7+vf/S/fNfupL3Si4yFy7iwqCuKKjP
43ReTp+Tq3Pn6vWsQaNUqTUyuUJDJFINwoxGRhK5an2bnlGjKShGVio3kb3Kb6Fjyt/plWqkJmr9
FDRFGSc9yi1kk/5edK/yHv3jypeR7nHswXm8Ue/ALq1dnq21sDatUWLW5k7TYQ8VKoAshDCEBghH
IfwQe3i/rKiusC6/zl/nrcurc9fl1Dnq7HWWOmOdvk5ZJ6sjdaiuPTIPC8Y21DYvKpgwvOdGhUiw
7RRxdwplwTZB2d7TfRLjz8cBKzC3wU43T5DcBpvbPPChFvZ0n8JZNHsPKAqMkdDWu+f2eDDoEhLU
strligtlNHKnKw42cFmH4OCiwcmfjZvSr80TsMI/m4SLTav7hIvghL0HHs7Fpl7hPS62MZVb2CQU
NfUJ+YD0c7EJDeJJ7SPoINUHfW3cCF1tpDHBLjTAfCeP56SSTry9M0qdhzYhAaa/o72nV8jmomDH
Q6qyvQdMwuhJBFbHSYYCGYCenu5pLpyDEtgFwQnBBsEKwQjBAEEPQQtBBUEJQQFBBkEKQcLPSlxK
fJB4M/Fa4s+JVxJ/TPw28XziXOLZxE8TP0mcTZxJ/ChxOvFE4mTi4cSBxP7EYGJf4tbEnsRAYnfi
lsTNiV2JnYkdie2JjkR7ojXRkvgQlT/NJ/5v1aLHf08CuFU6D+WjIlSCylEfbzKbdXkymQ4VBYMl
Oru9pJwPA9vwjhIUYSNMxKXOR6gwaDKXmYNqEikuriyJhM8Za8JGW825MDw1FKDw4nPZf8im+HOG
mvAffmGoMUQgUVqCK8rrmap6UlHu5/J0jJyrqKyMlOUwFjMkdMRisVm4CmzwGGhgqmTWQq/N79BP
q3eXeLOUvXX7GpuX1zv13roit98iN96JLw/LSN/lavyfVquvsCKQFY7UcG2dZm9Zzi05IVekucBf
P7W52FMUyHfK1j3wQPI1yZFLKyX/9cGDMG3EjFxESJonXYRykAd9Ewyyxq5uPuJGYNbnYqlHyurB
XbVaOanSo9TnYpJ7EKxE7CAYK/VEbrETlU2pVB2LKZE9HDSgiMEWsTfARJcuWZw96+2gwYhqSrA9
XAZEiAAJIuze06dpKHXwuf9+i3HskctkFrPN4qkAaoKeyWFovLISyBrweQgJJLs8OmN/sstXHcrG
D2A1nmHNKQkO/7a8TMcme3H/l/Hxpflthcvk0aikaOZ0yYJLX25rCCijUVmoMHdm7W+YCLUNVo1c
kEyTrgDqnE7RRjwU4yt0lhYgXjvTyxAlYZxOKZEe5J0SAwsZBr0e64jebAbVeNBsYrCeZ1m3Yrsd
6DDrFZhJ9rkXzqGGt4PIzp6BWdUEG+jERlOlJY5UL0WfuhfebEL2ia1MbjOODZwfWI4xsMZIWWVl
VcQgk3F5Xqai3OiNlFkl026z98+7/ytfuKN1UZV537rvLXsu+f72QzjnmRVfk1Ym/7jhmuQvky8m
30r+uXRZPPnLbPvdOPzXl/C0h6wwRLCLkLRO2oWcqBjtSHORx1lMig86eafjWMxJ9C7iOqjn9eyx
mF62PRAIu3ZYMgR5BYWDKNvOiiNuyESBDnzWR7ZBueNKdeK4LIdYzDLgD7mMA/YgFYbyEBOowNZI
WVUlfYBHgBBypv/4+YeuKW9tnfbEtjUPJGt9QYtMagn68QPG1nVt1YFpHu/Kx2+ud0i7ytffe+7m
+y52z1lpMUZVtoKGErIkzOdnqaKXvMRtL2xad8O3n7z0OYZyDFBCMgMoEcKmDMdoR07zM5WaFq2C
5eHFshaFhVgO8oqQR3GwpAQxGFY3FJIT+cEQHyo+FguRHI/HSqwHPbwn71jMo2X1eiuDc/jc3BKF
dUdApFuZyEkviiqmbDwB2TMN4xOw/vAOp9nhbDjInk2xGB1W3f9kWBOW4FP1SpkwxHCcIc2BmUS9
pCpCxq2VhN/nCfGzXh4oKvPoN2zQ5YXDAy9xJX7OkWPcZ7pckFkqaVfyR0sbA0l3Vu3U5JraqdnD
byqt/qKWhuShieuUXhnmWpFHu9IcarGZLeZjMQuRKRXKYzEF2qHT5bgMRlxDCYxE9QO8BZDyon5y
afuEAnGfOYeICikzC48F9DmDJRpbvmv4H5kxM9qCgFlxiavzZ5tA+aSGubSkvsCuikbVWd7aahjr
YoRkCRhrNXowPdbySgevNLc4HOX5KFKVYyHl5ZFjsXKi1PhJgTo/v+BYLN+RXVmZV2WR7jQYaity
824OpRiFcsorEdh+QP+iMZ0KEVvEEDEYYbZBcYbcp+hjvFae3EIc6xiLwWy1jpKhsooDOcQc9gc4
68Qsvx8ohLFHlqjw6zW+muGRojyTUkYsGocv+U8h+Zcsk1GlKyxP3uoLWqVafzV+B1twEf611KTn
prRdPjp1uk8fjWqMrikx/GbH70P5s5YPh0iwKfb1V5LlM2r9WiCuPb++hPTNrPay0cs/JxWgqdaM
XJD6QaPrkAv1pGlrR0ZihG3IJHcQx0FeLlFtt9ly9dvJmIJqyBb1THZaL7GTa4yq33SRuNSNDFSz
wsvMyGSYat16ULYM1cHMY8mXky/dga2ncRAXxb/2ejJx1+FZaxtdDTuX33U7i7vxgldww7HkN5MP
PZF856FO5mfJXyVfmnv42a3PYO2+5FspjSu5HzgkBxWiL6TnEXC6iRt2CKdZbi4khQfNsC8ci5mJ
VCFXHIvJ7Tu83qJctEM7qj/GeDwtunR3TUktnWXOx7c3JgBXqE3FgZkoDmVW0Muw5wQqqPhntDBW
2YLFw38ZFY+m4ctbzn+jr35+YktNzbr5zf4PolUeqyI6UaAf/Y89Z1ZINtTctLp/WzkD9KiDnZol
F8CSi6D30vSYpS4gBffzvLpdzaxXY7VaorfkWnZaiIpYHA6WsEO8g833HweuxhESRmE2zJglkjAJ
3y2xIqzOl7gHIpEKhZm3FO1RiFR7IfucgRLOFhF3cFBzVBLCwYnbL5RYvCFDxan//ih4GEa64U/u
Ke4LUOr6/RXlXl+KuiB7HCwAbO9U+ET1RKjdZBUXgPm6vvPeBfN3TgP7yV8YDYUaK7VPLNr6uSXh
G+9qkWnNrvzkAfu9h2N1oc6S3dL2lob1rYe+aV26eEWBOz7newVFLg1/587k1mgLZ9Gqovi3krX9
9dNKO0OwGiFYjR7pEMqG9bg9w51y2fGYXIlV6nzi1XuJ9zDs5NYcYs8Z4q3WbONuj6dQ5RjIHs+d
IHY1mRlTZWNveDrFmR/fFnAmrXKFqnFTeYgEKnygwOqZyChHygNYJIpolQOFjjIqsKaxbRuuW7iy
9jvfWf3c0P27Z+zCnq74or75PUXzqyUNLTOr3WZlVDf8Y1xVx1364NtvbK6pMeLmbZuf+u7TPwp1
RUCP94xcIF8CrsxBW9JUyGHVu9QmYhri1SySSJzEeVhiZXk92MBu+255RuNEXswetRFT6w0i9iyd
uuXDDYxjk0nF49gm8kRFOfUyQPmKNiBoadDEMF3SPmvZY2tfem37m1/seCB6Vl9X7WuM5BQta69d
BXtQ79yRf3zt79ts5neWzPf13LN58wMLyqjmgbUdhLV1ozB6PD2rihzX8VgOcmMzrMUQb2ZlCqI4
IZNJj8dkMqUqTILaIAke5rVWhdJG0EA4XJq/mx1Vr1SastPLFKYszs56fYzRGxrENS/41H2MX/WP
aC6ORfUk5aoCEwhUIaoqXwSnGSEtKhKn1JgfTl64UalvOdr6vUfXvXRPUVetzOQvw5btyT91dtXH
i+f3BLtqsXdmc6FD1ai8E7fO+eDSiTduULM918TD2apG3TDauiX+jY1P/ygYrwU6Ut54H3gjCyj5
dJqOtW4TcQ/x601Yb8o1zTEtNUmsxGRSERWYvkO8ikVZWE2yCAEz7DBPrFnIOJCdnec2DchGxead
s2Xp7UrUEA3Zo5oZUoszWin8GXuaqHau2GjcN56UVht9PCKfVRFRG8nJn1b+5JY33rrxj4d69i1z
+01mPHwr3nnLzK3Tn5C0tM/qUX5v7cKRS19568bCtoqGjrlbHv1WTQtuu+fu+w6BLNUjRPzS+5AP
fStNrTITNVxN+l16GOQQr8c58uMxac503qHnoNjxmM/lyjXxxlxHrkyTOyCRBPwZ4y5y1hBhXxQd
9MweCJMoG+USEJ9zIp08n9jH6DZ4pQbiVbDpG6gSrqJUSQsgMJYlYuHS9tC8sI/dGvbZdYR96zfz
G28zFHiCIcNTT7EF5UldVJc3dSbT3yQ3uELeRx7XPVtVXrN66cztw0Nt9V5NFBHkTfISF/ARyBCa
gwvStInz7tkBlSKsqCJVQzxRKMIsRmVlUH46X6YPTyVTh/gwy84m+tm5s8OziY3M5nXGltk8a28m
zUN2Z6tZ2ujScLyLK8RMGSlE0j21tR3lA4UZqX3nrNFWw545k82egyfj0oJPEkwZ/+MNIsoqoplY
k0lRY5TSd9r/bJy83Tna02frOo4DcivV/6D+ZaI+HN0OQmCnVVb5RU4WX+JWYfOM3yNG91Fxp+Xy
JK5vSZy+588tbyjLqqu6ePzYja/eu+HULdNbphX6A9PKZ7c3bj66KDLbh1cPL54+s6l1euuM6V6v
b/veHbvtzfyDrWShSe3siz30iLG4PMdtuGXfNUc6zBWLptf05uXMrgl3NuYX3dG7eM+8gEqW/OGO
bddv3nbzxssnnNFgS9O8mXklburh1IJNuBc085TRPTc/YNCRwoLC4zG2wDIlB4xV4gBpZqurjseq
US1WDFgsU6e4B0rGbbqgH0cVaATYOiIqUrpWro9tTXTDr1QxjlMKIWOCVFCRAD0rygHgJCJOQnGp
rRk/13NH27obqojG4nckHWFOq80tzffPrSIytTHPmbTm5Jl0EqIy+wtB/ZJFHY0dQzcmDxXNCrnM
4FKpC2csxdLEdVNzwh2h5E3VUz3ZViPg5aasQBNPNPM7qjxmBWzcT4MWbgWvcKr0OuA3B3osTbUa
whCynNczcxhmhMF65ofMnyAiUSKGZRiWMIYTer3ueEyvz5I4JMdjDmxkjAMKhcuZUS9n2DNjpjXd
fqiaXLJ4w/XZKe1b8ll7GGdrf6i5OAb6kTRRRQKmaIp/mfw/a0p9WmVWMA+btqeJZ5de969/ffC8
trBlKf5laZ3XJI8phmsyREpxEVMCXGRDHRk/2WI+HrMgG5bIZaD9ZGhAq82yT/aTU7u0fnJZ+7hs
2HXTHuDYauNnNb5IZkmVFnFJsWdpS1D74RWD0cF6yc6Dtouj36RHxyu8atECBHsIxwgv4QkPJhEb
P7FgwfzjsQV6W3Zpeat0ZiSrrW3m8VibYSBHUTRQnVNdndMTR00D7aNeck04zL5SxqZnlPZxRXqP
WicZ9ha30M/YcZoUn9AumGzp/TN9MPwhqdFJKI4Zw0nSkpSm7Rgj4J9peg7OnLEsZllxuKN9dSw3
JVE5xXlaTV7Yn11U7DbJpSznS3pDnEaqsTh8Tl9HldpbnPSU+LRSU6AEG3eQbtLV7G+dsmRmYffA
oklyplm4gXeynrzC8inJ78dailz0FKOwtRdroj3Vhdm6UGc4uX1JW1AdjYosd++M6UGHKqZAqbWU
HIa1rEH3pNcyaGNqSHZW9vEYzrIETvh8Xthg9fkGXbGO6A7zxWxkQCabkpMfMA3kiMsmnj6k/fOU
1kkTdkxruT+pzQlKa1L1uOcTiSwXPYnMQkkOJx0hr1amtTm9Tn9ntcYXTrrGaKnX1C9ZVdMJrr64
FFF1sHUpVk/vqQ1kacJzw8mdS2d8iFR3kqoGX3jhLfOTB1OkRynrURIB2unBtxg7xxD9AmRVgmIe
4pWsZrfd7mZ3Sz7mHGNSjQ+fY+SNboB0cxS3QHqOIVoxzJRDv75hxsBj17z73tZXk48s7a2YHjQu
XRzr9LOr/vzwrWd2TR1576G3rmf0LzxfufKO+G9+Pf9BOva6ZKdkFYydQ6Xoicz5FtUXRH6clzks
J0wmIzEe5036EltxdjEpPsxns54ACQzxHqtrd2FhxGL1ghehFudlK5s8s9RKps3VjJCJvJD/aXuZ
ZEN8RINx6QR2ICl2EMU37VgaJriV+FnRpgN7j6jNAT+2bNNr5h+eI/qXq5ZT33LBouKuyu+Kpp1o
+ZFrptcVOsyKmOIuMrdVdDKzcT11MZ85HeqqSEsRoVLkRz9O07LagNVIwSoYJVFIeEZtVOepiUEi
URM11U/+E14vdzzm1Vuz7FnHY3YFL5fn+8GTcI2dF4L3OWHDEalLr2DArKVHESnjLfTZOpq0iV2p
zbT2s6UuK3Tkilrt59rWIwunNj5qqApZK4pNMl1hWdI0Tl91kPkztcm/1dY7SiPl5cmnls4MKier
H4w6wP9aCHQLZ3aSxxE38tfHlGyLiuNM3KmRv/KlqQSxmXgTONpDJhaFwSsKF/FFhJChIqvdZgvk
7tHrQ4E9Mlkp4umJq+hUpMTNUBNOmcXpKTZkPAN6Fhukd4Kpo/jJ/Xo+vl++yDrezfiohuMma8ZA
DYTI2BGAaHlRi9eWunakJ3K/sfcvaJvFdSyr6msp7H/qptYD1w3YqqKh6Gxny6olW+rr1n6x5+s/
w7qenti0gtqKoL22dWHVwoFmjfkNvtlRV+mvjAQDXdfN6Ng80xf+O1DXB9RlJC8jJxpKc2WRSXk8
Jjfp9VhD9KbpPKt38hq2xem0E3ioj2k0IjNr1inMaW/2bASctDPgoaXd2bNh8VorxSxp7+yT2hzz
WyfXzrirKe8sYvFYPIbUsQj4q0z3ne2HD22fCg659O/YlfyzpcznLCp13NA29YGvMuEmVX7j2o4P
tienblgbUWXbqRzy9FyEnEfF6I7MiZeh2IhQ8fEY0hNF2HkiW+3KIXIPKKDDVJE5zQNqdZgZ8I2q
58j4c5BZr8PWJl4uGFLW98e2NuHMY2LVuMlD7QXxICN9FGuYePrhFze4AI/3aPJK/b7OGpnBW4Bv
zZx5aBYfnLFmZzUYkCaPk5wf/nXv2gZXaG4Y39I6Pd+hiQ7HMoceZH5szj034nXVdR4HmJNAFcfI
e7JlQBUf2p3hA7UzlyhMLizVZXFypVJxPKbUI6OFEB+ymE2YMEYMKUVWbkBHD10j7Nkyg406bakv
Ctsi6auH1Aaf9ZENgsKZUDYuJYQjqbsZ0X+zmUwRkyl1bSze18gxeeM/fvezf1hz/G78BtiDqu1/
+f6Pdpv1JUX4xhyPy8cl/6Fi9gxvY95vbuDACFIU+LKm5iX7mIeHO/DqyhnOwip5tFFpL2yPD8+C
+dO/bnLD/GvRdzNnPEjvKpbYfYHyKuKtSJsjUoWVZMntoposRrICl17l1aMqU7Gr1F5apZLJ6gq8
JnqDHDlD1TNAWOGa8WHizQ6NGMA/Fw2gT+pw0p3OWN04NqUv1kUlEpCniCbetFdVEWAZSkiKslWN
ElEmkzNfeNMTKXUls+plGuOG1XkGbyC5M7ig/pdvWd15Dpsav9ZgNK9aaTcVcHh78cwWxpt8JDw1
TwEWf7HGYsn+ys0Ffrs9TxKNKpunv41nugt8FiUGFR40+JyHduYUWJ0cA3ZmwwJ6Rw/CtwmHwIPT
PUoEBj/M0JPjt0tLxF9RbEr+A4eSv4J8jO6HtaiRrkDZaGl6LWxGmxXcG4VNTi/1vhlTWNGgTud0
ZHybs5ldUNwSjSI52cl1Rre10UL0dHHsLlA8+grgiMxC8rSe+iWzLj9w3dIyW64jq6d/KqPaJcO2
2ik+i5rp6ZEa8uqbmecLvKHpa3BN7wmqV9bCqG0w6gC6Kz3qAovVqpdLeGnuPr2+ICDXW3OtjJ5Y
HQ4waI7yDrkkIAc75ggvH3cFO/74Dofpj1FmvfNi6jbjHJ1W9mduhapQ8R6XiPyQsQrplQMj+vtm
mXgNb2Hencb7NBttl9cWHr1+7YbqZV3tq+2PbB3cO+fQ9+dOuevBWbe6/2UKh5NHor2v3rrzawdn
r9u+YevfSgPmOXsXzrntoa+03RNUUUrsBA1rBUoUo3fSlGjRqPM4Lo/kHeU5YuaO3lCiR7kIZoEI
TwpIwVEiX2/HejtWEruZN8NeetScpVHLOQ7JB/3sYE5O2FaMsnibuG+/IFJj1isvUGVMRWrc1j22
xY672hZPkyjxKj77OHhz1qRN/OO6iJsqKkdpaqH7tqi4AxURumNRHuNSv34RL30ODv9i2xOrYtuW
Lbija8Nfvrbh5Y5HXGvmv3B4aM5DjyycXzp3ml6ieXttbPfirpt7Q0r9/DuXbnp0VYHv0vWrsOz2
wevlh2+/bkPwmvnUVi8H7tspXYQcKA/9PE31Oo9brlQgFkwStdMklzvJ085fO193EkBpCOu8DwxK
h1KWBZWOxRwsb1ArXW5i3i+Vep30hiPFfLZI2QtjZiaVnVnDlK0Wp/YtiFHfTiRv8WfqcII8fkSb
cR+IZoWnAkfSv0WQc5aUTw3MXF7FYfyKN2iVDf+VWfpKbmm+S7taM6KyF7qT+C08X6VKnoiqbIH6
8OG1JHH5Ia039IfDFQ0+kzLKqF6/8+jwMOXWLwG3Vkm/iPzYl6abVqt2qYvVxC5xqonu1Mjp7zrd
LfTNR422Fp36Pl7vxE6nl94Phi1ESywsC2bMEVa2HmM9BubBXt4rJdKj3iwGZR3Q6xXIwlvdgwpF
PgK6imTN3FC2Cbr27pNZ7uo4e+7DjAyinL49BAqdpb+GEwXa8TFjLPuMY+S9V2bwj+g6XpXi5TQT
ywMGT1q5GCpHWR9Y/kuPZq1bcG3/rTtLNxQtZOb48qzadebhI3Xbe276waqb3vzq6pfrP7j2mr23
7z9o1FYz31LZ3cmnkkNGw6KHtwz+YHEh5el1sDK9oEfsqAB9O702pdIsRRbJuo9XKOysFrtwMaYm
JCb4Pt4uZ0XRZrMwztXsDwSCktz95rEjU8OoiTp2V2tM34SnHU/fp2p+otf54Xbi2CJDaQczQw8/
/QFXFaa+0qhvTk79LnmhWDX7/iUbvz5v/RvfvPdPW57Ga15PXi6dH7WpVq6u6yizLpW666XJS/+Q
VJatOLV1z8+vv+ndb7+Jt/6FHV7oKs2tbX3sVGju5ul3HBJ/BH9z6sEsPF9jCpj3Ug+ZmX7eJ+9L
Fkte///7kT4oK5EdkdfLX1QsU65SYdWg+Lyk/qFmseYH2mXwJHXf1vv1J/Un2VL21avP1ef/see/
rj5Xn6vPlR9Dp+E3xrtMIdMl86H/jQ+itk3qr9fM4A3Tz0okQ53iX7l5yUZkQrvR3WgQ8jToMPoi
2ovuQnvQfnQrugex6E60D30eHURyJEFG9AX8GhpAd6DbyCayGcnIFvI5cgNSoCOQS/9HigQe6OuC
d2QEIKYQ0hKE/q/1k/rrPCOiv+5DMA8NQo191y67fnVfUfS6tYnU3+7hO5F07H+ffMJnUrkL6MLI
BET6L/+kMfRkJuAfQ7pq5H0aJHejVdKvol7J0YmBeXZikD2NFtMgvROtkbwBZa6G/72hBdVJfoBC
5DTqkTwD6QbUw9yH6iUFyCs5i2qZAdQ6Gj6HauW5qFXyAoTPi+XraCAnUSt5EHUwf0M+SPM0yJYj
h6QcsVfD1XA1XA1Xw0cH/Du06mq4Gq6Gq+FquBo+S5A8ge5Ha9FOVI6+JP7nTPIJPiL1AbE096Tw
8PeX6uv+hdQpp/HxvwxNpe+nSqYdu3wxyatOyI9AWaXom8LnvwHf6FKZCmVuZHN0cmVhbQplbmRv
YmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC42NCkKL0NyZWF0aW9uRGF0
ZShEOjIwMTAwNDI3MTY1MDAwLTA0JzAwJykKL01vZERhdGUoRDoyMDEwMDQyNzE2NTAwMC0wNCcw
MCcpCi9UaXRsZShNaWNyb3NvZnQgV29yZCAtIFJQTC1QYXRoIENvbnRyb2xfUkEtMDEpCi9DcmVh
dG9yKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikKL0F1dGhvcihhbGV4YW5kZXJyKT4+ZW5kb2Jq
CnhyZWYKMCA3NQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMjU0NDkgMDAwMDAgbiAKMDAwMDA3
MzE5MSAwMDAwMCBuIAowMDAwMDI1MzQ4IDAwMDAwIG4gCjAwMDAwMjQyMTYgMDAwMDAgbiAKMDAw
MDAwMDAxNSAwMDAwMCBuIAowMDAwMDAzNzgzIDAwMDAwIG4gCjAwMDAwMjU0OTcgMDAwMDAgbiAK
MDAwMDAyOTI0MyAwMDAwMCBuIAowMDAwMDUyMDI1IDAwMDAwIG4gCjAwMDAwMzAxMTUgMDAwMDAg
biAKMDAwMDA2Mjg0MyAwMDAwMCBuIAowMDAwMDI2NTg4IDAwMDAwIG4gCjAwMDAwMzE4MTIgMDAw
MDAgbiAKMDAwMDAyNjc1MSAwMDAwMCBuIAowMDAwMDMyMzgzIDAwMDAwIG4gCjAwMDAwMjc1NjIg
MDAwMDAgbiAKMDAwMDA0MTA3MCAwMDAwMCBuIAowMDAwMDI3Nzk5IDAwMDAwIG4gCjAwMDAwNDE3
OTIgMDAwMDAgbiAKMDAwMDAyODM4NCAwMDAwMCBuIAowMDAwMDQyMzU0IDAwMDAwIG4gCjAwMDAw
MjYyNjYgMDAwMDAgbiAKMDAwMDAzMDY3NCAwMDAwMCBuIAowMDAwMDI1NTM4IDAwMDAwIG4gCjAw
MDAwMjU1NjggMDAwMDAgbiAKMDAwMDAyNDM3NiAwMDAwMCBuIAowMDAwMDAzODAzIDAwMDAwIG4g
CjAwMDAwMDc5OTQgMDAwMDAgbiAKMDAwMDAyNjQzMiAwMDAwMCBuIAowMDAwMDMxMjU0IDAwMDAw
IG4gCjAwMDAwMjU2NzUgMDAwMDAgbiAKMDAwMDAyNTcwNSAwMDAwMCBuIAowMDAwMDI0NTM4IDAw
MDAwIG4gCjAwMDAwMDgwMTUgMDAwMDAgbiAKMDAwMDAxMTkwMCAwMDAwMCBuIAowMDAwMDI1ODAx
IDAwMDAwIG4gCjAwMDAwMjU4MzEgMDAwMDAgbiAKMDAwMDAyNDcwMCAwMDAwMCBuIAowMDAwMDEx
OTIxIDAwMDAwIG4gCjAwMDAwMTU0OTMgMDAwMDAgbiAKMDAwMDAyNTg5NCAwMDAwMCBuIAowMDAw
MDI1OTI0IDAwMDAwIG4gCjAwMDAwMjQ4NjIgMDAwMDAgbiAKMDAwMDAxNTUxNCAwMDAwMCBuIAow
MDAwMDE4ODA1IDAwMDAwIG4gCjAwMDAwMjYwMDkgMDAwMDAgbiAKMDAwMDAyNjAzOSAwMDAwMCBu
IAowMDAwMDI1MDI0IDAwMDAwIG4gCjAwMDAwMTg4MjYgMDAwMDAgbiAKMDAwMDAyMTM3OSAwMDAw
MCBuIAowMDAwMDI2MTAyIDAwMDAwIG4gCjAwMDAwMjYxMzIgMDAwMDAgbiAKMDAwMDAyNTE4NiAw
MDAwMCBuIAowMDAwMDIxNDAwIDAwMDAwIG4gCjAwMDAwMjQxOTUgMDAwMDAgbiAKMDAwMDAyNjE5
NSAwMDAwMCBuIAowMDAwMDI2MjI1IDAwMDAwIG4gCjAwMDAwMzA5MjMgMDAwMDAgbiAKMDAwMDAz
MTQ5MyAwMDAwMCBuIAowMDAwMDMyMDU4IDAwMDAwIG4gCjAwMDAwMzI2MDMgMDAwMDAgbiAKMDAw
MDA0MTI4NCAwMDAwMCBuIAowMDAwMDQyMDMzIDAwMDAwIG4gCjAwMDAwNDI1NjUgMDAwMDAgbiAK
MDAwMDA1MjIyNSAwMDAwMCBuIAowMDAwMDYzMDUwIDAwMDAwIG4gCjAwMDAwMjcxOTQgMDAwMDAg
biAKMDAwMDAyNzcxMCAwMDAwMCBuIAowMDAwMDI3OTU3IDAwMDAwIG4gCjAwMDAwMjg2ODkgMDAw
MDAgbiAKMDAwMDAyODkyNiAwMDAwMCBuIAowMDAwMDI5NDk1IDAwMDAwIG4gCjAwMDAwMjk2OTEg
MDAwMDAgbiAKMDAwMDAzMDQyNiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDc1IC9Sb290IDEg
MCBSIC9JbmZvIDIgMCBSCi9JRCBbPENCMzEyNjIxREQ1N0JGMEY1M0E1MEFGRjM2RTc5NkIxPjxD
QjMxMjYyMURENTdCRjBGNTNBNTBBRkYzNkU3OTZCMT5dCj4+CnN0YXJ0eHJlZgo3MzQxNwolJUVP
Rgo=

------=_NextPart_000_01F7_01CAE62C.9C739350
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="RPL-Path Control_RA-01.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="RPL-Path Control_RA-01.docx"

UEsDBBQABgAIAAAAIQCitGbRsgEAALEHAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
VU1r20AQvQf6H8Rei7VODyUEyzm0ybENxIFc17sje+l+sTNO4n+fkRyJkDgSjfBFIMS8efPem9Hi
6tm74hEy2hgqcV7ORQFBR2PDphL3q5vZhSiQVDDKxQCV2AOKq+W3s8VqnwALrg5YiS1RupQS9Ra8
wjImCPyljtkr4te8kUnpf2oD8sd8/lPqGAgCzajBEMvFXyaQrYHiVmX6ozz3kU8xG1nHSCESYMlw
ovh1qGtaV0Kl5KxWxMTlYzDvms5iXVsNJuqd51ZlA5dy1IDIo3lX9tDfG2h5nITeIUX/4J20BP42
x4Tnk6n0oA0eZLKAHYffUKudo+L6mfU5WJLB4f9N/ip1yZWtOri1aajDsLQD6rQW9QoPw3zBoR7Z
Kxs6hT6NStj5NWT2drI/H6LSQ4+SQNq7U4T1gDvaHoI50bZ0yEMU2K92QyRv5mQToNkAA2bGS/tu
ST6NAAIRB+AEx6JDHhq/P1iQp9+IDxlszhXk0f7EBxhk+5xOooUZbVnzUV6ptYPJnh8Z+hV6lMQT
rO9O5v4b8CEiff51zF8QozvbTfWR1Mv2h7t8AQAA//8DAFBLAwQUAAYACAAAACEAHpEat/MAAABO
AgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyS20oDQQyG7wXfYch9N9sKItLZ3kihdyLrA4SZ7AF3
Dsyk2r69oyC6UNte5vTny0/Wm4Ob1DunPAavYVnVoNibYEffa3htt4sHUFnIW5qCZw1HzrBpbm/W
LzyRlKE8jDGrouKzhkEkPiJmM7CjXIXIvlS6kBxJCVOPkcwb9Yyrur7H9FcDmpmm2lkNaWfvQLXH
WDZf1g5dNxp+Cmbv2MuJFcgHYW/ZLmIqbEnGco1qKfUsGmwwzyWdkWKsCjbgaaLV9UT/X4uOhSwJ
oQmJz/N8dZwDWl4PdNmiecevOx8hWSwWfXv7Q4OzL2g+AQAA//8DAFBLAwQUAAYACAAAACEALvtM
30oBAADNBQAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACslE1Pg0AQhu8m/geyd1moWj9S6MWY9Ko18brA8BHZXbI7qPx7
xzZQapv1sheSeQnzPnlnmNX6W7bBJxjbaJWwOIxYACrXRaOqhL1tn6/uWWBRqEK0WkHCBrBsnV5e
rF6gFUgf2brpbEBdlE1Yjdg9cm7zGqSwoe5A0ZtSGymQSlPxTuQfogK+iKIlN/MeLD3qGWyKhJlN
Qf7boSPn/3vrsmxyeNJ5L0HhGQteao1gqKMwFWDC9nUcEiTj5/2vffpbHFoKcPLf1y77O5/2oApF
AcwARsWFsPCJoHqZgaHtOoQwSS6I2CdE3lvU8p2GPk0iDPmk8gZBOpdi6ZPmdwn/jGWSXJHc+oT4
guwVEGkws+2YiS6QmI6Gv38U6XbAYTC7ku+ezpHc+GSwJ1GMiiuHB58IpVa4FVk7i2KSRgh+dITT
HwAAAP//AwBQSwMEFAAGAAgAAAAhAPFPi5yDOQAAcuUCABEAAAB3b3JkL2RvY3VtZW50LnhtbOx9
23LbSJPm/UbsO1ToSo6xZVJnK8ackC1r2xHubofs2f9i7diASEjENAlwAFBqdfii32Fudl7vf5L9
MqsKrAIBiJRooWCXus0zwaysPFfWV//6b39OJ+ImTLMoiV9v9Xd6WyKMh8koiq9fb/375/MXx1si
y4N4FEySOHy9dRdmW/82+J//419vT0bJcD4N41zgEnF2coN3x3k+O3n5MhuOw2mQ7SSzMMabV0k6
DXI8Ta9fToP0j/nsxTCZzoI8uowmUX73crfXO9xSl0leb83T+ERd4sU0GqZJllzl9JWT5OoqGobq
Tn8jXeV35TfPFMn8iy/TcAIakjgbR7NMX2360KthiGN9kZumQdxMJ/pzt7NVfm2UBreYj+lEkn2b
pKNZmgzDLMOrZ/LN4or9XtNvKwbSJYpvrEKC/ZuakmkQxcVlSDpK819M3g4m76X87Zd0qcVAwIsB
ZOkyGd3R/UzcnkAWRxevt3q9o+PDo92DLf3SR0x0r/fubHf/tF+8eBZeBfNJTu8cv+u/6r/R73yk
l873+6cHh/wLs48p/8Cn/G4S4pI3weT11i9hQJLe33pJ72WzYIhnePMyhMxiPP0e9EE/PZ3nifoI
3qGvvATB8rJpJZF0UVYPvjSuN0vDLExvwq3BR0iLeJ9l8zATQZYlwyjIw5G4jfDyr2Brjn9EC/1G
zr/E5Be/cx9/+KcHv4I10QzjPTv9XXwMUmhrZl2RRsBs0fRXXNdgsT0jzGL1El9E8mLBxuAqD2nS
JHtTxarzBFTg94JsGEWvtz7Mh9EoEG+hh8kkJHaPT+Ns+Q05RX/hfZ66XXXV7K+3dDHjNYyJf0rP
TuUYewd7u69O6ddY3Iwx2u/wGNVLDo8RwyDqnprFteL9eRyKq2QySchwiTjJQxFlAmIdxiOIeZ40
CrbSZKdGNI6uxxP8yxspPzw93D9+wwanhbkY5OPQUm9IhJZwUmwX+eowOykiWbbcERltkVyJOeKk
OMtTWGqIdNf4PtWuoYnwdsW5mv+j5Da+DdKRSJN5fp+LbFfiB4hxx+7yd2DHAl0wFvk4yMUwiAUC
KQiwuEqTqXCZx9UyHIrhPKVoTFx8/CCyWTiMkNhwMrIjTjtnS5CNzJIsmDQS7qItQUwyDUYhxSPB
/JqTWbjQYnKsiXmO8GU4mVO+IIKRvBNxeIuXZYKLTFKEk1BeJYFUyrB7ijwtuA6fux30DDAk6FTG
ZMOvDcM03hGfXbZeUffMV6EoeHATjcKlEbQU8g5OLC/1M2RMq4xRVhwOjvbevkEZDP6RKhPrpooz
q+LwIcpyJOLBdRrMxjIvjudTmRlHk5uJTmVVdov33qMqINNbXXMovuBapm1EEBbrWpLqat8biGk4
HAdxlCFySARsXZ4mza6r3SiyehjkXiyldYz5HPuKf/79/8pEtiQMgytEjcgYyuRotXZXYP/593/X
zrSrWX0RpydDRLq15LvL9NtxGNeS7SrX4wQhhQiD4Rhhrawh147BXdYXlQmjaG0Pw/tuWK0NV8kd
cx/VTi8Ql0GGpA0Jly0RoL4lv1JN6Ci6ugopwceyDieMcX2F0F1NnKVRkkZ59JfbZbbqKXA9QKqm
uqhuluOUlsSbw7ilNNX9oEmwAy9ciSvcjMM/czFOZmV6OsBQqmUjuPgTCaxF/SrOeN2c2bXEtnKM
Z+dHh2eLTgRpxo/3+vu93apigf1xXldWL5FqN7Un7JZ6Dejz+eBjmlyi2mjNheHEOUbdPzo8lO0P
+XKxny9TbYVoeWvRO6AXXKhnIbP9biVjVLpsy3Q9Y+yPr8OYvRJjKn+xYZjchHGOvPD3efOybol4
a6rlbKB9gUqm1mxUMkf1S2hSDc2w3+lIc4Vrgdc/xgi7bBktKcVuf//8cL+1JXrOzuIwRxvUH5a0
uMZJdG1gZYTW2opcsnCnRmZWHoMWbLI/LbP6eZk2UtUW2jJqbCwFqDN0xlCSMJGOtTqzcYilGTrY
uGWuzFqTRhfLpcL1jBFVPlWhpHof/G8Th9tVrGp5bsq3nC2YzaeXoeOlBN3mIuPv7kkFGjaQ9KDv
b0minTLH3EniLncHgbiObkI7wHQzZMgTas+SnQQIFM5O/5dIkySnbgI0hc5TGIpUBDK8oFqebOEJ
+UPoksCHruFk0DnMjxcesqroZ7qddo0i9V4KWHDq2i6LkVOC3rQI1n7QVu1byB9adtBpDu9wMzva
O1IuVId/BlPqwScBUYG/yIZhHKC6KkbhLBpS538Ui/Poeo7kpU+Pb8cRVnFkskBxuI7BoVa3idnO
vyPex3xpJBQZ9cZlaDXixnvxH3O8kI/TMKSSU8a6hetTSH8ZYtcBLhrf0X3Ifc1o4coilBREUYMk
lmNBCavkRHuZ56buGR3yzgTYeZBeh8t5fUvKOKB0qmssFNv7/WdlottiIDojSZxD8eHDb+INdhFB
vy5IQlOx/eHNxTN2IOxWSpI+n5EISyEPJvh8jEWZG1JGWYzl78jUyxJ9WvVQsj8L0jwazicBnJIU
q6rpNDljdf2cw//RJoiLkFeFhqHaEfNUW2FuT67KFEB7o9FiH5NcPjMH8HS01WyR2rEtzs9QTfsZ
xthe0Do4RxEAKnwdwv8GcHTKG2P/GG27K6pb5Cy14lPkKoNSOxClbIzCvbJxNJ2ik3WQMsFOqTys
ua30EBaTo+2GGQNETk6zj8K6LLqOeTMBNheUiXWIlcHSmrJTgqhCAh11L2wDVb4RDNBGWu+fKrdp
r7ui9UcYzn5DJFbagu3G3mHD/shFv71Xu68OjtpaParJjgX/lbXdLYWSNMrb7RfGH0J349mL8ii0
zXKB/QM7F1olWrPI1mP50VTEXUlTUveS7unmpfjGL30TX+iebr7YbtJPaiWihaN2r2wtnJZEQwrF
tzLl2jZYBsOx4ZRpdow80u0yiS6xdfClTJ1rDJQG0aLS20NlD52bK3ZkxY1pXAon5/XhfpigWgwb
Yi0HCF4fiAO8rkPWoEPxgTVz7RUeG9M2rcGWAhsa7F3avUhfXoUfAIvmtjps9/vPxHZ/t6zBTsVz
djnAOYZu9/eIh/ueh3K5tR4qsMmAbPcPiIuHnosP5+J2/4h4eNwhHvq8x8d5J9kafrXJhugYT6cU
KFQIGeJx1MdphnxO77y01MQLYocEcSlYd7lqgOS2EEQphzLh1S96ORyQJnYx8SX7Yv1ZJqW9SHXw
pRA5LXEsc0rkvMRVSpzLRgRStr2LXI3ufLb2uFKF0tjtXeRtYGeXEjcfpXQoSnHEGaxUFmWdQKSi
YhWlIip4tgbiRbBDItipQLmQQQ5TTBH0AUtlwOJSlXZlK2MZk/ZC5AZ6l/oHusBnR9g66GTHDdka
RxjYIJfkjb0l7LQl7ICQab/L99t7/TLJLhnDUqewk95E8bFLSbsP8bsU4lsKaz0pq25LBa7lhkyX
bEiTw3WEgXUklslzn62oRltEe0vzY1gae1Zd88Nc15I7U2xCvfj9IOJnT6uT8qcW4tY2f+vuYnMN
1BeT4b5fcjFsqvP6Fq30ZAk9ZhWz1nWxWmWMcpNXb3f/3dnbKqzoh0IBQ54nOI309dbuPh9cTU8u
5hO8EODwagU6oyzrvfguYZDlp1kUfMZh7rjCNIqT9Bc6mpko3vzpE2vlAE9BW21Dl8LpsgymYUwI
RO0hQBVPNKbBUuHERc4PTsQ7hZumMdP4yDScjvnPv/9LvKMzbhigWEM0LAGjWdNTqZQ28Lh5sJv9
zmMgyYm3EyjSBR18nYajjzgK8g3gDf9guAOguBOOzMdU40JZRJdkSoGQ0xVrEJMId+6xKOS9vV7v
7EAbJR66Icxq84+DrnwtId6Q9cJEDBQmGeEESYG0sYQkaitQxBR+p4YPw0FNOBiGT3xtmnPlCFoa
XLWjV3BILLOQ6AVcYHkgTlHNgE1lCnX8Rya7XVYPgIRK2HZEZhOVhi46A7Todo7DR9HdAuVyFF7d
e1K7i+y9F5m4XcmtNhKMXNo1QQ7gPbO8AineHTtRzW2OhDIcPj3k08aiPBMA6gfWJNnnxWENO0Ie
j0EfJ/RXdURgAXy3+CTAYrs2eVkyBUxucbQr7GkchiOMn5zvZJLcLo2oJf/ESNEcL0DSCIF3mEyn
ODu8kL4qaFFTAl00UsRlIB7jLIurO+nICvljzyuP4wr+IEzVJZDVUTiMMhyf7jYmHJCW1QBpEIGh
YcWAeKiQvGCSJVr8uqZHPFNlottSFQUTPxwnSbZ8WnoXlGISTSMJW4xju+mwCUCZs5gYSMSlQ7Vc
qxJzBFWWCJP3R8f7u2eOgeJBC5tIdtGGaocMn0VJJFDgm0bgJNMReDTR3C7XB/oIgTwAzP2Ss7El
+vBo98AtmMefEG/UNUtoC3dlUXH3YO/gaF/Xz8yiov0OV9aMkt76B0D+muCU4UgF+L+GWYbSoqV8
lfTt7+4d759X0We/488fvMX277fABj+5CSZYUeGtXWCpKrvkA7UMsCuiyQQnbaQ4skbWcKbmxEzl
xAh8YD7M6XwPRMrZfDZLUhkWRPEQX4+smStVfnf3+6fnb92yRkhYEMlQyeojlbBRec7TZCIuo3wa
zEqmyjU1xooWZ8V6bnCy0BTHVCFkwPHiUCiMjQbWNCW9N0evzo4LNVILevLFtoLlUQrQ5BdRmF+9
wFRMXqSzyYve0QqjaIng6lrGEtudoo55LC6BU891/jScJjAPpAoX4U2YZqE8kkSk4QT2YCRQk5kS
WPjSqMxoQwlTSwMdbJdFpC1CCu0bzlG5ivPJnRhF2XCekVLO0gQnFCGzLlPrECfdBoSSJ7D1X1ze
5SWrjTBiMsLRAX+FZARlIXFhB4Msm09nOQo0MIuwk7CNcGO3cHt04ECcQNj/cx5BFTBli2obHdc2
TcjfjXHg1PFy1YeyYD5nQy+NGWtiapms5Ed+hoBmlTHe1z5SEcmpl0iz69dwoUndbB/xTFsDqIiY
VdldqfqR1rL+T9S0UhMqqI6znro37/rmE/V4t+K1PcudeEH6yQWpL3bFntgXB+JQHMFrvRI9HMi4
4mtelLCGk0zU6XbrgKf9cDbpX1488j8vS16WlLv6tpQ8ds9Fc73lE/KEED0W2g1bMm7UvKz4tkNj
XcCD1I2MD1iW1TydtsrBPqTE9+DYK0+jP0J53tYa7r627ZTaRuoG3KXRDS6aR2HkUCv33j39HA2C
+I/mcXQ2zpd2wwby8BH7Girsw6xyWGZpipelh8lSh1y0MiH3+CuHLeTg4uOH93GWU7fg+zNLfNdd
Znuwb1pDSmqDBkbw4+PbxefgGtPyTdA2mOhP8SGMr7GiWB6aHS89qS9eYbzYERddjyf4h5UhuWJ8
F1LXKW26g10pVo0RI1oLpt6bYenYFw3YLj2yZPDiXyydqfRmKs+wlemod9B/1y8Ws40duPbHuSfE
yFSqe1Y+//qBNJnX1LEEuuau09qtWVqJaFiV5Ws1irWc0b2/Vm+/tCeR9xW3lBZ9iK7CPEJjet3f
Cupvz8GFzKj8lM2H0SigvhNtPLSA3DdlXssatm9rJrqsZWeLvZM6Ztj+30EaUVenih4Ij9z481oG
8/60hnHHYP9DHu54X+anzHZ9PvyYpWEWpjfh1kCp1BP4MruZ5N7ww/44T5mRq6nIrQI/ABFpN3tP
ltYtHhKHtpuKS2Gi1YtP88sXCbd6bWfPdnZWMML2fHvx+C4BlAvisWRq7nfQlbJRj3pkf/wnMB0U
ZFNUNtPpOC0P2lzQCnXaO6rO0O2PM9OO5If5yjJTnn3K7xAbq8LULxUZuhHvrxUnPkwytZLUpmp6
b8VJbRnQWEl1geBiM46lFU9TkTW4OaCig9oLJM65BGMRtIrEGeWfCuFSLxnC9SM588fzxwDjqA92
eO09XRWIrbZIRTuUtFLff9A9jY1+cpUxqmX72r1snRaMaO3WB826pVhP7el7Agt0e7I+2TCvg9+S
3N4VaIyBYY8WzmJlgXyY0X/gCGpaf5dQ7LQPtUTX3YmpHtaJeC/3nmGVT4yTGfZqvMCdKHYu89YL
7NEo7bqgzRYXaPwQUSwL77xZI6H9GcaucoAgzQJsO8RupWBxSS6bYetGercjPmE3YvPGt1fn/bcH
r9YrJj2pvAwsNA5gcaS18t9pUcHWqGGOPWaWfy8pdwcmq478bs9N3ajI4jo/KdWm6VLi+tSNrCPz
NVAoWXL7MkXLH2EgsEGTUQ2xW03aVoKOErCkdaPtxDwOnteR35HJqhbExpSwo8pFSGCX0STKoWQJ
AMGAspzlcgfsHHuKOz6Pg6XQBNg20/vAwOziY8mz2WAaqkrifDS+pkB3Wk1PEXphZ3A2n+S18stF
HDvJ7PSYNaBEnb52wm1UCynwTeJsGmWE01c7nx2ZvEECqIZxGIw6PU8/qntHbyvwCVaYmo5l/APO
xMOYOndXGF3XShfALx3B3gO6I4tuAGSdJgDTzQCVWTfWjhiLanO4inx2bQbDK2Q89c66I/M1GAZ1
Etdh9xtTKQ9ozvMhElOk4iHhitL5AYCibRpuN+NkhkiehekLStBNWJhgNEJImS3VOutY0BGZrbYx
JfSbUgbkfKY7OP0hZwWA3SbeEVXe68bZCXszGIV5mMKYkCkh2LuZhdxdN7ZOa5YYApKqbmSdmLVq
ixFhYxjSGvIVOCApAiLdqHaYnZ5AAGYqaf0BZ1Ei3XV/6uThVjYyKGKXji9ZVWueuB1HOJKMgf+T
K5y8IaFgL8MYexp5xfUKJicBbiSKu4yUSumSXpuVH24S5bPT/vHpucvLrrRiDbRGYEsAHRPCW1q9
/uEzwlK0tkqXTXOnVUc7iVT3oS7OGGO035GtiscFzvoTdEut30FT2/hj9Fiu3DbT0Me1PmW1rZPU
8CN2N984+TTUf1LI2E1htYxc3J2BxXlKxka1U5m5AiJcne1AoTalt3rNYAEQjiXositYq5T0NDMV
48DDMpla6V2fIXQ5JSkQ2AmiuWS3kWW3yuzBL8ktIUk/F7fuc3fA7Wj3yDv6KwSvHhHkPQKDwAZA
kNjDGk0YWMPJMGLobAbY5nPkzA2fSo/sxeFKZ2u7G7VEXHrRJe+0sV7eUs3PGKP9DnvgxxxBUR0K
W/AWdTJMSfbxq729w32OafPBr/rkNusb1RMrjxvSxsYY38E5RniqgQxaiDAeMocbtDjr/HxtAPEZ
jsmaQ3mmQwH4rVZ2SJORwswQbuDUN5ywdwe4b3UiyXY2Qy+LIATwML0OR88EYMNZlfmkQqQGy1ZX
TydJhhH6biK62hhbFCcsES2VZQ2hboH0AdnRJvKOHDyqi9YKb3B4YDPdRaLQAlurDR08WRPJ7UpC
NckjwPQP6+M2V3VvcaxnU15Q8ilPLydNB71LzsNIqvoPNjvXroy7Og1C1bC6JvW298HqKR/KqCvI
RhMwNV+qQp6Vm1UtQU6DO66zjxCs5xFOKGniiotmVx4HsjiVEs6Nzv6QJ9ugQZMSVNP163UiOtGD
tpX8GU3nU7H4fiUf6aO05yQazidBykytYiatx2DRoomF7ZpT9I3HeRN57c7wYEe8w4pPM4EOelCz
AALPFM0isNllMeA8Fa3L9wQr7p2HimBlkgyDxuCwZRV7jt1ro3AW4sZlXauOrNCmIpfR0ZMjN5d0
TRlx8DOsdSp7AGyTXVGA4SV0Wmcu/B85z8WBT0ksy5tye00p3VszrVe2VWWIHUnrq8d4vrd/VHn6
pkp5uzVG10oX769wdiNi7ABnmcXXQLxA/CJPNGt2Kr23ewfHa25qbaiyr1lvQNJOpz2X7cWmytBr
UlNj3iiQs6pCZXLN+k27/KweQU3txikuy1o4WC2jb4qOusZmvZxVprslPg8aXBeF9NJewHMVJmOR
xpSHYEr4eX/v+LA9i1G7s5NKB6oK3hLHq7WvUY5bZiaW22Kk/XSoJVk5iMWIagOyVA3MhGJ9Kxjm
tLVhISGZvQzlmjsU8IdNQtw7PDrs763XVLRBt6f5WibRLcGF3ygTaBqClnm4dBquW8xzmHMVuCBu
8Q6lOAYlcFiFq22922HL4KwslE5Nu9EyVKbTMjvtZixLWzuc4qHaJKSKyhzmUYQXCzqnGse1U9xX
WbculSlKS7tHMnlvaagDNFJnWCVNCZdEhH8G09kkRJcQxy1B5S4pNJKhqBoiZhnJ4+qLIJfy4lKp
30ruZCLyf3r4a5LCljniNG0uE1cLnsYrj+2K+dcdcTZHJJ5wMM4rdbKkGk1nCZbZaPfjUjGC5ZW8
JfpMGtaX7sv4dsQ/1lGn/BYIa3rVzHll6fUdnvbqSOKrDIA4EyNrLtuKaPbJgE2DGbcgFSVolgu9
RZQECPNjJGuyA0laRL346651q+bIfbFVyxa5SveoS6xaYWuckvOa5K7QDJz21w7bn8FXNiUsei57
7p7LPOx9RbyZzdBhhpBzcmcXx9ZdD7NWyjq95if3OOnszWhX9mt+YArysddb96NX357k1R5RRmzk
YCpTOlr+mxBkBGJDuaqy+BhlQBS/PecoodGqt9o2O1CLKpVgti2lo9WTIRxmIgX/ZfLcYh7veCFJ
JsEsk6rth2wOda/ByKoflIlvic8Dzs54Pz1aEJOYdykYm5TLZLrOYxFME4V7UJiEKrE2x9HuAkWN
mVDZPbaLYKs8leOMNK1pUpxc2szm2PnPpQfbC5EWW1rB0hgM0wTuCKLIgy7mEX4K5clgoisfy27K
3Dla1PWIcfoaZc61pXV24FeqorrYG9JsbNuth50vqr3l+TXVvOXE/zkaKOqSf2NPp6UOeucnDvvO
x2nIRR3ZgS7TsH6//1W3GeoifrmkI8vf1GyoNEJCaegikPSoKANZP8x6SNrJv9PvI2/RRYoEKixb
IK1LFIXz8nXYVUtye73+10bJb3eKaixxk0y5qKorhPvXaYgNxDSLDRE/mWrDdsouQaMfyDblhnsS
10hurUyiiYV7B7tnb+Qe16ffj1STMeH4jyaS2511bLSQSVkTiU5q0jZvcLXLy6aEsS1qNCTPmsbc
8rTYlu3nLeZYZakLs5hjvdORglV7HWv16JCU4J6hM+14t7XOtLisiC1F0jU+O4ppq0k4IpwM2aZI
mxFVAGR6tUxcpcl00cAITMAJAFRj/hKXxPLFBg5cAFvIjGMoAuXqKlpo9UIpeck8yZG12OlKOUzK
yL82+GXTv9I1EaFhdQ/kI/gteWoC0EHuhK0nEluAtjHi4vSEFvXg3LQHkR9EopXc8oWy+WWGFIvS
TQ3GhuVi41VC5s5y/CQtOGalZpBqk/dj1XYrx2iDapgmz36HTd5j4EQkXuBHhh8NyyDplaS92esf
vn2r8T5M0nxpHcnhY0vrn6UmWpBVZc2mRfiytTTz0ocAF26ux7jagLIBKRPtlIkfB+gzp+NTJuh9
YTT9kAtlOJwvSdEDRpaOTXt5FO6wfjChY/+wEes6jq4idG9wWC83CS6/Xh6HU7OxI96g3QTdRxEV
ke9Vh2xMxT04qBlWQ8OUu+/0lp7CNxEq1igi2BPg6BRVXcsPaiwCcoC6GgFPV7S7ALoM2XAMOTHT
jApvXSS3KLvqpnv+jnn2mcJ9JsOr5A5DHUc4m5p3p7Eblm5ZZONkPgHZk4xPmITBnmDNFwNRqAHy
jDU8N4azijetN+f2Ox0Jrtd0WRVjVC+RMjwBPOY6GwVpbOr8YqdUlVxWOsfOT4g6NDBBxMcKaOFP
QYnwdhhncyghF+5RRizrET5UFNmLhblxdD1GiGjqChwiyv8GyjHFn7JvjcTfLIr++u+fPhvqS0SQ
bsNMwLjjcAdDXypVe4mkQpnJrJQ9M5a1C1MxRdCLGDkYMWMMtRRMEzhlrIoBOxzwiLwHyqKQTQPi
a6LZuMTGNdt9qfea/WE+jEYBiX2WTEKKwDcWtDWhKL0ByFyA9Bf/KASSmiPlUodFVMlH4XdEAEuU
DZK0LqkGfOZC66wDg/WCg4ZzaAT6aLe6Oxg5HTXJAJXYnybAimUTW5xjTRtuVSE9AEKg3bXNH8UX
YZ0pTCqsXDBB3YMOvUFEHId/5oQxDnShfIxc/RPOwwHCEG3+x5Z/s0BiZ/Vqw0RxTfs62FcBCHOj
65jirUvpTuggTkPgEOsUgqOHhdKBHGaYJfMUgdSifZ28CXaf0JAW8FNKPBe1Ex6M8l1a0AFRa81z
pfGx893OZ8KVY7TLDeYY7Xc2VIjQLh33V9H1HGDBCP5/uplor0Jcnbt/usMRJ9MXt0icCEpvMTNi
+yZCJvT+d/FpfvkimdFsPYO3YJQ26C6a0BNEY1cR1orJKLFqYvs/P1loIK8Nc0xIpofiKiP/sfwI
L1/vCMJbP7E9DG1V0MlRPk9j/DbOhEDAmUP/YaFgOiTK3DCATaFkkQjiX65xWFRlSUOyCGIeE1Hb
9K1e9kyBuKFeiWvA8iW3yE/pambcaSSP1J9L+8jIplFxFdfiM8ToKyUmNI6bF8x1dRbOmBBgFzEk
WG8ktVRN/eff/w1LehPARtNPW+HjZ/ptGgHXZRgtjiZP7u3AEYLXFJpbrAerePdHQT2iedSutbuv
aisqmmRQ8DXbdcrVa54F4rDq0yHGWL/N0456Nk3xRP8ijUd34VC2bXXyaKg8HGg2jXLKk8nM6xr0
KuHzz2Dd1ZKPLmBJCHlVTtYvGsttFdnyA2vP+uLWL1JSm6Mgbdn7UifT+XnvuPemqD5XfB+zrL3I
O7lhs+l6TRyQ9Ni7/SudpM2XC0nUu7Pd/dN+QanBRvs32XOqDxtFh9mn/A5KqwrKv+CEKcTWe1sv
BzQaXQaw2WhcJB+osYtV9i7UX6baH4h//v1fjQXoylmyyPuA0JGN4DnsNo7oseaoksk/mD665uOh
M3KnszUTJe0zqgQtdNbwCZXsvrEYOcfZHXxkAZzCOYWKodgrk+5UlUwlQXoVFA6LoyEZIwVwrRLb
lYMRaswjf4Uc61S6afTicXHIcnoUC9BWWJnUVUUf7N3JsxbbZilV7/NWTnPbkOzK6/V7qi1PdddR
MyD4W+2PtR+mSxd+uKZnkMaxNELK4PhsFlW5L1y1qoBxCktBilpuLrAFUDdUVGEMOOueqg6IS2Pe
BBXld1QsL8uCtnHU6WA4rTbE+NbOaFyzBMRbpVEOM9FxZddhOsfY2/v9Z1XJgQ9DRxdyaw3DJGsV
NUIl2+nXrEH9EYaz31CaQmx0e5LNgiHZg9uT4AqVK1yeYibomFo5OcdRgFhNPAmyYRS93vpuNdXa
KG3v1e6rg6O22qxqAjrBf2V1b4NvtXsOJYnqdvuF8ffhzYXx7EV5FFqsZFjeLvsHdrvpKoGuRbYe
y4+mIu5KmhK4l3S/w//oVohv/Ex84ZcskfOTqkytFlZLgl2baWvqnAvFWNTUzhzE5oYUCnuBwkjU
XGa369z+JpVcfFlsL7JI9rrtYgMKa4l1UyiKTmR7XzG1hsn2s0oc4KCYZLpDFtuaOTcNdiGKhRhy
zKADBy+IiAyMPukKQXQtSihmVIjtPpL57f5uWQ5dinZKaYZzWrLd3yMe7nseyuJE9tdbqklU6ERT
OrzdPyAuHnouPpyL2/0j4uFxh3joY1AfrZys0zfeZEMMx6ZqGTo6kdEK1Tdk2Mzxs6UmXhA7JIhL
6/XuhViLOgekroiYpRyKhXR+87l5RaDQsSzOtDv82LIs7QWsgy+F5C1KB1ocUfO1yPQGsBvVoO1d
pGzI3HZ90qZWQx+WcGil3d5F+gZ2dil/87raoWDFsrLtOYPGxXKtDHy/CJP1yxQui5fWQLwIdkgE
OxAvs6hZQTPFLouwhUTwpQ+WfbD8nTaN1kDdsVh+sSwfTLhL5fE6u16muaUUeaBTXuYktNi7Ed71
0MXVSppCR8SqTupZysyb7b3aTSMu9Ja4vrhVsHJ7r0v5po9OuxSdFkK29MARazPoZARA3HSEgXXm
ukye+4EVumAsor2l+TEsjT2rrpVpuCSD2HlJpb34KfFrKb2pM2xLnkzXMmhXIs+mLmbQtsQH2JR1
N034rUSPWyYoTZFrBqJC3mij3tququtitbo97O3uvzvbKPQvghdghoU4jG6/R1AJ9OQCUIKvt4J5
nqy5c4+wT0+zKAC2yRRXmEZxkv5yim3tdOUNQaURsx5iPp+Ctto+n++0m/eJxjR43Fbfp6LyRGjI
jTjElvj0D2CvB7OxOLUMilEJfehO9CcaUI2b3mYIZCVRJWu5roVvdyQEYjLPaK+wiTVkzdYqpvHH
NP+9g/67SvCaI+sd3pHdPz88fXfAO5qVbXQtcqqcR0W2zp+b59H9Ma6rfBtyiLVO5zdCF0MJ9BkA
HBPC3M6qIBDKcLmEm7DATAAQyCVOByOkEcI5MRDM0H2CHhQCM0EbyjOCdgNYEoODAaxEHSahgeYY
+Uthiljq3RrLGuBWq80uQaE8BzDHcDJnGBjJor3+MwNvuBaCDtyzWFqch7TgJ1iFs6Nxqgfg94Jp
CX1NI74BsiYfzwnSWKLBArqGnYF1cSwePCPUP+65ovkxwVy2sVUf8HmnuSKIpGMJXEYDzeHnstkE
qHNAPJfggAC2j68xzwRoQ5+iT9DJIvgJhqIzxmOJB5BKi2NIJnfPGV2QRwyMO3VJuhxdthbtRuKT
VmHsMLoHSCmAn3nMxZUXRD3HRgPs2GChpW0Hl3fMhqwkyyYuD/OKOMRYOMw+IoTwgZaAUBkwiKF0
eZYuAeK6mChG09a4qzSPAN+5Huvfx5YmSRzEiVQK1K2CTVIPcWa/82N6Cdt/dGSMrZm8fHAO006i
bCE1hRKiT0FYQftU0CzVjS032xhbB0jjDaujhJk+Q69CoSDAEGh4BiXQZGhMvcKTGZ4zQjt9DU8U
HHyhVvTbO+K9BLOG3YL3Avw2Lo7f1ool/gMwZAsjYn1XBDAJ9KMAqCIHhkdL+MTGKFlBgwXEsqmh
ajykmhLqC5aDqP5IkJYa7FCe7Km7f76SlZO4WvRJOqyTbSjslCYeGMfidzm8kkWRlgTIpvRVDH11
MsvuVQdXlOu0DNy9tKbtVPkTIQyf7wGrDf1gJD5ChgP/5ZEuhYCuYpdty2SCNtvvsM1SWI3EjS5F
7yWISSN6t9/hMRrQk2qMK8FrEk9qmpx0rt8k8MaBejVX2a1cQskHlJr+Np9eIpKF5SA1z8SHECdY
Q4cBziYhMwVjaFoEVOY5Nj9MabDfWV0aVKFuM1W7DeUhDy3MbejnawXlc9lOT0Mc+BdH2XSRFyl0
ep2vAMpMRbUSsVpDRibD4TzNxOU8pygvBr7/9TxIccgTokGyFAss6cIRaZB8adHZA7BbUG5JmXgK
LlexK7a8/OiSVKlMNiCdyQL7HVYm9ZLDprW9cLA6z0UwI1FoKRKSVdRsGMZBGiV26GMFkYD7vGVI
0O9U6N6cjRgsbZlpKQpBj+kvdNbHb1yloRKKDgs5OYRFWeStONRIh9WHnCdScC3zxGMqvdB1ZDTe
P3xGSTnj8MsT0uRpZ+TF1C/tPVt/D53h3DupZT+DJfkeY/TAnsbeBUCbPgglZKn/xTWbb63De2DP
qwAFA8qXVzJ1rqtIS+6tOrqwJE094f4wunkJSE/6+8ZIA3zzxU7PVjFxVoO8rn6s679cn1Q9Lmuw
rs20lRg7bfNY+NQNJPFbmfIusLtMs2vSAN0uk+gSW5e75V1joDSIFg+9PXxIJ9jmkslVnZzh4si9
0R/dWnMJA+n1AQVNxseAYKvjAmrqtsTCL/TP4qHXhw7ta7BmzvHwwFJgQ4O9Cj8OzsarsG3vyIC5
79I8AK8JFPuwspAH4H08DwkK2gPwBhMdNT1UEj0A76hmtdDXgR5f/+5SnEfxCGVmfMNBH+UY8gXc
0VseCqa7UDAdE0UtiVoQpSji1S8kiV4QuyuIZFHMP0cEE9i7SuYWIsdCR69++eZFTh7+XYbBcq5S
bIoWwcR68N1NJBuaqx58N0WLmI+YsRkhoOb/LJmE+vwTlPB/roiZleIL3bLn0DrCT3yE0t0IxZGI
ZNUVtiI01gLokzVdFdJraUZt2aWFxpVn2H2JtBcjHVvQreOzI2wddLLphqyNIwysm18iEd7Y++Lu
+uJuCBkJWvHnEYxVJ8vD1mQMPnoEY92HTWUWtTru12Uen2UWMrb8wBGXttyT2ZXA1REG1sUEZfLc
Zyvq0RbRvtOvQ51+ywZm8Yo1q651AXJdizam4M8i1IvfDyJ+9rQ6KX9qKW5t+Vt3z5NrkIEdqZ8s
TJnbsmTQqR96sGWsY10s7/S8kNvqPNgy2ZwH9SO3iiv7nTAonmhMjwSoeCoq68CW3wiGTipALcYA
YdszoSx+Oj9WGSuuBeSzEooNcrjNAblvaIucNh+VLLB3128CyMdlFrgWWv6DQWMCgM78GU3nU1FA
XBEeIaGbbgPdV4JWAU9mFF7hXACgzSoESQUN9Fx8J1u7IfkDJtjgwDI4rk2DAEQkECzTICdcS0CI
zRKCHouCiQKuJHT0AkxMgYglCsoHZ2XsWKN7Ij1DFxz4qDLA8yQGMPTtSZANo+j11oe51RaDNzY0
l9/Tlvhy8srl5LWBs1WyYcmpc1qoMyK69wA4HgCnZMXY4GV/wZitrCcN+9ZNYaPHXOChE4d36PRw
vufCo3zJUpxVDLyFCQOSqVlz7ejKW8QNzLQ1dW7avMXh9YYUCjuqAOVajCzZaiMKqEV5LRXoHeQ2
1PmLBgfvf7Vkw6u1+5veyTCbOlLYatl6yk9tvfGz2qFFIksfHbQeJH76zxJDQw7lQw4brOF4QXTf
vHhMjcfH1h5T4/E89Jgam8jy6PgbgJMcW2bYsTh6sP5Bu1b4r3OCdfsMfGr5+NSyLFeOpWI6UOF7
qmVwXWNxI58zzq+PVmoRwLSCWVrn2ky7L4mLEgcksZDBHaFz8d7Xb4vMvOcz82qMg04Io2V38MQR
4QSshpY7vtdkQu7EFxR9LTJ9suZ+skYT6FE1NhEoa1UgfqLhgE6MtLTBx8wpeXwfM/9cMTOrBQXO
0nFoLSGH4XfydjhAKds216J5JWhWyEwiaMXK4qV66oNlgv1BwFYGBPPB8uZBkSCaHl/j4WzFcYPG
HxyJB4TotOp2xJMUMucBITwgRNNmq71Xu68Ojra05/SLCt+pjbqhgarQ1eUHjlgbDwjxRIiTWg3d
XXpAD4wllL5s2qFmq2UDs3jFmlXXGrG4JKP6AC1Cvfh1o2oPObOLG0Uxo9//ijfXntR1AxWPsvDw
Q7SlkbCmyDUDsbBjxaO2UBbgwze3IfgptpWTDSUrsrot9QgNzKyHmN6nmNDaXOM77Rp+ojE9ckvx
E1FZjf3WDNtQNq06DSCIlOO9/n5vd2utFYsnGurgNsrHZdpdJLR6TsTHIB/TQQJ5mkzKw+jIFNSM
7HQ2m0ThyBrUKua961GVH+PDtp06GB2vZUc2hHVQ6zjf3YQxYCKS+fVYNGB3FLgdszCdRnkejp4z
uMRwnETDUCRXJiCPnfMYDTdk9fePj85OT9ez+t+bCdNgFC4R3dI0DS7vRAywo0z2LwXxiFqYninw
DhHFmKZhMp0meBAPwywHgMp2//DZjngTZABUweuE+pGGwzCa5TQz9PTs9HcxDbMsuMaFr9JkWvcb
s3CYRzfh5E7OL30vA3yIyBN52STJxfaHNxfPxC2ARsQ4uAn5DRCcR3GQR0TXaJTitwTlKSLIsmQY
AY1khG/AKwWWcxKXUT4NZkSm7ghA1hzFo2iIawGphIjHcC+j2DL5JaHaO9g9e7PfllANlolrS3iu
9YSbEQAxOcM05qJatnYU+kufpmt0E6Z5lBF4TGnKmybg7Hz3/OyotQmwN544l8IHIoMsT4DFQ3EZ
+FqlLVAB0nvWmh2L1z+t7y9hmsm1g3dnu/un/ap1PfvjfJyY+jCpo4IdnH3K7zATCnjjlzAYYWr2
VNuNhibUMbL1i3SRGhCOd38G0xmuak1byUadHR4dHu8WdK966b3aiy5fYUBIeb+G6TVZTssCvGEz
m1n0rSlW5/v904NDTX/NYW0+3FIoVjWCQoe7RaMwhRtUiGciG4ZxkEaJdI/DJI7ZBUf5Xe3MGwCj
LTma6uxspEHddIAhQwBL6tozzoNbQqgrE6NV3VWeFuHbxyClQMwSEEBhZuPkNqaw8DuVwDYXew8O
3eU9mtneU+AMZMKyXpaJbknjBs/LhDgvuWWC2+JcY+pgQKE+NQAhwokBR3x7CLwJ1lbiZFLOJZU9
e84hoSt8tMOHUnjTLh+r/REy5/6z57jdxa3MpPc8wGUlQHlzfdQo2qgQ2e8fevz+IV7QdUS5axSo
WHPGgwYYy/IgtGuSKYrqxGzL/NvFgVWyHotsPZYfTUNamo4VBE0JHYNS0c1LeRI0oztIbLQvdmrk
57RLrXplY+G0IBpCKDp5oKzj3Ma+oTKF2uBaVrglIVnuD2+JkHqzSR2k9j42bw4f0r+0uUJH/Vwp
z7bs4OTh8uznvDpQMf7Bp9x6deg0/FNZ+p0zt4YKm7GBocDeofW8BtM62YY8Crlz9x2ah5t9PFSq
h5t9PA/RDHVASKm1i01OpBV2Taq9NdGaUNWjzWKVnlscfOWbWhaSSahdOvza4yvfXYryKKFAlULe
cMgn5Eu4pdefBPbEi+H3EMOlSN3lbEOJG8mclEIuhePZF37JUilfAepSQZyMi/lnTWV7sQFAZsm+
4UbLm5I18QUvWUR6eXM/QaOp9BCzGwlfiJXi/3p8WToI0EfJFq6SKl1vRMwsE9ueH6jJEVkJ7BuE
KCpWVjEK+w/vKhiBoJOQnp0UQSl1UjTpsRfA7gqgnMXFrfsCaa/FG12yLhQe62y5I2wddLHFxhHe
1Uytbfw6Io7LTUHOVWbgWGzW+hy4YzUXt/V24fL0Iw947AGPNwZ47BcUvsuCgtbV5XtHrM1yQytK
FVTHuXA5PCV2OsLAmjBriTz32YqqvsVTH8B0LIBZNjLyFWtWXasbfpE08pKSRagXvx9E/Gyr4qT8
qQXNteWveQ+gsQVaNWw6CIfivl+yzJo1Ra7JkkWpfNIWNjOvOz01gAGZbDJaq5tuj6/MzFKWfq2i
1hNB31bHt98JXOaJxrSMPOMi5wd1UMpvLSO4irJ13U890RjhCzcHaP/D7PYY/INwslZCgx1pwC+A
kBJSp8JOsuQVTlvHHIyx1Tvov+u3hRRZbd0YGyYiBL8pILaAVAogHkbEpTFZOHqEpFke3Vq2ZENS
UotE+LwDOGBHTnNQANd2nuUpIGsJkQmgnUkOqYiCicLgJXDFEUDXboN0xIieDJX6m8funJl63j8/
PH13oOEiLwyPZL/D/WPqJdIkdzOnlvR88D4XgKUDjvJ8CtMUlZXHZHrLOMhLQGstsazGyjO83xAo
2VDrIFegx4S9ZoIeQ+HvQ+fVyMgLoDaF3LsLdDF92V2CdLshW8FQ3DeYuoBhuAv0bQmOyaDY+W2y
AGmmV4DnuOR7rqJwgvmHKFwCahYowgXZ/FmTarxJkM902QWRCk0OTcB7GLLCFd8R8Pbxgn5N7eLL
C9hw5eSvgQ8eVzKJAb9B+u04Go7FKLq6QiABzMolFyqAZUmA1M9BJo2oQJVvHpYGFsfwwgC/AMhk
GqYxxB3xmTAc8f8oiUMxDaI4xz+aBuInMWQUEVL5sESVZC5IItTxjC5DGOrZfML0sbxIdD6CcMYU
gH4gnmMmomxMAYOBlc0fHgaxuAzFnCDZr8C4wmEgsKCf2LHUuDLete1k5y1o5RhVyUzbMMNL2O90
BG748WNUGNaGJ/RIe4/fb8i1OUvjnC4leqS9AIbXQGRW9oGtQPc0xK0oqKJovUOv0c0O32LHF6/S
0c2OvZqzioGzGglWs+zdm1M9Lmuwrk10dyyekj8lhMKOjowKksvsdpzb3/QBO72vzGaLXK/XD1mS
+d7FPGhF6U9b6sWRw+hDtk20Y9qy3HDmmpUUX5Rm9PpfvVIQB7q4Vc2aOaejexlqaVennpEaez1+
JHBcWQZ0kEaZxO5pv//2lWPrThVz3pJ1HNghl48H3I8HPOLe45GoPOLe43noEfc2AInmEfc0loiv
BX2PnUnl0KilMKNmZZaC38WfrETiefFAIe7hOcXJPlQZdDVLW0pxHJdDVW9ZlFtYAndIDL0UdlcK
F7ZGPnLEOuIUSiVwfMe0SRC+nW9e3rDFoaI25bIBwQR6xD0UYTa0gO8R93indkdXwXUxzi/hkcnK
/nqb2ZqhbVtta3fZadFz6S6M8ITryE8CTOPztO+Rp3UqQGaJJBFkMVSbakkCvQBWxipdMIE8p+aN
I7FxQ+XAzsQcW/+uo9sRtpbWfbrBPEd4VzO1L1U7QR+NNvoxWgukTlmk+1U2tcrWFcNozZ7jTQYk
bx4yzkPGbQwyzgf83yXgN2Mt+7Ej1ma5g8+bazt1f2A6X55f99n6RJBxblma/y8AAAAA///sWN1u
2zYUfpUDXXXA2siOE7vGHCBLm21AVxjJ7rZe0OKRRYQiBZKy4l7tHfaGe5KeI8pplcRFDGRpjNVA
QvH/O/885+OZh2a6EnqWDNPk4OSng2bq5q5tK26pSwucV/Ji7mZJmh6+Hr4+GiftTLfg3JrAxwif
KTVL3tWZkgLOrPFWY0ITxanxdyfotmbqP/bv55FtmJppgOtST30lMpwllUOPboXJCXz1xzSFSFmL
+llB/ytCP+CmB5RAV4y02rCfmT+eHI+HR8zSuxLZDL7BXNQ63F0+56Hz83SS/tyKr5PvFWL1Hq9D
FAexVpklnSXygCxwVopOJ6h5KlEz9futfj1hEue+BRe3GsyfKf8Gafqh1b+D2E8Hgw9RHXvgH6KJ
X1e6Tm1bdY5SZRP+rmdkZve43q1Si7Lp/vdE9Nz0q4c0dl6MBj/0MP8f1OohNMawmg5Hb9+c3Xj2
R7AnUi6tDMXJ4Sjlc7lzUWsaEHWwO7p1FD6ceiX+KLCkE0plrPuVo/ojhvcvfP5OzvIpsG21yXO1
rB32QzdZI/G7jdAccieHg1E63O3F9EQ0nYx7JrmrG3kqlFN4ey3KSiMYDI11V7B0oirg7Db6PWH7
llfsi06ZjvuO8plKZQsR//79z95aQ6NCcVul9scVwVwEsglKxpzVt8nYb8s4rSqtUPaIekhsfYQw
+k3Tn+80xjC673Lc1YX/1wWTUyrXKK1hQRHVBpSQO1tCKBCwC7TKbGLsj+14VliVoYdSSITFuh1T
hkoEJUolAoIwNB2sowMlrctsrSWIPMcstItNXS7Qgc1BaNpmRFArBGkb0wgnoSLf5WmhCCDoPSVW
QmmxoIh/g8xZG17BpaJ72tV0RevpQHmo0OWWoUBhq5eL9Utq+FY+if6MhWUtnCC8BM2aW4DuA4HX
yhOUiD1e/d7S66NAjZ6BYs/dQolZIYzyJZGnbeOB8ICzNXEmFwboA4JlfneoNWEVhuh2dqWYYQIW
whMpvE8ZiSaofM0pMnMGJDGLHpRhDU2Bhnb2+Q1lTWhLcYVARTFbO+KRxEx5RUW4DcFRhCyBPsGv
+vH6Xp8zGo/HR/emJ91MrB6RsOe9t29/3yXN84u4G+XQmpNU0V1gTrJiydJDe11RhiFjFSsBN1Vy
lrjf5CSmLNXykkuGzSwZDLvMpqDvowllOS2Iavm7YAzBVjQ+ismPU8uCrt50FzYEW37ua8y/mC2Q
lJxqX2MqidJBEeJNd1kHQnxTGcus5tpnV5PkLS0KabNfnJI0w3nXXIWMUB4eb2qsvuVUW5RcWLlu
P2hLXZLcTz4BAAD//wMAUEsDBBQABgAIAAAAIQADE7RupAEAAGUEAAARAAAAd29yZC9lbmRub3Rl
cy54bWzEVMtu2zAQvBfIPwi825SNPAzBcoDE6Tlw2w9gKComQnIJkrLqv+9SFBU0MQwjl1wk7Gtm
Z3el9f1frYqDcF6CqcliXpJCGA6NNK81+fP752xFCh+YaZgCI2pyFJ7cb65+rPtKmMZAEL5ACOOr
A0b3IdiKUs/3QjM/BysMBltwmgU03SvVzL11dsZBWxbki1QyHOmyLG/JCAM16ZypRoiZltyBhzbE
kgraVnIxvnKFu4Q3VW6Bd1qYMDBSJxT2AMbvpfUZTX8VDSXuM8jhnIiDVjmvt5ewNY71uA+tUts9
uMY64MJ79G5TcEJclOe4xwFGiKnikhb+58ydaCbNBBOv48P+p+XNcXk0cdMI9S4EZ7F5v6Wir8LR
IpAXljkWwBF0yaYms8WQZ9HEW212NSnLh9Xy8eYpZgyurWhZp8LnyHN03a1u75Y3CeTZRU5vGccB
Yjlrg8ArwtvvKyWjkOX1ZOw6hQ7WBSB0s6Z9ZVN5wsh9phD6YsLwHD+PU+o4mCBNNxzfr4yQlZap
x6zqs5zddwg92fIZ0TiG/H/Y/AMAAP//AwBQSwMEFAAGAAgAAAAhABA2cYgUAwAA5gwAABIAAAB3
b3JkL2Zvb3Rub3Rlcy54bWzMV21v2jAQ/j5p/8HK50ECbSmLGqoWWmnSPlR0+wFuciFWHduynWT8
+53zVliBoW10/QLK2X7uuXvunMvV9Y+ckxK0YVJE3mgYeARELBMmVpH3/dv9YOoRY6lIKJcCIm8N
xrueffxwVYWplFZIC4YghjBhicuZtSr0fRNnkFMzlAoELqZS59Tio175OdXPhRrEMlfUsifGmV37
4yCYeC2MjLxCi7CFGOQs1tLI1LojoUxTFkP7153Qx/htTi5kXOQgbO3R18CRgxQmY8p0aPmfomGI
WQdSHgqizHm3r1LHeEs0rVCQnDe0K6kTpWUMxqB10Sz2iKPgkO82gQ6iP3EMhW2fHZOcMtHDuPL4
Rf9evCGK5ze+fQf1EgjmYrZRTKQK7VohkgFFNbVSe2hiSeQNRvVGhY9Yrcky8oLgdjqeX9y5HbVp
ASktuH298uBMl9PJ5fiiAXnQzqlRNMYM4nGaWsAywuqvQs5cJOPz/mFZcDTQwkrPn135Vaia4w1G
x7NZQpvbUP92DbIzvlgKy0RR199jh9HFGjQsu7heB7T8H6HupHx02E7DXRKejSbzeS/hg1MhuAwu
Rnej3rgZ7Nb2Wtdgcvb5fEtX9WjXHDB7JeWRd9/eU048LJRWu3vMv3HKm5ixyPtaxCyhZI6XgeTg
PGc3wrxeaMN1IBuF0Am1xX7T205CS0hB420LLbO/p/RyKSN2rwwG/VuC/8K3dTd43VTYLkqDAV2C
NyNfBBFgse2fDWGCVBmLM2IzIBqVIUImQJghLp+2zmrdVz1lVw9nQbCY1P1Y9/neNJ8wCir2Mjwt
nRlwKKmF5J0niKyQZEXXRGpCY/dyIkoyYffRPm3Wdpfip70auiqb3EzOp7f9rXNagjP2rjLjOpCz
Z+BrYiXJaAl1h2ZslYFpmzSBlQY4mMI3bdSZzQrznsqLGLYSDCdUKiwmkolYA3UzWp1LhbMyvvMp
J6LIn0ATmR7M5ZuW4+5+SWQlKqoTvKkLnFZWe/meuFfwUyEjlOOMJnBgKsEMt2TfMXGhqRu/zOwn
AAAA//8DAFBLAwQUAAYACAAAACEANwGX/KACAACSBwAAEAAAAHdvcmQvZm9vdGVyMS54bWy8VV1v
2jAUfZ+0/2D5aZtEk5SWQVRSQWj7sq4Ro2+TJpM44M6xPdtA6a/fdT4ooIHYpO6F2Nf3nnPuh83V
9XPB0ZJqw6To4+DMx4iKVGZMzPr4cXLb6mJkLBEZ4VLQPl5Tg6+j9++uVmFuNYJoYcIlHMytVaHn
mXROC2LOpKICDnOpC2Jhq2deQfTPhWqlslDEsinjzK69c9/v4BpG9vFCi7CGaBUs1dLI3LqQUOY5
S2n9aSL0KbxV5Eimi4IKWzJ6mnLQIIWZM2UatOJf0SDFeQOyPJbEsuCN30qdwpZpsoJWFLySvZI6
U1qm1BiwjqrDDWLgH+OuC+ggNhGnSNjlbJQUhIkNjBuMvf5vmncGzfMqbs9BvSYCtYhgjExm60+i
3YJlaBUuCe/jdtAJet3e5QX23EEm04Ro+zB92trdEc6pXjchCZlR9HVRTGGi0YehtFYWSObI2T/u
wDwK9mtBAdjbRYYtKKqkwCKWwsLUOEYFJHBPsnEf+/4QxMUxbkwjmpMFt+7EH563B5dlaqqCUd/s
mtNG4q2UlupKy1PaWDWbza0zAn8dVlbDRuPkSyuBAUNOipb8h3MBQfBbeuhGgyNv+/6o45fkEDlo
HfPtxBfdTq/29fc9XcY2Cv5oJtNKaMVfeu6atiXtVSqBO+v73V673bkouXVd65emFEG3Ko55ic2u
zaVceec8i+fEpV6vJmsFQzilMxjLbXFvroQJY/WEPlv3iIVGkRR0KE0N1UuKI5QM7m4QQt8/ofub
8d3N7cP4fjBBrqybyAO9/J+FM1QRTSw9WLvzQRDE1bDULRAy0VLmUGy4MX/VPBt93h+rN2/TgYGh
IntNGXqiyl5s33sw1i/Uife/blv5Yhy//47PeWx44R81+g0AAP//AwBQSwMEFAAGAAgAAAAhAJa1
reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrY
sZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiK
rT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7
itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4a
j6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0
cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/
rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uAN
yOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwAN
ZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp
+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuv
Pv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5
OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9
SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6Z
VukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhH
vYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/l
bobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2
FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYp
Ni1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLK
jHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3X
YVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+
0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxB
R22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRb
WEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAI
jdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFu
lbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgq
uEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4
qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzf
e8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hD
vg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnL
zsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5Lcc
zdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAI/BMrJQBAAApAwAABEAAAB3b3JkL3NldHRpbmdzLnht
bJxX2Y7bNhR9L9B/MPRcjyVx0YJ4AltLF8y0RZ18AC3RthBJFCjanunX91JLPG7vBEGfTN7l8G4U
jz98fGnqxUXqvlLt2vEeXGch20KVVXtcO58/5cvQWfRGtKWoVSvXzqvsnY+PP/7w4Rr30hgw6xcA
0faxWjtn3cZ9cZKN6JdNVWjVq4NZFqqJ1eFQFXL6cSYPvXZOxnTxajU5PahOtoB2ULoRpn9Q+rga
PVNVnBvZmpXvunylZS0MBNyfqq6f0Zr/iwZHnWaQy7eSuDT1bHf13G9ZTulelS6/enxPeNah06qQ
fQ+Vbeox3UZU7QzT19+DM9bzqdproV/fgDxC2/5Wqllc407qAgoKPXddZ2UVpTyIc20+if3OqA5M
LgIOC/xJXZyEFoWReteJAqJLVGu0qme7Uv2uTKKaTkPwI+BBKdMqI//UFn7egUNVrp2ld280iYfD
Vjfr0Ve25Q1o2vwL5146w9w5wiB2wgy5wryXvY3KLv6COOc0XDcIeeCzMTirvWlc4roprmHEjzao
DycRxX14wD2C+mx9ssF9tkGUhqhPQlgYoZrcS1mOabzUI+k7GspDXJPzTYbG5ns05xQ7x6feJk9Q
DSMswH02npeg+dgm8Gkm7/tDmJ9uUTTq0jzgWATUJyFFM6VBEDA0ahoG6QbtNo3YNkc1jAYsnUb+
PmrGXLJFK8oiN91ssahZ7jOCngNDFSRodfiG0xBF4wkNOVrrwGVehkYdhNRPAyy29+9PsHGDd9By
QgO0CyHxqOtj54Q04BztaRgRgk9imAahi05ImHmRh1YnojTL0HOijBKO3sYo9xKGVnRLPJ6gU7UN
/YRlWKbbiCUU7XYSeBFDu5CkActQtCR3cx+NIIXhCdFapxsv3KD9SXM/x+cghRuHT3xGXZahM5px
QihatywkPkdjy1KfbtAZzT3yzlzD9aH4tzeHbxVDu51zeBvQ2YECcPxbledu6A5TBU+avfbw5jSx
JRz2XRtXObyji2Z8bBPR7HUlFs+WksBD1cR7/WVbtbN+L4Eaybea3Xk/K5fLUdE3oq5zeKtnBbCR
UVNWfZfKwwBcPwt9vCEP7WhijUqBGfz2Fc2yBql/1urcjahXLbpf2xLE84EepRNe1Zqnqpnl/Xm/
m71aYCZvVOe2/OOiLeDqVqBrbIBMSluhJ9Ee55dYtsvPO2t6jYta7yzhlM+i64CUgMn+6K2dujqe
jOfA1sCuFPrLsNkf/UnnDzrYWd2wEYXNDKynhTUYl2A1LW4yMsvITUZnGb3J2CxjNxmfZdzKTq9A
xeqq/QLEbl5a+UHVtbrK8pdZuHb+IxqL0J9EJ6Gvlr3BgKl4EEx0rl9cYvkCPE+WlQEu31VlI17W
ju+yoUeTdS1e1dnc2Voka9zdSRelMAJY49CqO2doHfwpuI/FssqigoHcvTb7G1l8GAOvq97sZAe8
0igNKQ+E86cB+fb34vEfAAAA//8DAFBLAwQUAAYACAAAACEAMyDWSJcNAABpdAAADwAAAHdvcmQv
c3R5bGVzLnhtbOxd25LbNhJ936r9B5bendH94oqcGo+ttavGjmONa58pihpxTZFakvJ48vVpNEAS
vIBsiNBa3t2kKrZAEgfoPji4NvLrb98PvvXNjWIvDJa9wS/9nuUGTrj1gsdl78vD6sW8Z8WJHWxt
PwzcZe/ZjXu/vfr73359ehknz74bW5BBEL+Mlr19khxf3tzEzt492PEv4dEN4NkujA52Aj+jx5tw
t/Mc903onA5ukNwM+/3pTeT6dgLg8d47xj2R2xMlt6cw2h6j0HHjGEp78Hl+B9sLeq+geNvQeePu
7JOfxOxn9CkSP8Uv/GMVBklsPb20Y8fzHqDgUMWDF4TRu9sg9nrwxLXj5Db27NqHe/ZW7RMnTqTc
Xntbr3fDEOM/Ic9vtr/sDYdpyh0rQSHNt4PHNM0NXnxZyyVZ9rKkDeS77NnRi/Uty+wGq5n+KVX3
WKg8/MKiHG0HDAc49i5xwYHgD4bje8zRw9k0/fH55EOCfUpCAYIZAJicLfwsWRz8Cl5ec5bAU3d3
Hzpf3e06gQfLHmJB4pf3nyIvjLzkedlbLBgmJK7dg/fO225dRkqR9iXYe1v3n3s3+BK72zz9jxVS
TOTohKcggeJPZ8gCP96+/e64R0YxyDqwmYc/sg98lm0s4WCBTl5eGp5QQsXEf6eQA+7DWpS9a7Nm
ZGH5G4Gw1qfOQENWI7kCmK9WWUfdsxh3z2LSPQskbzdbzLqXAsSzq0c4NyRW0p2ahA4nn2yH0aKB
suyLCotav6iQpvWLCkdav6hQovWLCgNav6g4vPWLin9bv6i4s/ELx0bhKrNohNYgNewHL/Fd9n2j
AA06Sp3oaqxPdmQ/RvZxb7GOtVzsJrFcnzYJragop+eL5TqJwuCx1SLQO7Ome7Ymvz0c93bswYim
xfTDjqZ/sDe+a/0j8ratUBNOvkqdcGBS24V98m3H3Yf+1o2sB/c796jG9x9Da81HGa2F6+jWe+9x
n1jrPXa5rWBThdHVluD533sx2qCxMU0VVWnLnOTDqYKX6sw/uFvvdEhNQxiNTLmea7i5BIFFbDbR
mLmo2rpaa8EcQKkC7y70q4D5E8rPOxf9/JmPKeXnXdGZ+RPKzzuuM/NHfjT7V1tp3tjRV4vUvGba
bfcu9MNod/LTNtAqDzPtFpxB0Kqg3Yiz/EkiMdNuwQX5tG4dB2ZuFJ5q+yLXUQ0UbXdwFGxs9Lpo
O6UkewONGmk7qIQ11MDqprUaQNqi+9n95rGFJ93OAFU6G2vWN+eKtkGHQxox/3EKk/YR81ChcFSU
9wEsjsSuRUMbKdoZFU2wh/duGh7t1s1pAHXr7zSAunV8GkAKfqhHOFkPSAfp3hVqYGmLcNZnIe3I
OjzT1uEMSE/wDfWShNGWovWquVDtJQko2g6q9pIEFG3vlHqurJckYBnrJQlYZnpJApB2L1kr3gQg
M+JNADIj3gQgM+JNAOou3u0g5sSbgKWtDZmmyuJNAMJXdCb2GZAs3gQgbW3gaidWiNJ+D3Npnsoa
EG8CiraDquJNQNH2jkq8CVj4ig4TSljZFIeAZUa8CUBmxJsAZEa8CUBmxJsAZEa8CUDdxbsdxJx4
E7C0tSHTVFm8CUDa8pAByeJNAMJXdLShVryx1V9cvAko2g6qijcBRds7JUHNRt4ELG0HlbAy8SZg
4Ss6ZBBYSG6dSpkRb0KNzIg3AciMeBOAzIg3Aai7eLeDmBNvApa2NmSaKos3AUhbHjIgWbwJQNra
UCve2BgvLt4EFG0HVcWbgKLtnZKgZjpHwNJ2UAkrE28CFvKls3gTgPCVc4F0amRGvAk1MiPeBCAz
4k0A6i7e7SDmxJuApa0NmabK4k0A0paHDEgWbwKQtjbUije2kYuLNwFF20FV8SagaHunJKiZeBOw
tB1UwsqkjoBlRrwJQEjMzuJNAMJXzgDCVqTjJjPiTaiRGfEmAHUX73YQc+JNwNLWhkxTZfEmAGnL
QwYkizcBSFsb2KlaOB1KPow6UJCAes4gPdVABhwqnEQFFBX87O7cCOKW3PqzINLp+VFHwLSGGogK
elCr+DoMv1q0Y9wjBUHIUN7G90I8wP2MZ3Jkw80a4gYefr+z3vFwl8p3SKniyRuIFZKDgzAYiYUJ
QTmT5yME6BzTc+QsNwgHYlFcIuAHo87eQ/iPCOJhH7OoHngRQ6hEMu6tC1T8O0S4bdN3+v3ZfDob
TniNIDKMZRIVYsGWvTvb9zaRx0qQxoAVEjH2q5DixMveg3eAmLiP7pP1OTzYAUOQorKw8C3VzSoo
DDrAOCa5inlgEdZsY0M41O8suqligADObNelQ4jX1zQ9hbnb2xE3SB4ukr4jYkZo9hThZV9d9/gR
8LGM7Mc9xJXF+Cs4HbjN4S/vM69gPBwYK3saZwFqGxfCCIEX4znuxol4tT4vbnhKWMja/Tc/LS4+
gJxESWodnEbt2f9qCPZjD9+KAEBGhEK8X+HLPN6PJefxfhvuojtecYedRE1LOZpOVguUIwwVxE4B
wuzw7GWezDYsoeavV7yyUvzgPE2R4gcxrSPhhkrCiYhFM4QbEghXHMmhKdUcnI8G474oogYHPT8n
johQ0aWlCJxsoyXmfn207EiXkZIuI05QM3QZmabL2zfD8a1w+Jl0EWS7EF1SPbwGFRP65UET7EiX
sZIuY5N0GRPoki9goLJoic1qPLidTHmJz2SPaB4XYg/mfn1i8/SScQj+W9cjjlfzwes3rKOt6xG7
c2+i5J4YCpqRqsn1c0+0tQtxD3O/Du4VRlzD8WjFQ//q+JXSbs1HXDMccXVUu6mScUI7zDBuev2M
Ey3sQozD3K+DcQ369p/nH78Eo27yKKbzZvg3u37+ifZ2If5h7lfPv3Gf/VvuXxOYpOfzzQePXZ/C
p5sdxW+uFD8xdTVDvvn1k080tguRD3O/DvIVultduhVuRxKLO/Gf0upGuq6DCzpQ4XOW0xZKUopF
LjOkXFw/KUUjvBAp05WoK5i9NvTIP4qiDiy22g7cusXEWLHALS5VyeJc8UqV8nK34uYVPqHNlu/T
JUex3FGZ6arbUsKuF2koJF4/0rgUb+ErfKZcs7IsWp3eXDzZ+HwBGf7yPmAryHBjHO/YcP9g+93m
gPD8zvX9D3bEDJeER/Wrvrtja+WQ0aCPm658KyLLahMmSXhQfx/hDSTKDMDEcmH4T1YJte2hZW7c
CK4Qa7D/x5BtVlY0DS5ewXQFD+CeNXzSZnV12QoEdk4xmGbNtnDKuzSF3YUyecVDa2DlalmS39pG
gGWv28NQsow/0NwD+v8WAbvKiZEv25NahWESQHw8XgZUdudOPLTYiJJbvORNeXNO9p+cbU6FLmqh
drXokPLNpWzZHirKNpLg8kA+SGY/6u8+FPcsmhqwUBtTxUxlD6Qv4GVNXRtVmhn6Wk9I1Nav3Ysr
7KJ222y9iEsq9M93/8se2KVtIMqOJKDpSg1BLWuXIb0wO1z0mtz63mO2WRyfjnD3qxN5R2ywoPdn
ja1ZX5ONUyqdER6nyR/X2UMWBrUF1Ht//clouLjlmiMauIfjAtarL3szuGUNYR24lg7E6WT74l4y
SIVK4yfqzq5wHKGhs0tbTMUC2YO6uqcP83ZWJ425LDZYYTpajFtONYSnyIPb3OCEAhP29BBDMZUd
ZLiTkrDU+c7zQMwc5LkZT2vnj67UYbXLjSy1mFrh0jeYTXPL1dm1bmTQv347FiiZ6RMbUMGcomyv
PU+uI5/c8GTz8Jxy06kbZdsYEiSlcPRmvhiNpmL/QTRVmGTgHc3wJ3AST7GwC6j47OgYAhvHUzj5
geWX3sERN2MxvrIYwdI+vAIcTPPr1Mer5YDKYcmGZY/wR2r+qvuHqpO4XcgOUnvj0n1zuzrUs5o1
5hpW73iyDqt5ThRWV6bI/7s0loxWpjF/1JXGPJc2Gl8zb3UUAebz/OhT2ZhME9h94cOu9hQZidMp
NcLATV0yqHR6qlYIfsBsuF0wNA3PDxGpDD8yZHhxsINoePkc0g81vNYZH03D8+M4KsOPDRlejCqU
hi8NVYoNQD7R80P9wDs0yRuXOy2j6UV+sEXlxYkhL4oJzM/txcJG2EX2/TV9x4+IqHw3NeQ7scv+
c/uuYb/oGjzJD1uoPDkz5EmxZf1f60ndnT/jYxF+bEHlxrkhN4qlmp/bjQUx1XXcRVaEGxYBxeib
HwBQuXdhyL1iH+/ndm+D3v4oZ9cvRLx7+HD/CRb28f83lbjbykIbe8EqvKGzOlHO/q4pIiv1fOGe
a0QrDmtnt/3Z22KYQ7o8Ji2lsWXyfCVtILpx1QuD+UhMLlVvDGdjoTyqN0bTdBFQ9cZ4UrPmVyjo
ZLxoKel0PGgp6Ww0bCnpfDgWEwtVSRcDvvSIK4/pCmahpAMIOWwp6qC/WLSUdTBYwNEEdLKqKIMh
FLflldEM9jebcxlPeXAD9HqAhIuznRZTsw3TSpSltM0Alss3/8qBlPDwrM2KdOdH3qzgaQZ79JIu
YMOtSH9ZGzp3ASVU7tKarkBIhVoXaqe7xS2gn9Y3j5H7XNFpTKyTZvW6u8p6wCLcfmHuxr+ApfjJ
ocIELd+igQNKEVvErxTqXfZEr2Rqj5fWO1rXtOW+QnCiMPTqwz+rleAZ1BN3atj/fBOOiEGZqw0q
NU786i8AAAD//wMAUEsDBBQABgAIAAAAIQCTfdVeCAQAANwVAAASAAAAd29yZC9udW1iZXJpbmcu
eG1szFjdbtMwFL5H4h2qSLlc/pq0XUWHBtsECBASQ1ynibtaxHbkuC295WV4BB6LV+A4zp8ztqQh
SLtZ5+Pj43yfzzn+khcvv5Nkskc8w4yuDNdyjAmiEYsxvVsZX25vzhbGJBMhjcOEUbQyjigzXl48
f/bisKQ7skYcHCcQg2bLPUxvhUiXtp1FW0TCzGIpojC5YZyEAob8ziYh/7ZLzyJG0lDgNU6wONqe
48yMIgxbGTtOl0WIM4IjzjK2EXLJkm02OELFT7mC99lXrbxi0Y4gKvIdbY4SeAZGsy1OszIaGRoN
IG7LIPvHQOxJUvod0j67xTw8AM8kUY99YDxOOYtQloH1Sk1WEV3nsb0LAmWIakWfR9D3LJ+EhJhW
YWR6tM6/OjwLDs9We9syVA0EuLiAZArXmeBhJD7uyEQbvY1XhpO70AzHMLcPE0jUV5ezwJ/NDVsu
JrtE4Pdoj5LbY4pKn9yaSKvyEiRNyjnHd84dxwvUTLKXExh+yr0g5bkonV3lBfl+QypjjCJMwiJ0
+lkck2rjNyiU9VMsg6i36Hu1zqzN76JyhwRthNok/cQlIkwlVGleGf7UM2CwDekdRFVjgG0flrkz
/MIWclEThptTNgYMr+JIh2GZ9UxPJMEcqryBRI47kXijIZk+jMQy68meYOYe9MoGGDnuBDMdDYz/
KBjLrOd74lnMfA2PHHfi8UfDU5fivTSDwwE8llm79ITkOg5cX40zyg2doILRQOXpnRfmw6Ass/bq
i8sN9JbgSkMnrtlouIq+e6+1QU+oDgtwWWbt2Bead673CFcaOqHNR4O26KoryEMFzTJr377ofF9v
Gq40dKJbjIbu/BR0llm79wUYLPQu4krDXwDCrdW48jsVgLrONAVwde7OL+ePKoDtcc1x/EGqgwd0
wNUsuLx+dX1d0QLdotQB8K9IkwgkQS4WnL5X6nqXJEhUEZuV//vHr8rek9H2NTOdaQlzWHKlGPgN
oyKDZw6zCOOV8flI1gx0JnS/S+BNM2AKsiJGmxCYKQ4nj/KQlGgzMZVhBchoUM9S9Y/ADDuVl7xy
JLpSFvUl5jXbcYz45CM6NNhpWaNsZbRM29NYyxu0lj/B+Kz9/vHzVN48FxJoCG9fQXxKWQsvSlVO
6bbTCFJJpBfY6Gk1oOC8xWIYQeNVXN5Ctdx5ChUHBTaMmHYhqX7Usv57xan6aibU06g4eH8bxpte
XYo13XZaxeXCSksr93+0pJOvuAAu2EEtabyKm+dENHPnKVQcvB8PI6ZVW4UCaFn/veLylystoZ5G
xc38gS1cr64hFXdf18JnI7jW4K/8kqWUUkP5vpXfedQnrUKJgaeUw9oy9Q3kr8tKNZgvg93hV32V
vfgDAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0
ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbg
u+A7lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9H
Az/n79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj
6nVdb3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrc
C7pr9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhABsNzqziAAAAVQEAABgAKABjdXN0b21YbWwvaXRl
bVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBasMw
DIbvg72D0d112iZdWuKUpHWg17HCrq7jJIbYDrZTNsbefQ47dcedxCchfT8qjh96RHfpvLKGwnqV
AJJG2FaZnsL1rcE5IB+4aflojaRgLBzL56ei9YeWB+6DdfISpEaxoWK9nCl8sXR9qquM4fwlSXFa
bxneV1mNm2rT7Fi+bTK2/wYU1Sae8RSGEKYDIV4MUnO/spM0cdhZp3mI6Hpiu04JebZi1tIEskmS
HRFz1Ot3PUK55PndfpWdf8Ql2uzUfy03dRuV7R2fhk8gZUH+qBZ+eEX5AwAA//8DAFBLAwQUAAYA
CAAAACEA3IICxTACAAA2CAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbMyVXW+bMBSG7yftPyDfrxiH
NB8qqdpsuZp2sXXqtQMmWMI28oHQ/PsdG8i6lqplmqoRhYTD8eHw+PXrq+sHVQZHYUEanZDogpJA
6NRkUh8S8vNu92lJAqi5znhptEjISQC53nz8cNWuc6NrCHC8hrVNSFHX1ToMIS2E4nBhKqHxXm6s
4jVe2kNo8lym4rNJGyV0HTJKL0MrSl7js6GQFZC+WvuWaq2xWWVNKgCwWVV29RSXmmz67oJ2rbnC
ru+kEhB8E23w3SjeJVRcGxAR5hx5mRDK8HNJZ3ROY/wy/BeT0FVKC25B1OdE2oVzrmR5GqLW1/X5
lazTYogfuZV8X4puDMgD3mhgTxOCr0/ZzXJBukiUkCVG3NFHGDbVHTgHftTsHPE5qa/jU6LdzuVg
BOv0o3yfYTdPz4j8OKm9KT2ppyDm+PoRAojoAoEwvFqMg2D/BsS53TOIqA89AzGgGQXxGN/bQWxN
Y6WwThyjNBhSmNEVcnAkGIpjiiyUyYTVHac/dJHLB5H9b6K4x4XkVj6MkpgPE/X7d4IueFObEQ4v
r4/hKb0IUNfvKgteyr2VoyAY3XkpOEnEKA48j4MYdQpoJcAkEjcOBfviVzh6B5KIXYAubqctkI7o
aqJTbLlCEPwFEs4rO8903jmNxHTPHCdBafwuJL42qcx4sMXdyqCjO0996p2M3qJnrvwWEiOOaUCm
uoV3PLZ8JAw3xRGG/0YY0WvC6PcS2PwCAAD//wMAUEsDBBQABgAIAAAAIQAESF3dkgEAADADAAAR
AAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACM
kstu2zAQRfcF+g8C9zIpOU0LwVbQB7JJDASNiwTZseTEYSORBDm27L/viLIVu/GiOw7v5ZkXZ1fb
tsk2EKJxds6KiWAZWOW0sas5+7W8zr+wLKK0WjbOwpztILKr+uOHmfKVcgHugvMQ0EDMiGRjpfyc
vSD6ivOoXqCVcUIOS+KzC61ECsOKe6le5Qp4KcQlbwGllih5D8z9SGR7pFYj0q9DkwBacWigBYuR
F5OCv3kRQhvPPkjKkbM1uPPU077cY7ZWgzi6t9GMxq7rJt00lUH1F/xxcXufWs2N7WelgNUzrSo0
2EA9429HOsX17z+gcLgeAxJUAIku1NlPt4KQ3WRfG9jS4CEkwkHuB/8Ku84FHQlyEhFFQ1TBeKR1
DilOLsjdyIgL2u+zAf1tdzbbe1efNMDG9L+k/pSyjmGv9dC7YCyCrktRiFxc5OXnZSmqqaiEeEov
jk00nrSNoWvQGc23GrZxUB6m338sr9k/vLIYeAdXGgtlHYHtvrf/Jk7LU+IBMAz39I/XfwEAAP//
AwBQSwMEFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACig
IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnM
SbVVinEMcNSLCPZRUgAL+CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi
3MQSILcoXT8/LS0zOdUlP7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD/
/wMAUEsDBBQABgAIAAAAIQCHoo2/TQEAADQEAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsU01v
wjAMvU/af6hyH2mZBqyiICHEaaeN/YCQuDRSE1dJaAe/fqZlG4wdVmnHneL44+XZL57O30wZ1eC8
RpuxZBCzCKxEpe02Y6/r1d2ERT4Iq0SJFjK2B8/ms9ubaZM2sHmBECjTR4RifeoyVoRQpZx7WYAR
foAVWIrl6IwIdHVbjnmuJSxR7gzYwIdxPOIOShGIgS905dkJrfkNWoNOVQ4leE9ETNnhGaEtmxFH
pWt/OqMm1Spjj+PJ6CG5T5I2vkG1X+qaYrUoqX/Gj9lGuCfIw4c3/vQ+623xg3uN1XXuAkNA881P
fBbKHd8IXzWWJsso0R8yRvMnoxKSZt3aEkukuYpdwI5GecasX+XmglG/WnfeeZ9S3orQNt2Zl3Ik
I9JiOI6H/3r0+gV/qUenS7snWAVt9AFW6BYOGw+OFoLiZ7s+ewcAAP//AwBQSwMEFAAGAAgAAAAh
AI5jaeXwAQAA7AMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAnFPBbtswDL0P2D8Yvjeyk61LAkXFkG7oYVsDxG3PmkwnQmVJkNig2dePshvH
2XaaT+Qj/fT0SPGb19ZkBwhRO7vKy0mRZ2CVq7XdrfKH6uvVPM8iSltL4yys8iPE/Ea8f8c3wXkI
qCFmRGHjKt8j+iVjUe2hlXFCZUuVxoVWIqVhx1zTaAW3Tr20YJFNi+KawSuCraG+8gNh3jMuD/i/
pLVTSV98rI6eBAteQeuNRBA/khzD2QDwyqE0lW5BlFPCh4xv5A6i+MRZH/AnF+oopvPFgrM+5uu9
DFIh2SfK649TKowQ/tl7o5VEslZ81yq46BrM7jsTssTA2biFkzFbUC9B41EUnI1T/k1bElPOSE4f
krwgd0H6fRSzeRI5pHyrpIE1GSAaaSJwdgb4Hcg03I3UJJofcHkAhS5kUf+i8U7z7KeMkGxb5QcZ
tLRI9qW2Puli4yMGUWk0xE21Pu/Ccds41h9E2TVQcNmYCHoNVLhU150Q7xu6G/5DbDkW22nopY7k
jMLhjD9Y16710h5F9uVZZttjRGgjzfENTcY/xwdfudu0Pm9+XoKjNXjSuN96qdKsFrMFTfG8EKMa
39LiQE0TPjGeAX5H5geTjqV/7Q7qU8/fhbRij/3jpe2dFPR1O3XCaC2GVyV+AwAA//8DAFBLAQIt
ABQABgAIAAAAIQCitGbRsgEAALEHAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAA6wMAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAC77TN9KAQAAzQUAABwAAAAAAAAAAAAAAAAADwcAAHdvcmQvX3Jl
bHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA8U+LnIM5AABy5QIAEQAAAAAAAAAA
AAAAAACbCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAAxO0bqQBAABlBAAAEQAA
AAAAAAAAAAAAAABNQwAAd29yZC9lbmRub3Rlcy54bWxQSwECLQAUAAYACAAAACEAEDZxiBQDAADm
DAAAEgAAAAAAAAAAAAAAAAAgRQAAd29yZC9mb290bm90ZXMueG1sUEsBAi0AFAAGAAgAAAAhADcB
l/ygAgAAkgcAABAAAAAAAAAAAAAAAAAAZEgAAHdvcmQvZm9vdGVyMS54bWxQSwECLQAUAAYACAAA
ACEAlrWt4pYGAABQGwAAFQAAAAAAAAAAAAAAAAAySwAAd29yZC90aGVtZS90aGVtZTEueG1sUEsB
Ai0AFAAGAAgAAAAhAI/BMrJQBAAApAwAABEAAAAAAAAAAAAAAAAA+1EAAHdvcmQvc2V0dGluZ3Mu
eG1sUEsBAi0AFAAGAAgAAAAhADMg1kiXDQAAaXQAAA8AAAAAAAAAAAAAAAAAelYAAHdvcmQvc3R5
bGVzLnhtbFBLAQItABQABgAIAAAAIQCTfdVeCAQAANwVAAASAAAAAAAAAAAAAAAAAD5kAAB3b3Jk
L251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAAB2
aAAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABsNzqziAAAA
VQEAABgAAAAAAAAAAAAAAAAAfGoAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAI
AAAAIQDcggLFMAIAADYIAAASAAAAAAAAAAAAAAAAALxrAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwEC
LQAUAAYACAAAACEABEhd3ZIBAAAwAwAAEQAAAAAAAAAAAAAAAAAcbgAAZG9jUHJvcHMvY29yZS54
bWxQSwECLQAUAAYACAAAACEAqchcqowAAADaAAAAEwAAAAAAAAAAAAAAAADlcAAAY3VzdG9tWG1s
L2l0ZW0xLnhtbFBLAQItABQABgAIAAAAIQCHoo2/TQEAADQEAAAUAAAAAAAAAAAAAAAAAMpxAAB3
b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCOY2nl8AEAAOwDAAAQAAAAAAAAAAAA
AAAAAElzAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAASABIAkQQAAG92AAAAAA==

------=_NextPart_000_01F7_01CAE62C.9C739350--


From samitac@ipinfusion.com  Tue Apr 27 14:59:03 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE173A67A4 for ; Tue, 27 Apr 2010 14:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.186
X-Spam-Level: 
X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=-0.149,  BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEXm7sFLZtGm for ; Tue, 27 Apr 2010 14:59:03 -0700 (PDT)
Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id CD2F73A6920 for ; Tue, 27 Apr 2010 14:59:02 -0700 (PDT)
Received: (qmail 92313 invoked from network); 27 Apr 2010 21:58:47 -0000
Received: from  (samitac@65.223.109.250 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2010 14:58:47 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: 0SruhaoVM1lJeBIquFcp8b40R_L_P4jLA.JJVRh9bgAmCyisw0FBjjTXIe45oIybZCX3tE8wNLq8jqAJfMcLQaw9H52NE.U6CMuLROAoevcJpgkuNLDFhvOs.yicEtMcs5ZtPLHLypAxsG7TxoIyQCusRQk9lhFjfKwEODCYlOMu9.xO1Dx6UmdckO0Fo.L.UUJyJrZBDTq6alK85SZVoqHuj0RxkiM_77m6b4wzBFv8m37NUk1EpQ1CgEWqlahe
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Richard Kelsey'" , "'Michael Richardson'" 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com>	<0a9b01cae5a3$79d6a320$6d83e960$@com>	<6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>	<87d3xl0zmn.fsf@kelsey-ws.hq.ember.com>	<11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
In-Reply-To: <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
Date: Tue, 27 Apr 2010 14:58:46 -0700
Message-ID: <0b9101cae654$cf441f70$6dcc5e50$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrmH3S2RPB7JdKlTIigDUHltJicrwANJt0w
Content-Language: en-us
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 21:59:03 -0000

> ND works fine, using link-local, one-hop multicasts.  RPL need not be
> involved.
> 
> If someone wants to run RPL on a node that uses neither ordinary ND or
> 6lowpan's version, then they will need some third variety of ND.  I do not
> see why this is an issue for RPL to address.  It seems quite out of scope.
> 
>                               -Richard Kelsey

[SC>] I agree with Richard's point. RPL should work independently on a IPv6
network with RFC4861.
If one wants to run 6lowpan-nd instead of rfc4861 for minimizing multicast
in the network and reducing number of signaling messages that IPv6-ND
requires, then RPL should run on top of it as well.

All other routing protocols run independently of the interface address
assignment and bootstrapping etc. - why would RPL be different ?

-Samita





From samitac@ipinfusion.com  Tue Apr 27 18:33:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA483A688A for ; Tue, 27 Apr 2010 18:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Level: 
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=0.199,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, TRACKER_ID=2.003]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF79vaAukPIe for ; Tue, 27 Apr 2010 18:32:59 -0700 (PDT)
Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id A9E1D3A680E for ; Tue, 27 Apr 2010 18:32:59 -0700 (PDT)
Received: (qmail 56089 invoked from network); 28 Apr 2010 01:32:44 -0000
Received: from  (samitac@65.223.109.250 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2010 18:32:43 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: 5xyBY8oVM1kGvjQQ_vCByoBxBaQW2rzRHN1NxAFbm0Ta2n5dUauop11.B40WB9HgHF4QGsym8y7kWKWPLMC6.xrwdMSKkgDprDDpBOBtvgxqd50gck4xrzOeN_8f.l45lg6iHXlPfl8KDwf79k67I4rTqeOhPr2udB_hHF.Sq6SZnZggFhtqC0A6dFdJXblRq6bNSuWYSYri783I10WunT710AINsMi8yTuhKIfa1GrVd.yCpJ153_VCA4hKlGB.YHR4ETcwtvBuZRl.4So0NXzLeYyZ6JPr
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Pascal Thubert \(pthubert\)'" , , "'Anders Brandt'" 
References: <7069.1272031181@marajade.sandelman.ca>	<6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com>	<11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com>	<4BD58ED9.8070401@gridmerge.com>	<6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com>
Date: Tue, 27 Apr 2010 18:32:41 -0700
Message-ID: <0ba701cae672$b2209360$1661ba20$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BA8_01CAE638.05C1BB60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrlSm/U7APPVbHwRv+yrlSiDVpjHAAVPWqgABkKmOAAF2Yj8A==
Content-Language: en-us
x-cr-hashedpuzzle: Bo2T Hgpx H4Bn JYDx MsI0 QZfd QyuS dEjQ iSUp lxu4 sGNe 1Qgm 1dYH 4Eq+ 7572 8yKg; 6; YQBiAHIAQABzAGQAZQBzAGkAZwBuAHMALgBkAGsAOwBlAHIAaQBrAC4AbgBvAHIAZABtAGEAcgBrAEAAbwByAGEAYwBsAGUALgBjAG8AbQA7AHAAdABoAHUAYgBlAHIAdABAAGMAaQBzAGMAbwAuAGMAbwBtADsAcgBvAGIAZQByAHQALgBjAHIAYQBnAGkAZQBAAGcAcgBpAGQAbQBlAHIAZwBlAC4AYwBvAG0AOwByAG8AbABsAEAAaQBlAHQAZgAuAG8AcgBnADsAegBhAGMAaABAAHMAZQBuAHMAaQBuAG8AZABlAC4AYwBvAG0A; Sosha1_v1; 7; {5E6E09A4-AFBE-41FC-9959-67B2093F9DAE}; cwBhAG0AaQB0AGEAYwBAAGkAcABpAG4AZgB1AHMAaQBvAG4ALgBjAG8AbQA=; Wed, 28 Apr 2010 01:32:30 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAGgAbwB3ACAAZABvAGUAcwAgAGEAIABuAG8AZABlACAAZwBlAHQAIABhAG4AIABJAFAAIABhAGQAZAByAGUAcwBzAA==
x-cr-puzzleid: {5E6E09A4-AFBE-41FC-9959-67B2093F9DAE}
Cc: roll@ietf.org, 'Erik Nordmark' 
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 01:33:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0BA8_01CAE638.05C1BB60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

Hi Pascal,

 

 

 

It does not appear that you're answering the right question. 

[SC>]  Let's talk about the question and problem first  and our
understanding with respect to ND and ROLL.

Is the intention of this discussion is to do address assignment to all the
nodes in LLN?

Do you assume that there are multiple IPv6-subnets in that LLN ?  Can we
consider a LLN comprised of a single 6LoWPAN or multiple 6LoWPAN?

 

The question here is that the authoritative routers need to disseminate the
PIO (and the RIO) to all routers in the subnet.

[SC>] 6lowpan-nd-09 assumes that all nodes in a lowpan are configured with
the same set of prefixes in a route-over network. Thus the on-link concept
of nodes in a subnet is not there.

However, The authoritative router determines the prefix for the lowpan and
the same prefix is distributed through the intermediate routers across the
Lowpan. This ABRO option can exist with IPv6-ND PIO option. If the
authoritative routers(6LBRs) are to support RIO (rfc4191), this should also
co-exist with 6lowpan-nd.  But this RIO should not be propagated throughout
the route-over LLN - rather it could be sent by  intermediate routers at
each route-over hop.

 

In that case, each DoDag parent might be able to send the RIO type
information to its children. 

However, in RFC4191, the default-router preference seem to be done with
manual configuration in case of multi-homed hosts, but in case of ROLL
networks - this has to be done based on some algorithm for auto-conf.

Is this something needed in ROLL type LLN that you folks like to see as an
extension of 6lowpan-nd ? 

 

 

Neither the 6loWPAN ND nor your ND simple has a good story for this.

[SC>]  The scope of  base 6lowpan-nd is to distribute the same prefix across
Lowpan while it allows different default-routers at each route-over hop .

 

Adding Zach and Erik here as well.

 

Thanks,

-Samita

 

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Samita Chakrabarti
Sent: Tuesday, April 27, 2010 2:49 AM
To: robert.cragie@gridmerge.com; 'Anders Brandt'
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address

 

Hi Robert,

 

As per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be
off-link and in that case, the packets are always forwarded to the
default-router  and direct delivery from host-to-host are not done.
6lowpan-nd auto-configuration always assumes that the nodes are off-link and
use the default-router to be the forwarder.

When RPL or a routing protocol is running, the default-router functionality
will be unlikely  needed  if all nodes are running RPL code. However, the
initial address assignment/dissemination among all nodes are still possible
using 6lowpan-nd simple mechanism for address dissemination and address
auto-configuration. But one can decide to choose some other mechanism as
well such as dhcpv6, static configuration etc.

 

-Samita

 

 

 

Not mix up as such but provide the option for it to be carried by
alternative means than RS/RA, which is (still) very 'on-link' centric. If
the routing protocol provides the ability to naturally disseminate
information, we should be able to use that.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 26/04/2010 2:17 PM, Anders Brandt wrote: 

Just to be sure I understand you guys:

 

Do you mean to mix up IP subnet/address assignment with the actual routing
protocol?

I would expect the IP address assignment should be agnostic whether mesh
under, RPL or RPLvX is the current routing engine?

 

Thanks,

  Anders

 

  _____  

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Robert Cragie
Sent: Monday, April 26, 2010 15:02
To: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address

Hi Michael, Pascal,

Good to see this being discussed! My preference would be:

Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.

This then makes DIO more a general purpose message with controlled
propagation based on DODAG. This then eliminates the need for some of the
more complex parts of ND for 6LRs/6LBRs which use RPL.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  


On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote: 

Hi Michael:
 
You're right. So back to basics:
 
- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.
 
What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?
 
What do you think?
 
Pascal
 
 
  

-----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
    

"Pascal" == Pascal Thubert <(pthubert)"  
>
              

writes:
    Pascal> Good question!
 
    Pascal> In fact we have the problem at 6LoWPAN, when wan a router
 
s/wan/can/ ??
 
    Pascal> safely announce a prefix for autoconf.  An answer can be,
    

as
  

    Pascal> long as it is still tightly coupled with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.
 
So, what I think you are saying is that having RPL nodes sending out
    

RAs
  

themselves is frought with issues, and there are some situations where
it is in fact the right answer?
 
But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and
    

you
  

then provide a proposed format for it.
 
Before we discuss the solution, I'd like to get clear agreement from
    

the
  

WG that I've properly understood the problem.
 
I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address
   b) announcing routability information out of the DODAG.
 
- --
]       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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys
 
iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
J
ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
RH
hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
VV+6L6J
o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA==
=eFYy
-----END PGP SIGNATURE-----
    

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


------=_NextPart_000_0BA8_01CAE638.05C1BB60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable














    


     =

    


    Hi
Pascal,
    


     =

    


     =

    


    


     
    


    It does not appear that you’re answering the right
question. 
    


    [SC>]  Let’s talk about the question and
problem first  and our understanding with respect to ND and =
ROLL.
    


    Is the intention of this discussion is to do address
assignment to all the nodes in LLN?
    


    Do you assume that there are multiple IPv6-subnets in =
that
LLN ?  Can we consider a LLN comprised of a single 6LoWPAN or =
multiple
6LoWPAN?
    


     
    


    The question here is that the authoritative routers need =
to
disseminate the PIO (and the RIO) to all routers in the =
subnet.
    


    [SC>] 6lowpan-nd-09 assumes that all nodes in a =
lowpan are
configured with the same set of prefixes in a route-over network. Thus =
the
on-link concept of nodes in a subnet is not =
there.
    


    However, The authoritative router determines the =
prefix for
the lowpan and the same prefix is distributed through the intermediate =
routers across
the Lowpan. This ABRO option can exist with IPv6-ND PIO option. If the
authoritative routers(6LBRs) are to support RIO (rfc4191), this should =
also
co-exist with 6lowpan-nd.  But this RIO should not be propagated
throughout the route-over LLN – rather it could be sent by =
 intermediate
routers at each route-over hop.
    


     
    


    In that case, each DoDag parent might be able to send =
the RIO
type information to its children. 
    


    However, in RFC4191, the default-router preference =
seem to be
done with manual configuration in case of multi-homed hosts, but in case =
of
ROLL networks – this has to be done based on some algorithm for
auto-conf.
    


    Is this something needed in ROLL type LLN that you =
folks like
to see as an extension of 6lowpan-nd ? 
    


     
    


     
    


    Neither the 6loWPAN ND nor your ND simple has a good =
story for
this.
    


    [SC>]  The scope of  base 6lowpan-nd is =
to distribute
the same prefix across Lowpan while it allows different default-routers =
at each
route-over hop .
    


     
    


    Adding Zach and Erik here as =
well.
    


     
    


    Thanks,
    


    -Samita
    


     
    


     
    


     
    


    


    


    


    From: =
roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Samita =
Chakrabarti
    
Sent: Tuesday, April 27, 2010 2:49 AM
    
To: robert.cragie@gridmerge.com; 'Anders Brandt'
    
Cc: roll@ietf.org
    
Subject: Re: [Roll] how does a node get an IP =
address
    


    


    


     
    


    Hi
Robert,
    


     =

    


    As
per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be =
off-link
and in that case, the packets are always forwarded to the =
default-router 
and direct delivery from host-to-host are not done. 6lowpan-nd
auto-configuration always assumes that the nodes are off-link and use =
the
default-router to be the forwarder.
    


    When
RPL or a routing protocol is running, the default-router functionality =
will be
unlikely  needed  if all nodes are running RPL code. However, =
the
initial address assignment/dissemination among all nodes are still =
possible
using 6lowpan-nd simple mechanism for address dissemination and address
auto-configuration. But one can decide to choose some other mechanism as =
well
such as dhcpv6, static configuration etc.
    


     =

    


    -Samita
    


     =

    


     =

    


    


     
    


    Not mix up as such but provide the option for it to =
be
carried by alternative means than RS/RA, which is (still) very 'on-link'
centric. If the routing protocol provides the ability to naturally =
disseminate
information, we should be able to use that.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 26/04/2010 2:17 PM, Anders Brandt wrote: 
    


    Just to be sure I understand you guys:
    


     
    


    Do you mean to mix up IP subnet/address assignment with the =
actual
routing protocol?
    


    I would expect the IP address assignment should be agnostic =
whether
mesh under, RPL or RPLvX is the current routing =
engine?
    


     
    


    Thanks,
    


      Anders
    


    =



     
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] =
On
Behalf Of Robert Cragie
    
Sent: Monday, April 26, 2010 15:02
    
To: roll@ietf.org
    
Subject: Re: [Roll] how does a node get an IP =
address
    


    Hi Michael, =
Pascal,
    

    
Good to see this being discussed! My preference would be:
    


    Allow =
DIO to transport existing PIO and RIO. Get rid of DPO  =
that's
    obsoleted by =
RIO.
    


    This then makes DIO more a general purpose message =
with
controlled propagation based on DODAG. This then eliminates the need for =
some
of the more complex parts of ND for 6LRs/6LBRs which use RPL.
    

    
Robert
    


    


    Robert Cragie (Pacific Gas & =
Electric)
    


    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    


    



    
On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote: 
    


    Hi =
Michael:
     
    You're right. So =
back to basics:
     
    - we have a problem =
providing Route Information Option (RIO defined =
in
    RFC 4191) and =
Prefix Information Option (PIO defined in RFC 4861) in =
RAs
    sent out by RPL =
routers.
    - we can expect =
that there are authoritative routers in the RPL =
network
    that already know =
what to do there. We could assert that they should =
be
    roots since roots =
are providing such info already.
    - we figure ripples =
and trickles are well fit to propagate the =
knowledge
    of those prefixes =
and the right to use it.
    - we have something =
like a RIO in RPL today called the =
Destination
    Prefix subOption in =
the DIO message.
     
    What can we do from =
there
    - overload existing =
DPO like I proposed. That's the minimum change =
but
    lacks some info =
present in PIO like lifetimes.
    - Define a new =
option for use in DIO that looks more like a =
PIO
    - Allow DIO to =
transport existing PIO and RIO. Get rid of DPO  =
that's
    obsoleted by =
RIO.
    - =
other?
     
    What do you =
think?
     
    Pascal
     
     
      =

    


    -----Original =
Message-----
    From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]<=
/span>
    Sent: Monday, April =
26, 2010 2:38 AM
    To: Pascal Thubert =
(pthubert)
    Cc: IETF ROLL; Erik =
Nordmark
    Subject: Re: [Roll] =
how does a node get an IP address
     
    -----BEGIN PGP =
SIGNED MESSAGE-----
    Hash: =
SHA1
     
     
        =

    


    


    


    


    


    "Pascal" =
=3D=3D Pascal Thubert <(pthubert)" <pthubert@cisco.com>>
               &=
nbsp;  
    


    


    


    


    


    writes:
        =
Pascal> Good question!
     
        =
Pascal> In fact we have the problem at 6LoWPAN, when wan a =
router
     
    s/wan/can/ =
??
     
        =
Pascal> safely announce a prefix for autoconf.  An answer can =
be,
        =

    


    as
      =

    


        =
Pascal> long as it is still tightly coupled with an =
authoritative
        =
Pascal> router that owns that prefix, the coupling insuring =
that
        =
Pascal> both routers are still in a same subnet.  Typically a =
RPL
        =
Pascal> instance could tie together a =
subnet.
     
    So, what I think =
you are saying is that having RPL nodes sending =
out
        =

    


    RAs
      =

    


    themselves is =
frought with issues, and there are some situations =
where
    it is in fact the =
right answer?
     
    But, I think you =
are saying, in order to cover all situations =
more
    clearly, we are =
going to overload the Destination Prefix option, =
and
        =

    


    you
      =

    


    then provide a =
proposed format for it.
     
    Before we discuss =
the solution, I'd like to get clear agreement =
from
        =

    


    the
      =

    


    WG that I've =
properly understood the problem.
     
    I do wonder if =
adding the (R) flag is better than having a new =
option.
    It seems that there =
are really two distinct activities =
here:
       a) =
configuring a local address
       b) =
announcing routability information out of the =
DODAG.
     
    - =
--
    ]       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.o=
n.ca/
    |device =
driver[
       Kyoto =
Plus: watch the video
    <http://www.yout=
ube.com/watch?v=3Dkzx1ycLXQSE>
           =
            &=
nbsp;  then sign the petition.
    -----BEGIN PGP =
SIGNATURE-----
    Version: GnuPG =
v1.4.9 (GNU/Linux)
    Comment: Finger me =
for keys
     
    iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
    J
    ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
    oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC=

    RH
    hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
    VV+6L6J
    o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
    TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA=3D=3D
    =3DeFYy
    -----END PGP =
SIGNATURE-----
        =

    


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

    


    


    


    


    





------=_NextPart_000_0BA8_01CAE638.05C1BB60--



From samitac@ipinfusion.com  Tue Apr 27 18:48:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE04C3A6782 for ; Tue, 27 Apr 2010 18:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.186
X-Spam-Level: 
X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=-0.149,  BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vy0tO7HxRAJ for ; Tue, 27 Apr 2010 18:48:42 -0700 (PDT)
Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 0F0313A67FD for ; Tue, 27 Apr 2010 18:48:39 -0700 (PDT)
Received: (qmail 12331 invoked from network); 28 Apr 2010 01:48:25 -0000
Received: from  (samitac@65.223.109.250 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2010 18:48:25 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: evi30wcVM1ljoHSkHnl1M.8RnyHvja1QJNh2i_L4FfCtyYEcBF1S0QSd6WGwSBlo3OAU_YbF3gBZLETcZ8iAJqgnacDoKlzL2LhRCYcBXcAOdQK9oNE6wKMpnzK4rRHeXSRv5gDpDATDfmfq2DnFQfs7NrWAcBlSwzTQcUpQqV0Ga6HM3y9rAW4H2bMxGwaHGHJuA3vftqdDxBFb1aR1x6r.dFi6mhQoOhyec_eD6f.R.qp2omxihzXDJgTmMlLl
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: , 
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <7666.1272375794@marajade.sandelman.ca>
In-Reply-To: <7666.1272375794@marajade.sandelman.ca>
Date: Tue, 27 Apr 2010 18:48:23 -0700
Message-ID: <0bb201cae674$e36fcbf0$aa4f63d0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrmD4jyAiRAkLMaQ7aUYx2ITOOUdwAUL7Gg
Content-Language: en-us
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 01:48:42 -0000

Hi Michael,

> 
> As Pascal said, you are answering the wrong question.
[SC>] Please see my response to Pascal on this. Also please see below.


> The question is, rephrased against above:
>     a) where does the default router come from?
[SC>] 
[SC>] The base 6lowpan-nd (aka nd-09)  assumes that same prefix(es) are
disseminated throughout the LowPAN by copying the PIO option originally sent
by  the 6LBR(s). However each 6LR(intermediate routers, in RPL, it could be
a DODAG parent) creates its own RA and send it to its requesting neighbor.
Thus if one wants to add default-router preference, it should be added to
6LRs. If multiple 6LBRs are present, then the preference bit should be added
there too for its immediate neighbors.

>     b) or more to the point, where does the contents of the RA come
>        from?
> 
[SC>]  See above. PIO, ABRO come from 6LBR(the authoritative router). Since
default-routers change at each route-over hop, a fresh RA is generated by
each responding 6LR which attaches the received PIO/ABRO from its
parent/default-router.

BTW, 6lowpan-nd-09 does not do periodic RAs, instead it waits for the RS
message and then sends unicast RA.
However, I don't see that passing destination route-information via RIO
option is in scope of basic 6lowpan-nd, but preference bit in RA header
makes sense to me.


Regards,
-Samita



From zach.shelby@sensinode.com  Tue Apr 27 13:36:41 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5058C3A69C2 for ; Tue, 27 Apr 2010 13:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcIUIgBO9gwz for ; Tue, 27 Apr 2010 13:36:40 -0700 (PDT)
Received: from smtp-68.nebula.fi (smtp.nblnetworks.fi [IPv6:2001:1bc8:100c:f220::66]) by core3.amsl.com (Postfix) with ESMTP id 3F3853A6943 for ; Tue, 27 Apr 2010 13:36:34 -0700 (PDT)
Received: from webmail3.nebula.fi (webmail3.nebula.fi [83.145.246.137]) by smtp-68.nebula.fi (Postfix) with ESMTP id A430143F07B6; Tue, 27 Apr 2010 23:36:19 +0300 (EEST)
Received: from 84.34.7.52 (SquirrelMail authenticated user sensinodecom1) by webmail3.nebula.fi with HTTP; Tue, 27 Apr 2010 23:36:19 +0300 (EEST)
Message-ID: <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi>
In-Reply-To: <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
References: <7069.1272031181@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com> <11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> <11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com>
Date: Tue, 27 Apr 2010 23:36:19 +0300 (EEST)
From: zach.shelby@sensinode.com
To: "Richard Kelsey" 
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Mailman-Approved-At: Wed, 28 Apr 2010 00:43:36 -0700
Cc: roll@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Apr 2010 20:36:41 -0000

Hi Everyone,

Let me jump into this thread - just to make things more interesting ;-)
First, I recommend everyone goes and reads 6lowpan-nd-09 which was
submitted today. When it comes to ND, you need to separate two interfaces.

1. The host-router interface

Hosts know absolutely nothing about RPL (nor should they). Thus in this
case ND* does the job, and RS/RA is used for obtaining a prefix and
initializing its addresses. I think some people in the thread are
referring to this.

2. The router-router interface

As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than hosts
in how they obtain prefix information (among other things). nd-09 does
include an optional technique for an authorative border router to
disseminate PIOs and CIOs (Context Information Options) between the border
router and all routers in the LoWPAN using RAs. It is actually a decent
mechanism and improved over early versions. The draft clearly states that
it is optional as a routing algorithm may already do this. So Pascal is
correct in that respect. I haven't followed the thread well enough to have
an opinion if RPL should do that.

Routers will also find other features of 6lowpan-nd-09 useful, for example
during initial bootstrapping, to maintain their default router and
neighbor caches, avoid the need for address resolution, and to perform
NUD. The draft (tries to) clearly state when features are required or
optional for a router.

Zach


>> From: Michael Richardson 
>> Date: Tue, 27 Apr 2010 10:38:47 -0400
>>
>> >>>>> "Richard" == Richard Kelsey  writes:
>>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
>>     >> (pthubert)" 
>>     >>
>>     >> The question here is that the authoritative routers need to
>>     >> disseminate the PIO (and the RIO) to all routers in the subnet.
>>
>>     Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR)
>>
>> I can only speak for OSPF and ISIS.
>> Neither deal with multi-hop subnets or with any kind of address
>> assignment.
>
> Why should RPL be any different?  Yes, it will be run on
> multi-hop subnets, but I still do not see how this affects
> the routing.
>
>> Both were written when multicast was very new.
>
> I am not sure how RPL's handling of multicast matters here.
> While RPL is required to route multi-hop multicasts, ND
> uses link-local multicasts, which do not require routing.
>
>> Richard> I understand that multi-hop subnets are a
>> Richard> problem for ND, but I don't see how the routing protocol is
>> Richard> affected.
>>
>> RPL either requires 6lowpan, or it doesn't.
>
> RPL should work fine with ordinary ND.  Why would it require
> 6lowpan?
>
>> If it doesn't, then it has to provide for ND to work, or
>> for another protocol to replace it.
>
> ND works fine, using link-local, one-hop multicasts.  RPL
> need not be involved.
>
> If someone wants to run RPL on a node that uses neither
> ordinary ND or 6lowpan's version, then they will need some
> third variety of ND.  I do not see why this is an issue for
> RPL to address.  It seems quite out of scope.
>
>                               -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>



From root@core3.amsl.com  Wed Apr 28 00:45:02 2010
Return-Path: 
X-Original-To: roll@ietf.org
Delivered-To: roll@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 001563A67E5; Wed, 28 Apr 2010 00:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100428074502.001563A67E5@core3.amsl.com>
Date: Wed, 28 Apr 2010 00:45:01 -0700 (PDT)
Cc: roll@ietf.org
Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-06.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Apr 2010 07:45: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           : Routing Metrics used for Path Calculation in Low Power and Lossy Networks
	Author(s)       : J. Vasseur, et al.
	Filename        : draft-ietf-roll-routing-metrics-06.txt
	Pages           : 29
	Date            : 2010-04-28

Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad-hoc networks that require the
specification of new routing metrics and constraints.  By contrast
with typical Interior Gateway Protocol (IGP) routing metrics using
hop counts or link metrics, this document specifies a set of link and
node routing metrics and constraints suitable to LLNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-06.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-roll-routing-metrics-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-28004254.I-D@ietf.org>


--NextPart--

From jpv@cisco.com  Wed Apr 28 03:20:16 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ACC3A6971 for ; Wed, 28 Apr 2010 03:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.331
X-Spam-Level: 
X-Spam-Status: No, score=-10.331 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJO5bfSUthUU for ; Wed, 28 Apr 2010 03:20:09 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6CBB13A694F for ; Wed, 28 Apr 2010 03:19:49 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: None : None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAOuo10tAZnwN/2dsb2JhbACBPpsvcaQ3miuFDgQ
X-IronPort-AV: E=Sophos;i="4.52,287,1270425600";  d="scan'208,217";a="105990398"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2010 10:19:31 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3SAJUaT010921 for ; Wed, 28 Apr 2010 10:19:31 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 05:19:30 -0500
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 05:19:29 -0500
Message-Id: <7D618C1A-C97D-48F7-B819-15B6378C7ED3@cisco.com>
From: JP Vasseur 
To: ROLL WG 
Content-Type: multipart/alternative; boundary=Apple-Mail-155--62550400
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 12:18:29 +0200
References: <20100428074502.001563A67E5@core3.amsl.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 10:19:29.0988 (UTC) FILETIME=[49CCD040:01CAE6BC]
Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-06.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Apr 2010 10:20:16 -0000

--Apple-Mail-155--62550400
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Minor changes, reflecting the recent discussion on the list.

Thanks.

JP.

Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: April 28, 2010 9:45:01 AM CEDT
> To: i-d-announce@ietf.org
> Cc: roll@ietf.org
> Subject: I-D Action:draft-ietf-roll-routing-metrics-06.txt
> Reply-To: internet-drafts@ietf.org
>
> 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           : Routing Metrics used for Path Calculation in Low  
> Power and Lossy Networks
> 	Author(s)       : J. Vasseur, et al.
> 	Filename        : draft-ietf-roll-routing-metrics-06.txt
> 	Pages           : 29
> 	Date            : 2010-04-28
>
> Low power and Lossy Networks (LLNs) have unique characteristics
> compared with traditional wired and ad-hoc networks that require the
> specification of new routing metrics and constraints.  By contrast
> with typical Interior Gateway Protocol (IGP) routing metrics using
> hop counts or link metrics, this document specifies a set of link and
> node routing metrics and constraints suitable to LLNs.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--Apple-Mail-155--62550400
Content-Type: multipart/mixed;
	boundary=Apple-Mail-156--62550400


--Apple-Mail-156--62550400
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Minor changes, reflecting the =
recent discussion on the =
list.

    Thanks.

    JP.

    =

    Begin forwarded message:

    Date: April 28, 2010 9:45:01 AM =
CEDT
    To: i-d-announce@ietf.org
    Subject: =
I-D Action:draft-ietf-roll-routing-metrics-06.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 =
          : Routing =
Metrics used for Path Calculation in Low Power and Lossy =
Networks
    	=
Author(s)       : J. Vasseur, et =
al.
    	=
Filename        : =
draft-ietf-roll-routing-metrics-06.txt
    	Pages =
          : =
29
    	=
Date =
           : =
2010-04-28

    Low power and Lossy Networks (LLNs) have unique =
characteristics
    compared with traditional wired and ad-hoc networks =
that require the
    specification of new routing metrics and =
constraints.  By contrast
    with typical Interior Gateway Protocol =
(IGP) routing metrics using
    hop counts or link metrics, this document =
specifies a set of link and
    node routing metrics and constraints =
suitable to LLNs.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr=
ics-06.txt

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

    Below is the data =
which will enable a MIME compliant mail reader
    implementation to =
automatically retrieve the ASCII version of =
the
    Internet-Draft.
    =

--Apple-Mail-156--62550400
Content-Disposition: attachment;
	filename=mime-attachment
Content-Type: message/external-body;
	x-unix-mode=0666;
	name="mime-attachment"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
    Content-ID: <2010-04-28004254.I-D@ietf.org>

    


--Apple-Mail-156--62550400
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit


    _______________________________________________
    I-D-Announce mailing list
    I-D-Announce@ietf.org
    https://www.ietf.org/mailman/listinfo/i-d-announce
    Internet-Draft directories: http://www.ietf.org/shadow.html
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

    
--Apple-Mail-156--62550400--

--Apple-Mail-155--62550400--

From jpv@cisco.com  Wed Apr 28 04:06:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EBF3A6B74 for ; Wed, 28 Apr 2010 04:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.292
X-Spam-Level: 
X-Spam-Status: No, score=-9.292 tagged_above=-999 required=5 tests=[AWL=1.307,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKH2M8ExcZH6 for ; Wed, 28 Apr 2010 04:06:41 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BAA3F3A6B62 for ; Wed, 28 Apr 2010 04:06:41 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAP6y10urR7Ht/2dsb2JhbACcbnGkOpoxhQ4EjyI
X-IronPort-AV: E=Sophos;i="4.52,288,1270425600"; d="scan'208";a="121749609"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Apr 2010 11:06:29 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SB6QOt026179; Wed, 28 Apr 2010 11:06:29 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 13:06:26 +0200
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 13:06:26 +0200
Message-Id: <00EDBF30-7C9D-464F-AB35-AAB187F1C8BC@cisco.com>
From: JP Vasseur 
To: Omprakash Gnawali 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 13:06:24 +0200
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com> 
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 11:06:26.0434 (UTC) FILETIME=[D8885E20:01CAE6C2]
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 11:06:42 -0000

Hi,

On Apr 13, 2010, at 6:44 PM, Omprakash Gnawali wrote:

> On Tue, Apr 13, 2010 at 12:34 AM, JP Vasseur  wrote:
> ...
>>> 2. Towards the end of 4.3.2:
>>>
>>> "The ETX object may be used as a constraint or a path metric.  For
>>>  example, an Objective Function may indicate that the ETX must not  
>>> be
>>>  below some specified value."
>>>
>>> Should be: ETX must not be more than some specified value.
>>>
>>
>> Good catch, will fix it.
>
> The ETX Objective Function proposes a threshold. While I was working
> on ETXOF, the difficulty was coming up with the "right" threshold for
> both link ETX and path ETX. This might be a configuration parameter
> but it is not clear what the default value should be. It will be great
> to get feedback from the WG on what the default should be.

It is application dependent, and does not need to be standardized.  
This is not a protocol
parameter either, so no need to suggest a default value.

Thanks.

JP.

>
> - om_p


From prvs=727202196=mukul@uwm.edu  Wed Apr 28 10:46:43 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AACB3A6BEB for ; Wed, 28 Apr 2010 10:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.032
X-Spam-Level: *
X-Spam-Status: No, score=1.032 tagged_above=-999 required=5 tests=[AWL=1.218,  BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xbrpL4skGtC for ; Wed, 28 Apr 2010 10:46:42 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 3FAB53A68D5 for ; Wed, 28 Apr 2010 10:46:42 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 28 Apr 2010 12:46:27 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 333FA2C38011; Wed, 28 Apr 2010 12:46:27 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 2d8BjDoNtCCT; Wed, 28 Apr 2010 12:46:27 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0233D2C3800E; Wed, 28 Apr 2010 12:46:27 -0500 (CDT)
Date: Wed, 28 Apr 2010 12:46:26 -0500 (CDT)
From: Mukul Goyal 
To: roll 
Message-ID: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <20100428174038.4A9903A6B04@core3.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 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: charliep 
Subject: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 17:46:43 -0000

Hi all

The following draft has been submitted for WG's consideration. It describes the additional mechanisms required to support P2P routing in LLNs. The draft first provides a high level description of the mechanisms and then proposes one way of realizing these mechanisms in RPL.

Regards
Mukul

----- Forwarded Message -----
From: "IETF I-D Submission Tool" 
To: mukul@uwm.edu
Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada Central
Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 


A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.

Filename:	 draft-dt-roll-p2p-rpl
Revision:	 00
Title:		 Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks
Creation_date:	 2010-04-28
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This draft presents mechanisms to determine the end-to-end cost of an
existing route and to discover/establish "on demand" one or more
routes between two nodes in a low power and lossy network.  This
draft also proposes functionality that would enable RPL to provide
these P2P mechanisms.
                                                                                  


The IETF Secretariat.



From jpv@cisco.com  Wed Apr 28 11:17:33 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AC13A6B40 for ; Wed, 28 Apr 2010 11:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.349
X-Spam-Level: 
X-Spam-Status: No, score=-9.349 tagged_above=-999 required=5 tests=[AWL=1.250,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkQgInqFayLT for ; Wed, 28 Apr 2010 11:17:32 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 32D953A69D0 for ; Wed, 28 Apr 2010 11:17:32 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAPMY2EurR7Ht/2dsb2JhbACcd3GkCposhQ4EjyE
X-IronPort-AV: E=Sophos;i="4.52,289,1270425600"; d="scan'208";a="522031004"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2010 18:17:19 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SIHIIT029098; Wed, 28 Apr 2010 18:17:19 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 20:17:17 +0200
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 20:17:17 +0200
Message-Id: 
From: JP Vasseur 
To: Mukul Goyal 
In-Reply-To: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 20:17:16 +0200
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 18:17:17.0173 (UTC) FILETIME=[08C61A50:01CAE6FF]
Cc: charliep , roll 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 18:17:33 -0000

Thanks Mukul. Just a minor point to avoid confusion for the WG, there  
is no P2P Design Team.

Thanks.

JP.

On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:

> Hi all
>
> The following draft has been submitted for WG's consideration. It  
> describes the additional mechanisms required to support P2P routing  
> in LLNs. The draft first provides a high level description of the  
> mechanisms and then proposes one way of realizing these mechanisms  
> in RPL.
>
> Regards
> Mukul
>
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada  
> Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00
>
>
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been  
> successfully submitted by Mukul Goyal and posted to the IETF  
> repository.
>
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point Routing in Low Power  
> and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
>
> Abstract:
> This draft presents mechanisms to determine the end-to-end cost of an
> existing route and to discover/establish "on demand" one or more
> routes between two nodes in a low power and lossy network.  This
> draft also proposes functionality that would enable RPL to provide
> these P2P mechanisms.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From yoav@yitran.com  Wed Apr 28 11:21:30 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2475C28C11C for ; Wed, 28 Apr 2010 11:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfMj9rtyjmH3 for ; Wed, 28 Apr 2010 11:21:28 -0700 (PDT)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id E4C8B28C0FD for ; Wed, 28 Apr 2010 11:20:40 -0700 (PDT)
Received: from source ([74.125.83.53]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS9h8a8LgBRjaof5h/u5plIO47Hj+KUsb@postini.com; Wed, 28 Apr 2010 11:20:28 PDT
Received: by mail-gw0-f53.google.com with SMTP id 17so635432gwb.26 for ; Wed, 28 Apr 2010 11:20:27 -0700 (PDT)
Received: by 10.101.164.17 with SMTP id r17mr3256853ano.230.1272478827480;  Wed, 28 Apr 2010 11:20:27 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu>	 <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>	 <00EDBF30-7C9D-464F-AB35-AAB187F1C8BC@cisco.com>
In-Reply-To: <00EDBF30-7C9D-464F-AB35-AAB187F1C8BC@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrmwuMALM2qPqAKRhyMZHQdOTpLBwAO1Wtg
Date: Wed, 28 Apr 2010 21:20:27 +0300
Message-ID: <33f90a790ceb7027803faa6bdd82709e@mail.gmail.com>
To: JP Vasseur , Omprakash Gnawali 
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 18:21:30 -0000

Hi,

Sorry for coming up with this comment after this release... It came up to
me only when reviewing the diffs between new and previous version :)

I think there a small issue in the following para.:

"
4.3.1.  The Link Quality Level Reliability Metric
...
     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Aggregated LQL Value     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 13: LQL Type 2 sub-Object format

   Aggregated LQL Value: when used an an additive metric (A=0x00), the
   aggregated LQL value reports the sum of all the LQL values for all
   links along the path.  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path.

"

In case the LQL on any link is unknown 0, and the metric is multiplicative
(A=0x03), using a multiplication by 0 would reset the aggregated LQL
value, whereas if the metric is additive, the aggregated LQL value will
remain unchanged. So I suggest to update the above para. to:

"
...
   Aggregated LQL Value: when used an an additive metric (A=0x00), the
   aggregated LQL value reports the sum of all the LQL values for all
   links along the path.  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path. When
   used to report a multiplication (A=0x03), and the LQL
   field of one of the links along the path is undetermined (LQL=0),
   the undetermined LQL will be ignored and not aggregated (i.e. no
   reset to Aggregated LQL Value field).
"

Thanks,
Yoav

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP
Vasseur
Sent: Wednesday, April 28, 2010 2:06 PM
To: Omprakash Gnawali
Cc: roll
Subject: Re: [Roll] The need for multiplicative metrics and other comments
on draft-ietf-roll-routing-metrics-05

Hi,

On Apr 13, 2010, at 6:44 PM, Omprakash Gnawali wrote:

> On Tue, Apr 13, 2010 at 12:34 AM, JP Vasseur  wrote:
> ...
>>> 2. Towards the end of 4.3.2:
>>>
>>> "The ETX object may be used as a constraint or a path metric.  For
>>>  example, an Objective Function may indicate that the ETX must not
>>> be
>>>  below some specified value."
>>>
>>> Should be: ETX must not be more than some specified value.
>>>
>>
>> Good catch, will fix it.
>
> The ETX Objective Function proposes a threshold. While I was working
> on ETXOF, the difficulty was coming up with the "right" threshold for
> both link ETX and path ETX. This might be a configuration parameter
> but it is not clear what the default value should be. It will be great
> to get feedback from the WG on what the default should be.

It is application dependent, and does not need to be standardized.
This is not a protocol
parameter either, so no need to suggest a default value.

Thanks.

JP.

>
> - om_p

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

From jpv@cisco.com  Wed Apr 28 11:24:08 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662323A69DD for ; Wed, 28 Apr 2010 11:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.401
X-Spam-Level: 
X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=1.198,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wqHeQbg55by for ; Wed, 28 Apr 2010 11:24:07 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BE6783A69BF for ; Wed, 28 Apr 2010 11:23:51 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAB8a2EurR7H+/2dsb2JhbACcd3GkHZoshQ4E
X-IronPort-AV: E=Sophos;i="4.52,289,1270425600"; d="scan'208";a="121985254"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 28 Apr 2010 18:23:38 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3SINb73007602; Wed, 28 Apr 2010 18:23:37 GMT
Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 20:23:36 +0200
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 20:23:36 +0200
Message-Id: <5A0B475C-16EB-4D70-85B3-33778EA19B99@cisco.com>
From: JP Vasseur 
To: Yoav Ben-Yehezkel 
In-Reply-To: <33f90a790ceb7027803faa6bdd82709e@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 20:23:35 +0200
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu>	 <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>	 <00EDBF30-7C9D-464F-AB35-AAB187F1C8BC@cisco.com> <33f90a790ceb7027803faa6bdd82709e@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 18:23:36.0101 (UTC) FILETIME=[EAA1ED50:01CAE6FF]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17352.001
X-TM-AS-Result: No--16.910900-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 18:24:08 -0000

Hi,

Good comments, which we agreed upon some time ago, I forgot to  
incorporate it.
OK that will be in the next revision for sure.

Cheers.

JP.

On Apr 28, 2010, at 8:20 PM, Yoav Ben-Yehezkel wrote:

> Hi,
>
> Sorry for coming up with this comment after this release... It came  
> up to
> me only when reviewing the diffs between new and previous version :)
>
> I think there a small issue in the following para.:
>
> "
> 4.3.1.  The Link Quality Level Reliability Metric
> ...
>     0               1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Aggregated LQL Value     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Figure 13: LQL Type 2 sub-Object format
>
>   Aggregated LQL Value: when used an an additive metric (A=0x00), the
>   aggregated LQL value reports the sum of all the LQL values for all
>   links along the path.  When used to report a minimum (A=0x02), the
>   field reports the minimum LQL value of all links along the path.
>
> "
>
> In case the LQL on any link is unknown 0, and the metric is  
> multiplicative
> (A=0x03), using a multiplication by 0 would reset the aggregated LQL
> value, whereas if the metric is additive, the aggregated LQL value  
> will
> remain unchanged. So I suggest to update the above para. to:
>
> "
> ...
>   Aggregated LQL Value: when used an an additive metric (A=0x00), the
>   aggregated LQL value reports the sum of all the LQL values for all
>   links along the path.  When used to report a minimum (A=0x02), the
>   field reports the minimum LQL value of all links along the path.  
> When
>   used to report a multiplication (A=0x03), and the LQL
>   field of one of the links along the path is undetermined (LQL=0),
>   the undetermined LQL will be ignored and not aggregated (i.e. no
>   reset to Aggregated LQL Value field).
> "
>
> Thanks,
> Yoav
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf  
> Of JP
> Vasseur
> Sent: Wednesday, April 28, 2010 2:06 PM
> To: Omprakash Gnawali
> Cc: roll
> Subject: Re: [Roll] The need for multiplicative metrics and other  
> comments
> on draft-ietf-roll-routing-metrics-05
>
> Hi,
>
> On Apr 13, 2010, at 6:44 PM, Omprakash Gnawali wrote:
>
>> On Tue, Apr 13, 2010 at 12:34 AM, JP Vasseur  wrote:
>> ...
>>>> 2. Towards the end of 4.3.2:
>>>>
>>>> "The ETX object may be used as a constraint or a path metric.  For
>>>> example, an Objective Function may indicate that the ETX must not
>>>> be
>>>> below some specified value."
>>>>
>>>> Should be: ETX must not be more than some specified value.
>>>>
>>>
>>> Good catch, will fix it.
>>
>> The ETX Objective Function proposes a threshold. While I was working
>> on ETXOF, the difficulty was coming up with the "right" threshold for
>> both link ETX and path ETX. This might be a configuration parameter
>> but it is not clear what the default value should be. It will be  
>> great
>> to get feedback from the WG on what the default should be.
>
> It is application dependent, and does not need to be standardized.
> This is not a protocol
> parameter either, so no need to suggest a default value.
>
> Thanks.
>
> JP.
>
>>
>> - om_p
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jpv@cisco.com  Wed Apr 28 12:13:38 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAD63A6A64 for ; Wed, 28 Apr 2010 12:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.705
X-Spam-Level: 
X-Spam-Status: No, score=-8.705 tagged_above=-999 required=5 tests=[AWL=0.405,  BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+k8KiqVmrTZ for ; Wed, 28 Apr 2010 12:13:38 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 80D2B3A687E for ; Wed, 28 Apr 2010 12:13:37 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQBAJsl2EuQ/uCWiWdsb2JhbACQXowaFQEBAQoLEREGHKQ1miuFDgQ
X-IronPort-AV: E=Sophos;i="4.52,289,1270425600"; d="scan'208";a="60280980"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2010 19:13:23 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SJDNhd015034; Wed, 28 Apr 2010 19:13:23 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 21:13:23 +0200
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 21:13:22 +0200
Message-Id: <30788C5D-BFBA-4C16-B0D0-33B676A1BCB2@cisco.com>
From: JP Vasseur 
To: charliep@computer.org
In-Reply-To: <4BD880EE.4010502@computer.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 21:13:21 +0200
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>  <4BD880EE.4010502@computer.org>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 19:13:22.0854 (UTC) FILETIME=[DEE04460:01CAE706]
Cc: roll , Mukul Goyal 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 19:13:38 -0000

Hi Charles,

On Apr 28, 2010, at 8:39 PM, Charles E. Perkins wrote:

>
> Hello JP,
>
> I think that the members of the discussion team
> do qualify as a "design team".  However, it is true
> that the design team was not an official design
> team appointed by directive of the working group.
>
> Instead, it was an independently organized design
> team.  The document doesn't claim that the design
> team has any special working group status.
>

As I said, this was a minor point, I just wanted to clarify that this
was not an official WG DT.

> Nevertheless, the working group may find the
> results to be of significant value.
>

Sure, thanks for the work.

Cheers.

JP.

> Regards,
> Charlie P.
>
>
> On 4/28/2010 11:17 AM, JP Vasseur wrote:
>> Thanks Mukul. Just a minor point to avoid confusion for the WG,  
>> there is
>> no P2P Design Team.
>>
>> Thanks.
>>
>> JP.
>>
>> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:
>>
>>> Hi all
>>>
>>> The following draft has been submitted for WG's consideration. It
>>> describes the additional mechanisms required to support P2P  
>>> routing in
>>> LLNs. The draft first provides a high level description of the
>>> mechanisms and then proposes one way of realizing these mechanisms  
>>> in
>>> RPL.
>>>
>>> Regards
>>> Mukul


From prvs=727202196=mukul@uwm.edu  Wed Apr 28 12:37:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CBB3A6890 for ; Wed, 28 Apr 2010 12:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.627
X-Spam-Level: 
X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[AWL=0.812,  BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrwOVnVDhX5m for ; Wed, 28 Apr 2010 12:37:13 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 6E4A03A6781 for ; Wed, 28 Apr 2010 12:37:12 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 28 Apr 2010 14:36:59 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 36E032C38012; Wed, 28 Apr 2010 14:36:59 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 1kGfJAla6l0i; Wed, 28 Apr 2010 14:36:59 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0E6822C3800F; Wed, 28 Apr 2010 14:36:59 -0500 (CDT)
Date: Wed, 28 Apr 2010 14:36:59 -0500 (CDT)
From: Mukul Goyal 
To: JP Vasseur 
Message-ID: <1686310990.4160261272483418976.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <30788C5D-BFBA-4C16-B0D0-33B676A1BCB2@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: charliep@computer.org, roll 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 19:37:14 -0000

Hi JP,

My mistake. I forgot to make it clear - the P2P team listed in the draft does not have an official sanction. 

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" 
To: charliep@computer.org
Cc: "Mukul Goyal" , "roll" 
Sent: Wednesday, April 28, 2010 2:13:21 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi Charles,

On Apr 28, 2010, at 8:39 PM, Charles E. Perkins wrote:

>
> Hello JP,
>
> I think that the members of the discussion team
> do qualify as a "design team".  However, it is true
> that the design team was not an official design
> team appointed by directive of the working group.
>
> Instead, it was an independently organized design
> team.  The document doesn't claim that the design
> team has any special working group status.
>

As I said, this was a minor point, I just wanted to clarify that this
was not an official WG DT.

> Nevertheless, the working group may find the
> results to be of significant value.
>

Sure, thanks for the work.

Cheers.

JP.

> Regards,
> Charlie P.
>
>
> On 4/28/2010 11:17 AM, JP Vasseur wrote:
>> Thanks Mukul. Just a minor point to avoid confusion for the WG,  
>> there is
>> no P2P Design Team.
>>
>> Thanks.
>>
>> JP.
>>
>> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:
>>
>>> Hi all
>>>
>>> The following draft has been submitted for WG's consideration. It
>>> describes the additional mechanisms required to support P2P  
>>> routing in
>>> LLNs. The draft first provides a high level description of the
>>> mechanisms and then proposes one way of realizing these mechanisms  
>>> in
>>> RPL.
>>>
>>> Regards
>>> Mukul


From jpv@cisco.com  Wed Apr 28 12:38:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9B63A6890 for ; Wed, 28 Apr 2010 12:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.465
X-Spam-Level: 
X-Spam-Status: No, score=-9.465 tagged_above=-999 required=5 tests=[AWL=1.134,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01+sRCz1Q+v3 for ; Wed, 28 Apr 2010 12:38:25 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3F0F33A690D for ; Wed, 28 Apr 2010 12:38:25 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALIr2EurR7H+/2dsb2JhbACceXGkO5orhQ4EjyE
X-IronPort-AV: E=Sophos;i="4.52,289,1270425600"; d="scan'208";a="522071901"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2010 19:38:12 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3SJcBcW018247; Wed, 28 Apr 2010 19:38:12 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 21:38:11 +0200
Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 21:38:10 +0200
Message-Id: <2B6764C8-23A8-46E9-9063-3C168248168B@cisco.com>
From: JP Vasseur 
To: Mukul Goyal 
In-Reply-To: <1686310990.4160261272483418976.JavaMail.root@mail02.pantherlink.uwm.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 28 Apr 2010 21:38:10 +0200
References: <1686310990.4160261272483418976.JavaMail.root@mail02.pantherlink.uwm.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 28 Apr 2010 19:38:11.0116 (UTC) FILETIME=[55F306C0:01CAE70A]
Cc: charliep@computer.org, roll 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Apr 2010 19:38:26 -0000

again not a pb, just a minor clarification.

Looking forward to discussion on this important topic.

Cheers.

JP.

On Apr 28, 2010, at 9:36 PM, Mukul Goyal wrote:

> Hi JP,
>
> My mistake. I forgot to make it clear - the P2P team listed in the  
> draft does not have an official sanction.
>
> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" 
> To: charliep@computer.org
> Cc: "Mukul Goyal" , "roll" 
> Sent: Wednesday, April 28, 2010 2:13:21 PM GMT -06:00 US/Canada  
> Central
> Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll- 
> p2p-rpl-00
>
> Hi Charles,
>
> On Apr 28, 2010, at 8:39 PM, Charles E. Perkins wrote:
>
>>
>> Hello JP,
>>
>> I think that the members of the discussion team
>> do qualify as a "design team".  However, it is true
>> that the design team was not an official design
>> team appointed by directive of the working group.
>>
>> Instead, it was an independently organized design
>> team.  The document doesn't claim that the design
>> team has any special working group status.
>>
>
> As I said, this was a minor point, I just wanted to clarify that this
> was not an official WG DT.
>
>> Nevertheless, the working group may find the
>> results to be of significant value.
>>
>
> Sure, thanks for the work.
>
> Cheers.
>
> JP.
>
>> Regards,
>> Charlie P.
>>
>>
>> On 4/28/2010 11:17 AM, JP Vasseur wrote:
>>> Thanks Mukul. Just a minor point to avoid confusion for the WG,
>>> there is
>>> no P2P Design Team.
>>>
>>> Thanks.
>>>
>>> JP.
>>>
>>> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:
>>>
>>>> Hi all
>>>>
>>>> The following draft has been submitted for WG's consideration. It
>>>> describes the additional mechanisms required to support P2P
>>>> routing in
>>>> LLNs. The draft first provides a high level description of the
>>>> mechanisms and then proposes one way of realizing these mechanisms
>>>> in
>>>> RPL.
>>>>
>>>> Regards
>>>> Mukul
>


From watteyne@eecs.berkeley.edu  Wed Apr 28 19:02:22 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE243A686E for ; Wed, 28 Apr 2010 19:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fme2yY3Xnbv3 for ; Wed, 28 Apr 2010 19:02:20 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 33A203A67A4 for ; Wed, 28 Apr 2010 19:02:20 -0700 (PDT)
Received: from [128.32.33.68] (dhcp-33-68.EECS.Berkeley.EDU [128.32.33.68]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o3T225lA009694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Apr 2010 19:02:06 -0700 (PDT)
Message-ID: <4BD8E89C.9020809@eecs.berkeley.edu>
Date: Wed, 28 Apr 2010 19:02:04 -0700
From: Thomas Watteyne 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
Content-Type: multipart/alternative; boundary="------------030205010107090806090706"
Subject: [Roll] Fwd: Re:  DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 02:02:23 -0000

This is a multi-part message in MIME format.
--------------030205010107090806090706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Roger,

Having a single byte for fan-out control and prioritization of 
downstream paths is elegant. It reminds me of the (academic) GRAdient 
Broadcast protocol. I have a couple of questions, though.

1) Is this a technique you (or others on the list) have experience with? 
If it's a proven technique, I'm glad to learn about it, and the WG will 
have more confidence adopting it.

2) I have some questions related to path convergence, which relates to 
the following paragraph in your text:

"An intermediate node may receive DAO messages from multiple children nodes
that advertise reachability to a given Destination Address. Where the total
number of set Path Control bits is greater than the number of DAO 
Parents the
bitmaps for the DAO messages will be merged. This merging of set bits will
allow for subsequent fan out at subsequent ancestor nodes."

This is, if I receive DAOs with [00000110] and [00000001] from two of my 
children, I have [00000111] to play with, which I can redistribute (or 
re-"fan out" if you want) across my DAO Parents. Does that mean that, 
every time I receive a DAO, I buffer it for some time in case I can 
merge it with a later one? If yes, how do I choose the duration to wait? 
If I decide to retransmit DAO's ASAP, and never merge them, what are the 
implications? As you may understand, I'm not a very big fan of the idea 
of "buffering for some time"...

I have taken a few minutes to verify that during fan-out, you should 
control the parent selection 
(http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf). It tells you 
that, if two DAOs copies are sent towards the LBR, and each node 
en-route can select its DAO parent randomly, the two obtained routes 
will not be disjoint. That is, if one path fails, changes are the second 
will also as they share many links.

3) Similar to Fig.5, consider fan-out and convergence causes the LBR to 
receive two routes [00000001] and [00000110]. Which one will is prefer? 
Sure, [00000001] has traveled through all the best DAO parents, but 
wouldn't [00000110] offer me path diversity?

Similarly, what happens if the LBR has only one link to the rest of the 
network? If I read you text correctly, it will receive one packet with 
[111111111]. If I am missing something, please do tell me.

Thomas

On 4/27/2010 2:11 PM, Roger Alexander wrote:
> Hi Pascal,
>
> Please find attached an expanded note on the DAO fan out control and path
> prioritization mechanism.
>
> Roger
>
>    
>> -----Original Message-----
>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>> Sent: Monday, April 19, 2010 11:35 AM
>> To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
>> wintert@acm.org
>> Cc: ROLL WG
>> Subject: RE: [Roll] DAO fan out
>>
>> Hi Roger:
>>
>> At high level I'm very positive on the mechanism .
>>
>> What I'd wish to see from the list is more people:
>> - agreeing that the fan out MUST be solved
>>      
> For large scale networks it is important to have some mechanism to bound
> downward paths once nodes can maintain multiple DAO parents. It will be up
> to the WG of course but after having introduced multiple DAO parents,
> leaving paths unconstrained introduces a potentially uncontrolled element of
> the protocol that can affect scalability; as networks become larger the
> potential vulnerability increases. What is being recommended is a 1-byte
> information element per DAO Destination Address. While incurring some
> additional overhead path control can be disabled (bitmap set to all zeros)
> for networks in which only a single DAO parent per node is maintained or
> that not wish to implement constraints on path fan out or to differentiate
> preferred downward paths.
>
>    
>> - that this is a simple and efficient solution
>>      
> Yes it would be good to get feedback from others on any concerns they may
> have.
>
>    
>> - that the solution can be incorporated in 08
>>
>> Maybe what would help from you Roger is:
>> - a visual example on the mechanism as work (if you have a pdf
>> illustrating it?)
>>      
> Note plus a few examples attached (pdf and MS Word).
>
>    
>> - some more explanation on the source route case (how the root can play
>> the same game recursively and obtain a good result as well)
>>      
> Based on the current -07 source route specification, non-storing nodes will
> follow the same operation as storing nodes in using the Path Control byte to
> determine the number and selection of DAO parents through which the reverse
> route stack is built.
>
> If the source route specification is changed to the more recent proposal
> from Richard, the Path Control byte can still apply to the advertised DAO
> Destination Address and will be associated with each of the selected DAO
> Parents communicated to the root. As in the case of storing nodes, each DAO
> Destination Address will have a different Path Control byte for each
> selected DAO Parent. For the source route case the root will be able to use
> the Path Control preference associated with each selected DAO Parent to
> recursively determine the preferred downward path to a given target address.
> That is, at the root, the preferred downward path to a given target address
> begins with the target's preferred DAO parent as given by the Path Control
> byte. From that preferred DAO Parent the link to the next preferred DAO
> ancestor is added until the complete preferred path is derived. The root
> will also be capable of deriving all the potential path combinations to a
> target node.
>
> As I currently understand the new proposal it is not clear that non storing
> nodes have any ability to control path fan out (and the consequently
> increased reverse route processing at the root) when nodes maintain multiple
> DAO Parents.
>
>    
>> Could you please so that for us?
>>
>> Thanks a bunch,
>>
>> Pascal
>>
>>
>>      
>>> -----Original Message-----
>>> From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
>>> Sent: Friday, April 16, 2010 11:32 PM
>>> To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
>>>        
>> Vasseur';
>>      
>>> wintert@acm.org
>>> Cc: 'ROLL WG'
>>> Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
>>> welcome)
>>>
>>> Below is a quick summary aligned to Tim's concept of how the Path
>>>        
>> Control
>>      
>>> bitmap associated with the DAO destination address can be used to
>>>        
>> limit fan
>>      
>>> out and to identify the preferred path when nodes maintain multiple
>>>        
>> DAO
>>      
>>> Parents.
>>>
>>> Further details and examples can be provided as part of an larger
>>> application domain note.
>>>
>>> Roger
>>>
>>>        
>>>> -----Original Message-----
>>>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>>>> Sent: Tuesday, April 13, 2010 3:47 AM
>>>> To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
>>>> wintert@acm.org
>>>> Cc: ROLL WG
>>>> Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
>>>>
>>>>
>>>>
>>>> Pascal
>>>>
>>>>          
>>>>> One consequence of maintaining multiple DAO parents is the
>>>>>            
>> potential
>>      
>>>> fan
>>>>          
>>>>> out of routing paths. With path fan out a node may have multiple
>>>>>            
>>>> downward
>>>>          
>>>>> next hop addresses for a given target destination address.
>>>>>            
>> Without
>>      
>>>> some
>>>>          
>>>>> path preference indication there is no information available if a
>>>>>            
>>>> storing node
>>>>          
>>>>> (including the root) wishes to limit the number of downward next
>>>>>            
>> hops
>>      
>>>>> maintained for a given address. It is thus desirable to have some
>>>>>            
>>>> means of
>>>>          
>>>>> path control to limit fan out as well as a preference indication
>>>>>            
>> that
>>      
>>>> can work in
>>>>          
>>>>> conjunction with the hop-by-hop DAO exchanges.
>>>>>
>>>>> See the Figure below for an example in which nodes maintain two
>>>>>            
>> DAO
>>      
>>>>> Parents each, where in the worst case the fan out that occurs
>>>>>            
>> after
>>      
>>>> three
>>>>          
>>>>> hops results in eight next hop downward paths from the DODAG root
>>>>>            
>>>> (LBR)
>>>>          
>>>>> to a target node (41). Even with the hop-by-hop DAO mechanism it
>>>>>            
>>>> would
>>>> be
>>>>          
>>>>> desirable to be able to limit fan out as well as to identify path
>>>>>            
>>>> preference and
>>>>          
>>>>> diversity at the root or other intermediate storing node.
>>>>>
>>>>>                      (------------LBR------------)
>>>>>                      /    /   / |     | \    \   \
>>>>>                     /    /   /  |     |  \    \   \
>>>>>                    /    /   /   |     |   \    \   \
>>>>>                   /    /   /    |     |    \    \   \
>>>>>                (11) (12) (13) (14)   (15) (16) (17) (18)
>>>>>                   \   |    |    /     \    |    |   /
>>>>>                    \  |    |   /       \   |    |  /
>>>>>                     \ |    |  /         \  |    | /
>>>>>                    (21)   (22)           (23)  (24)
>>>>>                        \    |            |    /
>>>>>                         \   |            |   /
>>>>>                          \  |            |  /
>>>>>                           (31)          (32)
>>>>>                               \        /
>>>>>                                \      /
>>>>>                                 \    /
>>>>>                                  (41)
>>>>>
>>>>>            
>>>> [Pascal] Your schema illustrates clearly that even if we fan out a
>>>>          
>> lot,
>>      
>>>> it does not mean that a router on the way down will have more
>>>>          
>> feasible
>>      
>>>> successors.
>>>>
>>>> That's one thing that's important to remember, the properties of
>>>>          
>> the
>>      
>>>> DAG
>>>> are not symmetrical, so even if we build it to get multiple
>>>>          
>> feasible
>>      
>>>> successors on the way up, that does not mean that on the reverse
>>>>          
>> DAG
>> to
>>      
>>>> a target there are multiple successors at each hop towards that
>>>>          
>> target.
>>      
>>>> In other words, the ROI of fanning out is not guaranteed if we do
>>>>          
>> it
>>      
>>>> blindly.
>>>>
>>>>          
>>>>> A simple path control bitmap associated with the advertised
>>>>>            
>>>> Destination
>>>>          
>>>>> Address can be included within the DAO to address the issue of
>>>>>            
>> path
>>      
>>>>> preference as well as control of fan out. For a network of
>>>>>            
>>>> 'non-storing'
>>>>          
>>>>> nodes the preference indication would be processed only at the
>>>>>            
>> root.
>>      
>>>> [Pascal] so far so good, but that will give you a blind mechanism.
>>>>
>>>>          
>>>>> With the path control byte associated with each DAO destination
>>>>>            
>>>> address, a
>>>>          
>>>>> node will be able to specify preference among DAO parent paths
>>>>>            
>> and
>>      
>>>> can
>>>>          
>>>>> convey limits on the number of downward paths. This is an
>>>>>            
>> opportunity
>>      
>>>> for
>>>>          
>>>>> nodes to further influence the downward paths that are
>>>>>            
>> established
>>      
>>>> and
>>>>          
>>>>> maintained. Consistent with the DV-based RPL operation this DAO
>>>>>            
>> path
>>      
>>>>> control mechanism must operate hop-by-hop avoiding any
>>>>>            
>> requirement
>>      
>>>> for
>>>>          
>>>>> end-to-end path coordination. To avoid overloading this email
>>>>>            
>> thread
>>      
>>>> I
>>>> will
>>>>          
>>>>> initiate a separate discussion on how a path control element may
>>>>>            
>> be
>>      
>>>> included
>>>>          
>>>>> within the DAO.
>>>>>
>>>>>            
>>>> [Pascal] Too late, I just did :)
>>>>
>>>> And if I remember, Tim's idea was to control the stretch of the
>>>>          
>> fanout,
>>      
>>>> by decrementing a counter as the path loses preference point.
>>>> At the moment, we have a parent preference 0-lowest to 3 highest.
>>>>          
>> So
>> it
>>      
>>>> is easy to decrement a counter by (3-pref) and not fan out when the
>>>> counter reaches 0.
>>>> Tim, could you elaborate on this?
>>>>          
>>> A Path Control bit map will achieve an equivalent control mechanism
>>> whereby
>>> at each node the number of bits that are set will determine the
>>>        
>> extent
>> to
>>      
>>> which the associated DAO Destination Address can be advertised to
>>>        
>> multiple
>>      
>>> DAO Parents. If a DAO message destination address Path Control bitmap
>>>        
>> has
>>      
>>> 4
>>> set bits, that address can be send along a maximum of 4 paths. For
>>>        
>> example,
>>      
>>> at the originating node the DAO can be sent to two DAO Parents where
>>>        
>> the
>>      
>>> Path Control bit map in the message sent to each DAO Parent will have
>>>        
>> two
>>      
>>> set bits. If each parent then advertises to two DAO Parents a single
>>>        
>> bit is
>>      
>>> set for each DAO message. Eventually with a single bit set in the
>>>        
>> Path
>>      
>>> Control bit map, the DAO message can be advertised only to a single
>>>        
>> DAO
>>      
>>> Parent. This mechanism achieves the effect of limiting the stretch of
>>>        
>> the
>>      
>>> path fan out. Where multiple DAO messages are received at a common
>>> ancestor
>>> the number of set bits in the respective Path Control fields are
>>>        
>> recombined
>>      
>>> allowing for renewed advertising of the DAO message destination
>>>        
>> address to
>>      
>>> multiple DAO Parents along the path.
>>>
>>> As the set Path Control bits are split and recombined as the DAO
>>>        
>> messages
>>      
>>> are transferred to the root, their bit positions are maintained. This
>>>        
>> allows
>>      
>>> bit positions to be ordered from low to high in terms of path
>>>        
>> preference.
>>      
>>> Therefore when a DAO message is received in which the Path Control
>>>        
>> bitmap
>>      
>>> has the highest preference bit set, that DAO message destination
>>>        
>> address is
>>      
>>> always advertised to the preferred DAO Parent. Similarly, when a
>>>        
>> message is
>>      
>>> received with multiple Path Control bits set, the DAO messages can be
>>> distributed to DAO Parents according to parent preference. This will
>>>        
>> ensure
>>      
>>> that at any common ancestor, including the root, a node is always
>>>        
>> able
>> to
>>      
>>> distinguish the preferred downward path. The ability to determine the
>>> preferred downward path as well as to obtain an indication of path
>>>        
>> diversity
>>      
>>> will allow the Path Control field to be used when resource
>>>        
>> limitations
>> at a
>>      
>>> node require a truncation of the number of downward paths that the
>>>        
>> node
>>      
>>> maintain for a given destination address.
>>>
>>>        
>>>> Pascal
>>>>          
>> >
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll


--------------030205010107090806090706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Roger,
    

    
Having a single byte for fan-out control and prioritization of
downstream paths is elegant. It reminds me of the (academic) GRAdient
Broadcast protocol. I have a couple of questions, though.
    

    
1) Is this a technique you (or others on the list) have experience
with? If it's a proven technique, I'm glad to learn about it, and the
WG will have more confidence adopting it.
    

    
2) I have some questions related to path convergence, which relates to
the following paragraph in your text:
    

    
"An intermediate node may receive DAO messages from multiple children
nodes
    
that advertise reachability to a given Destination Address. Where the
total
    
number of set Path Control bits is greater than the number of DAO
Parents the
    
bitmaps for the DAO messages will be merged. This merging of set bits
will
    
allow for subsequent fan out at subsequent ancestor nodes."
    

    
This is, if I receive DAOs with [00000110] and     [00000001]
from two of my children, I have [00000111] to play
with, which I can redistribute (or re-"fan out" if you want) across my
DAO Parents. Does that mean that, every time I receive a DAO, I buffer
it for some time in case I can merge it with a later one? If yes, how
do I choose the duration to wait? If I decide to retransmit DAO's ASAP,
and never merge them, what are the implications? As you may understand,
I'm not a very big fan of the idea of "buffering for some time"...
    

    
I have taken a few minutes to verify that during fan-out, you should
control the parent selection
(http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf). It tells you
that, if two DAOs
copies are sent towards the LBR, and each node en-route can select its
DAO parent randomly, the two obtained routes will not be disjoint. That
is, if one path fails, changes are the second will also as they share
many links.
    

    
3) Similar to Fig.5, consider fan-out and convergence causes the LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer?
Sure, [00000001] has traveled through all the best DAO parents, but
wouldn't [00000110] offer me path diversity?
    

    
Similarly, what happens if the LBR has only one link to the rest of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.
    

    
Thomas
    

    
On 4/27/2010 2:11 PM, Roger Alexander wrote:

    
  
    Hi Pascal,

Please find attached an expanded note on the DAO fan out control and path
prioritization mechanism.

Roger

  
    
  
    
    
    -----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Monday, April 19, 2010 11:35 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: RE: [Roll] DAO fan out

Hi Roger:

At high level I'm very positive on the mechanism .

What I'd wish to see from the list is more people:
- agreeing that the fan out MUST be solved
    
    
  
    
  
    For large scale networks it is important to have some mechanism to bound
downward paths once nodes can maintain multiple DAO parents. It will be up
to the WG of course but after having introduced multiple DAO parents,
leaving paths unconstrained introduces a potentially uncontrolled element of
the protocol that can affect scalability; as networks become larger the
potential vulnerability increases. What is being recommended is a 1-byte
information element per DAO Destination Address. While incurring some
additional overhead path control can be disabled (bitmap set to all zeros)
for networks in which only a single DAO parent per node is maintained or
that not wish to implement constraints on path fan out or to differentiate
preferred downward paths.

  
    
  
    
    
    - that this is a simple and efficient solution
    
    
  
    
  
    Yes it would be good to get feedback from others on any concerns they may
have.

  
    
  
    
    
    - that the solution can be incorporated in 08

Maybe what would help from you Roger is:
- a visual example on the mechanism as work (if you have a pdf
illustrating it?)
    
    
  
    
  
    Note plus a few examples attached (pdf and MS Word).

  
    
  
    
    
    - some more explanation on the source route case (how the root can play
the same game recursively and obtain a good result as well)
    
    
  
    
  
    Based on the current -07 source route specification, non-storing nodes will
follow the same operation as storing nodes in using the Path Control byte to
determine the number and selection of DAO parents through which the reverse
route stack is built. 

If the source route specification is changed to the more recent proposal
from Richard, the Path Control byte can still apply to the advertised DAO
Destination Address and will be associated with each of the selected DAO
Parents communicated to the root. As in the case of storing nodes, each DAO
Destination Address will have a different Path Control byte for each
selected DAO Parent. For the source route case the root will be able to use
the Path Control preference associated with each selected DAO Parent to
recursively determine the preferred downward path to a given target address.
That is, at the root, the preferred downward path to a given target address
begins with the target's preferred DAO parent as given by the Path Control
byte. From that preferred DAO Parent the link to the next preferred DAO
ancestor is added until the complete preferred path is derived. The root
will also be capable of deriving all the potential path combinations to a
target node. 

As I currently understand the new proposal it is not clear that non storing
nodes have any ability to control path fan out (and the consequently
increased reverse route processing at the root) when nodes maintain multiple
DAO Parents.
   
  
    
  
    
    
    Could you please so that for us?

Thanks a bunch,

Pascal


    
    
    
    
      
    -----Original Message-----
From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
Sent: Friday, April 16, 2010 11:32 PM
To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
      
    
    
    
    
    Vasseur';
    
    
    
    
      
    wintert@acm.org
Cc: 'ROLL WG'
Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
welcome)

Below is a quick summary aligned to Tim's concept of how the Path
      
    
    
    
    
    Control
    
    
    
    
      
    bitmap associated with the DAO destination address can be used to
      
    
    
    
    
    limit fan
    
    
    
    
      
    out and to identify the preferred path when nodes maintain multiple
      
    
    
    
    
    DAO
    
    
    
    
      
    Parents.

Further details and examples can be provided as part of an larger
application domain note.

Roger

      
    
      
    
        
    -----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, April 13, 2010 3:47 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)



Pascal

        
    
        
    
          
    One consequence of maintaining multiple DAO parents is the
          
    
        
    
      
    
    
    
    
    potential
    
    
    
    
      
    
        
    fan
        
    
        
    
          
    out of routing paths. With path fan out a node may have multiple
          
    
        
    
        
    downward
        
    
        
    
          
    next hop addresses for a given target destination address.
          
    
        
    
      
    
    
    
    
    Without
    
    
    
    
      
    
        
    some
        
    
        
    
          
    path preference indication there is no information available if a
          
    
        
    
        
    storing node
        
    
        
    
          
    (including the root) wishes to limit the number of downward next
          
    
        
    
      
    
    
    
    
    hops
    
    
    
    
      
    
        
    
          
    maintained for a given address. It is thus desirable to have some
          
    
        
    
        
    means of
        
    
        
    
          
    path control to limit fan out as well as a preference indication
          
    
        
    
      
    
    
    
    
    that
    
    
    
    
      
    
        
    can work in
        
    
        
    
          
    conjunction with the hop-by-hop DAO exchanges.

See the Figure below for an example in which nodes maintain two
          
    
        
    
      
    
    
    
    
    DAO
    
    
    
    
      
    
        
    
          
    Parents each, where in the worst case the fan out that occurs
          
    
        
    
      
    
    
    
    
    after
    
    
    
    
      
    
        
    three
        
    
        
    
          
    hops results in eight next hop downward paths from the DODAG root
          
    
        
    
        
    (LBR)
        
    
        
    
          
    to a target node (41). Even with the hop-by-hop DAO mechanism it
          
    
        
    
        
    would
be
        
    
        
    
          
    desirable to be able to limit fan out as well as to identify path
          
    
        
    
        
    preference and
        
    
        
    
          
    diversity at the root or other intermediate storing node.

                    (------------LBR------------)
                    /    /   / |     | \    \   \
                   /    /   /  |     |  \    \   \
                  /    /   /   |     |   \    \   \
                 /    /   /    |     |    \    \   \
              (11) (12) (13) (14)   (15) (16) (17) (18)
                 \   |    |    /     \    |    |   /
                  \  |    |   /       \   |    |  /
                   \ |    |  /         \  |    | /
                  (21)   (22)           (23)  (24)
                      \    |            |    /
                       \   |            |   /
                        \  |            |  /
                         (31)          (32)
                             \        /
                              \      /
                               \    /
                                (41)

          
    
        
    
        
    [Pascal] Your schema illustrates clearly that even if we fan out a
        
    
      
    
    
    
    
    lot,
    
    
    
    
      
    
        
    it does not mean that a router on the way down will have more
        
    
      
    
    
    
    
    feasible
    
    
    
    
      
    
        
    successors.

That's one thing that's important to remember, the properties of
        
    
      
    
    
    
    
    the
    
    
    
    
      
    
        
    DAG
are not symmetrical, so even if we build it to get multiple
        
    
      
    
    
    
    
    feasible
    
    
    
    
      
    
        
    successors on the way up, that does not mean that on the reverse
        
    
      
    
    
    
    
    DAG
to
    
    
    
    
      
    
        
    a target there are multiple successors at each hop towards that
        
    
      
    
    
    
    
    target.
    
    
    
    
      
    
        
    In other words, the ROI of fanning out is not guaranteed if we do
        
    
      
    
    
    
    
    it
    
    
    
    
      
    
        
    blindly.

        
    
        
    
          
    A simple path control bitmap associated with the advertised
          
    
        
    
        
    Destination
        
    
        
    
          
    Address can be included within the DAO to address the issue of
          
    
        
    
      
    
    
    
    
    path
    
    
    
    
      
    
        
    
          
    preference as well as control of fan out. For a network of
          
    
        
    
        
    'non-storing'
        
    
        
    
          
    nodes the preference indication would be processed only at the
          
    
        
    
      
    
    
    
    
    root.
    
    
    
    
      
    
        
    [Pascal] so far so good, but that will give you a blind mechanism.

        
    
        
    
          
    With the path control byte associated with each DAO destination
          
    
        
    
        
    address, a
        
    
        
    
          
    node will be able to specify preference among DAO parent paths
          
    
        
    
      
    
    
    
    
    and
    
    
    
    
      
    
        
    can
        
    
        
    
          
    convey limits on the number of downward paths. This is an
          
    
        
    
      
    
    
    
    
    opportunity
    
    
    
    
      
    
        
    for
        
    
        
    
          
    nodes to further influence the downward paths that are
          
    
        
    
      
    
    
    
    
    established
    
    
    
    
      
    
        
    and
        
    
        
    
          
    maintained. Consistent with the DV-based RPL operation this DAO
          
    
        
    
      
    
    
    
    
    path
    
    
    
    
      
    
        
    
          
    control mechanism must operate hop-by-hop avoiding any
          
    
        
    
      
    
    
    
    
    requirement
    
    
    
    
      
    
        
    for
        
    
        
    
          
    end-to-end path coordination. To avoid overloading this email
          
    
        
    
      
    
    
    
    
    thread
    
    
    
    
      
    
        
    I
will
        
    
        
    
          
    initiate a separate discussion on how a path control element may
          
    
        
    
      
    
    
    
    
    be
    
    
    
    
      
    
        
    included
        
    
        
    
          
    within the DAO.

          
    
        
    
        
    [Pascal] Too late, I just did :)

And if I remember, Tim's idea was to control the stretch of the
        
    
      
    
    
    
    
    fanout,
    
    
    
    
      
    
        
    by decrementing a counter as the path loses preference point.
At the moment, we have a parent preference 0-lowest to 3 highest.
        
    
      
    
    
    
    
    So
it
    
    
    
    
      
    
        
    is easy to decrement a counter by (3-pref) and not fan out when the
counter reaches 0.
Tim, could you elaborate on this?
        
    
      
    
      
    A Path Control bit map will achieve an equivalent control mechanism
whereby
at each node the number of bits that are set will determine the
      
    
    
    
    
    extent
to
    
    
    
    
      
    which the associated DAO Destination Address can be advertised to
      
    
    
    
    
    multiple
    
    
    
    
      
    DAO Parents. If a DAO message destination address Path Control bitmap
      
    
    
    
    
    has
    
    
    
    
      
    4
set bits, that address can be send along a maximum of 4 paths. For
      
    
    
    
    
    example,
    
    
    
    
      
    at the originating node the DAO can be sent to two DAO Parents where
      
    
    
    
    
    the
    
    
    
    
      
    Path Control bit map in the message sent to each DAO Parent will have
      
    
    
    
    
    two
    
    
    
    
      
    set bits. If each parent then advertises to two DAO Parents a single
      
    
    
    
    
    bit is
    
    
    
    
      
    set for each DAO message. Eventually with a single bit set in the
      
    
    
    
    
    Path
    
    
    
    
      
    Control bit map, the DAO message can be advertised only to a single
      
    
    
    
    
    DAO
    
    
    
    
      
    Parent. This mechanism achieves the effect of limiting the stretch of
      
    
    
    
    
    the
    
    
    
    
      
    path fan out. Where multiple DAO messages are received at a common
ancestor
the number of set bits in the respective Path Control fields are
      
    
    
    
    
    recombined
    
    
    
    
      
    allowing for renewed advertising of the DAO message destination
      
    
    
    
    
    address to
    
    
    
    
      
    multiple DAO Parents along the path.

As the set Path Control bits are split and recombined as the DAO
      
    
    
    
    
    messages
    
    
    
    
      
    are transferred to the root, their bit positions are maintained. This
      
    
    
    
    
    allows
    
    
    
    
      
    bit positions to be ordered from low to high in terms of path
      
    
    
    
    
    preference.
    
    
    
    
      
    Therefore when a DAO message is received in which the Path Control
      
    
    
    
    
    bitmap
    
    
    
    
      
    has the highest preference bit set, that DAO message destination
      
    
    
    
    
    address is
    
    
    
    
      
    always advertised to the preferred DAO Parent. Similarly, when a
      
    
    
    
    
    message is
    
    
    
    
      
    received with multiple Path Control bits set, the DAO messages can be
distributed to DAO Parents according to parent preference. This will
      
    
    
    
    
    ensure
    
    
    
    
      
    that at any common ancestor, including the root, a node is always
      
    
    
    
    
    able
to
    
    
    
    
      
    distinguish the preferred downward path. The ability to determine the
preferred downward path as well as to obtain an indication of path
      
    
    
    
    
    diversity
    
    
    
    
      
    will allow the Path Control field to be used when resource
      
    
    
    
    
    limitations
at a
    
    
    
    
      
    node require a truncation of the number of downward paths that the
      
    
    
    
    
    node
    
    
    
    
      
    maintain for a given destination address.

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

    

    



--------------030205010107090806090706--

From pthubert@cisco.com  Thu Apr 29 00:01:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DA63A6B35; Thu, 29 Apr 2010 00:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.669
X-Spam-Level: 
X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[AWL=0.330,  BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx9DsnEd8yTz; Thu, 29 Apr 2010 00:01:58 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A287C3A6B24; Thu, 29 Apr 2010 00:01:57 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAnM2EurRN+J/2dsb2JhbACdC3GiUZoThRAE
X-IronPort-AV: E=Sophos;i="4.52,294,1270425600"; d="scan'208";a="522311357"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2010 07:01:31 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3T71I6l014408; Thu, 29 Apr 2010 07:01:31 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 29 Apr 2010 09:01:20 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Apr 2010 09:01:15 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com>
In-Reply-To: <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEA
References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com> <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi>
From: "Pascal Thubert (pthubert)" 
To: , "Richard Kelsey" 
X-OriginalArrivalTime: 29 Apr 2010 07:01:20.0396 (UTC) FILETIME=[C576CCC0:01CAE769]
Cc: roll@ietf.org, 6lowpan@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 07:01:59 -0000

Hi Zach:

I have yet to review the new ND-09 but my guts tell me that it is the
wrong place to do the job. Router to router is usually routing protocol
land and ND is definitely not a routing protocol.

The main question is how long can  a router advertise a prefix, and the
answer is, as long as it is in the same subnet of an authoritative
router that owns the prefix.
Asserting the continuous reachability of the authoritative router is a
routing protocol problem. Maintaining a subnet together is the job for a
new form of Gateway Protocol, a Subnet Gateway Protocol
RPL is just that.

Let see:

- Propagating the RA content is not an ND intrinsic  problem, it only
comes with route over. And route over comes with a routing protocol.
- the route over protocol should be able to tie the route over
subnetwork together so it is a SGP.

So why can't we just say in 6LoWPAN ND that you for those who use it in
route over we expect an SGP to tie the route over subnetwork together
and that the SGP should transport the RA content, maintaining the
validity with the reachability of the authoritative router? I can write
that text if you wish.

It seems that we have a reasonable consensus in this thread to do
exactly that in RPL anyway...

Pascal

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> zach.shelby@sensinode.com
> Sent: Tuesday, April 27, 2010 10:36 PM
> To: Richard Kelsey
> Cc: roll@ietf.org
> Subject: Re: [Roll] how does a node get an IP address
>=20
> Hi Everyone,
>=20
> Let me jump into this thread - just to make things more interesting
;-) First, I
> recommend everyone goes and reads 6lowpan-nd-09 which was submitted
> today. When it comes to ND, you need to separate two interfaces.
>=20
> 1. The host-router interface
>=20
> Hosts know absolutely nothing about RPL (nor should they). Thus in
this case
> ND* does the job, and RS/RA is used for obtaining a prefix and
initializing its
> addresses. I think some people in the thread are referring to this.
>=20
> 2. The router-router interface
>=20
> As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than
hosts in
> how they obtain prefix information (among other things). nd-09 does
include
> an optional technique for an authorative border router to disseminate
PIOs
> and CIOs (Context Information Options) between the border router and
all
> routers in the LoWPAN using RAs. It is actually a decent mechanism and
> improved over early versions. The draft clearly states that it is
optional as a
> routing algorithm may already do this. So Pascal is correct in that
respect. I
> haven't followed the thread well enough to have an opinion if RPL
should do
> that.
>=20
> Routers will also find other features of 6lowpan-nd-09 useful, for
example
> during initial bootstrapping, to maintain their default router and
neighbor
> caches, avoid the need for address resolution, and to perform NUD. The
> draft (tries to) clearly state when features are required or optional
for a
> router.
>=20
> Zach
>=20
>=20
> >> From: Michael Richardson 
> >> Date: Tue, 27 Apr 2010 10:38:47 -0400
> >>
> >> >>>>> "Richard" =3D=3D Richard Kelsey 
writes:
> >>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
> >>     >> (pthubert)" 
> >>     >>
> >>     >> The question here is that the authoritative routers need to
> >>     >> disseminate the PIO (and the RIO) to all routers in the
subnet.
> >>
> >>     Richard> How do other routing protocols (OSPF, IS-IS, AODV,
OLSR)
> >>
> >> I can only speak for OSPF and ISIS.
> >> Neither deal with multi-hop subnets or with any kind of address
> >> assignment.
> >
> > Why should RPL be any different?  Yes, it will be run on multi-hop
> > subnets, but I still do not see how this affects the routing.
> >
> >> Both were written when multicast was very new.
> >
> > I am not sure how RPL's handling of multicast matters here.
> > While RPL is required to route multi-hop multicasts, ND uses
> > link-local multicasts, which do not require routing.
> >
> >> Richard> I understand that multi-hop subnets are a problem for ND,
> >> Richard> but I don't see how the routing protocol is affected.
> >>
> >> RPL either requires 6lowpan, or it doesn't.
> >
> > RPL should work fine with ordinary ND.  Why would it require
6lowpan?
> >
> >> If it doesn't, then it has to provide for ND to work, or for
another
> >> protocol to replace it.
> >
> > ND works fine, using link-local, one-hop multicasts.  RPL need not
be
> > involved.
> >
> > If someone wants to run RPL on a node that uses neither ordinary ND
or
> > 6lowpan's version, then they will need some third variety of ND.  I
do
> > not see why this is an issue for RPL to address.  It seems quite out
> > of scope.
> >
> >                               -Richard Kelsey
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> >
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From abr@sdesigns.dk  Thu Apr 29 00:12:01 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6DD28C19D; Thu, 29 Apr 2010 00:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level: 
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRlYe2gR5suY; Thu, 29 Apr 2010 00:12:00 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id BF5FE3A6AE7; Thu, 29 Apr 2010 00:11:48 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Apr 2010 09:11:34 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] how does a node get an IP address
Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEAAACXZQA=
References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com>
From: "Anders Brandt" 
To: "Pascal Thubert (pthubert)" , , "Richard Kelsey" 
Cc: roll@ietf.org, 6lowpan@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 07:12:01 -0000

> It seems that we have a reasonable consensus in this thread=20
> to do exactly that in RPL anyway...
>=20
> Pascal

OK,
So could someone with the full overview outline explain to me
how many mechanisms a RPL node running over 6lowPan will have
to implement to be compatible with all other nodes claiming
to be RPL compliant?

My guess:
* Classic RS/RA
* DHCPv6
* 6lowPAN ND
* RPL address assignment
* etc

Should we make a decision someday? (!)

Thanks,
  Anders

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20
> Behalf Of Pascal Thubert (pthubert)
> Sent: Thursday, April 29, 2010 09:01
> To: zach.shelby@sensinode.com; Richard Kelsey
> Cc: roll@ietf.org; 6lowpan@ietf.org
> Subject: Re: [Roll] how does a node get an IP address
>=20
> Hi Zach:
>=20
> I have yet to review the new ND-09 but my guts tell me that=20
> it is the wrong place to do the job. Router to router is=20
> usually routing protocol land and ND is definitely not a=20
> routing protocol.
>=20
> The main question is how long can  a router advertise a=20
> prefix, and the answer is, as long as it is in the same=20
> subnet of an authoritative router that owns the prefix.
> Asserting the continuous reachability of the authoritative=20
> router is a routing protocol problem. Maintaining a subnet=20
> together is the job for a new form of Gateway Protocol, a=20
> Subnet Gateway Protocol RPL is just that.
>=20
> Let see:
>=20
> - Propagating the RA content is not an ND intrinsic  problem,=20
> it only comes with route over. And route over comes with a=20
> routing protocol.
> - the route over protocol should be able to tie the route=20
> over subnetwork together so it is a SGP.
>=20
> So why can't we just say in 6LoWPAN ND that you for those who=20
> use it in route over we expect an SGP to tie the route over=20
> subnetwork together and that the SGP should transport the RA=20
> content, maintaining the validity with the reachability of=20
> the authoritative router? I can write that text if you wish.
>=20
> It seems that we have a reasonable consensus in this thread=20
> to do exactly that in RPL anyway...
>=20
> Pascal
>=20
> > -----Original Message-----
> > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of
> > zach.shelby@sensinode.com
> > Sent: Tuesday, April 27, 2010 10:36 PM
> > To: Richard Kelsey
> > Cc: roll@ietf.org
> > Subject: Re: [Roll] how does a node get an IP address
> >=20
> > Hi Everyone,
> >=20
> > Let me jump into this thread - just to make things more interesting
> ;-) First, I
> > recommend everyone goes and reads 6lowpan-nd-09 which was submitted=20
> > today. When it comes to ND, you need to separate two interfaces.
> >=20
> > 1. The host-router interface
> >=20
> > Hosts know absolutely nothing about RPL (nor should they). Thus in
> this case
> > ND* does the job, and RS/RA is used for obtaining a prefix and
> initializing its
> > addresses. I think some people in the thread are referring to this.
> >=20
> > 2. The router-router interface
> >=20
> > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than
> hosts in
> > how they obtain prefix information (among other things). nd-09 does
> include
> > an optional technique for an authorative border router to=20
> disseminate
> PIOs
> > and CIOs (Context Information Options) between the border router and
> all
> > routers in the LoWPAN using RAs. It is actually a decent=20
> mechanism and=20
> > improved over early versions. The draft clearly states that it is
> optional as a
> > routing algorithm may already do this. So Pascal is correct in that
> respect. I
> > haven't followed the thread well enough to have an opinion if RPL
> should do
> > that.
> >=20
> > Routers will also find other features of 6lowpan-nd-09 useful, for
> example
> > during initial bootstrapping, to maintain their default router and
> neighbor
> > caches, avoid the need for address resolution, and to=20
> perform NUD. The=20
> > draft (tries to) clearly state when features are required=20
> or optional
> for a
> > router.
> >=20
> > Zach
> >=20
> >=20
> > >> From: Michael Richardson 
> > >> Date: Tue, 27 Apr 2010 10:38:47 -0400
> > >>
> > >> >>>>> "Richard" =3D=3D Richard Kelsey 
> writes:
> > >>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From:=20
> "Pascal Thubert
> > >>     >> (pthubert)" 
> > >>     >>
> > >>     >> The question here is that the authoritative=20
> routers need to
> > >>     >> disseminate the PIO (and the RIO) to all routers in the
> subnet.
> > >>
> > >>     Richard> How do other routing protocols (OSPF, IS-IS, AODV,
> OLSR)
> > >>
> > >> I can only speak for OSPF and ISIS.
> > >> Neither deal with multi-hop subnets or with any kind of address=20
> > >> assignment.
> > >
> > > Why should RPL be any different?  Yes, it will be run on=20
> multi-hop=20
> > > subnets, but I still do not see how this affects the routing.
> > >
> > >> Both were written when multicast was very new.
> > >
> > > I am not sure how RPL's handling of multicast matters here.
> > > While RPL is required to route multi-hop multicasts, ND uses=20
> > > link-local multicasts, which do not require routing.
> > >
> > >> Richard> I understand that multi-hop subnets are a=20
> problem for ND,=20
> > >> Richard> but I don't see how the routing protocol is affected.
> > >>
> > >> RPL either requires 6lowpan, or it doesn't.
> > >
> > > RPL should work fine with ordinary ND.  Why would it require
> 6lowpan?
> > >
> > >> If it doesn't, then it has to provide for ND to work, or for
> another
> > >> protocol to replace it.
> > >
> > > ND works fine, using link-local, one-hop multicasts.  RPL need not
> be
> > > involved.
> > >
> > > If someone wants to run RPL on a node that uses neither=20
> ordinary ND
> or
> > > 6lowpan's version, then they will need some third variety=20
> of ND.  I
> do
> > > not see why this is an issue for RPL to address.  It=20
> seems quite out=20
> > > of scope.
> > >
> > >                               -Richard Kelsey=20
> > > _______________________________________________
> > > Roll mailing list
> > > Roll@ietf.org
> > > https://www.ietf.org/mailman/listinfo/roll
> > >
> >=20
> >=20
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20

From cabo@tzi.org  Thu Apr 29 02:27:05 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3341B3A6C6F; Thu, 29 Apr 2010 02:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqLPufaOUuSS; Thu, 29 Apr 2010 02:27:04 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 11B473A6C51; Thu, 29 Apr 2010 02:23:02 -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 o3T9MYn6003208; Thu, 29 Apr 2010 11:22:34 +0200 (CEST)
Received: from [192.168.217.101] (p5489AD64.dip.t-dialin.net [84.137.173.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E87B7DE4F;  Thu, 29 Apr 2010 11:22:33 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local>
Date: Thu, 29 Apr 2010 11:22:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local>
To: "Anders Brandt" 
X-Mailer: Apple Mail (2.1078)
Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org
Subject: Re: [Roll] how does a node get an IP address
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 09:27:05 -0000

> So could someone with the full overview outline explain to me
> how many mechanisms a RPL node running over 6lowPan will have
> to implement to be compatible with all other nodes claiming
> to be RPL compliant?
>=20
> My guess:
> * Classic RS/RA
> * DHCPv6
> * 6lowPAN ND
> * RPL address assignment
> * etc
>=20
> Should we make a decision someday? (!)

Anders,

that is indeed a very important point.
We need to get rid of as many of these options as possible.
At least for the baseline expectation.

In the 6LoWPAN context, we need to distinguish three kinds of nodes:

1 -- hosts, which should have absolutely minimal requirements imposed on =
them;
2 -- router nodes (6LR in ND-09 terminology), which need to be more =
complex to do routing, so they probably can also implement some =
additional complexity for other purposes such as bootstrapping;
3 -- edge routers (6LBR in ND-09 terminology), which have multiple =
interfaces and are more likely to be relatively powerful.

1) Hosts don't participate in RPL, so there cannot be any requirement =
from RPL on them.
Of course, 6LoWPAN-ND must do everything to enable a host node to =
participate, and to enable the router node(s) to represent the host in =
the network (6LoWPAN and/or RPL LLN).

2) Router nodes participate in a routing protocol.  Since RPL does not =
seem to address mixed networks, from an RPL point of view it can be =
assumed that they participate in RPL.  But they have only one interface, =
so that participation can still be governed by 6LoWPAN-based =
assumptions.

3) Edge routers have multiple interfaces, more than one of which might =
be engaged in RPL.  Full complexity, likely including DHCPv6 prefix =
delegation etc.

4) =46rom the point of view of RPL, there is a fourth kind of node: One =
that has no 6LoWPAN interface.  If that is not using 6LoWPAN-ND, it =
needs other ways to achieve bootstrapping.  I would not be happy if RPL =
would grow features that are needed only for bootstrapping this fourth =
kind of node and still make them mandatory for type 2 nodes (or even try =
to browbeat type 1 nodes into using them!).

Gruesse, Carsten


From yoav@yitran.com  Thu Apr 29 04:38:07 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FC43A6A30 for ; Thu, 29 Apr 2010 04:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3ZmjJpXmBl4 for ; Thu, 29 Apr 2010 04:38:04 -0700 (PDT)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id D22E33A689C for ; Thu, 29 Apr 2010 04:38:03 -0700 (PDT)
Received: from source ([74.125.83.43]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKS9lvjlDZv06puroOMX7+nVofRWACM66a@postini.com; Thu, 29 Apr 2010 04:37:51 PDT
Received: by gwb11 with SMTP id 11so2533565gwb.2 for ; Thu, 29 Apr 2010 04:37:50 -0700 (PDT)
Received: by 10.101.99.11 with SMTP id b11mr4549978anm.32.1272541069740; Thu,  29 Apr 2010 04:37:49 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <4BD8E89C.9020809@eecs.berkeley.edu>
In-Reply-To: <4BD8E89C.9020809@eecs.berkeley.edu>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrnQAFYHEEily+MREStPaUvKOIg6gATlkGQ
Date: Thu, 29 Apr 2010 14:37:47 +0300
Message-ID: 
To: Thomas Watteyne , roll@ietf.org
Content-Type: multipart/alternative; boundary=001636ed6d746c8b9a04855e8e24
Subject: Re: [Roll] Fwd: Re: DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 11:38:07 -0000

--001636ed6d746c8b9a04855e8e24
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just a quick question to the group:

Would it make sense to add path diversity to the OF =96 or is it already
implicitly included?

Perhaps we should define bit-wise OR-ing operation for the A-Field (to
propagate the diversity values along the path)? Though it would be a shame
to cross the 2 bits allocated for this field.



Regards,

Yoav





*From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On
Behalf Of *Thomas
Watteyne
*Sent:* Thursday, April 29, 2010 5:02 AM
*To:* roll@ietf.org
*Subject:* [Roll] Fwd: Re: DAO fan out



Roger,

Having a single byte for fan-out control and prioritization of downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast
protocol. I have a couple of questions, though.

1) Is this a technique you (or others on the list) have experience with? If
it's a proven technique, I'm glad to learn about it, and the WG will have
more confidence adopting it.

2) I have some questions related to path convergence, which relates to the
following paragraph in your text:

"An intermediate node may receive DAO messages from multiple children nodes
that advertise reachability to a given Destination Address. Where the total
number of set Path Control bits is greater than the number of DAO Parents
the
bitmaps for the DAO messages will be merged. This merging of set bits will
allow for subsequent fan out at subsequent ancestor nodes."

This is, if I receive DAOs with [00000110] and [00000001] from two of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that mean that, every
time I receive a DAO, I buffer it for some time in case I can merge it with
a later one? If yes, how do I choose the duration to wait? If I decide to
retransmit DAO's ASAP, and never merge them, what are the implications? As
you may understand, I'm not a very big fan of the idea of "buffering for
some time"...

I have taken a few minutes to verify that during fan-out, you should contro=
l
the parent selection (
http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf). It tells you that=
,
if two DAOs copies are sent towards the LBR, and each node en-route can
select its DAO parent randomly, the two obtained routes will not be
disjoint. That is, if one path fails, changes are the second will also as
they share many links.

3) Similar to Fig.5, consider fan-out and convergence causes the LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer?
Sure, [00000001] has traveled through all the best DAO parents, but wouldn'=
t
[00000110] offer me path diversity?

Similarly, what happens if the LBR has only one link to the rest of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.

Thomas

On 4/27/2010 2:11 PM, Roger Alexander wrote:

Hi Pascal,



Please find attached an expanded note on the DAO fan out control and path

prioritization mechanism.



Roger





-----Original Message-----

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com ]

Sent: Monday, April 19, 2010 11:35 AM

To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;

wintert@acm.org

Cc: ROLL WG

Subject: RE: [Roll] DAO fan out



Hi Roger:



At high level I'm very positive on the mechanism .



What I'd wish to see from the list is more people:

- agreeing that the fan out MUST be solved



For large scale networks it is important to have some mechanism to bound

downward paths once nodes can maintain multiple DAO parents. It will be up

to the WG of course but after having introduced multiple DAO parents,

leaving paths unconstrained introduces a potentially uncontrolled element o=
f

the protocol that can affect scalability; as networks become larger the

potential vulnerability increases. What is being recommended is a 1-byte

information element per DAO Destination Address. While incurring some

additional overhead path control can be disabled (bitmap set to all zeros)

for networks in which only a single DAO parent per node is maintained or

that not wish to implement constraints on path fan out or to differentiate

preferred downward paths.





- that this is a simple and efficient solution



Yes it would be good to get feedback from others on any concerns they may

have.





- that the solution can be incorporated in 08



Maybe what would help from you Roger is:

- a visual example on the mechanism as work (if you have a pdf

illustrating it?)



Note plus a few examples attached (pdf and MS Word).





- some more explanation on the source route case (how the root can play

the same game recursively and obtain a good result as well)



Based on the current -07 source route specification, non-storing nodes will

follow the same operation as storing nodes in using the Path Control byte t=
o

determine the number and selection of DAO parents through which the reverse

route stack is built.



If the source route specification is changed to the more recent proposal

from Richard, the Path Control byte can still apply to the advertised DAO

Destination Address and will be associated with each of the selected DAO

Parents communicated to the root. As in the case of storing nodes, each DAO

Destination Address will have a different Path Control byte for each

selected DAO Parent. For the source route case the root will be able to use

the Path Control preference associated with each selected DAO Parent to

recursively determine the preferred downward path to a given target address=
.

That is, at the root, the preferred downward path to a given target address

begins with the target's preferred DAO parent as given by the Path Control

byte. From that preferred DAO Parent the link to the next preferred DAO

ancestor is added until the complete preferred path is derived. The root

will also be capable of deriving all the potential path combinations to a

target node.



As I currently understand the new proposal it is not clear that non storing

nodes have any ability to control path fan out (and the consequently

increased reverse route processing at the root) when nodes maintain multipl=
e

DAO Parents.





Could you please so that for us?



Thanks a bunch,



Pascal







-----Original Message-----

From: Roger Alexander [mailto:roger.alexander@ekasystems.com
]

Sent: Friday, April 16, 2010 11:32 PM

To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP



Vasseur';



wintert@acm.org

Cc: 'ROLL WG'

Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back

welcome)



Below is a quick summary aligned to Tim's concept of how the Path



Control



bitmap associated with the DAO destination address can be used to



limit fan



out and to identify the preferred path when nodes maintain multiple



DAO



Parents.



Further details and examples can be provided as part of an larger

application domain note.



Roger





-----Original Message-----

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com ]

Sent: Tuesday, April 13, 2010 3:47 AM

To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;

wintert@acm.org

Cc: ROLL WG

Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)







Pascal





One consequence of maintaining multiple DAO parents is the



 potential



 fan



out of routing paths. With path fan out a node may have multiple



downward



next hop addresses for a given target destination address.



 Without



 some



path preference indication there is no information available if a



storing node



(including the root) wishes to limit the number of downward next



 hops



 maintained for a given address. It is thus desirable to have some



means of



path control to limit fan out as well as a preference indication



 that



 can work in



conjunction with the hop-by-hop DAO exchanges.



See the Figure below for an example in which nodes maintain two



 DAO



 Parents each, where in the worst case the fan out that occurs



 after



 three



hops results in eight next hop downward paths from the DODAG root



(LBR)



to a target node (41). Even with the hop-by-hop DAO mechanism it



would

be



desirable to be able to limit fan out as well as to identify path



preference and



diversity at the root or other intermediate storing node.



                    (------------LBR------------)

                    /    /   / |     | \    \   \

                   /    /   /  |     |  \    \   \

                  /    /   /   |     |   \    \   \

                 /    /   /    |     |    \    \   \

              (11) (12) (13) (14)   (15) (16) (17) (18)

                 \   |    |    /     \    |    |   /

                  \  |    |   /       \   |    |  /

                   \ |    |  /         \  |    | /

                  (21)   (22)           (23)  (24)

                      \    |            |    /

                       \   |            |   /

                        \  |            |  /

                         (31)          (32)

                             \        /

                              \      /

                               \    /

                                (41)





[Pascal] Your schema illustrates clearly that even if we fan out a



 lot,



 it does not mean that a router on the way down will have more



 feasible



 successors.



That's one thing that's important to remember, the properties of



 the



 DAG

are not symmetrical, so even if we build it to get multiple



 feasible



 successors on the way up, that does not mean that on the reverse



 DAG

to



 a target there are multiple successors at each hop towards that



 target.



 In other words, the ROI of fanning out is not guaranteed if we do



 it



 blindly.





A simple path control bitmap associated with the advertised



Destination



Address can be included within the DAO to address the issue of



 path



 preference as well as control of fan out. For a network of



'non-storing'



nodes the preference indication would be processed only at the



 root.



 [Pascal] so far so good, but that will give you a blind mechanism.





With the path control byte associated with each DAO destination



address, a



node will be able to specify preference among DAO parent paths



 and



 can



convey limits on the number of downward paths. This is an



 opportunity



 for



nodes to further influence the downward paths that are



 established



 and



maintained. Consistent with the DV-based RPL operation this DAO



 path



 control mechanism must operate hop-by-hop avoiding any



 requirement



 for



end-to-end path coordination. To avoid overloading this email



 thread



 I

will



initiate a separate discussion on how a path control element may



 be



 included



within the DAO.





[Pascal] Too late, I just did :)



And if I remember, Tim's idea was to control the stretch of the



 fanout,



 by decrementing a counter as the path loses preference point.

At the moment, we have a parent preference 0-lowest to 3 highest.



 So

it



 is easy to decrement a counter by (3-pref) and not fan out when the

counter reaches 0.

Tim, could you elaborate on this?



A Path Control bit map will achieve an equivalent control mechanism

whereby

at each node the number of bits that are set will determine the



extent

to



which the associated DAO Destination Address can be advertised to



multiple



DAO Parents. If a DAO message destination address Path Control bitmap



has



4

set bits, that address can be send along a maximum of 4 paths. For



example,



at the originating node the DAO can be sent to two DAO Parents where



the



Path Control bit map in the message sent to each DAO Parent will have



two



set bits. If each parent then advertises to two DAO Parents a single



bit is



set for each DAO message. Eventually with a single bit set in the



Path



Control bit map, the DAO message can be advertised only to a single



DAO



Parent. This mechanism achieves the effect of limiting the stretch of



the



path fan out. Where multiple DAO messages are received at a common

ancestor

the number of set bits in the respective Path Control fields are



recombined



allowing for renewed advertising of the DAO message destination



address to



multiple DAO Parents along the path.



As the set Path Control bits are split and recombined as the DAO



messages



are transferred to the root, their bit positions are maintained. This



allows



bit positions to be ordered from low to high in terms of path



preference.



Therefore when a DAO message is received in which the Path Control



bitmap



has the highest preference bit set, that DAO message destination



address is



always advertised to the preferred DAO Parent. Similarly, when a



message is



received with multiple Path Control bits set, the DAO messages can be

distributed to DAO Parents according to parent preference. This will



ensure



that at any common ancestor, including the root, a node is always



able

to



distinguish the preferred downward path. The ability to determine the

preferred downward path as well as to obtain an indication of path



diversity



will allow the Path Control field to be used when resource



limitations

at a



node require a truncation of the number of downward paths that the



node



maintain for a given destination address.





Pascal



 >



_______________________________________________

Roll mailing list

Roll@ietf.org

https://www.ietf.org/mailman/listinfo/roll

--001636ed6d746c8b9a04855e8e24
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable













    


    Just a quick question to the group:
    


    Would it make sense to add path diversity to the OF =96 or i=
s
it already implicitly included? 
    


    Perhaps we should define bit-wise OR-ing operation for the
A-Field (to propagate the diversity values along the path)? Though it would=
 be
a shame to cross the 2 bits allocated for this field.
    


    =A0
    


    Regards,
    


    Yoav
    


    =A0
    


    =A0
    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org]=
 On Behalf Of Thomas Watteyne
    
Sent: Thursday, April 29, 2010 5:02 AM
    
To: roll@ietf.org
    
Subject: [Roll] Fwd: Re: DAO fan out
    


    


    


    =A0
    


    Roger,

    
Having a single byte for fan-out control and prioritization of downstre=
am
paths is elegant. It reminds me of the (academic) GRAdient Broadcast protoc=
ol.
I have a couple of questions, though.
    

    
1) Is this a technique you (or others on the list) have experience with=
? If
it's a proven technique, I'm glad to learn about it, and the WG wil=
l have more
confidence adopting it.
    

    
2) I have some questions related to path convergence, which relates to =
the
following paragraph in your text:
    

    
"An intermediate node may receive DAO messages from multiple child=
ren
nodes
    
that advertise reachability to a given Destination Address. Where the t=
otal
    
number of set Path Control bits is greater than the number of DAO Paren=
ts
the
    
bitmaps for the DAO messages will be merged. This merging of set bits w=
ill
    
allow for subsequent fan out at subsequent ancestor nodes."

    
This is, if I receive DAOs with [00000110] and [00000001] from two of m=
y
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that mean t=
hat,
every time I receive a DAO, I buffer it for some time in case I can merge i=
t
with a later one? If yes, how do I choose the duration to wait? If I decide=
 to
retransmit DAO's ASAP, and never merge them, what are the implications?=
 As you
may understand, I'm not a very big fan of the idea of "buffering f=
or some
time"...
    

    
I have taken a few minutes to verify that during fan-out, you should
control the parent selection (http://www.eecs.berkeley.edu/~watteyne/disjointness.=
pdf).
It tells you that, if two DAOs copies are sent towards the LBR, and each no=
de
en-route can select its DAO parent randomly, the two obtained routes will n=
ot
be disjoint. That is, if one path fails, changes are the second will also a=
s
they share many links.
    

    
3) Similar to Fig.5, consider fan-out and convergence causes the LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer? Sur=
e,
[00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?
    

    
Similarly, what happens if the LBR has only one link to the rest of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.
    

    
Thomas
    

    
On 4/27/2010 2:11 PM, Roger Alexander wrote: 
    


    Hi Pascal,
    =A0
    Please find attached an expanded no=
te on the DAO fan out control and path
    prioritization mechanism.<=
/pre>
    =A0
    Roger
    =A0
    =A0 
    


    -----Origin=
al Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Monday=
, April 19, 2010 11:35 AM
    

    To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
    =
wintert@acm.org
    Cc: ROLL W=
G
    Subject: RE: [Roll] DAO fan out
    =A0
    Hi Roge=
r:
    

    =A0
    At high level I'm very positive on the mechanism .
    =A0
    What I'd wish to see from the list is more peopl=
e:
    - agreeing that the fan out MUST be solved
    =A0=A0=A0=
 
    

    


    For large scale networks it is important to have some mechanism to bou=
nd
    downward paths once nodes can maintain multiple DAO parents. I=
t will be up
    to the WG of course but after having introduced mult=
iple DAO parents,
    

    leaving paths unconstrained introduces a potentially uncontrolled elem=
ent of
    the protocol that can affect scalability; as networks beco=
me larger the
    potential vulnerability increases. What is being re=
commended is a 1-byte
    

    information element per DAO Destination Address. While incurring some<=
/pre>
    additional overhead path control can be disabled (bitmap set to a=
ll zeros)
    for networks in which only a single DAO parent per node=
 is maintained or
    

    that not wish to implement constraints on path fan out or to different=
iate
    preferred downward paths.
    =A0
    =A0 
    


    - that this=
 is a simple and efficient solution
    =A0=A0=A0 
    


    Yes it would be good to get feedback from others on any concerns they =
may
    have.
    =A0
    =A0 
    


    - that the =
solution can be incorporated in 08
    =A0
    Maybe what would=
 help from you Roger is:
    - a visual example on the mechanism as w=
ork (if you have a pdf
    

    illustrating it?)
    =A0=A0=A0 
    


    Note plus a few examples attached (pdf and MS Word).
    =A0
    =A0 
    


    - some more=
 explanation on the source route case (how the root can play
    the =
same game recursively and obtain a good result as well)
    =A0=A0=A0=
 
    

    


    Based on the current -07 source route specification, non-storing nodes=
 will
    follow the same operation as storing nodes in using the Pat=
h Control byte to
    determine the number and selection of DAO paren=
ts through which the reverse
    

    route stack is built. 
    =A0
    If the source route spe=
cification is changed to the more recent proposal
    from Richard, t=
he Path Control byte can still apply to the advertised DAO
    Destin=
ation Address and will be associated with each of the selected DAO
    

    Parents communicated to the root. As in the case of storing nodes, eac=
h DAO
    Destination Address will have a different Path Control byte=
 for each
    selected DAO Parent. For the source route case the root=
 will be able to use
    

    the Path Control preference associated with each selected DAO Parent t=
o
    recursively determine the preferred downward path to a given ta=
rget address.
    That is, at the root, the preferred downward path t=
o a given target address
    

    begins with the target's preferred DAO parent as given by the Path=
 Control
    byte. From that preferred DAO Parent the link to the nex=
t preferred DAO
    ancestor is added until the complete preferred pa=
th is derived. The root
    

    will also be capable of deriving all the potential path combinations t=
o a
    target node. 
    =A0
    As I currently understa=
nd the new proposal it is not clear that non storing
    nodes have a=
ny ability to control path fan out (and the consequently
    

    increased reverse route processing at the root) when nodes maintain mu=
ltiple
    DAO Parents.
    =A0=A0 
    =A0=A0
    


    Could you p=
lease so that for us?
    =A0
    Thanks a bunch,
    =A0=

    Pascal
    =A0
    =A0
    =A0=A0=A0 
    


    -----Origin=
al Message-----
    From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
    
Sent: Friday, April 16, 2010 11:32 PM
    To: Pascal Thubert (pthuber=
t); Navneet Agarwal (navagar); 'JP
    =A0=A0=A0=A0=A0 
    


    Vasseur';
    =A0=A0=A0 
    


    wintert@acm.org
    Cc: 'ROLL WG'=

    Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed=
-back
    

    welcome)
    =A0
    Below is a quick summary aligned to T=
im's concept of how the Path
    =A0=A0=A0=A0=A0 
    


    Control
    =A0=A0=A0 
    


    bitmap asso=
ciated with the DAO destination address can be used to
    =A0=A0=A0=
=A0=A0 
    


    limit fan
    =A0=A0=A0 
    


    out and to =
identify the preferred path when nodes maintain multiple
    =A0=A0=
=A0=A0=A0 
    


    DAO
    =A0=A0 =A0
    


    Parents.
    =A0
    Further details and examples can be provided as part =
of an larger
    application domain note.
    =A0
    Rog=
er
    

    =A0
    =A0=A0=A0=A0=A0 
    


    -----Origin=
al Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Tuesda=
y, April 13, 2010 3:47 AM
    

    To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
    =
wintert@acm.org
    Cc: ROLL W=
G
    Subject: DAO fan out (was:] IPSO Interop event - Feed-back welc=
ome)
    

    =A0
    =A0
    =A0
    Pascal
    =A0
    =A0=A0=A0=A0=A0=A0=A0 
    


    One consequ=
ence of maintaining multiple DAO parents is the
    =A0=A0=A0=A0=A0=
=A0=A0=A0=A0 
    


    


    


    potential
    =A0=A0=A0 
    


    


    fan
    =A0=A0=A0=A0=A0=A0=A0 
    


    out of rout=
ing paths. With path fan out a node may have multiple
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    downward
    =A0=A0=A0=A0=A0=A0=A0 
    


    next hop ad=
dresses for a given target destination address.
    =A0=A0=A0=A0=A0=
=A0=A0 =A0=A0
    






    Without
    =A0=A0=A0 
    


    


    some
    <=
pre>=A0=A0=A0=A0=A0=A0=A0 
    


    path prefer=
ence indication there is no information available if a
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    storing node
    =A0=A0=A0=A0=A0=A0=A0 
    


    (including =
the root) wishes to limit the number of downward next
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    






    hops
    =A0=A0=A0 
    


    


    


    maintained =
for a given address. It is thus desirable to have some
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    means of
    =A0=A0=A0=A0=A0=A0=A0 
    


    path contro=
l to limit fan out as well as a preference indication
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    


    


    that
    =A0=A0=A0 
    


    


    can work in=

    =A0=A0=A0=A0=A0=A0=A0 
    


    conjunction=
 with the hop-by-hop DAO exchanges.
    =A0
    See the Figure =
below for an example in which nodes maintain two
    =A0=A0=A0=A0=A0=
=A0=A0=A0=A0 
    

    


    


    


    DAO
    =A0=A0=A0 
    


    


    


    Parents eac=
h, where in the worst case the fan out that occurs
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    after
    =A0=A0=A0 
    


    


    three
    =

    =A0=A0=A0=A0=A0=A0=A0 
    


    hops result=
s in eight next hop downward paths from the DODAG root
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    (LBR)
    =A0=A0=A0=A0=A0=A0=A0 
    


    to a target=
 node (41). Even with the hop-by-hop DAO mechanism it
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    would
    be
    =A0=A0=A0=A0=A0=A0=A0 
    


    desirable t=
o be able to limit fan out as well as to identify path
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    preference and
    =A0=A0=A0=A0=A0=A0=A0 
    


    diversity a=
t the root or other intermediate storing node.
    =A0
    =A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (------------LBR----=
--------)
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 /=A0=A0=A0 /=A0=A0 / |=A0=A0=A0=A0 | \=A0=A0=A0 \=A0=A0 \
    

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0 /=A0=
=A0 /=A0 |=A0=A0=A0=A0 |=A0 \=A0=A0=A0 \=A0=A0 \
    =A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0 /=A0=A0 /=A0=A0 |=A0=A0=A0=
=A0 |=A0=A0 \=A0=A0=A0 \=A0=A0 \
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 /=A0=A0=A0 /=A0=A0 /=A0=A0=A0 |=A0=A0=A0=A0 |=A0 =A0=A0\=
=A0=A0=A0 \=A0=A0 \
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (11) =
(12) (13) (14)=A0=A0 (15) (16) (17) (18)
    

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 |=A0=A0=A0 |=
=A0=A0=A0 /=A0=A0=A0=A0 \=A0=A0=A0 |=A0=A0=A0 |=A0=A0 /
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0 |=A0=A0=A0 |=A0=A0 /=A0=A0=
=A0=A0=A0=A0 \=A0=A0 |=A0=A0=A0 |=A0 /
    =A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ |=A0=A0=A0 |=A0 /=A0=A0=A0=A0=A0=A0=A0=A0 =
\=A0 |=A0=A0=A0 | /
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 (21)=A0=A0 (22)=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0(23)=A0 (24)
    

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 /
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 |=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 /
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 |=A0 /
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 (31)=A0=A0=A0=A0=A0=A0=A0=A0=A0 (32)
    

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 \=A0=A0=A0=A0=A0=A0=A0 /
    =A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\=A0=A0=A0=
=A0=A0 /
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0 /
    =A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 (41)
    =A0
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 
    

    


    [Pascal] Your schema illustrates clearly that even if we fan out a
    =A0=A0=A0=A0=A0=A0=A0 
    


    


    lot,
    =A0=A0=A0 
    


    


    it does not=
 mean that a router on the way down will have more
    =A0=A0=A0=A0=
=A0=A0=A0 
    


    


    feasible
    =A0=A0=A0 
    


    


    successors.=

    =A0
    That's one thing that's important to remem=
ber, the properties of
    =A0=A0=A0=A0=A0=A0=A0 
    


    


    the
    =A0=A0=A0 
    


    


    DAG
    are not symmetrical, so even if we build it to get multiple
    =
=A0=A0=A0=A0=A0=A0=A0 
    


    


    feasible
    =A0=A0=A0 
    


    


    successors =
on the way up, that does not mean that on the reverse
    =A0=A0=A0=
=A0=A0=A0=A0 
    


    


    DAG
    to
    =A0=A0=A0 
    


    


    a target th=
ere are multiple successors at each hop towards that
    =A0=A0=A0=A0=
=A0=A0=A0 
    


    


    target.
    =A0=A0=A0 
    


    


    In other wo=
rds, the ROI of fanning out is not guaranteed if we do
    =A0=A0=A0=
=A0=A0=A0=A0 
    


    


    it
    =A0=A0=A0 
    


    


    blindly.
    =A0
    =A0=A0=A0=A0=A0=A0=A0 
    


    A simple pa=
th control bitmap associated with the advertised
    =A0=A0=A0=A0=A0=
=A0=A0=A0=A0 
    


    Destination
    =A0=A0=A0=A0=A0=A0=A0 
    


    Address can=
 be included within the DAO to address the issue of
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    path
    =A0=A0=A0 
    


    


    


    preference =
as well as control of fan out. For a network of
    =A0=A0 =A0=A0=A0=
=A0=A0=A0=A0
    


    'non-storing'
    =A0=A0=A0=A0=A0=A0=A0 
    


    nodes the p=
reference indication would be processed only at the
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    root.
    =A0=A0=A0 
    


    


    [Pascal] so=
 far so good, but that will give you a blind mechanism.
    =A0
    =

    =A0=A0=A0=A0=A0=A0=A0 
    


    With the pa=
th control byte associated with each DAO destination
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    address, a
    =A0=A0=A0=A0=A0=A0=A0 
    


    node will b=
e able to specify preference among DAO parent paths
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    and
    =A0=A0=A0 
    


    


    can
    =A0=A0=A0=A0=A0=A0=A0 


    convey limi=
ts on the number of downward paths. This is an
    =A0=A0=A0=A0=A0=A0=
=A0=A0=A0 
    


    


    


    opportunity
    =A0=A0=A0 
    


    


    for
    =A0=A0=A0=A0=A0=A0=A0 


    nodes to fu=
rther influence the downward paths that are
    =A0=A0=A0=A0=A0=A0=A0=
=A0=A0 
    


    


    


    established
    =A0=A0=A0 
    


    


    and
    =A0=A0=A0=A0=A0=A0=A0 


    maintained.=
 Consistent with the DV-based RPL operation this DAO
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    path
    =A0=A0=A0 
    


    


    


    control mec=
hanism must operate hop-by-hop avoiding any
    =A0=A0=A0=A0=A0=A0=A0=
=A0=A0 
    


    


    


    requirement
    =A0=A0=A0 
    


    


    for
    =A0=A0=A0=A0=A0=A0=A0 


    end-to-end =
path coordination. To avoid overloading this email
    =A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
    


    


    


    thread
    =A0=A0=A0 
    


    


    I
    will
    =A0=A0=A0=A0=A0=A0=A0 
    


    initiate a =
separate discussion on how a path control element may
    =A0=A0=A0=
=A0=A0=A0=A0=A0=A0 
    


    


    


    be
    =A0=A0=A0 
    


    


    included
    =A0=A0=A0=A0=A0=A0=A0 
    


    within the =
DAO.
    =A0
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 
    


    [Pascal] Too late, I just did :)
    =A0
    And if I reme=
mber, Tim's idea was to control the stretch of the
    =A0=A0=A0=
=A0=A0=A0=A0 
    


    


    fanout,
    =A0=A0=A0 
    


    


    by decremen=
ting a counter as the path loses preference point.
    At the moment,=
 we have a parent preference 0-lowest to 3 highest.
    =A0=A0=A0=A0=
=A0=A0=A0 
    

    


    


    So
    it
    =A0=A0=A0 
    


    


    is easy to =
decrement a counter by (3-pref) and not fan out when the
    counter =
reaches 0.
    Tim, could you elaborate on this?
    =A0=A0=A0=
=A0=A0=A0=A0 
    

    


    A Path Control bit map will achieve an equivalent control mechanism
    whereby
    at each node the number of bits that are set will=
 determine the
    =A0=A0=A0=A0=A0 
    


    extent
    to
    =A0=A0=A0 
    


    which the a=
ssociated DAO Destination Address can be advertised to
    =A0=A0=A0=
=A0=A0 
    


    multiple
    =A0=A0=A0 
    


    DAO Parents=
. If a DAO message destination address Path Control bitmap
    =A0=A0=
=A0=A0=A0 
    


    has
    =A0=A0=A0 
    


    4
    set bits, that address can be send along a maximum of 4 paths. For=A0=A0=A0=A0=A0 
    


    example,
    =A0=A0=A0 
    


    at the orig=
inating node the DAO can be sent to two DAO Parents where
    =A0=A0=
=A0=A0=A0 
    


    the
    =A0=A0=A0 
    


    Path Contro=
l bit map in the message sent to each DAO Parent will have
    =A0=A0=
=A0=A0=A0 
    


    two
    =A0=A0=A0 
    


    set bits. I=
f each parent then advertises to two DAO Parents a single
    =A0=A0=
=A0=A0=A0 
    


    bit is
    =A0=A0=A0 
    


    set for eac=
h DAO message. Eventually with a single bit set in the
    =A0=A0=A0=
=A0=A0 
    


    Path
    =A0=A0=A0 
    


    Control bit=
 map, the DAO message can be advertised only to a single
    =A0=A0=
=A0=A0=A0 
    


    DAO
    =A0=A0=A0 
    


    Parent. Thi=
s mechanism achieves the effect of limiting the stretch of
    =A0=A0=
=A0=A0=A0 
    


    the
    =A0=A0=A0 
    


    path fan ou=
t. Where multiple DAO messages are received at a common
    ancestor<=
/pre>
    the number of set bits in the respective Path Control fields are<=
/pre>

    =A0=A0=A0=A0=A0 
    


    recombined
    =A0=A0=A0 
    


    allowing fo=
r renewed advertising of the DAO message destination
    =A0=A0=A0=A0=
=A0 
    


    address to
    =A0=A0=A0 
    


    multiple DA=
O Parents along the path.
    =A0
    As the set Path Control b=
its are split and recombined as the DAO
    =A0=A0=A0=A0=A0 
    



    messages
    =A0=A0=A0 
    


    are transfe=
rred to the root, their bit positions are maintained. This
    =A0=A0=
=A0=A0=A0 
    


    allows
    =A0=A0=A0 
    


    bit positio=
ns to be ordered from low to high in terms of path
    =A0=A0=A0=A0=
=A0 
    


    preference.
    =A0=A0=A0 
    


    Therefore w=
hen a DAO message is received in which the Path Control
    =A0=A0=A0=
=A0=A0 
    


    bitmap
    =A0=A0=A0 
    


    has the hig=
hest preference bit set, that DAO message destination
    =A0=A0=A0=
=A0=A0 
    


    address is
    =A0=A0=A0 
    


    always adve=
rtised to the preferred DAO Parent. Similarly, when a
    =A0=A0=A0=
=A0=A0 
    


    message is
    =A0=A0=A0 
    


    received wi=
th multiple Path Control bits set, the DAO messages can be
    distri=
buted to DAO Parents according to parent preference. This will
    =A0=A0=A0=A0=A0 
    


    ensure
    =A0=A0=A0 
    


    that at any=
 common ancestor, including the root, a node is always
    =A0=A0=A0=
=A0=A0 
    


    able
    to
    =A0=A0=A0 
    


    distinguish=
 the preferred downward path. The ability to determine the
    prefer=
red downward path as well as to obtain an indication of path
    =A0=
=A0=A0=A0=A0 
    

    


    diversity
    =A0=A0=A0 
    


    will allow =
the Path Control field to be used when resource
    =A0=A0=A0=A0=A0 <=
/pre>
    


    limitations
    at a
    =A0=A0=A0 
    


    node requir=
e a truncation of the number of downward paths that the
    =A0=A0=A0=
=A0=A0 
    


    node
    =A0=A0=A0 
    


    maintain fo=
r a given destination address.
    =A0
    =A0=A0=A0=A0=A0 


    Pascal
    =A0=A0=A0=A0=A0=A0=A0 
    


    


    >=A0
    =A0
    ______________________________________=
_________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll
    

    


    =A0
    


    





--001636ed6d746c8b9a04855e8e24--

From abr@sdesigns.dk  Thu Apr 29 04:42:21 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678F63A6BD5 for ; Thu, 29 Apr 2010 04:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.831
X-Spam-Level: 
X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyor+H6qcEOd for ; Thu, 29 Apr 2010 04:42:20 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 5E6EF3A6C4C for ; Thu, 29 Apr 2010 04:42:06 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Apr 2010 13:41:52 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A0EB@zensys17.zensys.local>
In-Reply-To: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-dt-roll-p2p-rpl-00: Discovery of backwards source route
Thread-Index: Acrm+rxASXUmTaLlSIuPcvjPE1h4NAAlMF3w
References: <20100428174038.4A9903A6B04@core3.amsl.com> <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
From: "Anders Brandt" 
To: "Mukul Goyal" , "roll" 
Subject: [Roll] draft-dt-roll-p2p-rpl-00: Discovery of backwards source route
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 11:42:21 -0000

Hi,

I have found a few editorials and then a single question
to section 3.2:

The text says
"If node A had requested the discovery of a backwards (i.e. from B
to A) source-route, node B simply caches the route."

But is this true?
I would expect that some acknowledgement is needed. In an RF environment
there is a fair chance of dropping the packet somewhere along the way...
Without acknowledgements, node A would not know if it should try again -

or mark node B as unreachable (?).

Thanks,
  Anders

> -----Original Message-----
> From: Mukul Goyal [mailto:mukul@uwm.edu]=20
> Sent: Wednesday, April 28, 2010 19:46
> To: roll
> Cc: Anders Brandt; robert cragie; Emmanuel; Jerald P=20
> Martocci; charliep; Richard Kelsey
> Subject: Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
>=20
> Hi all
>=20
> The following draft has been submitted for WG's=20
> consideration. It describes the additional mechanisms=20
> required to support P2P routing in LLNs. The draft first=20
> provides a high level description of the mechanisms and then=20
> proposes one way of realizing these mechanisms in RPL.
>=20
> Regards
> Mukul
>=20
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00=20
> US/Canada Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00=20
>=20
>=20
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been=20
> successfully submitted by Mukul Goyal and posted to the IETF=20
> repository.
>=20
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point=20
> Routing in Low Power and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
>=20
> Abstract:
> This draft presents mechanisms to determine the end-to-end=20
> cost of an existing route and to discover/establish "on=20
> demand" one or more routes between two nodes in a low power=20
> and lossy network.  This draft also proposes functionality=20
> that would enable RPL to provide these P2P mechanisms.
>                                                              =20
>                    =20
>=20
>=20
> The IETF Secretariat.
>=20
>=20
>=20

From yoav@yitran.com  Thu Apr 29 05:04:26 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD523A6C93 for ; Thu, 29 Apr 2010 05:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.424
X-Spam-Level: 
X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppbl5yLik8S9 for ; Thu, 29 Apr 2010 05:04:24 -0700 (PDT)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id 6F3A43A6907 for ; Thu, 29 Apr 2010 05:03:43 -0700 (PDT)
Received: from source ([209.85.211.172]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKS9l1kkdKADB0K64Zmr14Etps+4rHYuMK@postini.com; Thu, 29 Apr 2010 05:03:30 PDT
Received: by mail-yw0-f172.google.com with SMTP id 2so7860062ywh.0 for ; Thu, 29 Apr 2010 05:03:30 -0700 (PDT)
Received: by 10.100.234.26 with SMTP id g26mr4060227anh.147.1272542609753;  Thu, 29 Apr 2010 05:03:29 -0700 (PDT)
From: Yoav Ben-Yehezkel 
References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu>	 <3616A8AB-F095-4562-BD0F-110651FEB013@cisco.com>	 <00EDBF30-7C9D-464F-AB35-AAB187F1C8BC@cisco.com> <33f90a790ceb7027803faa6bdd82709e@mail.gmail.com>  <5A0B475C-16EB-4D70-85B3-33778EA19B99@cisco.com>
In-Reply-To: <5A0B475C-16EB-4D70-85B3-33778EA19B99@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrm//CIjB8a455wSaKsoSddhzPYMgAkJVBA
Date: Thu, 29 Apr 2010 15:03:28 +0300
Message-ID: <4007fd4e6df11190ae7147d84c7cfd07@mail.gmail.com>
To: JP Vasseur 
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll 
Subject: Re: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 12:04:26 -0000

While you're at it, I think I found a few more related small editorial
comments:
"
2.  Object Formats
...
   o  A Field: The A field is used to indicate whether a routing metric
      is additive, reports a maximum or a minimum.
"
Should be:
"   o  A Field: The A field is used to indicate whether a routing metric
      is additive, multiplicative, reports a maximum or a minimum.
"

Another one in section 2:
"
   Example 1: A DAG formed by RPL where all nodes must be main powered
   and the link metric is the link throughput.  In this case the DAG
   Metric container carries two routing objects: the link metric is the
   link throughput (C=0, O=0, A=00, G=1, R=0) and the node constraint is
   power (C=1, O=0, A=00, G=0, R=0).  Note that in this example, the
   link throughput is a global additive aggregated link metric.  An RPL
   implementation may use the metric to report a minimum (A=01).  In
   this case, when the link throughput metric is processed each node
   updates it is the link throughput is less than the value reported by
   the link throughput metric.
"

The text: "An RPL implementation may use the metric to report a minimum
(A=01)."
Should be changed either to:
"An RPL implementation may use the metric to report a minimum (A=02)." OR
"An RPL implementation may use the metric to report a maximum (A=01)."

Question regarding the following in 4.3.1:

"  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path."

This means that an undetermined value (0) beats best value (1) being the
minimum of the two. Is this really the intent? Suggested replacement text
if not:

"  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path,
   ignoring undetermined LQLs (Aggregated LQL Value = 0)."

Also, why does this para. describe only LQL for additive and minimum?
Shouldn't it also describe multiplicative (suggested in previous thread
message) and maximum as well?

I think there are some inconsistencies in section 9.2 and maybe also 9.3:
"
   Codespace of the A field (NSA Object)
    Value  Meaning                              Reference

      0    Routing metric is additive           This document
      2    Routing metric reports a maximum     This document
      3    Routing metric reports a minimum     This document
      4    Routing metric is multiplicative     This document
"
Should the values be inconsistent with the values in the text?

Also:
"   Codespace of the Flag field (Routing common header)
     Bit      Description              Reference

      8       Constraint/metric        This document
      7       Optional Constraint      This document
      5-6     Additive/Max/Min         This document
      4       Global/Local             This document
      3       Recorded/Aggregated      This document
"

Should it be?
"5-6     Additive/Max/Min/Mult    This document"

What does the term "flag field" mean (for example, "NSA Object flag
field")? Does it mean flags/fields?


That's it for now :)

Yoav



-----Original Message-----
From: JP Vasseur [mailto:jpv@cisco.com]
Sent: Wednesday, April 28, 2010 9:24 PM
To: Yoav Ben-Yehezkel
Cc: Omprakash Gnawali; roll
Subject: Re: [Roll] The need for multiplicative metrics and other comments
on draft-ietf-roll-routing-metrics-05

Hi,

Good comments, which we agreed upon some time ago, I forgot to
incorporate it.
OK that will be in the next revision for sure.

Cheers.

JP.

On Apr 28, 2010, at 8:20 PM, Yoav Ben-Yehezkel wrote:

> Hi,
>
> Sorry for coming up with this comment after this release... It came
> up to
> me only when reviewing the diffs between new and previous version :)
>
> I think there a small issue in the following para.:
>
> "
> 4.3.1.  The Link Quality Level Reliability Metric
> ...
>     0               1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Aggregated LQL Value     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Figure 13: LQL Type 2 sub-Object format
>
>   Aggregated LQL Value: when used an an additive metric (A=0x00), the
>   aggregated LQL value reports the sum of all the LQL values for all
>   links along the path.  When used to report a minimum (A=0x02), the
>   field reports the minimum LQL value of all links along the path.
>
> "
>
> In case the LQL on any link is unknown 0, and the metric is
> multiplicative
> (A=0x03), using a multiplication by 0 would reset the aggregated LQL
> value, whereas if the metric is additive, the aggregated LQL value
> will
> remain unchanged. So I suggest to update the above para. to:
>
> "
> ...
>   Aggregated LQL Value: when used an an additive metric (A=0x00), the
>   aggregated LQL value reports the sum of all the LQL values for all
>   links along the path.  When used to report a minimum (A=0x02), the
>   field reports the minimum LQL value of all links along the path.
> When
>   used to report a multiplication (A=0x03), and the LQL
>   field of one of the links along the path is undetermined (LQL=0),
>   the undetermined LQL will be ignored and not aggregated (i.e. no
>   reset to Aggregated LQL Value field).
> "
>
> Thanks,
> Yoav
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of JP
> Vasseur
> Sent: Wednesday, April 28, 2010 2:06 PM
> To: Omprakash Gnawali
> Cc: roll
> Subject: Re: [Roll] The need for multiplicative metrics and other
> comments
> on draft-ietf-roll-routing-metrics-05
>
> Hi,
>
> On Apr 13, 2010, at 6:44 PM, Omprakash Gnawali wrote:
>
>> On Tue, Apr 13, 2010 at 12:34 AM, JP Vasseur  wrote:
>> ...
>>>> 2. Towards the end of 4.3.2:
>>>>
>>>> "The ETX object may be used as a constraint or a path metric.  For
>>>> example, an Objective Function may indicate that the ETX must not
>>>> be
>>>> below some specified value."
>>>>
>>>> Should be: ETX must not be more than some specified value.
>>>>
>>>
>>> Good catch, will fix it.
>>
>> The ETX Objective Function proposes a threshold. While I was working
>> on ETXOF, the difficulty was coming up with the "right" threshold for
>> both link ETX and path ETX. This might be a configuration parameter
>> but it is not clear what the default value should be. It will be
>> great
>> to get feedback from the WG on what the default should be.
>
> It is application dependent, and does not need to be standardized.
> This is not a protocol
> parameter either, so no need to suggest a default value.
>
> Thanks.
>
> JP.
>
>>
>> - om_p
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From prvs=728cdad50=mukul@uwm.edu  Thu Apr 29 05:41:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6519428C105 for ; Thu, 29 Apr 2010 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.039
X-Spam-Level: 
X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=1.071,  BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggtk+bkSB03u for ; Thu, 29 Apr 2010 05:41:13 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 12EB13A6BFE for ; Thu, 29 Apr 2010 05:36:46 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 29 Apr 2010 07:36:32 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B498C2C38011; Thu, 29 Apr 2010 07:36:32 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 efMewHbFAcv2; Thu, 29 Apr 2010 07:36:32 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 819062C3800D; Thu, 29 Apr 2010 07:36:32 -0500 (CDT)
Date: Thu, 29 Apr 2010 07:36:32 -0500 (CDT)
From: Mukul Goyal 
To: Anders Brandt 
Message-ID: <1198136777.4420631272544592409.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A0EB@zensys17.zensys.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: Re: [Roll] draft-dt-roll-p2p-rpl-00: Discovery of backwards source route
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 12:41:15 -0000

Hi Anders

Good catch! This makes sense. I guess, in this case, B still needs to send a Discovery Reply message to node A acking the receipt of a "good enough" route. The Discovery Reply message would otherwise be empty. It should also be possible for node B to "aggregate" such Ack messages for each discovered route together. In other words, B should be able to send a "cumulative ack" to A saying it now has the desired number of "good enough" routes (to A), rather than acking the discovery of each such route separately.   

Thanks
Mukul

----- Original Message -----
From: "Anders Brandt" 
To: "Mukul Goyal" , "roll" 
Sent: Thursday, April 29, 2010 6:41:52 AM GMT -06:00 US/Canada Central
Subject: draft-dt-roll-p2p-rpl-00: Discovery of backwards source route

Hi,

I have found a few editorials and then a single question
to section 3.2:

The text says
"If node A had requested the discovery of a backwards (i.e. from B
to A) source-route, node B simply caches the route."

But is this true?
I would expect that some acknowledgement is needed. In an RF environment
there is a fair chance of dropping the packet somewhere along the way...
Without acknowledgements, node A would not know if it should try again -

or mark node B as unreachable (?).

Thanks,
  Anders

> -----Original Message-----
> From: Mukul Goyal [mailto:mukul@uwm.edu] 
> Sent: Wednesday, April 28, 2010 19:46
> To: roll
> Cc: Anders Brandt; robert cragie; Emmanuel; Jerald P 
> Martocci; charliep; Richard Kelsey
> Subject: Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
> 
> Hi all
> 
> The following draft has been submitted for WG's 
> consideration. It describes the additional mechanisms 
> required to support P2P routing in LLNs. The draft first 
> provides a high level description of the mechanisms and then 
> proposes one way of realizing these mechanisms in RPL.
> 
> Regards
> Mukul
> 
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 
> US/Canada Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 
> 
> 
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been 
> successfully submitted by Mukul Goyal and posted to the IETF 
> repository.
> 
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point 
> Routing in Low Power and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
> 
> Abstract:
> This draft presents mechanisms to determine the end-to-end 
> cost of an existing route and to discover/establish "on 
> demand" one or more routes between two nodes in a low power 
> and lossy network.  This draft also proposes functionality 
> that would enable RPL to provide these P2P mechanisms.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 
> 

From charliep@computer.org  Wed Apr 28 11:40:04 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AE53A6B64 for ; Wed, 28 Apr 2010 11:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.62
X-Spam-Level: 
X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0+h6CQWzhT9 for ; Wed, 28 Apr 2010 11:40:02 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0110A3A695F for ; Wed, 28 Apr 2010 11:40:02 -0700 (PDT)
Received: from [12.204.153.98] (helo=[10.166.254.28]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1O7CAl-0007Nk-Aj; Wed, 28 Apr 2010 14:39:47 -0400
Message-ID: <4BD880EE.4010502@computer.org>
Date: Wed, 28 Apr 2010 11:39:42 -0700
From: "Charles E. Perkins" 
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: JP Vasseur 
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5297913e864104b7c13f55906dc773a239350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
X-Mailman-Approved-At: Thu, 29 Apr 2010 09:52:42 -0700
Cc: roll , Mukul Goyal 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: charliep@computer.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, 28 Apr 2010 18:40:04 -0000

Hello JP,

I think that the members of the discussion team
do qualify as a "design team".  However, it is true
that the design team was not an official design
team appointed by directive of the working group.

Instead, it was an independently organized design
team.  The document doesn't claim that the design
team has any special working group status.

Nevertheless, the working group may find the
results to be of significant value.

Regards,
Charlie P.


On 4/28/2010 11:17 AM, JP Vasseur wrote:
> Thanks Mukul. Just a minor point to avoid confusion for the WG, there is
> no P2P Design Team.
>
> Thanks.
>
> JP.
>
> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:
>
>> Hi all
>>
>> The following draft has been submitted for WG's consideration. It
>> describes the additional mechanisms required to support P2P routing in
>> LLNs. The draft first provides a high level description of the
>> mechanisms and then proposes one way of realizing these mechanisms in
>> RPL.
>>
>> Regards
>> Mukul

From pal@cs.stanford.edu  Thu Apr 29 09:55:31 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD663A6BEA for ; Thu, 29 Apr 2010 09:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.233
X-Spam-Level: 
X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td5RyYGGhDID for ; Thu, 29 Apr 2010 09:55:30 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 479123A6BCB for ; Thu, 29 Apr 2010 09:55:30 -0700 (PDT)
Received: from dn0a210110.sunet ([10.33.1.16]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O7X1A-0005L7-5X; Thu, 29 Apr 2010 09:55:16 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <4BD880EE.4010502@computer.org>
Date: Thu, 29 Apr 2010 09:55:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>  <4BD880EE.4010502@computer.org>
To: charliep@computer.org
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2
Cc: roll , Mukul Goyal 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 16:55:31 -0000

On Apr 28, 2010, at 11:39 AM, Charles E. Perkins wrote:

>=20
> Hello JP,
>=20
> I think that the members of the discussion team
> do qualify as a "design team".  However, it is true
> that the design team was not an official design
> team appointed by directive of the working group.

Sure -- so please try to use clear, rather than confusing, terminology. =
I, for example, could think that the group of us working on trickle do =
qualify as a "working group" in that we are a group that is working. But =
using such a term would hardly be considered helpful.

Phil=

From roger.alexander@ekasystems.com  Thu Apr 29 10:42:42 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F723A691F for ; Thu, 29 Apr 2010 10:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.605
X-Spam-Level: 
X-Spam-Status: No, score=0.605 tagged_above=-999 required=5 tests=[AWL=-0.847,  BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+SA3bnJp7mM for ; Thu, 29 Apr 2010 10:42:26 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 96E023A6407 for ; Thu, 29 Apr 2010 10:42:25 -0700 (PDT)
Received: (qmail 78164 invoked from network); 29 Apr 2010 17:42:09 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp112.biz.mail.re2.yahoo.com with SMTP; 29 Apr 2010 10:42:09 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: WAt53noVM1kftcgT1jA02QN5NDppw0KN911lf5o_SHJ59G89b_UivlpqUblxU6wqCqYykpkCS1GiVojd9APfjgVMoOyxZ07eoFzlFjENkEWmyTZ_pT0qQ.NOkxz22RSu8Rfx.F5SItQtN_3cH9gYlTBZ8Z1DVuZPT6hpweJk6kXQ.TErZgvcNg0iadLe7CtcnVuBRRQg17GOT9awpGFkj8upNZWmwryfY3rqEv80Zbv2hDNexZR5BesU9cGdutaUwGL0ih.TS1P9VLne8O.KQRXTnL5MTexIjvJycxFxtrurA5gQ59Sz85YbMUSuGZ0kyvNQgzCN_k8uYlGcziXDQdk5e4ZvWBg576CXxsnQkPP3PqG5x7RYoi8QtkoxWL2nVe0-
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Thomas Watteyne'" , 
References: <4BD8E89C.9020809@eecs.berkeley.edu>
In-Reply-To: <4BD8E89C.9020809@eecs.berkeley.edu>
Date: Thu, 29 Apr 2010 13:40:03 -0400
Message-ID: <02dc01cae7c3$0023b6e0$006b24a0$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DD_01CAE7A1.791216E0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrnP/tiv3Ff0WoRRhuIa74A6HTa6AAY56GQ
Content-Language: en-us
Subject: Re: [Roll] Fwd: Re:  DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 17:42:42 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_02DD_01CAE7A1.791216E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Thomas,

 

Thanks for the feedback and the simulation results.

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Thomas Watteyne
Sent: Wednesday, April 28, 2010 10:02 PM
To: roll@ietf.org
Subject: [Roll] Fwd: Re: DAO fan out

 

Roger,

Having a single byte for fan-out control and prioritization of downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast
protocol. I have a couple of questions, though.

1) Is this a technique you (or others on the list) have experience with? If
it's a proven technique, I'm glad to learn about it, and the WG will have
more confidence adopting it.

[RA] No this is not a proven or deployed technique. The proposal is based on
a concern that arises from our deployed networks where single root nodes do
support a network of thousands of nodes. Once multiple DAO parents are
entertained for downward routing availability, routing scalability can be
affected if DAO exchanges are left  unbounded. Furthermore, there will need
to be a means of extracting the preferred downward path and selecting from
the many alternatives that can result.



2) I have some questions related to path convergence, which relates to the
following paragraph in your text:

"An intermediate node may receive DAO messages from multiple children nodes
that advertise reachability to a given Destination Address. Where the total
number of set Path Control bits is greater than the number of DAO Parents
the
bitmaps for the DAO messages will be merged. This merging of set bits will
allow for subsequent fan out at subsequent ancestor nodes."

This is, if I receive DAOs with [00000110] and [00000001] from two of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that mean that, every
time I receive a DAO, I buffer it for some time in case I can merge it with
a later one? If yes, how do I choose the duration to wait? If I decide to
retransmit DAO's ASAP, and never merge them, what are the implications? As
you may understand, I'm not a very big fan of the idea of "buffering for
some time"...

[RA] The note was written from the perspective of a network with all storing
nodes. For storing nodes, DAO advertisements and made and updated based on
the validity period of the received Destination Address routing updates. It
that context the issue of buffering is well defined. There is however an
issue of dealing with the sequence of DAO advertisements that will be
received at different intervals that may require subsequent change in the
selected DAO Parent. To maintain the requirement that the preferred path can
always be determined, there may be periods during which fewer DAO Parents
are selected than may be otherwise available at a given intermediate node
(future consideration required).

 

[RA] For non storing nodes, based on my understanding of the currently
discussed proposal, the situation is simpler in that the originating owner
of the Destination Address establishes the preference and includes the
applicable Path Control setting with the different DAO Parents selected.
Each node selects its DAO Parents and indicates the preference of each. Each
node's information needs only to be available at the root which then
computes all downward paths. The onus for scalability in processing the
downward path routing is placed on the root node - with processing
requirements increasing with the number of DAO Parents. However, all the
information is available for global determination of preferred, as well as
secondary downward paths. 



I have taken a few minutes to verify that during fan-out, you should control
the parent selection
(http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf). It tells you
that, if two DAOs copies are sent towards the LBR, and each node en-route
can select its DAO parent randomly, the two obtained routes will not be
disjoint. That is, if one path fails, changes are the second will also as
they share many links.

[RA] Thanks. This is an interesting result, caveats notwithstanding. I would
like to digest a bit further and get back to you. The benefit of multiple
DAO Parents is predicated on the downward diversity that it provides. The
cost of multiple DAO Parents and fan out is that it can negate some of RPL's
routing scalability benefits (for storing nodes). If as the results suggest
multiple DAO Parents does not provide a meaningful path availability gain
then its utility is somewhat diminished. 



3) Similar to Fig.5, consider fan-out and convergence causes the LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer?
Sure, [00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?

[RA] Yes, diversity information may be derived from the path Control and can
be used as a selection criteria when making a choice of downward path. That
would be an implementation choice. 



Similarly, what happens if the LBR has only one link to the rest of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.

[RA] If that were the case the LBR would indeed receive one packet with
[11111111].  However the collective path information would be available to
the single node that connects to the LBR. That node, and all other
intermediate (storing) nodes, use the available path control information to
support downward path selection. In the case of non-storing nodes the root
would calculate the downward paths that would diverge not from the root but
a node(s) further down the tree.



Thomas

On 4/27/2010 2:11 PM, Roger Alexander wrote: 

Hi Pascal,
 
Please find attached an expanded note on the DAO fan out control and path
prioritization mechanism.
 
Roger
 
  

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Monday, April 19, 2010 11:35 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: RE: [Roll] DAO fan out
 
Hi Roger:
 
At high level I'm very positive on the mechanism .
 
What I'd wish to see from the list is more people:
- agreeing that the fan out MUST be solved
    

For large scale networks it is important to have some mechanism to bound
downward paths once nodes can maintain multiple DAO parents. It will be up
to the WG of course but after having introduced multiple DAO parents,
leaving paths unconstrained introduces a potentially uncontrolled element of
the protocol that can affect scalability; as networks become larger the
potential vulnerability increases. What is being recommended is a 1-byte
information element per DAO Destination Address. While incurring some
additional overhead path control can be disabled (bitmap set to all zeros)
for networks in which only a single DAO parent per node is maintained or
that not wish to implement constraints on path fan out or to differentiate
preferred downward paths.
 
  

- that this is a simple and efficient solution
    

Yes it would be good to get feedback from others on any concerns they may
have.
 
  

- that the solution can be incorporated in 08
 
Maybe what would help from you Roger is:
- a visual example on the mechanism as work (if you have a pdf
illustrating it?)
    

Note plus a few examples attached (pdf and MS Word).
 
  

- some more explanation on the source route case (how the root can play
the same game recursively and obtain a good result as well)
    

Based on the current -07 source route specification, non-storing nodes will
follow the same operation as storing nodes in using the Path Control byte to
determine the number and selection of DAO parents through which the reverse
route stack is built. 
 
If the source route specification is changed to the more recent proposal
from Richard, the Path Control byte can still apply to the advertised DAO
Destination Address and will be associated with each of the selected DAO
Parents communicated to the root. As in the case of storing nodes, each DAO
Destination Address will have a different Path Control byte for each
selected DAO Parent. For the source route case the root will be able to use
the Path Control preference associated with each selected DAO Parent to
recursively determine the preferred downward path to a given target address.
That is, at the root, the preferred downward path to a given target address
begins with the target's preferred DAO parent as given by the Path Control
byte. From that preferred DAO Parent the link to the next preferred DAO
ancestor is added until the complete preferred path is derived. The root
will also be capable of deriving all the potential path combinations to a
target node. 
 
As I currently understand the new proposal it is not clear that non storing
nodes have any ability to control path fan out (and the consequently
increased reverse route processing at the root) when nodes maintain multiple
DAO Parents.
   
  

Could you please so that for us?
 
Thanks a bunch,
 
Pascal
 
 
    

-----Original Message-----
From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
Sent: Friday, April 16, 2010 11:32 PM
To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
      

Vasseur';
    

wintert@acm.org
Cc: 'ROLL WG'
Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
welcome)
 
Below is a quick summary aligned to Tim's concept of how the Path
      

Control
    

bitmap associated with the DAO destination address can be used to
      

limit fan
    

out and to identify the preferred path when nodes maintain multiple
      

DAO
    

Parents.
 
Further details and examples can be provided as part of an larger
application domain note.
 
Roger
 
      

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, April 13, 2010 3:47 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
 
 
 
Pascal
 
        

One consequence of maintaining multiple DAO parents is the
          

potential
    

fan
        

out of routing paths. With path fan out a node may have multiple
          

downward
        

next hop addresses for a given target destination address.
          

Without
    

some
        

path preference indication there is no information available if a
          

storing node
        

(including the root) wishes to limit the number of downward next
          

hops
    

maintained for a given address. It is thus desirable to have some
          

means of
        

path control to limit fan out as well as a preference indication
          

that
    

can work in
        

conjunction with the hop-by-hop DAO exchanges.
 
See the Figure below for an example in which nodes maintain two
          

DAO
    

Parents each, where in the worst case the fan out that occurs
          

after
    

three
        

hops results in eight next hop downward paths from the DODAG root
          

(LBR)
        

to a target node (41). Even with the hop-by-hop DAO mechanism it
          

would
be
        

desirable to be able to limit fan out as well as to identify path
          

preference and
        

diversity at the root or other intermediate storing node.
 
                    (------------LBR------------)
                    /    /   / |     | \    \   \
                   /    /   /  |     |  \    \   \
                  /    /   /   |     |   \    \   \
                 /    /   /    |     |    \    \   \
              (11) (12) (13) (14)   (15) (16) (17) (18)
                 \   |    |    /     \    |    |   /
                  \  |    |   /       \   |    |  /
                   \ |    |  /         \  |    | /
                  (21)   (22)           (23)  (24)
                      \    |            |    /
                       \   |            |   /
                        \  |            |  /
                         (31)          (32)
                             \        /
                              \      /
                               \    /
                                (41)
 
          

[Pascal] Your schema illustrates clearly that even if we fan out a
        

lot,
    

it does not mean that a router on the way down will have more
        

feasible
    

successors.
 
That's one thing that's important to remember, the properties of
        

the
    

DAG
are not symmetrical, so even if we build it to get multiple
        

feasible
    

successors on the way up, that does not mean that on the reverse
        

DAG
to
    

a target there are multiple successors at each hop towards that
        

target.
    

In other words, the ROI of fanning out is not guaranteed if we do
        

it
    

blindly.
 
        

A simple path control bitmap associated with the advertised
          

Destination
        

Address can be included within the DAO to address the issue of
          

path
    

preference as well as control of fan out. For a network of
          

'non-storing'
        

nodes the preference indication would be processed only at the
          

root.
    

[Pascal] so far so good, but that will give you a blind mechanism.
 
        

With the path control byte associated with each DAO destination
          

address, a
        

node will be able to specify preference among DAO parent paths
          

and
    

can
        

convey limits on the number of downward paths. This is an
          

opportunity
    

for
        

nodes to further influence the downward paths that are
          

established
    

and
        

maintained. Consistent with the DV-based RPL operation this DAO
          

path
    

control mechanism must operate hop-by-hop avoiding any
          

requirement
    

for
        

end-to-end path coordination. To avoid overloading this email
          

thread
    

I
will
        

initiate a separate discussion on how a path control element may
          

be
    

included
        

within the DAO.
 
          

[Pascal] Too late, I just did :)
 
And if I remember, Tim's idea was to control the stretch of the
        

fanout,
    

by decrementing a counter as the path loses preference point.
At the moment, we have a parent preference 0-lowest to 3 highest.
        

So
it
    

is easy to decrement a counter by (3-pref) and not fan out when the
counter reaches 0.
Tim, could you elaborate on this?
        

A Path Control bit map will achieve an equivalent control mechanism
whereby
at each node the number of bits that are set will determine the
      

extent
to
    

which the associated DAO Destination Address can be advertised to
      

multiple
    

DAO Parents. If a DAO message destination address Path Control bitmap
      

has
    

4
set bits, that address can be send along a maximum of 4 paths. For
      

example,
    

at the originating node the DAO can be sent to two DAO Parents where
      

the
    

Path Control bit map in the message sent to each DAO Parent will have
      

two
    

set bits. If each parent then advertises to two DAO Parents a single
      

bit is
    

set for each DAO message. Eventually with a single bit set in the
      

Path
    

Control bit map, the DAO message can be advertised only to a single
      

DAO
    

Parent. This mechanism achieves the effect of limiting the stretch of
      

the
    

path fan out. Where multiple DAO messages are received at a common
ancestor
the number of set bits in the respective Path Control fields are
      

recombined
    

allowing for renewed advertising of the DAO message destination
      

address to
    

multiple DAO Parents along the path.
 
As the set Path Control bits are split and recombined as the DAO
      

messages
    

are transferred to the root, their bit positions are maintained. This
      

allows
    

bit positions to be ordered from low to high in terms of path
      

preference.
    

Therefore when a DAO message is received in which the Path Control
      

bitmap
    

has the highest preference bit set, that DAO message destination
      

address is
    

always advertised to the preferred DAO Parent. Similarly, when a
      

message is
    

received with multiple Path Control bits set, the DAO messages can be
distributed to DAO Parents according to parent preference. This will
      

ensure
    

that at any common ancestor, including the root, a node is always
      

able
to
    

distinguish the preferred downward path. The ability to determine the
preferred downward path as well as to obtain an indication of path
      

diversity
    

will allow the Path Control field to be used when resource
      

limitations
at a
    

node require a truncation of the number of downward paths that the
      

node
    

maintain for a given destination address.
 
      

Pascal
        

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

 


------=_NextPart_000_02DD_01CAE7A1.791216E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi Thomas,
    


     
    


    Thanks for the feedback and the simulation =
results.
    


     
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Thomas Watteyne
    
Sent: Wednesday, April 28, 2010 10:02 PM
    
To: roll@ietf.org
    
Subject: [Roll] Fwd: Re: DAO fan out
    


    


    


     
    


    Roger,
    

    
Having a single byte for fan-out control and prioritization of =
downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast =
protocol.
I have a couple of questions, though.
    

    
1) Is this a technique you (or others on the list) have experience =
with? If
it's a proven technique, I'm glad to learn about it, and the WG will =
have more
confidence adopting it.
    


    [RA] No this is not a proven or deployed technique. The =
proposal
is based on a concern that arises from our deployed networks where =
single root
nodes do support a network of thousands of nodes. Once multiple DAO =
parents are
entertained for downward routing availability, routing scalability can =
be
affected if DAO exchanges are left  unbounded. Furthermore, there =
will need
to be a means of extracting the preferred downward path and selecting =
from the
many alternatives that can result.
    



    

    
2) I have some questions related to path convergence, which relates =
to the
following paragraph in your text:
    

    
"An intermediate node may receive DAO messages from multiple =
children
nodes
    
that advertise reachability to a given Destination Address. Where =
the total
    
number of set Path Control bits is greater than the number of DAO =
Parents
the
    
bitmaps for the DAO messages will be merged. This merging of set =
bits will
    
allow for subsequent fan out at subsequent ancestor =
nodes."
    

    
This is, if I receive DAOs with [00000110] and [00000001] from two =
of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that =
mean that,
every time I receive a DAO, I buffer it for some time in case I can =
merge it
with a later one? If yes, how do I choose the duration to wait? If I =
decide to
retransmit DAO's ASAP, and never merge them, what are the implications? =
As you
may understand, I'm not a very big fan of the idea of "buffering =
for some
time"...
    


    [RA] The note was written from the perspective of a =
network with
all storing nodes. For storing nodes, DAO advertisements and made and =
updated
based on the validity period of the received Destination Address routing =
updates.
It that context the issue of buffering is well defined. There is however =
an
issue of dealing with the sequence of DAO advertisements that will be =
received at
different intervals that may require subsequent change in the selected =
DAO
Parent. To maintain the requirement that the preferred path can always =
be
determined, there may be periods during which fewer DAO Parents are =
selected
than may be otherwise available at a given intermediate node (future =
consideration
required).
    


     
    


    [RA] For non storing nodes, based on my understanding of =
the
currently discussed proposal, the situation is simpler in that the =
originating
owner of the Destination Address establishes the preference and includes =
the applicable
Path Control setting with the different DAO Parents selected. Each node =
selects
its DAO Parents and indicates the preference of each. Each node’s =
information
needs only to be available at the root which then computes all downward =
paths. The
onus for scalability in processing the downward path routing is placed =
on the
root node – with processing requirements increasing with the =
number of
DAO Parents. However, all the information is available for global =
determination
of preferred, as well as secondary downward paths. =

    



    

    
I have taken a few minutes to verify that during fan-out, you should
control the parent selection (http://w=
ww.eecs.berkeley.edu/~watteyne/disjointness.pdf).
It tells you that, if two DAOs copies are sent towards the LBR, and each =
node
en-route can select its DAO parent randomly, the two obtained routes =
will not
be disjoint. That is, if one path fails, changes are the second will =
also as
they share many links.
    


    [RA] Thanks. This is an interesting result, caveats =
notwithstanding.
I would like to digest a bit further and get back to you. The benefit of =
multiple
DAO Parents is predicated on the downward diversity that it provides. =
The cost of
multiple DAO Parents and fan out is that it can negate some of =
RPL’s
routing scalability benefits (for storing nodes). If as the results =
suggest multiple
DAO Parents does not provide a meaningful path availability gain then =
its
utility is somewhat diminished. 
    



    

    
3) Similar to Fig.5, consider fan-out and convergence causes the LBR =
to
receive two routes [00000001] and [00000110]. Which one will is prefer? =
Sure,
[00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?
    


    [RA] Yes, diversity information may be derived from the =
path
Control and can be used as a selection criteria when making a choice of
downward path. That would be an implementation choice. =

    



    

    
Similarly, what happens if the LBR has only one link to the rest of =
the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell =
me.
    


    [RA] If that were the case the LBR would indeed receive =
one
packet with [11111111].  However the collective path information =
would be
available to the single node that connects to the LBR. That node, and =
all other
intermediate (storing) nodes, use the available path control information =
to
support downward path selection. In the case of non-storing nodes the =
root
would calculate the downward paths that would diverge not from the root =
but a
node(s) further down the tree.
    



    

    
Thomas
    

    
On 4/27/2010 2:11 PM, Roger Alexander wrote: 
    


    Hi Pascal,
     
    Please =
find attached an expanded note on the DAO fan out control and =
path
    prioritization =
mechanism.
     
    Roger
     
      
    


    -----Original =
Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Monday, April 19, 2010 11:35 =
AM
    To: Roger Alexander; Navneet Agarwal (navagar); =
JP Vasseur;
    wintert@acm.org
    =
Cc: ROLL WG
    Subject: RE: [Roll] DAO fan =
out
     
    Hi =
Roger:
     
    At high level =
I'm very positive on the mechanism =
.
     
    What I'd wish to see =
from the list is more people:
    - agreeing that the =
fan out MUST be solved
        =

    


    For large scale networks it is important to have some mechanism to =
bound
    downward paths once nodes can maintain =
multiple DAO parents. It will be up
    to the WG of =
course but after having introduced multiple DAO =
parents,
    leaving paths unconstrained introduces a =
potentially uncontrolled element of
    the protocol =
that can affect scalability; as networks become larger =
the
    potential vulnerability increases. What is =
being recommended is a 1-byte
    information element =
per DAO Destination Address. While incurring =
some
    additional overhead path control can be =
disabled (bitmap set to all zeros)
    for networks in =
which only a single DAO parent per node is maintained =
or
    that not wish to implement constraints on path =
fan out or to differentiate
    preferred downward =
paths.
     
      =

    


    - that =
this is a simple and efficient =
solution
        =

    


    Yes it would be good to get feedback from others on any concerns =
they =
may
    have.
     
      
    


    - that =
the solution can be incorporated in =
08
     
    Maybe what would =
help from you Roger is:
    - a visual example on the =
mechanism as work (if you have a pdf
    illustrating =
it?)
        =

    


    Note plus a few examples attached (pdf and MS =
Word).
     
      =

    


    - some =
more explanation on the source route case (how the root can =
play
    the same game recursively and obtain a good =
result as well)
        =

    


    Based on the current -07 source route specification, non-storing =
nodes will
    follow the same operation as storing =
nodes in using the Path Control byte to
    determine =
the number and selection of DAO parents through which the =
reverse
    route stack is built. =

     
    If the source route =
specification is changed to the more recent =
proposal
    from Richard, the Path Control byte can =
still apply to the advertised DAO
    Destination =
Address and will be associated with each of the selected =
DAO
    Parents communicated to the root. As in the =
case of storing nodes, each DAO
    Destination Address =
will have a different Path Control byte for =
each
    selected DAO Parent. For the source route case =
the root will be able to use
    the Path Control =
preference associated with each selected DAO Parent =
to
    recursively determine the preferred downward =
path to a given target address.
    That is, at the =
root, the preferred downward path to a given target =
address
    begins with the target's preferred DAO =
parent as given by the Path Control
    byte. From that =
preferred DAO Parent the link to the next preferred =
DAO
    ancestor is added until the complete preferred =
path is derived. The root
    will also be capable of =
deriving all the potential path combinations to =
a
    target node. =

     
    As I currently =
understand the new proposal it is not clear that non =
storing
    nodes have any ability to control path fan =
out (and the consequently
    increased reverse route =
processing at the root) when nodes maintain =
multiple
    DAO =
Parents.
       =

      
    


    Could =
you please so that for =
us?
     
    Thanks a =
bunch,
     
    Pascal=

     
     
     =
   
    


    -----Original =
Message-----
    From: Roger Alexander [mailto:roger.alexander@eka=
systems.com]
    Sent: Friday, April 16, 2010 11:32 =
PM
    To: Pascal Thubert (pthubert); Navneet Agarwal =
(navagar); 'JP
          =

    


    Vasseur';
        
    


    wintert@acm.org
    =
Cc: 'ROLL WG'
    Subject: RE: [Roll] DAO fan out =
(was:] IPSO Interop event - =
Feed-back
    welcome)
     <=
/o:p>
    Below is a quick summary aligned to Tim's concept of how =
the Path
          =

    


    Control
        
    


    bitmap =
associated with the DAO destination address can be used =
to
          =

    


    limit fan
        
    


    out and =
to identify the preferred path when nodes maintain =
multiple
          =

    


    DAO
        
    


    Parents.
     
    Further details and examples can be =
provided as part of an larger
    application domain =
note.
     
    Roger
     
          =

    


    -----Original =
Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Tuesday, April 13, 2010 3:47 =
AM
    To: Roger Alexander; Navneet Agarwal (navagar); =
JP Vasseur;
    wintert@acm.org
    =
Cc: ROLL WG
    Subject: DAO fan out (was:] IPSO =
Interop event - Feed-back =
welcome)
     
     
     
    Pascal
     
            =

    


    One =
consequence of maintaining multiple DAO parents is =
the
            =
  
    


    


    


    potential
        
    


    


    fan
    <=
pre>        
    


    out of =
routing paths. With path fan out a node may have =
multiple
           &=
nbsp;  
    


    downward
          &n=
bsp; 
    


    next hop =
addresses for a given target destination =
address.
         =
     
    






    Without
        
    


    


    some
    =

            
    


    path =
preference indication there is no information available if =
a
            &n=
bsp; 
    


    storing =
node
            =

    


    (including the root) =
wishes to limit the number of downward =
next
            =
;  
    


    


    


    hops
        
    


    


    


    maintained for a =
given address. It is thus desirable to have =
some
            =
;  
    


    means =
of
            =

    


    path =
control to limit fan out as well as a preference =
indication
           =
;   
    


    


    


    that
        
    


    


    can work =
in
            =

    


    conjunction with the =
hop-by-hop DAO =
exchanges.
     
    See the =
Figure below for an example in which nodes maintain =
two
            =
  
    


    


    


    DAO
        
    


    


    


    Parents =
each, where in the worst case the fan out that =
occurs
           &nb=
sp;  
    


    


    


    after
        
    


    


    three
            
    


    hops =
results in eight next hop downward paths from the DODAG =
root
            =
;  
    


    (LBR)
           =
; 
    


    to a =
target node (41). Even with the hop-by-hop DAO mechanism =
it
            &=
nbsp; 
    


    would
    be
       =
;     
    


    desirable to be able =
to limit fan out as well as to identify =
path
            =
;  
    


    preference =
and
            =

    


    diversity at the =
root or other intermediate storing =
node.
     
       =
            &=
nbsp;    =
(------------LBR------------)
       &nbs=
p;            =
;    /    /   / =
|     | \    \   =
\
            &n=
bsp;          =
/    /   /  |     =
|  \    \   =
\
            &n=
bsp;         /    =
/   /   |     |   =
\    \   =
\
            &n=
bsp;        /    =
/   /    |     |  =
  \    \   =
\
            &n=
bsp;     (11) (12) (13) (14)   (15) (16) =
(17) =
(18)
            =
;         \   =
|    |    /     =
\    |    |   =
/
            &n=
bsp;         \  =
|    |   /       =
\   |    |  =
/
            &n=
bsp;          \ =
|    |  =
/         \  =
|    | =
/
            &n=
bsp;         (21)   =
(22)  =
         (23)  =
(24)
            =
;            =
  \    =
|            =
|    =
/
            &n=
bsp;           &nb=
sp;  \   =
|            =
|   =
/
            &n=
bsp;           &nb=
sp;   \  =
|            =
|  =
/
            &n=
bsp;           &nb=
sp;    =
(31)          =
(32)
            =
;            =
         =
\        =
/
            &n=
bsp;     =
            &=
nbsp;   \      =
/
            &n=
bsp;           &nb=
sp;          =
\    =
/
            &n=
bsp;           &nb=
sp;           =
(41)
     
       &=
nbsp;      
    


    [Pascal] Your schema illustrates clearly that even if we fan out =
a
            =

    


    


    lot,
        
    


    


    it does =
not mean that a router on the way down will have =
more
            =

    


    


    feasible
        
    


    


    successors.
     
    That's one thing that's =
important to remember, the properties =
of
            =

    


    


    the
        
    


    


    DAG
    <=
pre>are not symmetrical, so even if we build it to get =
multiple
            =

    


    


    feasible
        
    


    


    successors on the =
way up, that does not mean that on the =
reverse
            =

    


    


    DAG
    to
        =

    


    


    a target =
there are multiple successors at each hop towards =
that
            =

    


    


    target.
        
    


    


    In other =
words, the ROI of fanning out is not guaranteed if we =
do
          =
  
    


    


    it
        
    


    


    blindly.
     
          =
  
    


    A simple =
path control bitmap associated with the =
advertised
           =
;   
    


    Destination
          =
;  
    


    Address =
can be included within the DAO to address the issue =
of
            &=
nbsp; 
    


    


    


    path
        
    


    


    


    preference as well =
as control of fan out. For a network =
of
            &=
nbsp; 
    


    'non-storing'
         &nb=
sp;  
    


    nodes =
the preference indication would be processed only at =
the
            =
  
    


    


    


    root.
        
    


    


    [Pascal] =
so far so good, but that will give you a blind =
mechanism.
     
      &=
nbsp;     
    


    With the =
path control byte associated with each DAO =
destination
          &nbs=
p;   
    


    address, =
a
            =

    


    node =
will be able to specify preference among DAO parent =
paths
           &nbs=
p;  
    


    


    


    and
        
    


    


    can
    <=
pre>        


    convey =
limits on the number of downward paths. This is =
an
           =
   
    


    


    


    opportunity
        =

    


    


    for
    <=
pre>        


    nodes to =
further influence the downward paths that =
are
            =
  
    


    


    


    established
        =

    


    


    and
    <=
pre>        


    maintained. =
Consistent with the DV-based RPL operation this =
DAO
            =
  
    


    


    


    path
        
    


    


    


    control =
mechanism must operate hop-by-hop avoiding =
any
            =
  
    


    


    


    requirement
        =

    


    


    for
    <=
pre>        


    end-to-end path =
coordination. To avoid overloading this =
email
           &nbs=
p;  
    


    


    


    thread
        
    


    


    I
    will
            =

    


    initiate =
a separate discussion on how a path control element =
may
            =
  
    


    


    


    be
        
    


    


    included
            
    


    within =
the =
DAO.
     
       &=
nbsp;      
    


    [Pascal] Too late, I just did =
:)
     
    And if I remember, =
Tim's idea was to control the stretch of =
the
            =

    


    


    fanout,
        
    


    


    by =
decrementing a counter as the path loses preference =
point.
    At the moment, we have a parent preference =
0-lowest to 3 =
highest.
            =

    


    


    So
    it
        =

    


    


    is easy =
to decrement a counter by (3-pref) and not fan out when =
the
    counter reaches 0.
    Tim, =
could you elaborate on =
this?
            =

    


    A Path Control bit map will achieve an equivalent control =
mechanism
    whereby
    at each node =
the number of bits that are set will determine =
the
          =

    


    extent
    to
      &nbs=
p; 
    


    which =
the associated DAO Destination Address can be advertised =
to
          =

    


    multiple
        
    


    DAO =
Parents. If a DAO message destination address Path Control =
bitmap
          =

    


    has
        
    


    4
    set bits, that address can be send along a maximum of 4 paths. =
For
          =

    


    example,
        
    


    at the =
originating node the DAO can be sent to two DAO Parents =
where
          =

    


    the
        
    


    Path =
Control bit map in the message sent to each DAO Parent will =
have
          =

    


    two
        
    


    set =
bits. If each parent then advertises to two DAO Parents a =
single
          =

    


    bit is
        
    


    set for =
each DAO message. Eventually with a single bit set in =
the
          =

    


    Path
        
    


    Control =
bit map, the DAO message can be advertised only to a =
single
          =

    


    DAO
        
    


    Parent. =
This mechanism achieves the effect of limiting the stretch =
of
          =

    


    the
        
    


    path fan =
out. Where multiple DAO messages are received at a =
common
    ancestor
    the number of =
set bits in the respective Path Control fields =
are
          =

    


    recombined
       =
 
    


    allowing =
for renewed advertising of the DAO message =
destination
          =

    


    address to
        =

    


    multiple =
DAO Parents along the =
path.
     
    As the set Path =
Control bits are split and recombined as the =
DAO
          =

    


    messages
        
    


    are =
transferred to the root, their bit positions are maintained. =
This
          =

    


    allows
        
    


    bit =
positions to be ordered from low to high in terms of =
path
          =

    


    preference.
        =

    


    Therefore when a DAO =
message is received in which the Path =
Control
          =

    


    bitmap
        
    


    has the =
highest preference bit set, that DAO message =
destination
          =

    


    address is
        =

    


    always =
advertised to the preferred DAO Parent. Similarly, when =
a
          =

    


    message is
        =

    


    received =
with multiple Path Control bits set, the DAO messages can =
be
    distributed to DAO Parents according to parent =
preference. This =
will
          =

    


    ensure
        
    


    that at =
any common ancestor, including the root, a node is =
always
          =

    


    able
    to
       =
 
    


    distinguish the =
preferred downward path. The ability to determine =
the
    preferred downward path as well as to obtain an =
indication of path
          =

    


    diversity
        
    


    will =
allow the Path Control field to be used when =
resource
          =

    


    limitations
    at =
a
        
    


    node =
require a truncation of the number of downward paths that =
the
          =

    


    node
        
    


    maintain =
for a given destination =
address.
     
      &nb=
sp;   
    


    Pascal
            =

    


    


    > 
     
    ________=
_______________________________________
    Roll =
mailing list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
    


     
    


    


    





------=_NextPart_000_02DD_01CAE7A1.791216E0--


From watteyne@eecs.berkeley.edu  Thu Apr 29 11:26:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F408A3A6B20 for ; Thu, 29 Apr 2010 11:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si6Mbij4PXvX for ; Thu, 29 Apr 2010 11:26:01 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 87EE228C268 for ; Thu, 29 Apr 2010 11:25:52 -0700 (PDT)
Received: from [128.32.45.155] (dhcp-45-155.EECS.Berkeley.EDU [128.32.45.155]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o3TIPaDG020133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 29 Apr 2010 11:25:38 -0700 (PDT)
Message-ID: <4BD9CF1E.20708@eecs.berkeley.edu>
Date: Thu, 29 Apr 2010 11:25:34 -0700
From: Thomas Watteyne 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <4BD8E89C.9020809@eecs.berkeley.edu> <02dc01cae7c3$0023b6e0$006b24a0$%alexander@ekasystems.com>
In-Reply-To: <02dc01cae7c3$0023b6e0$006b24a0$%alexander@ekasystems.com>
Content-Type: multipart/alternative; boundary="------------080607010108070405080209"
Subject: Re: [Roll] Fwd: Re:  DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 18:26:14 -0000

This is a multi-part message in MIME format.
--------------080607010108070405080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Roger,
Thanks for the clear answers. I'm eager to see what people on the list 
think.
Thomas

On 4/29/2010 10:40 AM, Roger Alexander wrote:
>
> Hi Thomas,
>
> Thanks for the feedback and the simulation results.
>
> *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On 
> Behalf Of *Thomas Watteyne
> *Sent:* Wednesday, April 28, 2010 10:02 PM
> *To:* roll@ietf.org
> *Subject:* [Roll] Fwd: Re: DAO fan out
>
> Roger,
>
> Having a single byte for fan-out control and prioritization of 
> downstream paths is elegant. It reminds me of the (academic) GRAdient 
> Broadcast protocol. I have a couple of questions, though.
>
> 1) Is this a technique you (or others on the list) have experience 
> with? If it's a proven technique, I'm glad to learn about it, and the 
> WG will have more confidence adopting it.
>
> [RA] No this is not a proven or deployed technique. The proposal is 
> based on a concern that arises from our deployed networks where single 
> root nodes do support a network of thousands of nodes. Once multiple 
> DAO parents are entertained for downward routing availability, routing 
> scalability can be affected if DAO exchanges are left  unbounded. 
> Furthermore, there will need to be a means of extracting the preferred 
> downward path and selecting from the many alternatives that can result.
>
>
>
> 2) I have some questions related to path convergence, which relates to 
> the following paragraph in your text:
>
> "An intermediate node may receive DAO messages from multiple children 
> nodes
> that advertise reachability to a given Destination Address. Where the 
> total
> number of set Path Control bits is greater than the number of DAO 
> Parents the
> bitmaps for the DAO messages will be merged. This merging of set bits will
> allow for subsequent fan out at subsequent ancestor nodes."
>
> This is, if I receive DAOs with [00000110] and [00000001] from two of 
> my children, I have [00000111] to play with, which I can redistribute 
> (or re-"fan out" if you want) across my DAO Parents. Does that mean 
> that, every time I receive a DAO, I buffer it for some time in case I 
> can merge it with a later one? If yes, how do I choose the duration to 
> wait? If I decide to retransmit DAO's ASAP, and never merge them, what 
> are the implications? As you may understand, I'm not a very big fan of 
> the idea of "buffering for some time"...
>
> [RA] The note was written from the perspective of a network with all 
> storing nodes. For storing nodes, DAO advertisements and made and 
> updated based on the validity period of the received Destination 
> Address routing updates. It that context the issue of buffering is 
> well defined. There is however an issue of dealing with the sequence 
> of DAO advertisements that will be received at different intervals 
> that may require subsequent change in the selected DAO Parent. To 
> maintain the requirement that the preferred path can always be 
> determined, there may be periods during which fewer DAO Parents are 
> selected than may be otherwise available at a given intermediate node 
> (future consideration required).
>
> [RA] For non storing nodes, based on my understanding of the currently 
> discussed proposal, the situation is simpler in that the originating 
> owner of the Destination Address establishes the preference and 
> includes the applicable Path Control setting with the different DAO 
> Parents selected. Each node selects its DAO Parents and indicates the 
> preference of each. Each node's information needs only to be available 
> at the root which then computes all downward paths. The onus for 
> scalability in processing the downward path routing is placed on the 
> root node -- with processing requirements increasing with the number 
> of DAO Parents. However, all the information is available for global 
> determination of preferred, as well as secondary downward paths.
>
>
>
> I have taken a few minutes to verify that during fan-out, you should 
> control the parent selection 
> (http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf 
> ). It tells 
> you that, if two DAOs copies are sent towards the LBR, and each node 
> en-route can select its DAO parent randomly, the two obtained routes 
> will not be disjoint. That is, if one path fails, changes are the 
> second will also as they share many links.
>
> [RA] Thanks. This is an interesting result, caveats notwithstanding. I 
> would like to digest a bit further and get back to you. The benefit of 
> multiple DAO Parents is predicated on the downward diversity that it 
> provides. The cost of multiple DAO Parents and fan out is that it can 
> negate some of RPL's routing scalability benefits (for storing nodes). 
> If as the results suggest multiple DAO Parents does not provide a 
> meaningful path availability gain then its utility is somewhat 
> diminished.
>
>
>
> 3) Similar to Fig.5, consider fan-out and convergence causes the LBR 
> to receive two routes [00000001] and [00000110]. Which one will is 
> prefer? Sure, [00000001] has traveled through all the best DAO 
> parents, but wouldn't [00000110] offer me path diversity?
>
> [RA] Yes, diversity information may be derived from the path Control 
> and can be used as a selection criteria when making a choice of 
> downward path. That would be an implementation choice.
>
>
>
> Similarly, what happens if the LBR has only one link to the rest of 
> the network? If I read you text correctly, it will receive one packet 
> with [111111111]. If I am missing something, please do tell me.
>
> [RA] If that were the case the LBR would indeed receive one packet 
> with [11111111].  However the collective path information would be 
> available to the single node that connects to the LBR. That node, and 
> all other intermediate (storing) nodes, use the available path control 
> information to support downward path selection. In the case of 
> non-storing nodes the root would calculate the downward paths that 
> would diverge not from the root but a node(s) further down the tree.
>
>
>
> Thomas
>
> On 4/27/2010 2:11 PM, Roger Alexander wrote:
>
> Hi Pascal,
>   
> Please find attached an expanded note on the DAO fan out control and path
> prioritization mechanism.
>   
> Roger
>   
>    
>
>     -----Original Message-----
>
>     From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>
>     Sent: Monday, April 19, 2010 11:35 AM
>
>     To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
>
>     wintert@acm.org  
>
>     Cc: ROLL WG
>
>     Subject: RE: [Roll] DAO fan out
>
>       
>
>     Hi Roger:
>
>       
>
>     At high level I'm very positive on the mechanism .
>
>       
>
>     What I'd wish to see from the list is more people:
>
>     - agreeing that the fan out MUST be solved
>
>          
>
> For large scale networks it is important to have some mechanism to bound
> downward paths once nodes can maintain multiple DAO parents. It will be up
> to the WG of course but after having introduced multiple DAO parents,
> leaving paths unconstrained introduces a potentially uncontrolled element of
> the protocol that can affect scalability; as networks become larger the
> potential vulnerability increases. What is being recommended is a 1-byte
> information element per DAO Destination Address. While incurring some
> additional overhead path control can be disabled (bitmap set to all zeros)
> for networks in which only a single DAO parent per node is maintained or
> that not wish to implement constraints on path fan out or to differentiate
> preferred downward paths.
>   
>    
>
>     - that this is a simple and efficient solution
>
>          
>
> Yes it would be good to get feedback from others on any concerns they may
> have.
>   
>    
>
>     - that the solution can be incorporated in 08
>
>       
>
>     Maybe what would help from you Roger is:
>
>     - a visual example on the mechanism as work (if you have a pdf
>
>     illustrating it?)
>
>          
>
> Note plus a few examples attached (pdf and MS Word).
>   
>    
>
>     - some more explanation on the source route case (how the root can play
>
>     the same game recursively and obtain a good result as well)
>
>          
>
> Based on the current -07 source route specification, non-storing nodes will
> follow the same operation as storing nodes in using the Path Control byte to
> determine the number and selection of DAO parents through which the reverse
> route stack is built.
>   
> If the source route specification is changed to the more recent proposal
> from Richard, the Path Control byte can still apply to the advertised DAO
> Destination Address and will be associated with each of the selected DAO
> Parents communicated to the root. As in the case of storing nodes, each DAO
> Destination Address will have a different Path Control byte for each
> selected DAO Parent. For the source route case the root will be able to use
> the Path Control preference associated with each selected DAO Parent to
> recursively determine the preferred downward path to a given target address.
> That is, at the root, the preferred downward path to a given target address
> begins with the target's preferred DAO parent as given by the Path Control
> byte. From that preferred DAO Parent the link to the next preferred DAO
> ancestor is added until the complete preferred path is derived. The root
> will also be capable of deriving all the potential path combinations to a
> target node.
>   
> As I currently understand the new proposal it is not clear that non storing
> nodes have any ability to control path fan out (and the consequently
> increased reverse route processing at the root) when nodes maintain multiple
> DAO Parents.
>     
>    
>
>     Could you please so that for us?
>
>       
>
>     Thanks a bunch,
>
>       
>
>     Pascal
>
>       
>
>       
>
>          
>
>         -----Original Message-----
>
>         From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
>
>         Sent: Friday, April 16, 2010 11:32 PM
>
>         To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
>
>                
>
>     Vasseur';
>
>          
>
>         wintert@acm.org  
>
>         Cc: 'ROLL WG'
>
>         Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
>
>         welcome)
>
>           
>
>         Below is a quick summary aligned to Tim's concept of how the Path
>
>                
>
>     Control
>
>          
>
>         bitmap associated with the DAO destination address can be used to
>
>                
>
>     limit fan
>
>          
>
>         out and to identify the preferred path when nodes maintain multiple
>
>                
>
>     DAO
>
>          
>
>         Parents.
>
>           
>
>         Further details and examples can be provided as part of an larger
>
>         application domain note.
>
>           
>
>         Roger
>
>           
>
>                
>
>             -----Original Message-----
>
>             From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>
>             Sent: Tuesday, April 13, 2010 3:47 AM
>
>             To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
>
>             wintert@acm.org  
>
>             Cc: ROLL WG
>
>             Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
>
>               
>
>               
>
>               
>
>             Pascal
>
>               
>
>                      
>
>                 One consequence of maintaining multiple DAO parents is the
>
>                            
>
>     potential
>
>          
>
>             fan
>
>                      
>
>                 out of routing paths. With path fan out a node may have multiple
>
>                            
>
>             downward
>
>                      
>
>                 next hop addresses for a given target destination address.
>
>                            
>
>     Without
>
>          
>
>             some
>
>                      
>
>                 path preference indication there is no information available if a
>
>                            
>
>             storing node
>
>                      
>
>                 (including the root) wishes to limit the number of downward next
>
>                            
>
>     hops
>
>          
>
>                 maintained for a given address. It is thus desirable to have some
>
>                            
>
>             means of
>
>                      
>
>                 path control to limit fan out as well as a preference indication
>
>                            
>
>     that
>
>          
>
>             can work in
>
>                      
>
>                 conjunction with the hop-by-hop DAO exchanges.
>
>                   
>
>                 See the Figure below for an example in which nodes maintain two
>
>                            
>
>     DAO
>
>          
>
>                 Parents each, where in the worst case the fan out that occurs
>
>                            
>
>     after
>
>          
>
>             three
>
>                      
>
>                 hops results in eight next hop downward paths from the DODAG root
>
>                            
>
>             (LBR)
>
>                      
>
>                 to a target node (41). Even with the hop-by-hop DAO mechanism it
>
>                            
>
>             would
>
>             be
>
>                      
>
>                 desirable to be able to limit fan out as well as to identify path
>
>                            
>
>             preference and
>
>                      
>
>                 diversity at the root or other intermediate storing node.
>
>                   
>
>                                      (------------LBR------------)
>
>                                      /    /   / |     | \    \   \
>
>                                     /    /   /  |     |  \    \   \
>
>                                    /    /   /   |     |   \    \   \
>
>                                   /    /   /    |     |    \    \   \
>
>                                (11) (12) (13) (14)   (15) (16) (17) (18)
>
>                                   \   |    |    /     \    |    |   /
>
>                                    \  |    |   /       \   |    |  /
>
>                                     \ |    |  /         \  |    | /
>
>                                    (21)   (22)           (23)  (24)
>
>                                        \    |            |    /
>
>                                         \   |            |   /
>
>                                          \  |            |  /
>
>                                           (31)          (32)
>
>                                               \        /
>
>                                                \      /
>
>                                                 \    /
>
>                                                  (41)
>
>                   
>
>                            
>
>             [Pascal] Your schema illustrates clearly that even if we fan out a
>
>                      
>
>     lot,
>
>          
>
>             it does not mean that a router on the way down will have more
>
>                      
>
>     feasible
>
>          
>
>             successors.
>
>               
>
>             That's one thing that's important to remember, the properties of
>
>                      
>
>     the
>
>          
>
>             DAG
>
>             are not symmetrical, so even if we build it to get multiple
>
>                      
>
>     feasible
>
>          
>
>             successors on the way up, that does not mean that on the reverse
>
>                      
>
>     DAG
>
>     to
>
>          
>
>             a target there are multiple successors at each hop towards that
>
>                      
>
>     target.
>
>          
>
>             In other words, the ROI of fanning out is not guaranteed if we do
>
>                      
>
>     it
>
>          
>
>             blindly.
>
>               
>
>                      
>
>                 A simple path control bitmap associated with the advertised
>
>                            
>
>             Destination
>
>                      
>
>                 Address can be included within the DAO to address the issue of
>
>                            
>
>     path
>
>          
>
>                 preference as well as control of fan out. For a network of
>
>                            
>
>             'non-storing'
>
>                      
>
>                 nodes the preference indication would be processed only at the
>
>                            
>
>     root.
>
>          
>
>             [Pascal] so far so good, but that will give you a blind mechanism.
>
>               
>
>                      
>
>                 With the path control byte associated with each DAO destination
>
>                            
>
>             address, a
>
>                      
>
>                 node will be able to specify preference among DAO parent paths
>
>                            
>
>     and
>
>          
>
>             can
>
>                      
>
>                 convey limits on the number of downward paths. This is an
>
>                            
>
>     opportunity
>
>          
>
>             for
>
>                      
>
>                 nodes to further influence the downward paths that are
>
>                            
>
>     established
>
>          
>
>             and
>
>                      
>
>                 maintained. Consistent with the DV-based RPL operation this DAO
>
>                            
>
>     path
>
>          
>
>                 control mechanism must operate hop-by-hop avoiding any
>
>                            
>
>     requirement
>
>          
>
>             for
>
>                      
>
>                 end-to-end path coordination. To avoid overloading this email
>
>                            
>
>     thread
>
>          
>
>             I
>
>             will
>
>                      
>
>                 initiate a separate discussion on how a path control element may
>
>                            
>
>     be
>
>          
>
>             included
>
>                      
>
>                 within the DAO.
>
>                   
>
>                            
>
>             [Pascal] Too late, I just did :)
>
>               
>
>             And if I remember, Tim's idea was to control the stretch of the
>
>                      
>
>     fanout,
>
>          
>
>             by decrementing a counter as the path loses preference point.
>
>             At the moment, we have a parent preference 0-lowest to 3 highest.
>
>                      
>
>     So
>
>     it
>
>          
>
>             is easy to decrement a counter by (3-pref) and not fan out when the
>
>             counter reaches 0.
>
>             Tim, could you elaborate on this?
>
>                      
>
>         A Path Control bit map will achieve an equivalent control mechanism
>
>         whereby
>
>         at each node the number of bits that are set will determine the
>
>                
>
>     extent
>
>     to
>
>          
>
>         which the associated DAO Destination Address can be advertised to
>
>                
>
>     multiple
>
>          
>
>         DAO Parents. If a DAO message destination address Path Control bitmap
>
>                
>
>     has
>
>          
>
>         4
>
>         set bits, that address can be send along a maximum of 4 paths. For
>
>                
>
>     example,
>
>          
>
>         at the originating node the DAO can be sent to two DAO Parents where
>
>                
>
>     the
>
>          
>
>         Path Control bit map in the message sent to each DAO Parent will have
>
>                
>
>     two
>
>          
>
>         set bits. If each parent then advertises to two DAO Parents a single
>
>                
>
>     bit is
>
>          
>
>         set for each DAO message. Eventually with a single bit set in the
>
>                
>
>     Path
>
>          
>
>         Control bit map, the DAO message can be advertised only to a single
>
>                
>
>     DAO
>
>          
>
>         Parent. This mechanism achieves the effect of limiting the stretch of
>
>                
>
>     the
>
>          
>
>         path fan out. Where multiple DAO messages are received at a common
>
>         ancestor
>
>         the number of set bits in the respective Path Control fields are
>
>                
>
>     recombined
>
>          
>
>         allowing for renewed advertising of the DAO message destination
>
>                
>
>     address to
>
>          
>
>         multiple DAO Parents along the path.
>
>           
>
>         As the set Path Control bits are split and recombined as the DAO
>
>                
>
>     messages
>
>          
>
>         are transferred to the root, their bit positions are maintained. This
>
>                
>
>     allows
>
>          
>
>         bit positions to be ordered from low to high in terms of path
>
>                
>
>     preference.
>
>          
>
>         Therefore when a DAO message is received in which the Path Control
>
>                
>
>     bitmap
>
>          
>
>         has the highest preference bit set, that DAO message destination
>
>                
>
>     address is
>
>          
>
>         always advertised to the preferred DAO Parent. Similarly, when a
>
>                
>
>     message is
>
>          
>
>         received with multiple Path Control bits set, the DAO messages can be
>
>         distributed to DAO Parents according to parent preference. This will
>
>                
>
>     ensure
>
>          
>
>         that at any common ancestor, including the root, a node is always
>
>                
>
>     able
>
>     to
>
>          
>
>         distinguish the preferred downward path. The ability to determine the
>
>         preferred downward path as well as to obtain an indication of path
>
>                
>
>     diversity
>
>          
>
>         will allow the Path Control field to be used when resource
>
>                
>
>     limitations
>
>     at a
>
>          
>
>         node require a truncation of the number of downward paths that the
>
>                
>
>     node
>
>          
>
>         maintain for a given destination address.
>
>           
>
>                
>
>             Pascal
>
>                      
>
>     >  
>
>       
>
>     _______________________________________________
>
>     Roll mailing list
>
>     Roll@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/roll
>


--------------080607010108070405080209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Roger,
    
Thanks for the clear answers. I'm eager to see what people on the list
think.
    
Thomas
    

    
On 4/29/2010 10:40 AM, Roger Alexander wrote:

    
  
  
  

  
    
  
    Hi
Thomas,
    
  
     
    
  
    Thanks
for the feedback and the simulation results.
    
  
     
    
  
    
  
    
  
    
  
    From:
roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Thomas Watteyne
    
  Sent: Wednesday, April 28, 2010 10:02 PM
    
  To: roll@ietf.org
    
  Subject: [Roll] Fwd: Re: DAO fan out
    
  
    
  
    
  
     
    
  
    Roger,
    
  
    
  Having a single byte for fan-out control and prioritization of
downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast
protocol.
I have a couple of questions, though.
    
  
    
  1) Is this a technique you (or others on the list) have
experience with? If
it's a proven technique, I'm glad to learn about it, and the WG will
have more
confidence adopting it.
    
  
    [RA]
No this is not a proven or deployed technique. The proposal
is based on a concern that arises from our deployed networks where
single root
nodes do support a network of thousands of nodes. Once multiple DAO
parents are
entertained for downward routing availability, routing scalability can
be
affected if DAO exchanges are left  unbounded. Furthermore, there will
need
to be a means of extracting the preferred downward path and selecting
from the
many alternatives that can result.
    
  

    
  
    
  2) I have some questions related to path convergence, which
relates to the
following paragraph in your text:
    
  
    
  "An intermediate node may receive DAO messages from multiple
children
nodes
    
  that advertise reachability to a given Destination Address. Where
the total
    
  number of set Path Control bits is greater than the number of DAO
Parents
the
    
  bitmaps for the DAO messages will be merged. This merging of set
bits will
    
  allow for subsequent fan out at subsequent ancestor nodes."
    
  
    
  This is, if I receive DAOs with [00000110] and [00000001] from
two of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that mean that,
every time I receive a DAO, I buffer it for some time in case I can
merge it
with a later one? If yes, how do I choose the duration to wait? If I
decide to
retransmit DAO's ASAP, and never merge them, what are the implications?
As you
may understand, I'm not a very big fan of the idea of "buffering for
some
time"...
    
  
    [RA]
The note was written from the perspective of a network with
all storing nodes. For storing nodes, DAO advertisements and made and
updated
based on the validity period of the received Destination Address
routing updates.
It that context the issue of buffering is well defined. There is
however an
issue of dealing with the sequence of DAO advertisements that will be
received at
different intervals that may require subsequent change in the selected
DAO
Parent. To maintain the requirement that the preferred path can always
be
determined, there may be periods during which fewer DAO Parents are
selected
than may be otherwise available at a given intermediate node (future
consideration
required).
    
  
     
    
  
    [RA]
For non storing nodes, based on my understanding of the
currently discussed proposal, the situation is simpler in that the
originating
owner of the Destination Address establishes the preference and
includes the applicable
Path Control setting with the different DAO Parents selected. Each node
selects
its DAO Parents and indicates the preference of each. Each node’s
information
needs only to be available at the root which then computes all downward
paths. The
onus for scalability in processing the downward path routing is placed
on the
root node – with processing requirements increasing with the number of
DAO Parents. However, all the information is available for global
determination
of preferred, as well as secondary downward paths. 
    
  

    
  
    
  I have taken a few minutes to verify that during fan-out, you
should
control the parent selection (http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf).
It
tells you that, if two DAOs copies are sent towards the LBR, and each
node
en-route can select its DAO parent randomly, the two obtained routes
will not
be disjoint. That is, if one path fails, changes are the second will
also as
they share many links.
    
  
    [RA]
Thanks. This is an interesting result, caveats notwithstanding.
I would like to digest a bit further and get back to you. The benefit
of multiple
DAO Parents is predicated on the downward diversity that it provides.
The cost of
multiple DAO Parents and fan out is that it can negate some of RPL’s
routing scalability benefits (for storing nodes). If as the results
suggest multiple
DAO Parents does not provide a meaningful path availability gain then
its
utility is somewhat diminished. 
    
  

    
  
    
  3) Similar to Fig.5, consider fan-out and convergence causes the
LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer?
Sure,
[00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?
    
  
    [RA]
Yes, diversity information may be derived from the path
Control and can be used as a selection criteria when making a choice of
downward path. That would be an implementation choice. 
    
  

    
  
    
  Similarly, what happens if the LBR has only one link to the rest
of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.
    
  
    [RA]
If that were the case the LBR would indeed receive one
packet with [11111111].  However the collective path information would
be
available to the single node that connects to the LBR. That node, and
all other
intermediate (storing) nodes, use the available path control
information to
support downward path selection. In the case of non-storing nodes the
root
would calculate the downward paths that would diverge not from the root
but a
node(s) further down the tree.
    
  

    
  
    
  Thomas
    
  
    
On 4/27/2010 2:11 PM, Roger Alexander wrote: 
    
  
    Hi Pascal,
    
  
     
    
  
    Please find attached an expanded note on the DAO fan out control and path
    
  
    prioritization mechanism.
    
  
     
    
  
    Roger
    
  
     
    
  
      
    
  
    
    
    -----Original Message-----
    
    
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    
    
    Sent: Monday, April 19, 2010 11:35 AM
    
    
    To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
    
    
    wintert@acm.org
    
    
    Cc: ROLL WG
    
    
    Subject: RE: [Roll] DAO fan out
    
    
     
    
    
    Hi Roger:
    
    
     
    
    
    At high level I'm very positive on the mechanism .
    
    
     
    
    
    What I'd wish to see from the list is more people:
    
    
    - agreeing that the fan out MUST be solved
    
    
        
    
  
    
  
    For large scale networks it is important to have some mechanism to bound
    
  
    downward paths once nodes can maintain multiple DAO parents. It will be up
    
  
    to the WG of course but after having introduced multiple DAO parents,
    
  
    leaving paths unconstrained introduces a potentially uncontrolled element of
    
  
    the protocol that can affect scalability; as networks become larger the
    
  
    potential vulnerability increases. What is being recommended is a 1-byte
    
  
    information element per DAO Destination Address. While incurring some
    
  
    additional overhead path control can be disabled (bitmap set to all zeros)
    
  
    for networks in which only a single DAO parent per node is maintained or
    
  
    that not wish to implement constraints on path fan out or to differentiate
    
  
    preferred downward paths.
    
  
     
    
  
      
    
  
    
    
    - that this is a simple and efficient solution
    
    
        
    
  
    
  
    Yes it would be good to get feedback from others on any concerns they may
    
  
    have.
    
  
     
    
  
      
    
  
    
    
    - that the solution can be incorporated in 08
    
    
     
    
    
    Maybe what would help from you Roger is:
    
    
    - a visual example on the mechanism as work (if you have a pdf
    
    
    illustrating it?)
    
    
        
    
  
    
  
    Note plus a few examples attached (pdf and MS Word).
    
  
     
    
  
      
    
  
    
    
    - some more explanation on the source route case (how the root can play
    
    
    the same game recursively and obtain a good result as well)
    
    
        
    
  
    
  
    Based on the current -07 source route specification, non-storing nodes will
    
  
    follow the same operation as storing nodes in using the Path Control byte to
    
  
    determine the number and selection of DAO parents through which the reverse
    
  
    route stack is built. 
    
  
     
    
  
    If the source route specification is changed to the more recent proposal
    
  
    from Richard, the Path Control byte can still apply to the advertised DAO
    
  
    Destination Address and will be associated with each of the selected DAO
    
  
    Parents communicated to the root. As in the case of storing nodes, each DAO
    
  
    Destination Address will have a different Path Control byte for each
    
  
    selected DAO Parent. For the source route case the root will be able to use
    
  
    the Path Control preference associated with each selected DAO Parent to
    
  
    recursively determine the preferred downward path to a given target address.
    
  
    That is, at the root, the preferred downward path to a given target address
    
  
    begins with the target's preferred DAO parent as given by the Path Control
    
  
    byte. From that preferred DAO Parent the link to the next preferred DAO
    
  
    ancestor is added until the complete preferred path is derived. The root
    
  
    will also be capable of deriving all the potential path combinations to a
    
  
    target node. 
    
  
     
    
  
    As I currently understand the new proposal it is not clear that non storing
    
  
    nodes have any ability to control path fan out (and the consequently
    
  
    increased reverse route processing at the root) when nodes maintain multiple
    
  
    DAO Parents.
    
  
       
    
  
      
    
  
    
    
    Could you please so that for us?
    
    
     
    
    
    Thanks a bunch,
    
    
     
    
    
    Pascal
    
    
     
    
    
     
    
    
        
    
    
    
      
    -----Original Message-----
    
      
    From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
    
      
    Sent: Friday, April 16, 2010 11:32 PM
    
      
    To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
    
      
          
    
    
    
    
    Vasseur';
    
    
        
    
    
    
      
    wintert@acm.org
    
      
    Cc: 'ROLL WG'
    
      
    Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
    
      
    welcome)
    
      
     
    
      
    Below is a quick summary aligned to Tim's concept of how the Path
    
      
          
    
    
    
    
    Control
    
    
        
    
    
    
      
    bitmap associated with the DAO destination address can be used to
    
      
          
    
    
    
    
    limit fan
    
    
        
    
    
    
      
    out and to identify the preferred path when nodes maintain multiple
    
      
          
    
    
    
    
    DAO
    
    
        
    
    
    
      
    Parents.
    
      
     
    
      
    Further details and examples can be provided as part of an larger
    
      
    application domain note.
    
      
     
    
      
    Roger
    
      
     
    
      
          
    
      
    
        
    -----Original Message-----
    
        
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    
        
    Sent: Tuesday, April 13, 2010 3:47 AM
    
        
    To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
    
        
    wintert@acm.org
    
        
    Cc: ROLL WG
    
        
    Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
    
        
     
    
        
     
    
        
     
    
        
    Pascal
    
        
     
    
        
            
    
        
    
          
    One consequence of maintaining multiple DAO parents is the
    
          
              
    
        
    
      
    
    
    
    
    potential
    
    
        
    
    
    
      
    
        
    fan
    
        
            
    
        
    
          
    out of routing paths. With path fan out a node may have multiple
    
          
              
    
        
    
        
    downward
    
        
            
    
        
    
          
    next hop addresses for a given target destination address.
    
          
              
    
        
    
      
    
    
    
    
    Without
    
    
        
    
    
    
      
    
        
    some
    
        
            
    
        
    
          
    path preference indication there is no information available if a
    
          
              
    
        
    
        
    storing node
    
        
            
    
        
    
          
    (including the root) wishes to limit the number of downward next
    
          
              
    
        
    
      
    
    
    
    
    hops
    
    
        
    
    
    
      
    
        
    
          
    maintained for a given address. It is thus desirable to have some
    
          
              
    
        
    
        
    means of
    
        
            
    
        
    
          
    path control to limit fan out as well as a preference indication
    
          
              
    
        
    
      
    
    
    
    
    that
    
    
        
    
    
    
      
    
        
    can work in
    
        
            
    
        
    
          
    conjunction with the hop-by-hop DAO exchanges.
    
          
     
    
          
    See the Figure below for an example in which nodes maintain two
    
          
              
    
        
    
      
    
    
    
    
    DAO
    
    
        
    
    
    
      
    
        
    
          
    Parents each, where in the worst case the fan out that occurs
    
          
              
    
        
    
      
    
    
    
    
    after
    
    
        
    
    
    
      
    
        
    three
    
        
            
    
        
    
          
    hops results in eight next hop downward paths from the DODAG root
    
          
              
    
        
    
        
    (LBR)
    
        
            
    
        
    
          
    to a target node (41). Even with the hop-by-hop DAO mechanism it
    
          
              
    
        
    
        
    would
    
        
    be
    
        
            
    
        
    
          
    desirable to be able to limit fan out as well as to identify path
    
          
              
    
        
    
        
    preference and
    
        
            
    
        
    
          
    diversity at the root or other intermediate storing node.
    
          
     
    
          
                        (------------LBR------------)
    
          
                        /    /   / |     | \    \   \
    
          
                       /    /   /  |     |  \    \   \
    
          
                      /    /   /   |     |   \    \   \
    
          
                     /    /   /    |     |    \    \   \
    
          
                  (11) (12) (13) (14)   (15) (16) (17) (18)
    
          
                     \   |    |    /     \    |    |   /
    
          
                      \  |    |   /       \   |    |  /
    
          
                       \ |    |  /         \  |    | /
    
          
                      (21)   (22)           (23)  (24)
    
          
                          \    |            |    /
    
          
                           \   |            |   /
    
          
                            \  |            |  /
    
          
                             (31)          (32)
    
          
                                 \        /
    
          
                                  \      /
    
          
                                   \    /
    
          
                                    (41)
    
          
     
    
          
              
    
        
    
        
    [Pascal] Your schema illustrates clearly that even if we fan out a
    
        
            
    
      
    
    
    
    
    lot,
    
    
        
    
    
    
      
    
        
    it does not mean that a router on the way down will have more
    
        
            
    
      
    
    
    
    
    feasible
    
    
        
    
    
    
      
    
        
    successors.
    
        
     
    
        
    That's one thing that's important to remember, the properties of
    
        
            
    
      
    
    
    
    
    the
    
    
        
    
    
    
      
    
        
    DAG
    
        
    are not symmetrical, so even if we build it to get multiple
    
        
            
    
      
    
    
    
    
    feasible
    
    
        
    
    
    
      
    
        
    successors on the way up, that does not mean that on the reverse
    
        
            
    
      
    
    
    
    
    DAG
    
    
    to
    
    
        
    
    
    
      
    
        
    a target there are multiple successors at each hop towards that
    
        
            
    
      
    
    
    
    
    target.
    
    
        
    
    
    
      
    
        
    In other words, the ROI of fanning out is not guaranteed if we do
    
        
            
    
      
    
    
    
    
    it
    
    
        
    
    
    
      
    
        
    blindly.
    
        
     
    
        
            
    
        
    
          
    A simple path control bitmap associated with the advertised
    
          
              
    
        
    
        
    Destination
    
        
            
    
        
    
          
    Address can be included within the DAO to address the issue of
    
          
              
    
        
    
      
    
    
    
    
    path
    
    
        
    
    
    
      
    
        
    
          
    preference as well as control of fan out. For a network of
    
          
              
    
        
    
        
    'non-storing'
    
        
            
    
        
    
          
    nodes the preference indication would be processed only at the
    
          
              
    
        
    
      
    
    
    
    
    root.
    
    
        
    
    
    
      
    
        
    [Pascal] so far so good, but that will give you a blind mechanism.
    
        
     
    
        
            
    
        
    
          
    With the path control byte associated with each DAO destination
    
          
              
    
        
    
        
    address, a
    
        
            
    
        
    
          
    node will be able to specify preference among DAO parent paths
    
          
              
    
        
    
      
    
    
    
    
    and
    
    
        
    
    
    
      
    
        
    can
    
        
            
    
        
    
          
    convey limits on the number of downward paths. This is an
    
          
              
    
        
    
      
    
    
    
    
    opportunity
    
    
        
    
    
    
      
    
        
    for
    
        
            
    
        
    
          
    nodes to further influence the downward paths that are
    
          
              
    
        
    
      
    
    
    
    
    established
    
    
        
    
    
    
      
    
        
    and
    
        
            
    
        
    
          
    maintained. Consistent with the DV-based RPL operation this DAO
    
          
              
    
        
    
      
    
    
    
    
    path
    
    
        
    
    
    
      
    
        
    
          
    control mechanism must operate hop-by-hop avoiding any
    
          
              
    
        
    
      
    
    
    
    
    requirement
    
    
        
    
    
    
      
    
        
    for
    
        
            
    
        
    
          
    end-to-end path coordination. To avoid overloading this email
    
          
              
    
        
    
      
    
    
    
    
    thread
    
    
        
    
    
    
      
    
        
    I
    
        
    will
    
        
            
    
        
    
          
    initiate a separate discussion on how a path control element may
    
          
              
    
        
    
      
    
    
    
    
    be
    
    
        
    
    
    
      
    
        
    included
    
        
            
    
        
    
          
    within the DAO.
    
          
     
    
          
              
    
        
    
        
    [Pascal] Too late, I just did :)
    
        
     
    
        
    And if I remember, Tim's idea was to control the stretch of the
    
        
            
    
      
    
    
    
    
    fanout,
    
    
        
    
    
    
      
    
        
    by decrementing a counter as the path loses preference point.
    
        
    At the moment, we have a parent preference 0-lowest to 3 highest.
    
        
            
    
      
    
    
    
    
    So
    
    
    it
    
    
        
    
    
    
      
    
        
    is easy to decrement a counter by (3-pref) and not fan out when the
    
        
    counter reaches 0.
    
        
    Tim, could you elaborate on this?
    
        
            
    
      
    
      
    A Path Control bit map will achieve an equivalent control mechanism
    
      
    whereby
    
      
    at each node the number of bits that are set will determine the
    
      
          
    
    
    
    
    extent
    
    
    to
    
    
        
    
    
    
      
    which the associated DAO Destination Address can be advertised to
    
      
          
    
    
    
    
    multiple
    
    
        
    
    
    
      
    DAO Parents. If a DAO message destination address Path Control bitmap
    
      
          
    
    
    
    
    has
    
    
        
    
    
    
      
    4
    
      
    set bits, that address can be send along a maximum of 4 paths. For
    
      
          
    
    
    
    
    example,
    
    
        
    
    
    
      
    at the originating node the DAO can be sent to two DAO Parents where
    
      
          
    
    
    
    
    the
    
    
        
    
    
    
      
    Path Control bit map in the message sent to each DAO Parent will have
    
      
          
    
    
    
    
    two
    
    
        
    
    
    
      
    set bits. If each parent then advertises to two DAO Parents a single
    
      
          
    
    
    
    
    bit is
    
    
        
    
    
    
      
    set for each DAO message. Eventually with a single bit set in the
    
      
          
    
    
    
    
    Path
    
    
        
    
    
    
      
    Control bit map, the DAO message can be advertised only to a single
    
      
          
    
    
    
    
    DAO
    
    
        
    
    
    
      
    Parent. This mechanism achieves the effect of limiting the stretch of
    
      
          
    
    
    
    
    the
    
    
        
    
    
    
      
    path fan out. Where multiple DAO messages are received at a common
    
      
    ancestor
    
      
    the number of set bits in the respective Path Control fields are
    
      
          
    
    
    
    
    recombined
    
    
        
    
    
    
      
    allowing for renewed advertising of the DAO message destination
    
      
          
    
    
    
    
    address to
    
    
        
    
    
    
      
    multiple DAO Parents along the path.
    
      
     
    
      
    As the set Path Control bits are split and recombined as the DAO
    
      
          
    
    
    
    
    messages
    
    
        
    
    
    
      
    are transferred to the root, their bit positions are maintained. This
    
      
          
    
    
    
    
    allows
    
    
        
    
    
    
      
    bit positions to be ordered from low to high in terms of path
    
      
          
    
    
    
    
    preference.
    
    
        
    
    
    
      
    Therefore when a DAO message is received in which the Path Control
    
      
          
    
    
    
    
    bitmap
    
    
        
    
    
    
      
    has the highest preference bit set, that DAO message destination
    
      
          
    
    
    
    
    address is
    
    
        
    
    
    
      
    always advertised to the preferred DAO Parent. Similarly, when a
    
      
          
    
    
    
    
    message is
    
    
        
    
    
    
      
    received with multiple Path Control bits set, the DAO messages can be
    
      
    distributed to DAO Parents according to parent preference. This will
    
      
          
    
    
    
    
    ensure
    
    
        
    
    
    
      
    that at any common ancestor, including the root, a node is always
    
      
          
    
    
    
    
    able
    
    
    to
    
    
        
    
    
    
      
    distinguish the preferred downward path. The ability to determine the
    
      
    preferred downward path as well as to obtain an indication of path
    
      
          
    
    
    
    
    diversity
    
    
        
    
    
    
      
    will allow the Path Control field to be used when resource
    
      
          
    
    
    
    
    limitations
    
    
    at a
    
    
        
    
    
    
      
    node require a truncation of the number of downward paths that the
    
      
          
    
    
    
    
    node
    
    
        
    
    
    
      
    maintain for a given destination address.
    
      
     
    
      
          
    
      
    
        
    Pascal
    
        
            
    
      
    
    
    
    
    > 
    
    
     
    
    
    _______________________________________________
    
    
    Roll mailing list
    
    
    Roll@ietf.org
    
    
    https://www.ietf.org/mailman/listinfo/roll
    
  
    
  
     
    
  
    
  
    

    

    



--------------080607010108070405080209--

From jeonggil.ko@gmail.com  Thu Apr 29 11:49:27 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B223A6AA3 for ; Thu, 29 Apr 2010 11:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qdk2pFQDC60 for ; Thu, 29 Apr 2010 11:49:26 -0700 (PDT)
Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 2085F3A6A5D for ; Thu, 29 Apr 2010 11:49:26 -0700 (PDT)
Received: by qyk33 with SMTP id 33so3321083qyk.24 for ; Thu, 29 Apr 2010 11:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=+BdOT+Q30a2nKLdW+hdUSIxaygmse93gX8e21k73k2o=; b=tgqQFiv0k+tmxIBhOkxmXOBVvjaqnInuVYwTJ0oW8SOIecEj7drbZVGcrZ90hbakLW f18FmgXBHML6XTG1xdBwoVlkHWzcCFeHRTlvsN1V/4BvGAre8xQsUKLbLqdOaFXV8rVp Vw8ZwpiAIZLDzbfhMkUX40fzeCp43d0fU2wZU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Wo0B0nUUaRG/rhlOxTU/c0Gd1DojbJz+GaJw+sFyST4kCNqZ4XlyEsELxLYhNi5Itl DnyR6ER/Yab6hNxpwdVIYgbRBpg+xmgz0v/rDvAgh8qMC7NhwIv/bniyQBDs3cPLfeEI Btu8ocYl8Cc00Ec40GaajL0gE1/+zVXjRgBoA=
Received: by 10.224.110.132 with SMTP id n4mr3007498qap.55.1272566914739; Thu, 29 Apr 2010 11:48:34 -0700 (PDT)
Received: from python.isi.jhu.edu (python.isi.jhu.edu [128.220.247.192]) by mx.google.com with ESMTPS id 7sm2057708qwf.16.2010.04.29.11.48.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 11:48:32 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: "JeongGil Ko (John)" 
In-Reply-To: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
Date: Thu, 29 Apr 2010 14:48:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>
To: Mukul Goyal 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 18:49:27 -0000

Hi all!

Great to see that things are actually moving on with the point to point =
discussions and I think this draft is a nice in the sense that we are =
trying to focus on this topic :)

One confusion as I read through the draft is where the authors say in =
4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, =
4.3 indicates that DAOs are needed in some cases to support the Rout =
Stack option. Not that its impossible, it would be more than =
overwhelming to deal with both DAOs and DIOs for discovery :)=20

Overall it looks like a nice high level description of what =
'should/could/can/may' happen (although I thought the discussion on =
loose source routing was over with) but we would need to tie it harder =
with RPL itself. Just my 2 cents ;)

Thanks.

-John

On Apr 28, 2010, at 1:46 PM, Mukul Goyal wrote:

> Hi all
>=20
> The following draft has been submitted for WG's consideration. It =
describes the additional mechanisms required to support P2P routing in =
LLNs. The draft first provides a high level description of the =
mechanisms and then proposes one way of realizing these mechanisms in =
RPL.
>=20
> Regards
> Mukul
>=20
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada =
Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00=20
>=20
>=20
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been =
successfully submitted by Mukul Goyal and posted to the IETF repository.
>=20
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point Routing in =
Low Power and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
>=20
> Abstract:
> This draft presents mechanisms to determine the end-to-end cost of an
> existing route and to discover/establish "on demand" one or more
> routes between two nodes in a low power and lossy network.  This
> draft also proposes functionality that would enable RPL to provide
> these P2P mechanisms.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From prvs=728cdad50=mukul@uwm.edu  Thu Apr 29 12:03:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECAD3A688E for ; Thu, 29 Apr 2010 12:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.209
X-Spam-Level: 
X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[AWL=0.394,  BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GrzH1E-Ht-2 for ; Thu, 29 Apr 2010 12:03:09 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B058128C197 for ; Thu, 29 Apr 2010 12:03:09 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 29 Apr 2010 14:02:56 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1142C2C3800E; Thu, 29 Apr 2010 14:02:56 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 6UZ4LagPT5GZ; Thu, 29 Apr 2010 14:02:55 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9604C2C38011; Thu, 29 Apr 2010 14:02:55 -0500 (CDT)
Date: Thu, 29 Apr 2010 14:02:55 -0500 (CDT)
From: Mukul Goyal 
To: "JeongGil Ko (John)" 
Message-ID: <904489479.4678151272567775562.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: ROLL WG 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 19:03:14 -0000

Hi John

>One confusion as I read through the draft is where the authors say in 4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, 4.3 indicates that DAOs are needed in some cases to support the Rout Stack option. Not that its impossible, it would be more than overwhelming to deal with both DAOs and DIOs for discovery :) 

No. The draft merely points out that RPL-07 allows only a DAO to carry the Route Stack option. To support the P2P mechanisms described in the draft, RPL should allow Measurement Request and Discovery messages to carry the Route Stack option as well.

>Overall it looks like a nice high level description of what 'should/could/can/may' happen (although I thought the discussion on loose source routing was over with) but we would need to tie it harder with RPL itself. Just my 2 cents ;)

Regarding loose source routing, there are good reasons to ditch it for DAG-based routing. But there are no reasons why it can not be supported for the route discovery mechanism described in the draft. Loose source routes are useful and should be supported if there are no major technical difficulties in doing so. 

Thanks
Mukul

 

On Apr 28, 2010, at 1:46 PM, Mukul Goyal wrote:

> Hi all
> 
> The following draft has been submitted for WG's consideration. It describes the additional mechanisms required to support P2P routing in LLNs. The draft first provides a high level description of the mechanisms and then proposes one way of realizing these mechanisms in RPL.
> 
> Regards
> Mukul
> 
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 
> 
> 
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.
> 
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
> 
> Abstract:
> This draft presents mechanisms to determine the end-to-end cost of an
> existing route and to discover/establish "on demand" one or more
> routes between two nodes in a low power and lossy network.  This
> draft also proposes functionality that would enable RPL to provide
> these P2P mechanisms.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From prvs=728cdad50=mukul@uwm.edu  Thu Apr 29 12:08:00 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9993A68AD for ; Thu, 29 Apr 2010 12:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.063
X-Spam-Level: 
X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=1.536,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Sci40PIKNZ for ; Thu, 29 Apr 2010 12:07:59 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 32CBA3A688E for ; Thu, 29 Apr 2010 12:07:59 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 29 Apr 2010 14:07:45 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id CA3342C3800D; Thu, 29 Apr 2010 14:07:45 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 6ExbkEVYL0QJ; Thu, 29 Apr 2010 14:07:45 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 57D212C3800F; Thu, 29 Apr 2010 14:07:45 -0500 (CDT)
Date: Thu, 29 Apr 2010 14:07:45 -0500 (CDT)
From: Mukul Goyal 
To: "JeongGil Ko (John)" 
Message-ID: <1241226766.4681661272568065316.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <904489479.4678151272567775562.JavaMail.root@mail02.pantherlink.uwm.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: ROLL WG 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 19:08:00 -0000

Just to clarify further, the route discovery mechanism described in the draft do not prescribe any use of DAOs although when you think about it, a DAO MAY serve as the Discovery Reply message. The difference is that a DAO is restricted to travel along the DAG where as we (the draft's authors) have allowed the Discovery Reply message to travel along any route if it merely carries a source-route back to the originator of route discovery.

Regards
Mukul
   
----- Original Message -----
From: "Mukul Goyal" 
To: "JeongGil Ko (John)" 
Cc: "ROLL WG" 
Sent: Thursday, April 29, 2010 2:02:55 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi John

>One confusion as I read through the draft is where the authors say in 4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, 4.3 indicates that DAOs are needed in some cases to support the Rout Stack option. Not that its impossible, it would be more than overwhelming to deal with both DAOs and DIOs for discovery :) 

No. The draft merely points out that RPL-07 allows only a DAO to carry the Route Stack option. To support the P2P mechanisms described in the draft, RPL should allow Measurement Request and Discovery messages to carry the Route Stack option as well.

>Overall it looks like a nice high level description of what 'should/could/can/may' happen (although I thought the discussion on loose source routing was over with) but we would need to tie it harder with RPL itself. Just my 2 cents ;)

Regarding loose source routing, there are good reasons to ditch it for DAG-based routing. But there are no reasons why it can not be supported for the route discovery mechanism described in the draft. Loose source routes are useful and should be supported if there are no major technical difficulties in doing so. 

Thanks
Mukul

 

On Apr 28, 2010, at 1:46 PM, Mukul Goyal wrote:

> Hi all
> 
> The following draft has been submitted for WG's consideration. It describes the additional mechanisms required to support P2P routing in LLNs. The draft first provides a high level description of the mechanisms and then proposes one way of realizing these mechanisms in RPL.
> 
> Regards
> Mukul
> 
> ----- Forwarded Message -----
> From: "IETF I-D Submission Tool" 
> To: mukul@uwm.edu
> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada Central
> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 
> 
> 
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.
> 
> Filename:	 draft-dt-roll-p2p-rpl
> Revision:	 00
> Title:		 Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks
> Creation_date:	 2010-04-28
> WG ID:		 Independent Submission
> Number_of_pages: 13
> 
> Abstract:
> This draft presents mechanisms to determine the end-to-end cost of an
> existing route and to discover/establish "on demand" one or more
> routes between two nodes in a low power and lossy network.  This
> draft also proposes functionality that would enable RPL to provide
> these P2P mechanisms.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

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

From jeonggil.ko@gmail.com  Thu Apr 29 12:08:14 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76ED928C268 for ; Thu, 29 Apr 2010 12:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGDJPU5efTVu for ; Thu, 29 Apr 2010 12:08:13 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id F2A4328C1D7 for ; Thu, 29 Apr 2010 12:08:12 -0700 (PDT)
Received: by qyk11 with SMTP id 11so19510996qyk.13 for ; Thu, 29 Apr 2010 12:07:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=KTmeejeFP4DuRbXcTttTO0sh1381DTMvQZad2smQEoU=; b=sMQ+2lPpyaqZSzH4JhbkVwC24E/KobwlpDvD4vouffrtoSdk5m52/kpm5G9E8LEIP3 lRlqQCQ0PBlCr7SeO22aviOFaqNBCha/AulugvYYbomAYYN+e7OWNAkbT6gibTVBg7/D eckJcI6dRHe0kRLtDPNcv6HtV2pjWH5lex1hs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=P9vgus57f7lFGW4yK7asLSQtDFSBCyDfFEEqukwIq0CkaYGUI35iw5PneATxcWGe4h 5umrLl3Th74nM9U2irn18cem2fyXXWr/EepDueBp2IQ8QV6prtWlldk00UjU4l3FW9wr tl0uVZgdZLAM6tCrQlEDRGnEbDC0YWDF3y1fo=
Received: by 10.224.50.80 with SMTP id y16mr700019qaf.375.1272568075074; Thu, 29 Apr 2010 12:07:55 -0700 (PDT)
Received: from python.isi.jhu.edu (python.isi.jhu.edu [128.220.247.192]) by mx.google.com with ESMTPS id 26sm2106817qwa.12.2010.04.29.12.07.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 12:07:54 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: "JeongGil Ko (John)" 
In-Reply-To: <904489479.4678151272567775562.JavaMail.root@mail02.pantherlink.uwm.edu>
Date: Thu, 29 Apr 2010 15:07:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <904489479.4678151272567775562.JavaMail.root@mail02.pantherlink.uwm.edu>
To: Mukul Goyal 
X-Mailer: Apple Mail (2.1078)
Cc: ROLL WG 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 19:08:14 -0000

Hi Mukul

>> One confusion as I read through the draft is where the authors say in =
4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, =
4.3 indicates that DAOs are needed in some cases to support the Rout =
Stack option. Not that its impossible, it would be more than =
overwhelming to deal with both DAOs and DIOs for discovery :)=20
>=20
> No. The draft merely points out that RPL-07 allows only a DAO to carry =
the Route Stack option. To support the P2P mechanisms described in the =
draft, RPL should allow Measurement Request and Discovery messages to =
carry the Route Stack option as well.
>=20

It would be nice if what you just said above was explicitly mentioned in =
4.3 to avoid misunderstandings.

- John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From prvs=728cdad50=mukul@uwm.edu  Thu Apr 29 12:11:36 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1816F3A6B2C for ; Thu, 29 Apr 2010 12:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.353
X-Spam-Level: 
X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.387,  BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2tEu1nzMvOS for ; Thu, 29 Apr 2010 12:11:33 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 63D6E3A688E for ; Thu, 29 Apr 2010 12:11:33 -0700 (PDT)
Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 29 Apr 2010 14:11:19 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C4BF72C38017; Thu, 29 Apr 2010 14:11:19 -0500 (CDT)
X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul
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 XI5D3XoETijk; Thu, 29 Apr 2010 14:11:19 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 766402C38012; Thu, 29 Apr 2010 14:11:19 -0500 (CDT)
Date: Thu, 29 Apr 2010 14:11:19 -0500 (CDT)
From: Mukul Goyal 
To: "JeongGil Ko (John)" 
Message-ID: <1503904706.4684281272568279398.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64)
X-Authenticated-User: mukul@uwm.edu
Cc: ROLL WG 
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 19:11:36 -0000

Hi John

I will change the language of Section 4.3 as you suggested.

cheers
Mukul

----- Original Message -----
From: "JeongGil Ko (John)" 
To: "Mukul Goyal" 
Cc: "ROLL WG" 
Sent: Thursday, April 29, 2010 2:07:51 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi Mukul

>> One confusion as I read through the draft is where the authors say in 4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, 4.3 indicates that DAOs are needed in some cases to support the Rout Stack option. Not that its impossible, it would be more than overwhelming to deal with both DAOs and DIOs for discovery :) 
> 
> No. The draft merely points out that RPL-07 allows only a DAO to carry the Route Stack option. To support the P2P mechanisms described in the draft, RPL should allow Measurement Request and Discovery messages to carry the Route Stack option as well.
> 

It would be nice if what you just said above was explicitly mentioned in 4.3 to avoid misunderstandings.

- John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko


From robert.cragie@gridmerge.com  Thu Apr 29 12:16:40 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13843A688E for ; Thu, 29 Apr 2010 12:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnOLgt+TVba9 for ; Thu, 29 Apr 2010 12:16:39 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1EBF328C287 for ; Thu, 29 Apr 2010 12:16:39 -0700 (PDT)
Received: from client-82-27-2-50.pete.adsl.virginmedia.com ([82.27.2.50] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1O7ZDk-0006aj-9h for roll@ietf.org; Thu, 29 Apr 2010 20:16:24 +0100
Message-ID: <4BD9DB05.3070309@gridmerge.com>
Date: Thu, 29 Apr 2010 20:16:21 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: roll@ietf.org
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>		<4BD880EE.4010502@computer.org> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400080306070809060605"
Subject: Re: [Roll] Fwd: New Version Notification for	draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Apr 2010 19:16:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms030400080306070809060605
Content-Type: multipart/alternative;
 boundary="------------030401080408010906080904"

This is a multi-part message in MIME format.
--------------030401080408010906080904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Please refer to http://tools.ietf.org/html/rfc1603#page-19 for the=20
definitive answer. Can we now carry on with the real analysis and=20
feedback on the P2P proposal?

FWIW my personal interpretation is that Charlie is right. Working groups =

seem to be much more formal.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com 


On 29/04/2010 5:55 PM, Philip Levis wrote:
> On Apr 28, 2010, at 11:39 AM, Charles E. Perkins wrote:
>
>   =20
>> Hello JP,
>>
>> I think that the members of the discussion team
>> do qualify as a "design team".  However, it is true
>> that the design team was not an official design
>> team appointed by directive of the working group.
>>     =20
> Sure -- so please try to use clear, rather than confusing, terminology.=
 I, for example, could think that the group of us working on trickle do q=
ualify as a "working group" in that we are a group that is working. But u=
sing such a term would hardly be considered helpful.
>
> Phil
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>   =20

--------------030401080408010906080904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




  


Please refer to ht=
tp://tools.ietf.org/html/rfc1603#page-19
for the definitive answer. Can we now carry on with the real analysis
and feedback on the P2P proposal?
    

    
FWIW my personal interpretation is that Charlie is right. Working
groups seem to be much more formal.
    

    
Robert
    

    


    Robert Cragie (Pacific Gas & Electric)
    

    Gridmerge Ltd.
    
89 Greenfield Crescent,
    
Wakefield, WF4 4WA, UK
    
+44 (0) 1924 910888
    
http://www.gridmerge.com
    

    

    
On 29/04/2010 5:55 PM, Philip Levis wrote:

    
  
    On Apr 28, 2010, at 11:39 AM, Charles E. Perkins wrote:

  
    
  
    
    
    Hello JP,

I think that the members of the discussion team
do qualify as a "design team".  However, it is true
that the design team was not an official design
team appointed by directive of the working group.
    
    
  
    
  
    Sure -- so please try to use clear, rather than confusing, terminology. I=
, for example, could think that the group of us working on trickle do qua=
lify as a "working group" in that we are a group that is working. But usi=
ng such a term would hardly be considered helpful.

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

  
    

    



--------------030401080408010906080904--

--------------ms030400080306070809060605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0
MjkxOTE2MjFaMCMGCSqGSIb3DQEJBDEWBBTz1UYnH2EGrjxnNhjZGmr8mhNvwjBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAA4AQnRQcNSB4JEOZVExNST1pfPpaNc1x+aVH0tERILfWJESZ1evmJ/XhqQv0iwc4QGm
wwTc25+IbnPL6QCrLFeHGxIv+5VyEG/DU5z/Ywjw3I8Mb+LGgik9S+VYoz1U10vFPN0zlJ0Y
4ENsZ6qnoDNJDQ0xlnCBo5CkFoQx9VQvyy765gJCOqoMdCpQUP6vDLU0r9zjVp5Jccb2MN4/
YJQpyahdk2Gb+cmOt+2pyC4G64U5h8gTZP7e66G1jf4BdNuc59hDMvJuHWk4uhJ6n55VwYgV
j4liKBYUwuRPtRlyorMw4RGp648KhfYZLIzLcKoBiPyg8XCottsmQ3DrPFEAAAAAAAA=
--------------ms030400080306070809060605--

From emmanuel.baccelli@gmail.com  Thu Apr 29 13:56:02 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AFA3A6942 for ; Thu, 29 Apr 2010 13:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.438
X-Spam-Level: 
X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs0OadVPlVZW for ; Thu, 29 Apr 2010 13:56:01 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6C1573A6845 for ; Thu, 29 Apr 2010 13:56:01 -0700 (PDT)
Received: by wwb24 with SMTP id 24so277963wwb.31 for ; Thu, 29 Apr 2010 13:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=4yPdNfkeSlP9dkix+2Da53zqbIItDKlfqTS4UhwyUuA=; b=noGwKRwF5GGJDAk3usQlyqJVRkTRBAYU8oiUqtRKmhcQUabyvZEg0EdZPvpwDzDivO dXqu953xZi+3T0OsNMOK0oNfmHydldkjsnU6VkJQvumQ9KY4M6SPWE1gqQf/32gXd6ux D4MYGUXa/xeUDx8pnEWebKmzlTZxjOZS94Jwk=
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=xHZFoMxjf5589tbNchk2HpgDOY9JwKoduiNW5BqaaCE+EYsLkiuSGbf1lhhm0Cnmxe QYSAQcfhfmjpN9ZRtFkY4/xUy7Ukx5KveR44siD979Hoh0gbeD83WFuaPsF/gAQ+KlsD 0Iypgq15IbKEIEiD8NxpY+oEtbaDdw7pOWsCw=
Received: by 10.216.90.20 with SMTP id d20mr3411684wef.75.1272574545164; Thu,  29 Apr 2010 13:55:45 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by 10.216.222.136 with HTTP; Thu, 29 Apr 2010 13:55:25 -0700 (PDT)
In-Reply-To: 
References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu>  <4BD880EE.4010502@computer.org>  
From: Emmanuel Baccelli 
Date: Thu, 29 Apr 2010 22:55:25 +0200
X-Google-Sender-Auth: 22ab7ed367f9e769
Message-ID: 
To: ROLL WG 
Content-Type: multipart/alternative; boundary=0016e6d77ecbb6fb270485665973
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 20:56:02 -0000

--0016e6d77ecbb6fb270485665973
Content-Type: text/plain; charset=ISO-8859-1

"design team" is a rather loose term in the IETF -- contrary to "working
group".

Anyways, let's focus on discussing the content rather than on administrative
terminology ;)

Emmanuel


On Thu, Apr 29, 2010 at 6:55 PM, Philip Levis  wrote:

>
> On Apr 28, 2010, at 11:39 AM, Charles E. Perkins wrote:
>
> >
> > Hello JP,
> >
> > I think that the members of the discussion team
> > do qualify as a "design team".  However, it is true
> > that the design team was not an official design
> > team appointed by directive of the working group.
>
> Sure -- so please try to use clear, rather than confusing, terminology. I,
> for example, could think that the group of us working on trickle do qualify
> as a "working group" in that we are a group that is working. But using such
> a term would hardly be considered helpful.
>
> Phil
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

--0016e6d77ecbb6fb270485665973
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

"design team" is a rather loose term in the IETF -- contrary to &=
quot;working group".

    Anyways, let's focus on discussi=
ng the content rather than on administrative terminology ;)

    


    Emmanuel


    On Thu, Ap=
r 29, 2010 at 6:55 PM, Philip Levis <pal@cs.stanford.edu> wrote:
    



    
On Apr 28, 2010, at 11:39 AM, Charles E. Perkins wrote:
    

    
>
    
> Hello JP,
    
>
    
> I think that the members of the discussion team
    
> do qualify as a "design team". =A0However, it is true
    
> that the design team was not an official design
    
> team appointed by directive of the working group.
    

    

    Sure -- so please try to use clear, rather than confusing, terminolog=
y. I, for example, could think that the group of us working on trickle do q=
ualify as a "working group" in that we are a group that is workin=
g. But using such a term would hardly be considered helpful.
    



    
Phil
    

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


    

--0016e6d77ecbb6fb270485665973--

From roger.alexander@ekasystems.com  Thu Apr 29 15:19:10 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6C628C13E for ; Thu, 29 Apr 2010 15:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.711
X-Spam-Level: 
X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[AWL=-0.741,  BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 712SOOkch32r for ; Thu, 29 Apr 2010 15:18:49 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 2F97B3A6A81 for ; Thu, 29 Apr 2010 15:18:49 -0700 (PDT)
Received: (qmail 38815 invoked from network); 29 Apr 2010 22:18:33 -0000
Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp112.biz.mail.re2.yahoo.com with SMTP; 29 Apr 2010 15:18:32 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: cpfQPRIVM1nLQ9jitzag4M2MOXbnuexuGXwuqwGZj0w80eNXLKoKJjrsVbJSiJKmyd8wrBf_IMizbk46OLGFs.YQGfnvIFiSgNNFvyCwuzB9gI0bHSfkhv2L3QIOl3W3iJ_QGbNQnlQInZJj73IdMv9Z5ALRMT7vzBYm0oTD7.hI2crx0fOeHuHE3GezY42zh_daJjQvdl7rll5sHyRbayzaYGkSEWWKueManHfzjguWrSisB5iEH6dLTIUkOB0idJCvt2YANdo.xMV..gcwyisaNjOYMRxIKQDZsb9NnB1UWsV.UHKax.FGtvUCeqZa_nkyI5hpFT7kq7ySE64A7vN019mnPJVBtqIx0o9RcXcJQXTgUJMAk7RORTHNDdE-
X-Yahoo-Newman-Property: ymail-3
From: "Roger Alexander" 
To: "'Thomas Watteyne'" , , "'Tzeta Tsao'" 
References: <4BD8E89C.9020809@eecs.berkeley.edu>	<02dc01cae7c3$0023b6e0$006b24a0$%alexander@ekasystems.com> <4BD9CF1E.20708@eecs.berkeley.edu>
In-Reply-To: <4BD9CF1E.20708@eecs.berkeley.edu>
Date: Thu, 29 Apr 2010 18:16:26 -0400
Message-ID: <031a01cae7e9$9c3a8ec0$d4afac40$@alexander@ekasystems.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01CAE7C8.1528EEC0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrnyXAu4ayL+XrXS3S2bomuzfNBXAAFEwHQ
Content-Language: en-us
Subject: Re: [Roll] Fwd: Re:  DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Apr 2010 22:19:11 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_031B_01CAE7C8.1528EEC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Thomas,

 

Still mulling the interesting results of your simulation and the potential
implications. A couple further thoughts, particularly as it relates to the
'disjointness' measure.

 

1.       While 'disjointness' as you have defined it does capture some
measure of the independence of paths, it may not be adequately reflecting
the increased path availability that results from multiple DAO Parents. That
is, it is possible for disjointedness to remain the same or even fall while
the end-to-end path availability goes up. See a simple example below. This
raises the question of whether it would be better to more directly capture
path availability in the simulated data.

2.       An artifact of the network model is that the node degree is the
same for all nodes including the root. This means that regardless of
fan-out, the paths to/from the root will converge based on node degree. More
importantly, paths from the target node all converge according to the number
of assumed DAO Parents. The way disjointness is calculated, each new fanout
path adds a common link count based on the node-DAO Parent link from which
the path emerged. This is not a problem in itself, but the node-parent links
and a common ancestor-root link get counted in the number of common links
for each link fan out occurring in between. This may be having some effect
on compressing the resulting disjointness measure.

 

A simple example to try to clarify these thoughts. Consider a downward path
between an LBR root node and a node A given by A-B-C-LBR. Disjointness is of
course 1 (3/3). Add a second completely independent path given by A-E-F-LBR.
Here the disjointness of the two paths is again 1 (6/6, all links remain
disjoint). However the path availability to node A has increased (all links
equally available, it has doubled). If a third path is added via a third DAO
Parent given by A-H-F-LBR. The disjointed measure has fallen to (7/9) even
though the availability of the connection from A to the LBR has increased.
If a fourth DAO parent is added to offer a path given by A-J-B-C-LBR, the
disjointed measure falls further to (7/13) even as the path availability
from the LBR root to node A has improved due to the additional diversity
along the path from B-A. What this seems to be implying is that even as
disjointness is capturing some measure of reduced path independence, it may
not be adequately capturing the improved path availability potential. Let me
know if I have accurately characterized the measure.

 

 What we will try to do as well in the coming weeks is to analyze some
sample field network data to see how additional DAO parents would affect
downward path availability.

 

Roger

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Thomas Watteyne
Sent: Thursday, April 29, 2010 2:26 PM
To: roll@ietf.org
Subject: Re: [Roll] Fwd: Re: DAO fan out

 

Hi Roger,
Thanks for the clear answers. I'm eager to see what people on the list
think.
Thomas

On 4/29/2010 10:40 AM, Roger Alexander wrote: 

Hi Thomas,

 

Thanks for the feedback and the simulation results.

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Thomas Watteyne
Sent: Wednesday, April 28, 2010 10:02 PM
To: roll@ietf.org
Subject: [Roll] Fwd: Re: DAO fan out

 

Roger,

Having a single byte for fan-out control and prioritization of downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast
protocol. I have a couple of questions, though.

1) Is this a technique you (or others on the list) have experience with? If
it's a proven technique, I'm glad to learn about it, and the WG will have
more confidence adopting it.

[RA] No this is not a proven or deployed technique. The proposal is based on
a concern that arises from our deployed networks where single root nodes do
support a network of thousands of nodes. Once multiple DAO parents are
entertained for downward routing availability, routing scalability can be
affected if DAO exchanges are left  unbounded. Furthermore, there will need
to be a means of extracting the preferred downward path and selecting from
the many alternatives that can result.



2) I have some questions related to path convergence, which relates to the
following paragraph in your text:

"An intermediate node may receive DAO messages from multiple children nodes
that advertise reachability to a given Destination Address. Where the total
number of set Path Control bits is greater than the number of DAO Parents
the
bitmaps for the DAO messages will be merged. This merging of set bits will
allow for subsequent fan out at subsequent ancestor nodes."

This is, if I receive DAOs with [00000110] and [00000001] from two of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that mean that, every
time I receive a DAO, I buffer it for some time in case I can merge it with
a later one? If yes, how do I choose the duration to wait? If I decide to
retransmit DAO's ASAP, and never merge them, what are the implications? As
you may understand, I'm not a very big fan of the idea of "buffering for
some time"...

[RA] The note was written from the perspective of a network with all storing
nodes. For storing nodes, DAO advertisements and made and updated based on
the validity period of the received Destination Address routing updates. It
that context the issue of buffering is well defined. There is however an
issue of dealing with the sequence of DAO advertisements that will be
received at different intervals that may require subsequent change in the
selected DAO Parent. To maintain the requirement that the preferred path can
always be determined, there may be periods during which fewer DAO Parents
are selected than may be otherwise available at a given intermediate node
(future consideration required).

 

[RA] For non storing nodes, based on my understanding of the currently
discussed proposal, the situation is simpler in that the originating owner
of the Destination Address establishes the preference and includes the
applicable Path Control setting with the different DAO Parents selected.
Each node selects its DAO Parents and indicates the preference of each. Each
node's information needs only to be available at the root which then
computes all downward paths. The onus for scalability in processing the
downward path routing is placed on the root node - with processing
requirements increasing with the number of DAO Parents. However, all the
information is available for global determination of preferred, as well as
secondary downward paths. 



I have taken a few minutes to verify that during fan-out, you should control
the parent selection
(http://www.eecs.berkeley.edu/~watteyne/disjointness.pdf
 ). It tells you
that, if two DAOs copies are sent towards the LBR, and each node en-route
can select its DAO parent randomly, the two obtained routes will not be
disjoint. That is, if one path fails, changes are the second will also as
they share many links.

[RA] Thanks. This is an interesting result, caveats notwithstanding. I would
like to digest a bit further and get back to you. The benefit of multiple
DAO Parents is predicated on the downward diversity that it provides. The
cost of multiple DAO Parents and fan out is that it can negate some of RPL's
routing scalability benefits (for storing nodes). If as the results suggest
multiple DAO Parents does not provide a meaningful path availability gain
then its utility is somewhat diminished. 



3) Similar to Fig.5, consider fan-out and convergence causes the LBR to
receive two routes [00000001] and [00000110]. Which one will is prefer?
Sure, [00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?

[RA] Yes, diversity information may be derived from the path Control and can
be used as a selection criteria when making a choice of downward path. That
would be an implementation choice. 



Similarly, what happens if the LBR has only one link to the rest of the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell me.

[RA] If that were the case the LBR would indeed receive one packet with
[11111111].  However the collective path information would be available to
the single node that connects to the LBR. That node, and all other
intermediate (storing) nodes, use the available path control information to
support downward path selection. In the case of non-storing nodes the root
would calculate the downward paths that would diverge not from the root but
a node(s) further down the tree.



Thomas

On 4/27/2010 2:11 PM, Roger Alexander wrote: 

Hi Pascal,
 
Please find attached an expanded note on the DAO fan out control and path
prioritization mechanism.
 
Roger
 
  

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Monday, April 19, 2010 11:35 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: RE: [Roll] DAO fan out
 
Hi Roger:
 
At high level I'm very positive on the mechanism .
 
What I'd wish to see from the list is more people:
- agreeing that the fan out MUST be solved
    

For large scale networks it is important to have some mechanism to bound
downward paths once nodes can maintain multiple DAO parents. It will be up
to the WG of course but after having introduced multiple DAO parents,
leaving paths unconstrained introduces a potentially uncontrolled element of
the protocol that can affect scalability; as networks become larger the
potential vulnerability increases. What is being recommended is a 1-byte
information element per DAO Destination Address. While incurring some
additional overhead path control can be disabled (bitmap set to all zeros)
for networks in which only a single DAO parent per node is maintained or
that not wish to implement constraints on path fan out or to differentiate
preferred downward paths.
 
  

- that this is a simple and efficient solution
    

Yes it would be good to get feedback from others on any concerns they may
have.
 
  

- that the solution can be incorporated in 08
 
Maybe what would help from you Roger is:
- a visual example on the mechanism as work (if you have a pdf
illustrating it?)
    

Note plus a few examples attached (pdf and MS Word).
 
  

- some more explanation on the source route case (how the root can play
the same game recursively and obtain a good result as well)
    

Based on the current -07 source route specification, non-storing nodes will
follow the same operation as storing nodes in using the Path Control byte to
determine the number and selection of DAO parents through which the reverse
route stack is built. 
 
If the source route specification is changed to the more recent proposal
from Richard, the Path Control byte can still apply to the advertised DAO
Destination Address and will be associated with each of the selected DAO
Parents communicated to the root. As in the case of storing nodes, each DAO
Destination Address will have a different Path Control byte for each
selected DAO Parent. For the source route case the root will be able to use
the Path Control preference associated with each selected DAO Parent to
recursively determine the preferred downward path to a given target address.
That is, at the root, the preferred downward path to a given target address
begins with the target's preferred DAO parent as given by the Path Control
byte. From that preferred DAO Parent the link to the next preferred DAO
ancestor is added until the complete preferred path is derived. The root
will also be capable of deriving all the potential path combinations to a
target node. 
 
As I currently understand the new proposal it is not clear that non storing
nodes have any ability to control path fan out (and the consequently
increased reverse route processing at the root) when nodes maintain multiple
DAO Parents.
   
  

Could you please so that for us?
 
Thanks a bunch,
 
Pascal
 
 
    

-----Original Message-----
From: Roger Alexander [mailto:roger.alexander@ekasystems.com]
Sent: Friday, April 16, 2010 11:32 PM
To: Pascal Thubert (pthubert); Navneet Agarwal (navagar); 'JP
      

Vasseur';
    

wintert@acm.org
Cc: 'ROLL WG'
Subject: RE: [Roll] DAO fan out (was:] IPSO Interop event - Feed-back
welcome)
 
Below is a quick summary aligned to Tim's concept of how the Path
      

Control
    

bitmap associated with the DAO destination address can be used to
      

limit fan
    

out and to identify the preferred path when nodes maintain multiple
      

DAO
    

Parents.
 
Further details and examples can be provided as part of an larger
application domain note.
 
Roger
 
      

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, April 13, 2010 3:47 AM
To: Roger Alexander; Navneet Agarwal (navagar); JP Vasseur;
wintert@acm.org
Cc: ROLL WG
Subject: DAO fan out (was:] IPSO Interop event - Feed-back welcome)
 
 
 
Pascal
 
        

One consequence of maintaining multiple DAO parents is the
          

potential
    

fan
        

out of routing paths. With path fan out a node may have multiple
          

downward
        

next hop addresses for a given target destination address.
          

Without
    

some
        

path preference indication there is no information available if a
          

storing node
        

(including the root) wishes to limit the number of downward next
          

hops
    

maintained for a given address. It is thus desirable to have some
          

means of
        

path control to limit fan out as well as a preference indication
          

that
    

can work in
        

conjunction with the hop-by-hop DAO exchanges.
 
See the Figure below for an example in which nodes maintain two
          

DAO
    

Parents each, where in the worst case the fan out that occurs
          

after
    

three
        

hops results in eight next hop downward paths from the DODAG root
          

(LBR)
        

to a target node (41). Even with the hop-by-hop DAO mechanism it
          

would
be
        

desirable to be able to limit fan out as well as to identify path
          

preference and
        

diversity at the root or other intermediate storing node.
 
                    (------------LBR------------)
                    /    /   / |     | \    \   \
                   /    /   /  |     |  \    \   \
                  /    /   /   |     |   \    \   \
                 /    /   /    |     |    \    \   \
              (11) (12) (13) (14)   (15) (16) (17) (18)
                 \   |    |    /     \    |    |   /
                  \  |    |   /       \   |    |  /
                   \ |    |  /         \  |    | /
                  (21)   (22)           (23)  (24)
                      \    |            |    /
                       \   |            |   /
                        \  |            |  /
                         (31)          (32)
                             \        /
                              \      /
                               \    /
                                (41)
 
          

[Pascal] Your schema illustrates clearly that even if we fan out a
        

lot,
    

it does not mean that a router on the way down will have more
        

feasible
    

successors.
 
That's one thing that's important to remember, the properties of
        

the
    

DAG
are not symmetrical, so even if we build it to get multiple
        

feasible
    

successors on the way up, that does not mean that on the reverse
        

DAG
to
    

a target there are multiple successors at each hop towards that
        

target.
    

In other words, the ROI of fanning out is not guaranteed if we do
        

it
    

blindly.
 
        

A simple path control bitmap associated with the advertised
          

Destination
        

Address can be included within the DAO to address the issue of
          

path
    

preference as well as control of fan out. For a network of
          

'non-storing'
        

nodes the preference indication would be processed only at the
          

root.
    

[Pascal] so far so good, but that will give you a blind mechanism.
 
        

With the path control byte associated with each DAO destination
          

address, a
        

node will be able to specify preference among DAO parent paths
          

and
    

can
        

convey limits on the number of downward paths. This is an
          

opportunity
    

for
        

nodes to further influence the downward paths that are
          

established
    

and
        

maintained. Consistent with the DV-based RPL operation this DAO
          

path
    

control mechanism must operate hop-by-hop avoiding any
          

requirement
    

for
        

end-to-end path coordination. To avoid overloading this email
          

thread
    

I
will
        

initiate a separate discussion on how a path control element may
          

be
    

included
        

within the DAO.
 
          

[Pascal] Too late, I just did :)
 
And if I remember, Tim's idea was to control the stretch of the
        

fanout,
    

by decrementing a counter as the path loses preference point.
At the moment, we have a parent preference 0-lowest to 3 highest.
        

So
it
    

is easy to decrement a counter by (3-pref) and not fan out when the
counter reaches 0.
Tim, could you elaborate on this?
        

A Path Control bit map will achieve an equivalent control mechanism
whereby
at each node the number of bits that are set will determine the
      

extent
to
    

which the associated DAO Destination Address can be advertised to
      

multiple
    

DAO Parents. If a DAO message destination address Path Control bitmap
      

has
    

4
set bits, that address can be send along a maximum of 4 paths. For
      

example,
    

at the originating node the DAO can be sent to two DAO Parents where
      

the
    

Path Control bit map in the message sent to each DAO Parent will have
      

two
    

set bits. If each parent then advertises to two DAO Parents a single
      

bit is
    

set for each DAO message. Eventually with a single bit set in the
      

Path
    

Control bit map, the DAO message can be advertised only to a single
      

DAO
    

Parent. This mechanism achieves the effect of limiting the stretch of
      

the
    

path fan out. Where multiple DAO messages are received at a common
ancestor
the number of set bits in the respective Path Control fields are
      

recombined
    

allowing for renewed advertising of the DAO message destination
      

address to
    

multiple DAO Parents along the path.
 
As the set Path Control bits are split and recombined as the DAO
      

messages
    

are transferred to the root, their bit positions are maintained. This
      

allows
    

bit positions to be ordered from low to high in terms of path
      

preference.
    

Therefore when a DAO message is received in which the Path Control
      

bitmap
    

has the highest preference bit set, that DAO message destination
      

address is
    

always advertised to the preferred DAO Parent. Similarly, when a
      

message is
    

received with multiple Path Control bits set, the DAO messages can be
distributed to DAO Parents according to parent preference. This will
      

ensure
    

that at any common ancestor, including the root, a node is always
      

able
to
    

distinguish the preferred downward path. The ability to determine the
preferred downward path as well as to obtain an indication of path
      

diversity
    

will allow the Path Control field to be used when resource
      

limitations
at a
    

node require a truncation of the number of downward paths that the
      

node
    

maintain for a given destination address.
 
      

Pascal
        

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

 

 


------=_NextPart_000_031B_01CAE7C8.1528EEC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













    


    Hi Thomas,
    


     
    


    Still mulling the interesting results of your simulation =
and the
potential implications. A couple further thoughts, particularly as it =
relates
to the ‘disjointness’ measure…
    


     
    


    1.      
While ‘disjointness’ as you have defined it =
does
capture some measure of the independence of paths, it may not be =
adequately
reflecting the increased path availability that results from multiple =
DAO
Parents. That is, it is possible for disjointedness to remain the same =
or even
fall while the end-to-end path availability goes up. See a simple =
example
below. This raises the question of whether it would be better to more =
directly
capture path availability in the simulated data.
    


    2.      
An artifact of the network model is that the node degree =
is the
same for all nodes including the root. This means that regardless of =
fan-out,
the paths to/from the root will converge based on node degree. More
importantly, paths from the target node all converge according to the =
number of
assumed DAO Parents. The way disjointness is calculated, each new fanout =
path
adds a common link count based on the node-DAO Parent link from which =
the path
emerged. This is not a problem in itself, but the node-parent links and =
a
common ancestor-root link get counted in the number of common links for =
each link
fan out occurring in between. This may be having some effect on =
compressing the
resulting disjointness measure.
    


     
    


    A simple example to try to clarify these thoughts. =
Consider a
downward path between an LBR root node and a node A given by A-B-C-LBR.
Disjointness is of course 1 (3/3). Add a second completely independent =
path given
by A-E-F-LBR. Here the disjointness of the two paths is again 1 (6/6, =
all links
remain disjoint). However the path availability to node A has increased =
(all
links equally available, it has doubled). If a third path is added via a =
third
DAO Parent given by A-H-F-LBR. The disjointed measure has fallen to =
(7/9) even
though the availability of the connection from A to the LBR has =
increased. If a
fourth DAO parent is added to offer a path given by A-J-B-C-LBR, the =
disjointed
measure falls further to (7/13) even as the path availability from the =
LBR root
to node A has improved due to the additional diversity along the path =
from B-A.
What this seems to be implying is that even as disjointness is capturing =
some
measure of reduced path independence, it may not be adequately capturing =
the improved
path availability potential. Let me know if I have accurately =
characterized the
measure.
    


     
    


     What we will try to do as well in the coming weeks =
is to analyze
some sample field network data to see how additional DAO parents would =
affect
downward path availability.
    


     
    


    Roger
    


     
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf Of Thomas Watteyne
    
Sent: Thursday, April 29, 2010 2:26 PM
    
To: roll@ietf.org
    
Subject: Re: [Roll] Fwd: Re: DAO fan out
    


    


    


     
    


    Hi Roger,
    
Thanks for the clear answers. I'm eager to see what people on the list =
think.
    
Thomas
    

    
On 4/29/2010 10:40 AM, Roger Alexander wrote: 
    


    Hi Thomas,
    


     
    


    Thanks for the feedback and the simulation =
results.
    


     
    


    


    


    


    From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] =
On
Behalf Of Thomas Watteyne
    
Sent: Wednesday, April 28, 2010 10:02 PM
    
To: roll@ietf.org
    
Subject: [Roll] Fwd: Re: DAO fan out
    


    


    


     
    


    Roger,
    

    
Having a single byte for fan-out control and prioritization of =
downstream
paths is elegant. It reminds me of the (academic) GRAdient Broadcast =
protocol.
I have a couple of questions, though.
    

    
1) Is this a technique you (or others on the list) have experience =
with? If
it's a proven technique, I'm glad to learn about it, and the WG will =
have more
confidence adopting it.
    


    [RA] No this is not a proven or deployed technique. The =
proposal
is based on a concern that arises from our deployed networks where =
single root
nodes do support a network of thousands of nodes. Once multiple DAO =
parents are
entertained for downward routing availability, routing scalability can =
be
affected if DAO exchanges are left  unbounded. Furthermore, there =
will need
to be a means of extracting the preferred downward path and selecting =
from the
many alternatives that can result.
    



    

    
2) I have some questions related to path convergence, which relates =
to the
following paragraph in your text:
    

    
"An intermediate node may receive DAO messages from multiple =
children
nodes
    
that advertise reachability to a given Destination Address. Where =
the total
    
number of set Path Control bits is greater than the number of DAO =
Parents
the
    
bitmaps for the DAO messages will be merged. This merging of set =
bits will
    
allow for subsequent fan out at subsequent ancestor =
nodes."
    

    
This is, if I receive DAOs with [00000110] and [00000001] from two =
of my
children, I have [00000111] to play with, which I can redistribute (or
re-"fan out" if you want) across my DAO Parents. Does that =
mean that,
every time I receive a DAO, I buffer it for some time in case I can =
merge it
with a later one? If yes, how do I choose the duration to wait? If I =
decide to
retransmit DAO's ASAP, and never merge them, what are the implications? =
As you
may understand, I'm not a very big fan of the idea of "buffering =
for some
time"...
    


    [RA] The note was written from the perspective of a =
network with
all storing nodes. For storing nodes, DAO advertisements and made and =
updated
based on the validity period of the received Destination Address routing
updates. It that context the issue of buffering is well defined. There =
is
however an issue of dealing with the sequence of DAO advertisements that =
will
be received at different intervals that may require subsequent change in =
the
selected DAO Parent. To maintain the requirement that the preferred path =
can
always be determined, there may be periods during which fewer DAO =
Parents are
selected than may be otherwise available at a given intermediate node =
(future
consideration required).
    


     
    


    [RA] For non storing nodes, based on my understanding of =
the
currently discussed proposal, the situation is simpler in that the =
originating
owner of the Destination Address establishes the preference and includes =
the
applicable Path Control setting with the different DAO Parents selected. =
Each
node selects its DAO Parents and indicates the preference of each. Each
node’s information needs only to be available at the root which =
then
computes all downward paths. The onus for scalability in processing the
downward path routing is placed on the root node – with processing
requirements increasing with the number of DAO Parents. However, all the
information is available for global determination of preferred, as well =
as secondary
downward paths. 
    



    

    
I have taken a few minutes to verify that during fan-out, you should
control the parent selection (http:/=
/www.eecs.berkeley.edu/~watteyne/disjointness.pdf).
It tells you that, if two DAOs copies are sent towards the LBR, and each =
node
en-route can select its DAO parent randomly, the two obtained routes =
will not
be disjoint. That is, if one path fails, changes are the second will =
also as
they share many links.
    


    [RA] Thanks. This is an interesting result, caveats
notwithstanding. I would like to digest a bit further and get back to =
you. The
benefit of multiple DAO Parents is predicated on the downward diversity =
that it
provides. The cost of multiple DAO Parents and fan out is that it can =
negate
some of RPL’s routing scalability benefits (for storing nodes). If =
as the
results suggest multiple DAO Parents does not provide a meaningful path
availability gain then its utility is somewhat diminished. =

    



    

    
3) Similar to Fig.5, consider fan-out and convergence causes the LBR =
to
receive two routes [00000001] and [00000110]. Which one will is prefer? =
Sure,
[00000001] has traveled through all the best DAO parents, but wouldn't
[00000110] offer me path diversity?
    


    [RA] Yes, diversity information may be derived from the =
path
Control and can be used as a selection criteria when making a choice of
downward path. That would be an implementation choice. =

    



    

    
Similarly, what happens if the LBR has only one link to the rest of =
the
network? If I read you text correctly, it will receive one packet with
[111111111]. If I am missing something, please do tell =
me.
    


    [RA] If that were the case the LBR would indeed receive =
one
packet with [11111111].  However the collective path information =
would be
available to the single node that connects to the LBR. That node, and =
all other
intermediate (storing) nodes, use the available path control information =
to
support downward path selection. In the case of non-storing nodes the =
root
would calculate the downward paths that would diverge not from the root =
but a
node(s) further down the tree.
    



    

    
Thomas
    

    
On 4/27/2010 2:11 PM, Roger Alexander wrote: 
    


    Hi Pascal,
     
    Please =
find attached an expanded note on the DAO fan out control and =
path
    prioritization =
mechanism.
     
    Roger
     
      
    


    -----Original =
Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Monday, April 19, 2010 11:35 =
AM
    To: Roger Alexander; Navneet Agarwal (navagar); =
JP Vasseur;
    wintert@acm.org
    =
Cc: ROLL WG
    Subject: RE: [Roll] DAO fan =
out
     
    Hi =
Roger:
     
    At high level =
I'm very positive on the mechanism =
.
     
    What I'd wish to see =
from the list is more people:
    - agreeing that the =
fan out MUST be solved
        =

    


    For large scale networks it is important to have some mechanism to =
bound
    downward paths once nodes can maintain =
multiple DAO parents. It will be up
    to the WG of =
course but after having introduced multiple DAO =
parents,
    leaving paths unconstrained introduces a =
potentially uncontrolled element of
    the protocol =
that can affect scalability; as networks become larger =
the
    potential vulnerability increases. What is =
being recommended is a 1-byte
    information element =
per DAO Destination Address. While incurring =
some
    additional overhead path control can be =
disabled (bitmap set to all zeros)
    for networks in =
which only a single DAO parent per node is maintained =
or
    that not wish to implement constraints on path =
fan out or to differentiate
    preferred downward =
paths.
     
      =

    


    - that =
this is a simple and efficient =
solution
        =

    


    Yes it would be good to get feedback from others on any concerns =
they =
may
    have.
     
      
    


    - that =
the solution can be incorporated in =
08
     
    Maybe what would =
help from you Roger is:
    - a visual example on the =
mechanism as work (if you have a pdf
    illustrating =
it?)
        =

    


    Note plus a few examples attached (pdf and MS =
Word).
     
      =

    


    - some =
more explanation on the source route case (how the root can =
play
    the same game recursively and obtain a good =
result as well)
        =

    


    Based on the current -07 source route specification, non-storing =
nodes will
    follow the same operation as storing =
nodes in using the Path Control byte to
    determine =
the number and selection of DAO parents through which the =
reverse
    route stack is built. =

     
    If the source route =
specification is changed to the more recent =
proposal
    from Richard, the Path Control byte can =
still apply to the advertised DAO
    Destination =
Address and will be associated with each of the selected =
DAO
    Parents communicated to the root. As in the =
case of storing nodes, each DAO
    Destination Address =
will have a different Path Control byte for =
each
    selected DAO Parent. For the source route case =
the root will be able to use
    the Path Control =
preference associated with each selected DAO Parent =
to
    recursively determine the preferred downward =
path to a given target address.
    That is, at the =
root, the preferred downward path to a given target =
address
    begins with the target's preferred DAO =
parent as given by the Path Control
    byte. From that =
preferred DAO Parent the link to the next preferred =
DAO
    ancestor is added until the complete preferred =
path is derived. The root
    will also be capable of =
deriving all the potential path combinations to =
a
    target node. =

     
    As I currently =
understand the new proposal it is not clear that non =
storing
    nodes have any ability to control path fan =
out (and the consequently
    increased reverse route =
processing at the root) when nodes maintain =
multiple
    DAO =
Parents.
       =

      
    


    Could =
you please so that for =
us?
     
    Thanks a =
bunch,
     
    Pascal=

     
     
     =
   
    


    -----Original =
Message-----
    From: Roger Alexander [mailto:roger.alexander@eka=
systems.com]
    Sent: Friday, April 16, 2010 11:32 =
PM
    To: Pascal Thubert (pthubert); Navneet Agarwal =
(navagar); 'JP
          =

    


    Vasseur';
        
    


    wintert@acm.org
    =
Cc: 'ROLL WG'
    Subject: RE: [Roll] DAO fan out =
(was:] IPSO Interop event - =
Feed-back
    welcome)
     <=
/o:p>
    Below is a quick summary aligned to Tim's concept of how =
the Path
          =

    


    Control
        
    


    bitmap =
associated with the DAO destination address can be used =
to
          =

    


    limit fan
        
    


    out and =
to identify the preferred path when nodes maintain =
multiple
          =

    


    DAO
        
    


    Parents.
     
    Further details and examples can be =
provided as part of an larger
    application domain =
note.
     
    Roger
     
          =

    


    -----Original =
Message-----
    From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Tuesday, April 13, 2010 3:47 =
AM
    To: Roger Alexander; Navneet Agarwal (navagar); =
JP Vasseur;
    wintert@acm.org
    =
Cc: ROLL WG
    Subject: DAO fan out (was:] IPSO =
Interop event - Feed-back =
welcome)
     
     
     
    Pascal
    &nbs=
p;
            =

    


    One =
consequence of maintaining multiple DAO parents is =
the
            =
  
    


    


    


    potential
        
    


    


    fan
    <=
pre>        
    


    out of =
routing paths. With path fan out a node may have =
multiple
           &=
nbsp;  
    


    downward
          &n=
bsp; 
    


    next hop =
addresses for a given target destination =
address.
         =
     
    






    Without
        
    


    


    some
    =

            
    


    path =
preference indication there is no information available if =
a
            &n=
bsp; 
    


    storing =
node
            =

    


    (including the root) =
wishes to limit the number of downward =
next
            =
;  
    


    


    


    hops
        
    


    


    


    maintained for a =
given address. It is thus desirable to have =
some
            =
;  
    


    means =
of
            =

    


    path =
control to limit fan out as well as a preference =
indication
           =
;   
    


    


    


    that
        
    


    


    can work =
in
            =

    


    conjunction with the =
hop-by-hop DAO =
exchanges.
     
    See the =
Figure below for an example in which nodes maintain =
two
            =
  
    


    


    


    DAO
        
    


    


    


    Parents =
each, where in the worst case the fan out that =
occurs
           &nb=
sp;  
    


    


    


    after
        
    


    


    three
            
    


    hops =
results in eight next hop downward paths from the DODAG =
root
            =
;  
    


    (LBR)
           =
; 
    


    to a =
target node (41). Even with the hop-by-hop DAO mechanism =
it
            &=
nbsp; 
    


    would
    be
       =
;     
    


    desirable to be able =
to limit fan out as well as to identify =
path
            =
;  
    


    preference =
and
            =

    


    diversity at the =
root or other intermediate storing =
node.
     
       =
            &=
nbsp;    =
(------------LBR------------)
       &nbs=
p;            =
;    /    /   / =
|     | \    \   =
\
            &n=
bsp;          =
/    /   /  |     =
|  \    \   =
\
            &n=
bsp;         /    =
/   /   |     |   =
\    \   =
\
            &n=
bsp;        /    =
/   /    |     |  =
  \    \   =
\
            &n=
bsp;     (11) (12) (13) (14)   (15) (16) =
(17) =
(18)
            =
;         \   =
|    |    /     =
\    |    |   =
/
            &n=
bsp;         \  =
|    |   /       =
\   |    |  =
/
            &n=
bsp;          \ =
|    |  =
/         \  =
|    | =
/
            &n=
bsp;         (21)   =
(22)  =
         (23)  =
(24)
            =
;            =
  \    =
|            =
|    =
/
            &n=
bsp;           &nb=
sp;  \   =
|            =
|   =
/
            &n=
bsp;           &nb=
sp;   \  =
|            =
|  =
/
            &n=
bsp;           &nb=
sp;    =
(31)          =
(32)
            =
;            =
         =
\        =
/
            &n=
bsp;     =
            &=
nbsp;   \      =
/
            &n=
bsp;           &nb=
sp;          =
\    =
/
            &n=
bsp;           &nb=
sp;           =
(41)
     
       &=
nbsp;      
    


    [Pascal] Your schema illustrates clearly that even if we fan out =
a
            =

    


    


    lot,
        
    


    


    it does =
not mean that a router on the way down will have =
more
            =

    


    


    feasible
        
    


    


    successors.
     
    That's one thing that's =
important to remember, the properties =
of
            =

    


    


    the
        
    


    


    DAG
    <=
pre>are not symmetrical, so even if we build it to get =
multiple
            =

    


    


    feasible
        
    


    


    successors on the =
way up, that does not mean that on the =
reverse
            =

    


    


    DAG
    to
        =

    


    


    a target =
there are multiple successors at each hop towards =
that
            =

    


    


    target.
        
    


    


    In other =
words, the ROI of fanning out is not guaranteed if we =
do
          =
  
    


    


    it
        
    


    


    blindly.
     
          =
  
    


    A simple =
path control bitmap associated with the =
advertised
           =
;   
    


    Destination
          =
;  
    


    Address =
can be included within the DAO to address the issue =
of
            &=
nbsp; 
    


    


    


    path
        
    


    


    


    preference as well =
as control of fan out. For a network =
of
            &=
nbsp; 
    


    'non-storing'
         &nb=
sp;  
    


    nodes =
the preference indication would be processed only at =
the
            =
  
    


    


    


    root.
        
    


    


    [Pascal] =
so far so good, but that will give you a blind =
mechanism.
     
      &=
nbsp;     
    


    With the =
path control byte associated with each DAO =
destination
          &nbs=
p;   
    


    address, =
a
            =

    


    node =
will be able to specify preference among DAO parent =
paths
           &nbs=
p;  
    


    


    


    and
        
    


    


    can
    <=
pre>        


    convey =
limits on the number of downward paths. This is =
an
           =
   
    


    


    


    opportunity
        =

    


    


    for
    <=
pre>        


    nodes to =
further influence the downward paths that =
are
            =
  
    


    


    


    established
        =

    


    


    and
    <=
pre>        


    maintained. =
Consistent with the DV-based RPL operation this =
DAO
            =
  
    


    


    


    path
        
    


    


    


    control =
mechanism must operate hop-by-hop avoiding =
any
            =
  
    


    


    


    requirement
        =

    


    


    for
    <=
pre>        


    end-to-end path =
coordination. To avoid overloading this =
email
           &nbs=
p;  
    


    


    


    thread
        
    


    


    I
    will
            =

    


    initiate =
a separate discussion on how a path control element =
may
            =
  
    


    


    


    be
        
    


    


    included
            
    


    within =
the =
DAO.
     
       &=
nbsp;      
    


    [Pascal] Too late, I just did =
:)
     
    And if I remember, =
Tim's idea was to control the stretch of =
the
            =

    


    


    fanout,
        
    


    


    by =
decrementing a counter as the path loses preference =
point.
    At the moment, we have a parent preference =
0-lowest to 3 =
highest.
            =

    


    


    So
    it
        =

    


    


    is easy =
to decrement a counter by (3-pref) and not fan out when =
the
    counter reaches 0.
    Tim, =
could you elaborate on =
this?
            =

    


    A Path Control bit map will achieve an equivalent control =
mechanism
    whereby
    at each node =
the number of bits that are set will determine =
the
          =

    


    extent
    to
      &nbs=
p; 
    


    which =
the associated DAO Destination Address can be advertised =
to
          =

    


    multiple
        
    


    DAO =
Parents. If a DAO message destination address Path Control =
bitmap
          =

    


    has
        
    


    4
    set bits, that address can be send along a maximum of 4 paths. =
For
          =

    


    example,
        
    


    at the =
originating node the DAO can be sent to two DAO Parents =
where
          =

    


    the
        
    


    Path =
Control bit map in the message sent to each DAO Parent will =
have
          =

    


    two
        
    


    set =
bits. If each parent then advertises to two DAO Parents a =
single
          =

    


    bit is
        
    


    set for =
each DAO message. Eventually with a single bit set in =
the
          =

    


    Path
        
    


    Control =
bit map, the DAO message can be advertised only to a =
single
          =

    


    DAO
        
    


    Parent. =
This mechanism achieves the effect of limiting the stretch =
of
          =

    


    the
        
    


    path fan =
out. Where multiple DAO messages are received at a =
common
    ancestor
    the number of =
set bits in the respective Path Control fields =
are
          =

    


    recombined
       =
 
    


    allowing =
for renewed advertising of the DAO message =
destination
          =

    


    address to
        =

    


    multiple =
DAO Parents along the =
path.
     
    As the set Path =
Control bits are split and recombined as the =
DAO
          =

    


    messages
        
    


    are =
transferred to the root, their bit positions are maintained. =
This
          =

    


    allows
        
    


    bit =
positions to be ordered from low to high in terms of =
path
          =

    


    preference.
        =

    


    Therefore when a DAO =
message is received in which the Path =
Control
          =

    


    bitmap
        
    


    has the =
highest preference bit set, that DAO message =
destination
          =

    


    address is
        =

    


    always =
advertised to the preferred DAO Parent. Similarly, when =
a
          =

    


    message is
        =

    


    received =
with multiple Path Control bits set, the DAO messages can =
be
    distributed to DAO Parents according to parent =
preference. This =
will
          =

    


    ensure
        
    


    that at =
any common ancestor, including the root, a node is =
always
          =

    


    able
    to
       =
 
    


    distinguish the =
preferred downward path. The ability to determine =
the
    preferred downward path as well as to obtain an =
indication of path
          =

    


    diversity
        
    


    will =
allow the Path Control field to be used when =
resource
          =

    


    limitations
    at =
a
        
    


    node =
require a truncation of the number of downward paths that =
the
          =

    


    node
        
    


    maintain =
for a given destination =
address.
     
      &nb=
sp;   
    


    Pascal
            =

    


    


    > 
     
    ________=
_______________________________________
    Roll =
mailing list
    Roll@ietf.org
    https://www.ietf.org/=
mailman/listinfo/roll
    


     
    


    


     
    


    


    





------=_NextPart_000_031B_01CAE7C8.1528EEC0--


From gnawali@cs.stanford.edu  Thu Apr 29 19:27:54 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D451C3A67A4 for ; Thu, 29 Apr 2010 19:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.445
X-Spam-Level: 
X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCZHUNPcnsuE for ; Thu, 29 Apr 2010 19:27:53 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DEBDD3A6765 for ; Thu, 29 Apr 2010 19:27:53 -0700 (PDT)
Received: from mail-gw0-f44.google.com ([74.125.83.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O7fx6-0000Zv-B3 for roll@ietf.org; Thu, 29 Apr 2010 19:27:40 -0700
Received: by gwaa12 with SMTP id a12so5004321gwa.31 for ; Thu, 29 Apr 2010 19:27:39 -0700 (PDT)
Received: by 10.150.159.15 with SMTP id h15mr650159ybe.27.1272594458258; Thu,  29 Apr 2010 19:27:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.11.9 with HTTP; Thu, 29 Apr 2010 19:27:17 -0700 (PDT)
From: Omprakash Gnawali 
Date: Thu, 29 Apr 2010 19:27:17 -0700
Message-ID: 
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1
X-Scan-Signature: 361e41f17a936014d5971e9dffa805f4
Subject: [Roll] Some results on reducing control overhead using Trickle's suppression mechanism
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 02:27:55 -0000

I did some experiments to understand how different settings for the
redundancy constant impacts control overhead of CTP. Here are my
notes:

http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html

- om_p

From privateanand@gmail.com  Thu Apr 29 21:36:50 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C603A68AC for ; Thu, 29 Apr 2010 21:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Qwwjo8-9I9 for ; Thu, 29 Apr 2010 21:36:49 -0700 (PDT)
Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 5A38B3A677C for ; Thu, 29 Apr 2010 21:36:49 -0700 (PDT)
Received: by iwn29 with SMTP id 29so12744488iwn.17 for ; Thu, 29 Apr 2010 21:36:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=3Cldlpot3lUWjoWTZN1aW8FXC1BBCpUduyTn+q2/VY0=; b=nCNvH3FypZJpH2tDXLU5oVFmMUTuj5DzngZi4YPcMOzHmyXd7d9MzanhS3NvwXgwvU dKjB5WQTWchzpYRZ+EheF8R5uiwAEkXYEJ/dFzHLmnlQin+JU1t//DOINgsizZBM0FYE AHITMYlBVni50Xt+alF5HgEBypRkCpfHbCuzk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ufRvJ01+cnQLFN34IRWsFfiiSsMuqtoFQhsVA+7eYCUNBJpkIPtu7mnKwQjVv3mlsP L3kiJqfW028tZZyS2fNQZE30bX52Le/HjBlbYK29mLc8NHKvej/d4N4emESKyvVBEmYx 7Yc2OxTHbkcy9VEqf+CHuxYxs/N+AaJUpLQRM=
MIME-Version: 1.0
Received: by 10.231.176.74 with SMTP id bd10mr326371ibb.97.1272602193084; Thu,  29 Apr 2010 21:36:33 -0700 (PDT)
Received: by 10.231.151.205 with HTTP; Thu, 29 Apr 2010 21:36:33 -0700 (PDT)
In-Reply-To: <-6403192417562817879@unknownmsgid>
References: <4BD8E89C.9020809@eecs.berkeley.edu> <02dc01cae7c3$0023b6e0$006b24a0$%alexander@ekasystems.com> <4BD9CF1E.20708@eecs.berkeley.edu> <-6403192417562817879@unknownmsgid>
Date: Fri, 30 Apr 2010 00:36:33 -0400
Message-ID: 
From: "M. B. Anand" 
To: roll@ietf.org
Content-Type: multipart/alternative; boundary=0016363b8c10a8c40004856cc942
Subject: Re: [Roll] Fwd: Re: DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 04:36:51 -0000

--0016363b8c10a8c40004856cc942
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Roger,

> 1.       While =91disjointness=92 as you have defined it does capture som=
e
> measure of the independence of paths, it may not be adequately reflecting
> the increased path availability that results from multiple DAO Parents. T=
hat
> is, it is possible
>

There are both overall path concerns and local concerns here. The
availability of a lot of alternatives at a given node along the path says
nothing about the overall path since there may be no edge-disjoint paths an=
d
everything may go through a single edge, so there are no independent paths
at all. On the other hand, you might argue that you do want to capture the
high availability of edges at a given node .

If you wish to get a measure of the overall situation over the whole
network, you might perhaps consider the formal notion of edge connectivity =
-
defined as the minimal number of edges that separates the graph, and
evaluate it for the whole graph with multiple parent situations and see if
it makes an overall difference. Would depend completely on the topology.

You could also do the same exercise on a per node basis, with a subgraph
consisting of all edges and included nodes in the LBR - x paths, where x is
each node, and evaluate the minimal number of edges that separates x from
LBR.

For example, in the first step you give in the example below, for LBR - A
paths, that number would 1. In the second step, it would be 2. In the third
step it would still be 2 (LBR - C and LBR - F still separates A from LBR.
Also, a useful graph theorem is that the minimal number of edges that
separates a vertex s from t is equal to the maximal number of edge-disjoint
s-t paths and clearly there are still only two edge-disjoint paths). In the
fourth step, it is still 2 - same as above.

This would be the situation for the overall A - LBR path.

If you wish to capture something about the fact that A has a lot of next ho=
p
choices by step 4 in your example, regardless of the A - LBR path, then you
could repeat the above exercise for each A - z path where z is each node in
the A - LBR paths, and arrive at a range of values. For example, 1 edge
separates A from F in step 2, but 2 edges separate it from F in step 3,
although the addition of A - H - F didn't do anything to improve the A - LB=
R
path. Thus, if you added several A - Hi - F, with i going from 1 to 50, the=
n
51 edges will separate A from F, thus capturing the high availability
between A and F, but again contributing nothing to the A - LBR path.

Regards,
Anand.

>
>
> A simple example to try to clarify these thoughts. Consider a downward pa=
th
> between an LBR root node and a node A given by A-B-C-LBR. Disjointness is=
 of
> course 1 (3/3). Add a second completely independent path given by A-E-F-L=
BR.
> Here the disjointness of the two paths is again 1 (6/6, all links remain
> disjoint). However the path availability to node A has increased (all lin=
ks
> equally available, it has doubled). If a third path is added via a third =
DAO
> Parent given by A-H-F-LBR. The disjointed measure has fallen to (7/9) eve=
n
> though the availability of the connection from A to the LBR has increased=
.
> If a fourth DAO parent is added to offer a path given by A-J-B-C-LBR, the
> disjointed measure falls further to (7/13) even as the path availability
> from the LBR root to node A has improved due to the additional diversity
> along the path from B-A. What this seems to be implying is that even as
> disjointness is capturing some measure of reduced path independence, it m=
ay
> not be adequately capturing the improved path availability potential. Let=
 me
> know if I have accurately characterized the measure.
>
>
>

Regards,
Anand.

--0016363b8c10a8c40004856cc942
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Roger,
    

    1.<=
span style=3D"font-family: "Times New Roman"; font-style: normal;=
 font-variant: normal; font-weight: normal; font-size: 7pt; line-height: no=
rmal; font-size-adjust: none; font-stretch: normal;">=A0=A0=A0=A0=A0=A0
While =91disjointness=92 as you have defined it does
capture some measure of the independence of paths, it may not be adequately
reflecting the increased path availability that results from multiple DAO
Parents. That is, it is possible 
    <=
br>There a=
re both overall path concerns and local concerns here. The availability of =
a lot of alternatives at a given node along the path says nothing about the=
 overall path since there may be no edge-disjoint paths and everything may =
go through a single edge, so there are no independent paths at all. On the =
other hand, you might argue that you do want to capture the high availabili=
ty of edges at a given node .
    

    If you wish to get a measure of the overall situation over the whole ne=
twork, you might perhaps consider the formal notion of edge connectivity - =
defined as the minimal number of edges that separates the graph, and evalua=
te it for the whole graph with multiple parent situations and see if it mak=
es an overall difference. Would depend completely on the topology. 
    

    You could also do the same exercise on a per node basis, with a subgrap=
h consisting of all edges and included nodes in the LBR - x paths, where x =
is each node, and evaluate the minimal number of edges that separates x fro=
m LBR.
    

    For example, in the first step you give in the example below, for LBR -=
 A paths, that number would 1. In the second step, it would be 2. In the th=
ird step it would still be 2 (LBR - C and LBR - F still separates A from LB=
R. Also, a useful graph theorem is that the minimal number of edges that se=
parates a vertex s from t is equal to the maximal number of edge-disjoint s=
-t paths and clearly there are still only two edge-disjoint paths). In the =
fourth step, it is still 2 - same as above. 
    

    This would be the situation for the overall A - LBR path.

    If you=
 wish to capture something about the fact that A has a lot of next hop choi=
ces by step 4 in your example, regardless of the A - LBR path, then you cou=
ld repeat the above exercise for each A - z path where z is each node in th=
e A - LBR paths, and arrive at a range of values. For example, 1 edge separ=
ates A from F in step 2, but 2 edges separate it from F in step 3, although=
 the addition of A - H - F didn't do anything to improve the A - LBR pa=
th. Thus, if you added several A - Hi - F, with i going from 1 to 50, then =
51 edges will separate A from F, thus capturing the high availability betwe=
en A and F, but again contributing nothing to the A - LBR path.
    

    Regards,
    Anand.
    

    =A0
    


    A simple example to try to clarify these thoughts. Consider a
downward path between an LBR root node and a node A given by A-B-C-LBR.
Disjointness is of course 1 (3/3). Add a second completely independent path=
 given
by A-E-F-LBR. Here the disjointness of the two paths is again 1 (6/6, all l=
inks
remain disjoint). However the path availability to node A has increased (al=
l
links equally available, it has doubled). If a third path is added via a th=
ird
DAO Parent given by A-H-F-LBR. The disjointed measure has fallen to (7/9) e=
ven
though the availability of the connection from A to the LBR has increased. =
If a
fourth DAO parent is added to offer a path given by A-J-B-C-LBR, the disjoi=
nted
measure falls further to (7/13) even as the path availability from the LBR =
root
to node A has improved due to the additional diversity along the path from =
B-A.
What this seems to be implying is that even as disjointness is capturing so=
me
measure of reduced path independence, it may not be adequately capturing th=
e improved
path availability potential. Let me know if I have accurately characterized=
 the
measure.
    


    =A0

    Regards,
    Anan=
d.
    

--0016363b8c10a8c40004856cc942--

From pthubert@cisco.com  Fri Apr 30 05:37:53 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D209C3A6C2A for ; Fri, 30 Apr 2010 05:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.049
X-Spam-Level: 
X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=0.691,  BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1JpOmdytuYe for ; Fri, 30 Apr 2010 05:37:52 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6BF563A6BB5 for ; Fri, 30 Apr 2010 05:37:51 -0700 (PDT)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAENs2kurR7Hu/2dsb2JhbACdH3GjfpoLhRIEjzU
X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208";a="221009423"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2010 12:37:37 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3UCbYBD014705; Fri, 30 Apr 2010 12:37:37 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 30 Apr 2010 14:37:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 Apr 2010 14:37:20 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01C467E2@XMB-AMS-107.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism
Thread-Index: AcroDNSIjtlALH2lQD+qfohQK/sAPAAUJ0sQ
References: 
From: "Pascal Thubert (pthubert)" 
To: "Omprakash Gnawali" , "ROLL WG" 
X-OriginalArrivalTime: 30 Apr 2010 12:37:21.0180 (UTC) FILETIME=[E0A40DC0:01CAE861]
Subject: Re: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 12:37:53 -0000

Hi Om:

By looking at your result, a value of k=3D10 strikes out as being the
straight diagonal before the curve reverses.

What's so special with it? Would it be the 'right' value for some
reasons?

Does that value change with the density in your simulation?

Thanks for this great work,

Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> Omprakash Gnawali
> Sent: Friday, April 30, 2010 4:27 AM
> To: ROLL WG
> Subject: [Roll] Some results on reducing control overhead using
> Trickle'ssuppression mechanism
>=20
> I did some experiments to understand how different settings for the
> redundancy constant impacts control overhead of CTP. Here are my
> notes:
>=20
> http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html
>=20
> - om_p
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

From Matteo.Paris@ember.com  Fri Apr 30 08:28:59 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722783A696F for ; Fri, 30 Apr 2010 08:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDa6L-z4Ssie for ; Fri, 30 Apr 2010 08:28:57 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4726A3A6902 for ; Fri, 30 Apr 2010 08:28:57 -0700 (PDT)
Received: from [192.168.81.79] ([192.168.81.79]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 11:31:57 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
Date: Fri, 30 Apr 2010 11:27:37 -0400
To: ROLL WG 
From: Matteo Paris 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-OriginalArrivalTime: 30 Apr 2010 15:31:57.0772 (UTC) FILETIME=[452D20C0:01CAE87A]
Subject: Re: [Roll] Some results on reducing control overhead using Trickle's suppression mechanism
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 15:28:59 -0000

Hi Om, thanks for this work.  I have some questions.

The two graphs seem to use different data sets.  For example, looking 
at the left bar graph for motelab for k = 10, it looks like about 10% 
suppression as compared with k = infinity.  But looking at the CDF 
plot, it looks like 50% suppression for k = 10.  The tutornet data 
does not fit either, and the CDF graph does not indicate whether it 
is Motelab or Tutornet data.  The CDF graph counts "beacons 
suppressed", whereas the bar graph counts "control packets sent". 
Are there control packets that are not beacons?  I would like to see 
both graphs for the same data set.

What is the density of these networks?  Is it uniform?

To get a true picture of the impact of beacon suppression on delivery 
ratios, the experiment must be done on many different networks with 
different densities and topologies.  In particular, networks with 
nonuniform density have a higher risk that beacon suppression will 
partition them.  We can't conclude from only two data points that 
"beacon suppression can be used to reduce control overhead without 
any negative impact on routing performance".

Matteo


At 7:27 PM -0700 4/29/10, Omprakash Gnawali wrote:
>I did some experiments to understand how different settings for the
>redundancy constant impacts control overhead of CTP. Here are my
>notes:
>
>http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html
>
>- om_p
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


From pal@cs.stanford.edu  Fri Apr 30 09:00:04 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25E428C0FC for ; Fri, 30 Apr 2010 09:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.07
X-Spam-Level: 
X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-1.071,  BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBjVjyo2kK+a for ; Fri, 30 Apr 2010 09:00:03 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2011C3A6AA5 for ; Fri, 30 Apr 2010 09:00:03 -0700 (PDT)
Received: from dnab4046d9.stanford.edu ([171.64.70.217]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O7sd2-0004Ah-QK; Fri, 30 Apr 2010 08:59:49 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01C467E2@XMB-AMS-107.cisco.com>
Date: Fri, 30 Apr 2010 08:36:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <6A2A459175DABE4BB11DE2026AA50A5D01C467E2@XMB-AMS-107.cisco.com>
To: Pascal Thubert (pthubert) 
X-Mailer: Apple Mail (2.1078)
X-Scan-Signature: f69c4e6b4bf914f22ae37cd490358bf0
Cc: ROLL WG 
Subject: Re: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 16:00:04 -0000

On Apr 30, 2010, at 5:37 AM, Pascal Thubert (pthubert) wrote:

> Hi Om:
>=20
> By looking at your result, a value of k=3D10 strikes out as being the
> straight diagonal before the curve reverses.

I'm confused -- it seems to me that 5 is the local minimum, and 3 goes =
up a bit. What do you mean by "before the curve reverses"?

>=20
> What's so special with it? Would it be the 'right' value for some
> reasons?
>=20
> Does that value change with the density in your simulation?

These aren't simulations -- they are on two PAN testbeds that are =
publicly available, and which the CTP developers found especially useful =
after evaluating the protocol on 12 or so different ones. Tutornet on =
802.15.4 channel 26 is a very stable and easy topology.  Motelab is =
notable because some nodes are only very weakly connected (e.g., have =
outages for a minute or so). It is therefore useful to evaluate how a =
protocol behaves when the network is not carefully deployed or =
engineered. Om -- you should also try tutornet channel 16, to see how a =
k affects a brutally challenging network.

I would caution us from taking too strong a conclusion into these =
results, e.g., saying "5 seems to be the magic number." They are two =
short (1h) experiments in two testbeds. Confounds like time of day play =
into results on this scale.

Correlated with Jonathan Hui's extensive results on the ARC IP stack, I =
think this strongly demonstrates that setting k to a small integer (< =
10) does not harm datapath performance. Coming up with a strong =
recommendation on exactly what k should be requires more data and =
experimentation, though. When we roll out the next 300 powernet[1] nodes =
(the current 100 have been running CTP for 4 months with heavy =
instrumentation), maybe we can incorporate a firmware update that allows =
us to dynamically adjust k. We can then try week-long (or longer) trials =
with different values and see what happens.

Phil

[1] http://powernet.stanford.edu



From pthubert@cisco.com  Fri Apr 30 09:28:23 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80D03A6804 for ; Fri, 30 Apr 2010 09:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.198
X-Spam-Level: 
X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZUlchuRwQ9f for ; Fri, 30 Apr 2010 09:28:18 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B5F5A3A67C2 for ; Fri, 30 Apr 2010 09:28:16 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: image001.png : 13590
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisDAO6h2kuQ/uCWiWdsb2JhbABvT5tiFQEBAQoLEREGHKRZmg6FEgSPOA
X-IronPort-AV: E=Sophos;i="4.52,303,1270425600";  d="png'150?scan'150,208,217,150";a="60435253"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2010 16:28:01 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3UGS1pv025178; Fri, 30 Apr 2010 16:28:01 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 30 Apr 2010 18:28:01 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----_=_NextPart_001_01CAE882.19F55469"; type="multipart/alternative"
Date: Fri, 30 Apr 2010 18:28:01 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01C46916@XMB-AMS-107.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism
Thread-Index: Acrofj303ZMymvsgSd6ljPZN18Y+TwAAKuYg
References:  <6A2A459175DABE4BB11DE2026AA50A5D01C467E2@XMB-AMS-107.cisco.com> 
From: "Pascal Thubert (pthubert)" 
To: "Philip Levis" 
X-OriginalArrivalTime: 30 Apr 2010 16:28:01.0726 (UTC) FILETIME=[1A3FC5E0:01CAE882]
Cc: ROLL WG 
Subject: Re: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 16:28:23 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAE882.19F55469
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CAE882.19F55469"


------_=_NextPart_002_01CAE882.19F55469
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Phil

=20

=20

=20

In the image above, there's a value (close to K=3D10 in this case) where
the suppression is quasi linear. This looks like a local optimal so it
attracts my curiosity.

I'm wondering what the turn of concavity observed there means for the
operation in that network, and which network properties influence that
value.

=20

Cheers,

=20

Pascal

=20

=20

> -----Original Message-----

> From: Philip Levis [mailto:pal@cs.stanford.edu]

> Sent: Friday, April 30, 2010 5:36 PM

> To: Pascal Thubert (pthubert)

> Cc: Omprakash Gnawali; ROLL WG

> Subject: Re: [Roll] Some results on reducing control overhead using

> Trickle'ssuppression mechanism

>=20

>=20

> On Apr 30, 2010, at 5:37 AM, Pascal Thubert (pthubert) wrote:

>=20

> > Hi Om:

> >

> > By looking at your result, a value of k=3D10 strikes out as being =
the

> > straight diagonal before the curve reverses.

>=20

> I'm confused -- it seems to me that 5 is the local minimum, and 3 goes
up a

> bit. What do you mean by "before the curve reverses"?

>=20

> >

> > What's so special with it? Would it be the 'right' value for some

> > reasons?

> >

> > Does that value change with the density in your simulation?

>=20

> These aren't simulations -- they are on two PAN testbeds that are
publicly

> available, and which the CTP developers found especially useful after

> evaluating the protocol on 12 or so different ones. Tutornet on
802.15.4

> channel 26 is a very stable and easy topology.  Motelab is notable
because

> some nodes are only very weakly connected (e.g., have outages for a
minute

> or so). It is therefore useful to evaluate how a protocol behaves when
the

> network is not carefully deployed or engineered. Om -- you should also
try

> tutornet channel 16, to see how a k affects a brutally challenging
network.

>=20

> I would caution us from taking too strong a conclusion into these
results, e.g.,

> saying "5 seems to be the magic number." They are two short (1h)

> experiments in two testbeds. Confounds like time of day play into
results on

> this scale.

>=20

> Correlated with Jonathan Hui's extensive results on the ARC IP stack,
I think

> this strongly demonstrates that setting k to a small integer (< 10)
does not

> harm datapath performance. Coming up with a strong recommendation on

> exactly what k should be requires more data and experimentation,
though.

> When we roll out the next 300 powernet[1] nodes (the current 100 have

> been running CTP for 4 months with heavy instrumentation), maybe we
can

> incorporate a firmware update that allows us to dynamically adjust k.
We can

> then try week-long (or longer) trials with different values and see
what

> happens.

>=20

> Phil

>=20

> [1] http://powernet.stanford.edu =20

>=20

=20


------_=_NextPart_002_01CAE882.19F55469
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Hi =
Phil
     
     
    In the =
image above, there’s a value (close to K=3D10 in this case) where =
the suppression is quasi linear. This looks like a local optimal so it =
attracts my curiosity.
    I’m =
wondering what the turn of concavity observed there means for the =
operation in that network, and which network properties influence that =
value.
     
    Cheers,
     
    Pascal
     
     
    > =
-----Original Message-----
    > From: Philip Levis =
[mailto:pal@cs.stanford.edu]
    > =
Sent: Friday, April 30, 2010 5:36 PM
    > To: Pascal Thubert =
(pthubert)
    > Cc: =
Omprakash Gnawali; ROLL WG
    > Subject: Re: [Roll] Some results on reducing control overhead =
using
    > Trickle'ssuppression mechanism
    > 
    > 
    > On Apr 30, 2010, at 5:37 AM, Pascal Thubert =
(pthubert) wrote:
    > 
    > > Hi Om:
    > =
>
    > > By looking at your result, a =
value of k=3D10 strikes out as being the
    > =
> straight diagonal before the curve reverses.
    > 
    > I'm confused =
-- it seems to me that 5 is the local minimum, and 3 goes up a
    > bit. What do you mean by "before the =
curve reverses"?
    > 
    > >
    > > =
What's so special with it? Would it be the 'right' value for some
    > > reasons?
    > =
>
    > > Does that value change with =
the density in your simulation?
    > 
    > These aren't simulations -- they are on two =
PAN testbeds that are publicly
    > =
available, and which the CTP developers found especially useful =
after
    > evaluating the protocol on 12 or =
so different ones. Tutornet on 802.15.4
    > =
channel 26 is a very stable and easy topology.  Motelab is notable =
because
    > some nodes are only very weakly =
connected (e.g., have outages for a minute
    > or so). It is therefore useful to evaluate how =
a protocol behaves when the
    > network is =
not carefully deployed or engineered. Om -- you should also try
    > tutornet channel 16, to see how a k affects a =
brutally challenging network.
    > 
    > I would caution us from taking too strong a =
conclusion into these results, e.g.,
    > =
saying "5 seems to be the magic number." They are two short =
(1h)
    > experiments in two testbeds. =
Confounds like time of day play into results on
    > this scale.
    > =

    > Correlated with Jonathan Hui's =
extensive results on the ARC IP stack, I think
    > this strongly demonstrates that setting k to a =
small integer (< 10) does not
    > harm =
datapath performance. Coming up with a strong recommendation on
    > exactly what k should be requires more data =
and experimentation, though.
    > When we =
roll out the next 300 powernet[1] nodes (the current 100 have
    > been running CTP for 4 months with heavy =
instrumentation), maybe we can
    > =
incorporate a firmware update that allows us to dynamically adjust k. We =
can
    > then try week-long (or longer) =
trials with different values and see what
    > happens.
    > =

    > Phil
    > =

    > [1] http://powernet.stanford.=
edu
    > 
     
    
------_=_NextPart_002_01CAE882.19F55469--

------_=_NextPart_001_01CAE882.19F55469
Content-Type: image/png;
	name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Description: image001.png
Content-Location: image001.png

iVBORw0KGgoAAAANSUhEUgAAAWgAAAD8CAIAAADVB6ljAAAAAXNSR0IArs4c6QAANNBJREFUeF7t
nT0IN0e1/83/Vg8KuT7gW2KhRkG08SWIkosSULh2WviQNAFR/moK8YX4Uhkr9abSwqhglSZqYUTh
EbTQFAnKFbEQQR8lRSSCoEYt0vn/3Hz/9zjO7szO7M7OzO5vtvixu7/ZmTNnZs6ctznnpn/84x/P
GdfAwMDAwEAOBv5PTuFRdmBgYGBg4H8wMAjHmAcDAwMD2RgYhCMbZeODgYGBgUE4xhwYGBgYyMbA
IBzZKBsfDAwMDAzCMebAwMDAQDYGBuHIRtn4YGBgYGAQjjEHBgYGBrIxMAhHNsrGBwMDAwODcIw5
MDAwMJCNgUE4slE2PhgYGBg4HuF4xzveMYZtYGBgoC0GDkY4vvCFL/zwhz9si7LR+sDAwMBNRzkd
+6lPfQqS8bOf/YwxOwrMY3oNDJwVA4chHJCMP//5z/xCQQbhOOt0HP06CgaCogqr9Gtf+xrd+N3v
fnfbbbddvXpVu32r641vfOPb3/52flsBMNodGBgYMAwEOY5r165R6Jvf/CY7/POf/3xRDR7b4g5p
BeXoIsfxxBNPfO5znxOot95665UrV9qCPVofGOgQA08++eQzzzwDYK9+9as/+tGPZkEY5Di+9a1v
vec97xHH8clPfpJ73mRV3bAwVOPRRx9tCEBK09evX08p1rBMOoQ3btxIL1ywR7TLVbDCParaFTNU
vhEDv/rVrz72sY89+OCDeX1n9569qOUHP/gBf0Ey+OWeN6HC1d4ngvF/n72qQbWuIcjxug+rfZUO
4W9/+1vNlsoXjTZpN6ub6WjMqlaF6T7Itw+1QLJw8u1vf5tP+M1qPchxvOIVr0Au4OJGfAcCSx5N
GqWPjwHGnU5oJsgQzhsuPeqel5jJh39N/dEG+cgBGgJd6AFZ//ymA/Ob3/yGwvpNv4KEAzLJbEDT
wdZNdSa5pFfdsCR6Da6GAKQ0LcR2ezEdn376aeYAEEIUdHGPypxLj7rXyyYdQVnev758p4GGcIN2
o93CP48oJV1Ssjguz3ve8yij3/QrSDjo7X8/e4nj4PHzn/98er1tS6IN7V8hKsR2ezH5vvKVr2hZ
SiIQGywxUI+6twL1+wIX3D8jvNNAQzjgLFiVWfzFdIxe8pKX8FK/GVeWYHOUwv/17HUUaPuEc4W0
3GdHzgoV9OKrX/3q9t6xUqAXuesl5gAGzyMJCuBginbiuDKIXHLRBx54gLL33Xdf8heXWFC2bXrO
FEQy5cY8+qEaDD2bOYO+04Z5iRh/VugDn+bfYHKW3B2yHqmEgfNWJfXcfvvtDF86G4I95d577/3y
l7/8oQ99KH1QgoQDqsE0oieAAuHAAexA0sogHCkzgC1BugmmsuaZ9J2SR7hJn3wpzY0yYIDVxAXC
hWcjyqsf3TFiNCH3rNkscv/II4+8+93vxqryrne9K2OMQqwOXZJFk7r4hSnizXa+qE4NQ1RJwTNm
PBgN15iX8tUoswUDrKMi8sUsDDAaK0y/60SVoHIUEigHMF1GIzNo0ijaNwYYU1RrQxLpdpRkIpEV
nBuxhJFHV9hJ71RhqwrzieMq1jz3/auv05E1SmoW3nTTTSNMQbeTgRXHutMAyS5uhCP0qJMiWdc6
q0qQ44DdADjRDn65P5ByNAtxo/DAQDUMZDmeaLfWupPSAA5RXhGhR73Pugo7gMk+jIYWIPiVxTgL
oFF4YGBgYAsG0HQqmkSkEvEgijix7ubXv/419ec6gLU/frJF1RT6diflKPjNOgWwR9dGnYfGQJZy
VJxF/BJNMfvrupsVE/tgoQO30O8m36LTIpoJqgTs2R/4wAfc3YO/eMklvVf9a4V7cn0gL7NFpgSX
fPDi15/+9CeKIQEhEKy7kVUl+/LoWfz7JfLXy/+dcBzyquKXESWUiWIRCUe8RHzlJRc3jHp93A1z
bH2cJ3IcOu2RAp4mWErJUJl1LsK+A5jp2NGGIjXJXKetiUnfPJBPIl3cyQEMxkGsIIyDfC55jBib
xEqYbkiemlJfwYYw3tJ74bcDtlnGib2bLaagivwlIzo123FVgJSjlyKqWAFUV3yV5WW4BcLzfSus
yt3T4uPFH3W4ZtGzznMkjaCOOclE2qJ/1LTMnQa+qEKXdIlqMP/k1sr9gQL57DpHE6mGSIaNqE5A
a1bpRKO5yXDjnXFcAb/sdnFFmletZvCwsq/ANp/kHkJVK4pWsdgiUyVxubEPbaEai5AEC4QYGD6A
v7B/xWts4YhqfrufqCKJgwvZMrFHJqnaV3rjfi7mJbHC2WKSddOh2tLW+FbC5sYhK4JGZk4TUSWo
HGUvgn+WCz2/3C/yV+up13G+RMHpcQdyo5pe1ifoBTMM4ZY38tvZ41rBcewBRld1aqRksLSwQ6Ue
d+2plKO7NrGx8uAhN0QVFolJblJwHIWt3U/HIakNDcWKI38wnzj2sc/oCCPcgfDJmse2gjJsS0wa
6TiAbUslGydTb59LKDDRwA7yCc7tj/ttpek6ju04X6fjWJA+mM3sloc7B7WfqCLuVFKl7kM2M/6C
LrgnmrjnjRhU9y/3/Wr2dZ1ufHVzh/iwE2liBa76t6os+HHIgjjOQXl0nRkJWsRMmoXVmx/8hdaT
MujeIer8cm9u+9wo3AmX+377BjJqOAEG0pWjzTobJ4eKXp1oUl5BWXf6ZG+OA7BlPY3rpRBG5K9B
SYivW1h/adRzlVvSmLj2M0XxG2fkvenUIcfBcEuxqkGPP+60Orxq1/GqQVGFme2KcNwfSGO/E+Go
M5CLrTDbIBNQLsiHpmCr7ASLoLYt0JWULXc7xbgBMMm5Ih+hxxTsrdh4ihCOoKgi/2hpN/jlnjfN
+KLR8L9iAC5GkZbkKmIhvAaeOseA2Ey5SnEjZVnosee+BK0q2Bcxo5iTklkEeu6MwbaTVaWTvuPn
x7j0GeVA5oBEN8osn8sVhVEeSRvVcOAUzk/Ou9iGTXTdDpLsaDqlsqW2dVaVcchtC87bfNt8MYS6
zRRM9HesgzjIa1uqIW7CbAss9ayMJylYos42SW1CchRIh5iZqMK9ckEe4jq3jqMr0d2dDwCWq+g9
xHTaAuR+6qft2g31a51yNMhxyLlAR8L5ld9BCgkcZfbGgCUx2Luh9PrNm7b5Dp8O88aS8isTE2EB
/qaPOsG4sa0OPw8SDiiFDLH2exS30Q6xXBYkeU+XrXNjbSwPdOede0lv7KP3OZomBkJ+OtALnUWe
PvIy5CK4ER6YhY3ajS0AxHQcFrZMBDXlVN8WUMa3x8UAjAbCLDzp5XAckAOFiUdLreNIDN/s407D
iijQkFIHCQcwcZ7Csg1bzuE9sABJMpkoRJ5E1HWWzAultQdIPdcpd68OIbzAYzJ0WZnZRDFnHzsc
qe0gBQmHcj56aqHt7U1rgOvm6BeaV9YDv9xP+XCFwJD0hJEYIrIiDPwewK+uE7osIsiNmF47XysG
2KjkbIHeRJXVeDjuh801TW1FlZgfh+vUvN8Ay6/MNK/eo9p1Y2dNH6ew9e/HYdn62KmUbNGMakq/
6KobvQINJdvQNDBvhf3myajZw8D22F/u4spe7CFTE1N5v1x1bqNwet4R0mmuSZ1AF1fiBe+chb9/
c+x+VrottsPV30q7sfrzI35YbYGEkMOyL2L8XmeODXIcbPJs/kDmHo3dQ/VlgTxnmQujsnJd1SNE
hIUXsfL0yXFIvpBNBOFLyYEPtJHCVoSSJEsz1SErVBa9GjudbJab/wkOjq/zHA0ecpulEXvsDAyt
Dvy47iheQ2xoLDMd0oVkKBJqBBg4jjvvvNMOgO0Bdm6d0mh6R1pzK2lYXlnHhVK5rnLZo8wKDcGr
07Q6TlvepK3T+lThuJHj0CHJu+66a0V32ocRjUS7MUwpk4A9IrnQ1chh/w5FFZ1uajLDijSaHlqm
SHMdViJa2Q9gbUWV9mdVGAw7EwUuuJ9ldrwM2GVZ0FGbhwGwzWU6Wj1eOJbcmPU9oAIS1lA2/Lf7
77+/LRbgJj7ykY8888wzgIEU/aUvfemLX/yiREf5t3CvrNfcU0zWyltuuSUC+WOPPUbhO+64o23X
3NZZhAB/zz339ANSCBJAfeihh/hXuUu5rly5otNrF+ipYVj63ve+99RTT/WDAZSDzKjtakcNNzMz
T1/TA+sl+Vk0whVJXGbM1LTK3x2PKtShqBI5ACa1dg8DIRhk8QHD3Oji/kBhnHbCpIXt2qn+3Grb
iiodzddcxMWVo9COghVurypif11BONyghFBSV0kmV2hR4XUKy3HIdftwH6iGdeZYX8cB/yPTGjf9
M9UHghApzHIybgdbh6mgF4w6gq4iIVNtihuu27qiOSiLBzd2bYfwfDXseupiBbr6OqvC9mXn2Sx1
jd2s6N74JAsDrGTltY9/pQMBsg4qgKB0QPziJscj7/nlPnKmW6lzplpPnd3KAvsSCvemHG2Mc4+n
igfdOAoD1qGOI2KONVEFk6c0OLl4Vq4svkpxw7XKR7b6LDwnJprPqrOHwutElaDnqNKCNaZqa5vv
0HNUps1ZHbhc96AaCiaaGzBJ4olYjEQ3XOGVD8W55KnT1w7K0b+TMNh8UYj9Z9Q4UM5uBDwax9Xo
heXk82JnVXqghath6JDjiJzmEMmHZdDpbOv17FRw9Z1yonWVo3yy6IY7OI7V86qHD8W6as5YdoXV
VMM+zNWjLziAKWev66C1HcTLrIFdPe4CwNaBxOHG+52dpsazoLwgYIqO7dg2yKN74p77yIkethqL
1XSZg5LV606Uozojow3GZX9yV747u9785jfn+oMECYdCYMAO8auIPsN3MGueeYWhCPHYkzqAg6hi
CkuL0OHeyOYlI4hMKi5pSHTD3dKRi/22E+Xo4g5UZ4BGQqYkPFvcHfmtWtwdxeCRkkLLO1QgkWuT
gkMkJsJxQDUgMRbS0QxhUB+ZVwWGVBihHkJxYIJGKNkQfhhNZfaVHZ3tM3EQk6ZUZiFNMI1sD9GP
g4QDlJmzpo5FdpUyIxPtW4uLPxRCdJhafoSsXu65uNGbeIFFOFjGsq2Ks5i9+Es++NPAjgoSwUjx
F7/IPrks6CKEl1OA0ZTWSWnJpFxodWmC2aHkVmD8s92QvocSrvc396E9sAeNkQdDceXoKZ0phzm2
w6kbAini8L7OnurpOHJREeQ45DskTRu/8ixqT+caQSA+olHjezU7lKNxzO7tmilnYi4F4l68aSgo
TRE1EjIlLcuyDuNJTY5CrTHgmS2Kg5PlPqMkDMVhWF9hnEWxhEy5nEzb8sVFlaOH4ZkdjiGqxGep
jgLtN5NLBWrtS1QRKYLIwaL3RerWE8nsLy2136FN0RJJdFlsnj0SIGfjt6cPptkb9x50OUn1hIMM
WNpHAMsAtnpRCZ9S9IiuH/FSGhrvCCyPPVj1+sHnNHujpVnaCUjZ6XaqfPdq9+PEGtZcSlQxJhCu
vmF3NjZN8A64YvqC4GmxeUYMUcOqRhkruEIWSTwRrjZiPv75mUWV3enWQRrI0mN12Ce5GypBoS49
dghqfZAUol2H/bxkjrsCc1pRBRbXC8mxKx47rFxT6ugLTJqavSX2DocvBBJ2VjmDyvGXeY7UVh8/
hxZVukg63e2cG0uu26HZAhgyiJySzPG3yd4Ax9GVa0YWStsnnc4Ct3Lh4SJVGeF1mrMAaxJPFPGs
vjR6TlGFNXPJrqKawd1yHAoOaoJk/JFDK3DF4zCbUSXpeuoQqUgr5xRV6JUb2aE5lgcAhgHF7OAy
wrH4OLDnYkDHFJvj5NCiSjA9gqLsy4xn167WqYKVlzLH9ulbyXDsbSksOBYdVgXJ2Jh1tUinSrkj
9+U5qhNuSIPu2e3mRLoyAH3qOGA0BjO4ZSbsfQglEbZziiqzXvqJGDlNMcXd6IGtPQ1Ke+gIe+GW
6L6lunBoUWXEHI1NA7mcH9dmVmqKn6yeuHJU4d0qdPm0VpVqMUcZKoKbMlr8Ro79ID1ZsUsOR9aJ
bq/C0tqpieIIZGvxAsQql0L8OqeoopC5UsLxy/1ierElRM3/n5i1EKrBpZPObkTfdY2Ory4ZA8VF
FUWTd80IkVCvhvlDiypBqwrdqxM6EBS7ucu8R1Nfy8STqM0uZVXRkafeErXvHSciEclnLWaJ9XTU
LSW3nqKB5iLknFaVajsSsonr8Mv9VFpRFAlAkqjCIfE6Jwu6dQCrNjqnbCiR45CGKyW3HvOEy+To
FDkFxJ5TVKkWcxSK4JotuJ/aGvUGTbiyFkm6qTCn+zTHVuj4oZvQiT6NHR1R0in3McVzNJ1q0IQ2
NpOjkalTaMc5RRX4czc8L/c7cezgfTFrobhHAwCdC4+wkSHmEFHlzjvvVGDoLb5S211rctnXlPLD
ASyOJeiCHBclPvAr7YP7GKlBg56VkdMbEZnwF4eyuagClrRGXvOa1yxC6xUI6jhUrkLMUUbIVV5w
r8Tr7mWjbi89cuOVL6XjGIQjdz71UJ4NRpe2Fn6nj4uEQ6TH0/Ql9s7VksQbKuLAun2WkgIysWtW
bMGPo0LM0ZSshZRxI0pICVLBL6tPB7DhORqXpBBjsdYrTx0lla3Oe1yUxdIzciIEIZi48jUDlDI5
Dy2q+ITD1qcXwseSDC5iPLdAJGuhEt6pQmizspNxYRhWJIXctnLL96DjkCZPEUOFkDqK4Vxc9VNe
No4i8KRk5IQkMShQK51XVuxSNx20B4nSiYrWHDdYsS+qmAgwi/dcfiaxPMMjKsCvawMWvVAlcJtm
G+cmrnApJar0YI4FIVzmI6CgoYmIvcxiG3VAnqAh2jF7AsPQq8mpwAUwOO4c9oZARE1qVK7jiioL
Oo6DzrxShGO79LgdgSOqcC4OlUA396s65ZX8tWxb22dpSR2H564PW3X16tUi7N+oJAsDyoeS9cmF
F2YhpThuNsESInbZ+FiIPE2OX/g6DsldEr1cNQdi2xCtm0y10WguBhL9u3KrLVLeXBmL1EYl+Iw0
OenrEw5LhAtMbiQO4CulcCqFsgr1nCPKeQVEddVEQeVo8X7twT9KUVJ5efqEA22wBDBXbSNNpESp
i7raupzL31E5UC4K7emdlRBn23j/RoqCosp+hs4U/Af9OGT+1EgwPCg4LlDSbmuO1e7URIJNmTo9
lJHtU5d45IbcewpCCooqEghSGt2jTCyvivnMSBW807H6PXpVqs6GHIeUTfJAGxxHaEClaNSJam7E
FGNS6VY5WlZUoZutNMELeVUspj4gXiDHUYoAbamngp/bFvDafiuSodwoQCI53x7bwjbbekFRhfqV
sLLJDIm5nLtmlMs0qTRxOYdAy1W0wrzfEiYPCJvvJW3Z9RUDtF1Ucc0XKwAo9UmQcEDIsaSY8on7
btm/UriY1lNfx8HEklJD20i39Ho232piCMiC4yX/y4IV7l3VdlHFHNVb8RpCUZBwYF6BEbr99tsV
CpT7iPv93uhuVX8TjkMsN9jm6lC7AV1jn2dieIOSGAKy7FCaWrRstfvVVkpUEcVsuJffhJ01giZx
VqYl3Q+hZWt+4IEHqPC+++7bWC1bKItEh/o3VjX93OVaxV/wBhZD2K6TsVEd1BxQ6BqoVXw6Gtge
ZqQ718kOLu+xOPZUoYwpDddPbr8kgU734HTJlGFi1OLLNheqt7zlLY8//njeV2Xd5jup7RBnVTiE
wv7DpHePPOl+p5hJ09GxA10Krpl1xIN55h798oLC6uBiJ/OhHzBCZ1XyFu1zCh8xK3lWxesJO+E4
q5I7uvHyLFSJQuw/mk8ST7ipw24YeOI1gGTL1p0SArIsAqntcMrRiKiSdVK2OCZzK4yZY91UEZdJ
NXZ1OZctrTKNmJ0f8iNyFbFelhA9duiXeTjlaNyqssXIlbvyN5YPEg7MKFBHIgto8Vym43NZBzAL
xqN90oxWG4dw++fidFx4Znn7uKIHCuhGwZJqbDtsqsE4C9EvMClix2OTI17p/VLYHruUHmhKl9Mr
9ErCLcqCwVUz62CQcDDwMK4KtKXQIx1uOKvRnfhhQXOssCeRRPyqbgqursROTYvJjQp4TEW3guPg
c9etg/uCGmXompxEFQdYqNPj6l7X/FAxgbn+89nLHt2bFehifkIsFP6K3Z25xGMlE35IbwRapfpS
3JHE+KudaKE6VI6WCvdUFsPusCp2fLp+1GaIQFJVUu5qPcejZmV1BKjSAcuqee/CQoW1IkoRatQd
jhR1NWVYnq4qfR3aSypHkVDME4ndkg2kh72xwi4hNlinp5p7RlborzUhTS0dX7dlMYNZ2/Ly4Jc9
MHcL9c6quY/bHS5rYtJt6xe/+AWPUj/L1zZlUiWaxqVGsIWJEERbdTzQY6djRTjgCdXnLSr3VsO2
ol13aCVZFKGYYrBXwLPrJ2InrQkkAravxP5OY0AwQyzZcG6cq3jodmlhdkXFTpX/5S9/cWtOcepb
YeRihSoAsoXv3ak7/6w2hVVjNkSyH6XUULnMFlFlJ64YHBZk3Svjs0JzYlgqNFS5ibvuussVVeKt
S1RRMgdXopmlAu50Uv4jiDU8yIoOlhRVXA3tEU0qN27csEgnYnT16AZ9mS2wjlFfJPDHjoW/2L3N
Bdo6UG8Gv2QFK4xcyn8E5ZVfaUloAnXFTsemCGMVQFzXhHuIUNKyTHqu5GxGPrcAhONChLJ1iN3p
Kw3NTpU3rPaJJ57IbT3dyIVSg3NkufUXKR88qwLd4riBrF/WUodS+iwWOKsCxyExG5jlX6BfS+Bi
hHlaYA/1kribgwrqRaZavBJFLdoD8xWAjzRx9913P/zww4lHS9yjQ0xXiEI8KJHK6OACG56Uo4gt
uV0ueVZllkasEJ+afLJFx7ETwEPHsSjenzLR1Aodh2u7RdkRP7gkF01RCijIulNOJXUcs5q8XEo2
yg8MJGKA3bKOcJ4IT6liWaLKCiMXxMIMFxCRRIvY9t75Og47kuAlZNre0oXXMJSj8QlwVuXoy172
slPOfJ9wKIOuaL9u3OuUKBid6gEDZ1WO9oDbPWCYyasC06gTRDI6uNceEIhCoeNRqLFFfhXd++CG
dhqIvauVPy6tWK52e9Thnb0BKFi/zvXo4GLkJktUKQje7lWFVFZZ0QG2KBRRicndRWccuI8oyeTA
D1LiLQ7l6JYR2e9bHaWTiUHD7T7u1+4eNdMFC3dmRpPpzQc/+MHF6boHeFl1llSOVjMc6vy+Atjo
EKSsStMLg9O1a9eqAbY7zb68BhhcLTa5qzOUdqzrWOyGhg69ldankYbpzc0333zKcY45gNXpMLKJ
G5KX+5C0gtDEVDuWqV+OqjqevyiF1UF4w1bOpMjwtLlThaDe7OSI3HAQ1fRCsOIK8KGwcKMBuz4w
but4oynSeqiAWxgHsOvXr7/pTW/ipRL2VOjIbBMSgNlONY1WOOe0gny0G8cA81ZhH///Qrrppkj5
RAewyjhHwSSvyO9+97u//OUvs1o/BuGgh6w6zNT0LZFwUHJ7lPMsVE4Li2pAuaSXKRvbZiNsTT6H
45CbY5PWyzY6JRwKfDXbSueC2ArP0ZiowryXsQNc7HeOICXkHAf8uSw+2v9wSs8eIi47FXaqDX5H
5x07nz07dd+tFjm0IfdXtoNTxxMN8exVtukeaoslnUZJaY5oZnYqDjSIXgw5Jy2aLjGHh/AXOuXh
i5QJYGGQZNe3RwT+0xCOM+lrUsbUKxMkHOzwsF4mk7NcFden+EUrSpWKDKIZZqysXtKiTg3rkiaV
m9NMweIobVghMrN8NGZhGO6zDYemcNMhe692dTM17Rpz1MIWKeyqgQQMU3eSFEg68ePYKSZQlom+
cmFFwTxW2Kd1KGIeug5Hs3N1Xc31v1rhxxFUjqLdkFcF2gR6AruBXYOzd4Xp1j7VlUoBuRG6UL6/
jdWOzytjAEZpquNDkGe9ve1tbxMwPLpGlsoQbmxuhXI06IIJFhAKRCn45b6aL+l2itsJxxEPab29
mx3WIH7wZEES1anF60ALxJs5KziOWLZ6eE4lJedXfn6LuBsFXAxcoHJ019x3bWeXRw09UYWleFEL
JGaOBREWtPqikNJ2gh669bK573pGxbCqzI9OSDHe81gO2JpgwE3IiC4M4/px/ayVZ8C77LC4nBLk
Q3ThRr0gx4FyFG3ooeMVN1lFbqPHTSOUiDqM5fIPtISM3MDDu4ePEqvqp5gSU7kXJ1yJx0P0UDkE
6FAvJrOL9ugLKdgwi1qw38MlvBjK0Tp6U7TmkIl1cS7rQJjbikiD99UpNb5uH0sqR5WqnjnBDbYo
GJCjuHi33btkumMrdoOqtwVpY+sadx3S48Z9PJlGI+S6Jl/yauE8N45Xnc8XjtWDLPw4xX2EwmTU
AfRArUAyEPX5BXs7udtWwIYSEfKrcTfC4T7SQR5Pow4L9YVuInwNwvEvsy7Cy2FSsVSXYkByGb9W
5RuKKqdxnTyfGLI4G1kYs74YQ1SZoi7IcRBrC/EErlvJGkzlUWGvG020woCFHTp3zKFQ0J0Q2oeo
MsVMkHCALLm4KA5oq6l8uHYPzdayT8iUhpCC/uKsZrVpFG5LBjo73w49pjutIJ9wWLAzmVQ82rwT
EKPaTjCgw8fy/tSBw0MbViNYRXNngRrcm9kgQzBiZ1LllJlsnvRCpXYodtrAopTYSYGGOg7xaAfN
ZngheSpDuozQ7D2N3irUwRXm2PahA8vQv3+tpebpWNh7bctylpOF0pTKe/RuvzqxR7K19hkgc0Wv
5fE5vRig0ElWMMA4KlIZFjG7kVfYWb1FV5yODeo4vKRHcGtXr15dMXjn/gSq4VmppRs6KIcPvTsN
1ZCgPWsqjkSBCgUNVaj6c0/mrN75HId5SUOt3dPEjMGB9qJqHId0QKc5AQgdZJtNPEWeNc+aFPbi
CafAcJkhVFZwHD7hELM6i2Lo9FGm1E6EQ1TVdQmV2fIchIO+QDWUgyJlje1XxpzNUpr48Y9/TDEC
6kxvFGvn8ccfN3KweCN58yjzPAU/KWUKEA5rBhQ3n0ApfZ4tswfhkGqddaW5JWEE9pVd+gTsvagG
fexhzUR2rxVTgtGR3J1ygx6U1ntAwoqerv5kBeGIBfJZDcdZP5QDvgVbh7Dq+N8J+otkKu1MP31J
sdDNnkmbGgr1RrQjfiNTdD9I6BaS1BSQbK1DOdrtKG4HjOV0XAZze/dHDbkYCBIOOHA3nMnFUg3J
24rgcugQNd7MgMWwfvEX47tfzq30Sak4OunHKSF2g96lo7dgySDhUBJ5+Q7Kj/CgJsYtyFIeEPoO
Sywh5TRIYHDpnVh9UNQ2w647RhZHJ2Xg9ssTltL6RZcJSZIgRS6kzDB+EeZNREwRPtuWKeU5emg3
0LZDsK71FJ2FW3Nu+XVQnf6rFZ6jyzoO+b2c1WfuEjYNJCyJIfKk5J4rfqyrDlp0ms69ckNVDlGl
zkhNWwkSDnhyBaGBZMCuM6IXeEb2HOepdc7VOykv21Craad2pwHEdMQuHaohqqTjqnDJEBuGdoNl
w782vQ6Ub6aUqHKBwWxqsuXbA+QMUaXIeJUUVRS/ByrF2CDq4xizn/qazZCgQajT+Q2FkIH9IS+U
DD0EGaoTru64MTVlAOLiJp4IuvBGFK3Oi9KQK5hM6x6iSs3hc9vyXc7joZ/2iAfPtIYioNWnclpH
/IZIeSoVykBToGUUYzHIXEexENZKeY4q8nA/Fof0WYLiAA6R8uAKxTaPPYTz905OqjvwHavnlbQ2
zWWu9HHps+QKz1GfcMwOrfV2Dy9JxG/ql9WGy3vUS0RZOA4YHz2KjkQm3IUTDpaTcv0KV9yzt0OL
m2upmF1QYe8E6pY4wINwFKFEKwhHMOl0EdkppRImtJu3hXvexD+UDAXHESp24ToOxXxMQX7lMoxa
WU0ZcyAyDSr37rjNldRxFKFkKZWwJbqCCfdx/QWiCgyIgtxF6r9+/bpU7nW0ISk9rVMGcQ+urU6v
aWuaMDHypggGLAkjNwi5I93PaqwihmuN/PWvf82tJBgBbCqz7HSsnoZcoYO5CP8ZkokUOAeSAWMS
YbwvWVSRXsZcQnMnRFZ5DRbSR7oQtBEwxYVhAkgtIr/e2UChWR258MIlRRU3gqtW6U55VajZE1Vk
BvYuOFJNF/mzxq9SosrhPEel11hCT7H/t9tTc0Gp3MFc8A5avqSoop1BFxQdu9dOPCH1u2Y57qc6
dsQTdjYlNF6tgT/frmJ2Vlmj1EFTIe/aX7G4e+SpE/8sjfj0hukh2jGuxhhIpJHaWxILZxVTzcwG
bjQnjKfQS2pTnFiXCeI+kuu4FMfRuQMYNEJoUf50yXcpHFnWAM0Wdmdt2Ra1MZisOnuzHf5Rg4uB
FRxHkBZ4q5ThXDR2rB4MWVKYLsrlYfWIoPA4y2VE5uuFEI7VCN/+oQ3N9qqmMukwlBTHarzCkoTD
Y4Q8TUTljuU2V4pwaDPv07QJTuqrGKY0PWtotBvBx0EaQjcgvKzJNgvCyyy8gnAED7l5GGSwL0p3
LWdzrp7j4ks8OZDSRwdh0VOgvAjd8O92V/TG8v8FNL98rP4CkDDTRREO1LE9p+Hp5xBK4iSRzgjr
GLr2yM1+p6IS4RzFFjEQIxwQfu9U0mJ1pymg42F0Z4tD9GmwUaojBChkRimHM4xS6CbrZH0p2EY9
WRgIEg655XlxVrKqPnThPQyN2xGiGDyKf0Nt3KNOrhxjSUGApn0RVIrMGrrZjoFRQycYiMUcneqo
OgF6bzDkqC5eeu+2cutvTtEUh1VWNgPedSSJ9Gh67jm3+6N8LxgIqZGBr6x9vqa+eqNVxfxHasJ8
lLZmfTeHQ+dRhm8WzhVWleBZFeQUnVtNP4bQCy18znNWn1XR2YdqZz1yMbZHblfqzDoRJ82X+WWp
C9KFDaVm7oB2Ur7kWZVZx96jkNXVHId4jW5ZLTxKisO2zprrzQQ5vBxlegw4PQys4DhiCZl0osy9
OiGQO4Fh2aTXraWdoKpQrfxBsi4PKh1arQDqaKITDAQJB/ZInYBwr06Avlgwul2fTJJx9uyipmUs
PUKW6HtcrBEQhMg3WFJk6dy1I7QlWyY3UAE5UKY/YlKRm/mWy4u+E48yu6Wh8e2JMfBv999/f6h7
TGs0hU899RQURFdll4HVeH/sscf49o477kip4Zlnnnnta1+L5ZXecb+rx9c999xz5coVmqAheUDd
csstuY8pnYqUYRwfeughRYf+j/+9NhqeFWApMpc2wjw+3xUDX//619///vfnNRGSbGfl/CwxuGHh
LOUoe3i1Y2xg1Y1a1ARFexyNG8rRJkNZqtGSytFZ7X0eTeq7tA5ZcbFVVhPKxNe0Qowko8SATHIA
tSyN8ZuhGW01pq3avdxDbqxh0QtOslUzo3gOl5VHXYQyMa+lnQ9OBHJv9VAiGKNYJQxEPEc9CFYY
7UqxUrn1pIgqTdxDQWlDfwcZyBKRuYdEk9j0KFYZA4VFFfPgkP/omeJxSNe7nTZrW6YeZVpcfNwv
k6Zlq5RnJ48/+tGP8KB95JFHHnzwQd38/ve/52C7Dv6qTOSGEe/ztM72URs1FMBAIm1LyZOUWFWF
YoscB0sife+NAKxtmQJyZFh83C+QmjEIErt4fMMb3jA7P9R3lUm5qTBeo4m2GFjBcQTPqnhzLp7u
pAABK1rF4lkVneYkvumWZtEdsmlzQIPlJ90Bl6K0Rx53OgivsFo6LQJUaHAefvjhe++99zOf+cyL
XvSiv//976961auwrPPvXXfdJeZIWp7FmyMeVtoyrBf47YqzKkHC4fkFyfRQJ/T+9pFLIRwnO5Ql
ucN1QhGtN7ZiO1ZHDWfFwArCEbSqeCF8mJSn8SlmZ2aZzW6kCjahJccs4Tf+aNlMZqcUn8tVVFkL
c2/uvvvu9ASLBNeifn7tk9lwO2ed+qNflTGQKqpUBmtjcxGOA9KAgzlEcJbjYIXDW8FY8S/KYJ2v
B5jQI39FdMZQW5zEJZvowH7WzdNPP/2JT3zirW99K96lTzzxxL8/e8VvXve61918880u9gCvoefI
xnEcn9fBwAqOY5lwhDbnOl1a10qccEAO6iwnuVqtjlIxZI11oz++ysXACsIxI6qwSRLFx9pmB4YB
jvPkuYBWKK9s9TTkZhKE+Wc1fuMb3xBlmSYZfOc73/nyl7989q/ZjISRZIWKvpnrFqWTb/slWKyA
+dHERWDAswPJ0OCaKnE9wLeSlzslnd7DEIU5VoNH5d6N+jL7Fybn0F/TelLegLpco+9UkVQ8cs8e
CB91HhoDK8yxPscBZ6HczkY1UdRDMnh5LKYD2qG1rRHVDf2yRJbeXyqjE2izf7n1JJYBdetOwbuz
sJo7/EXsk6OThTDg6zjQyYtMePUjv1y7ds222UKt51WjkBl8g4YirjhAEvn+97//3ve+949//ONz
n/vcF77whT/5yU84O//LZ68Pf/jDP//5z1//+tf/4Q9/oLYXv/jF9sh9HkylS4Nn+tgWz6X7NOrr
HQMrdBx+0mm6OMsbm09kK5YMHh4DKkSNixsIRwSSz372s72PVRS+Vkj22q0WbWB1f/Gg51r9eZ0P
+0cjm2guKnyO47bbbmOJTk2MbINs+AxSqwXpAqawMRFvNAyuP/3pTz/+8Y97HAePL3jBC1wWw+M4
/va3v+FhWaePRE953/veN9tWJ+KJuaLWQciKVuSm2Am6QvD3j8aXvvSlTz75ZB7+PUoDyUAyn5If
XvJXLlkqVV40wvYW0a8IIQfUhtAm9rrhMdnTQKhzmIndaVWs/4G+9dZbc5Hjcxx4bbC3Ky2wwskp
QC5mxYZpuKYnZdDFRJyp4TgeffRRXKeAH6QQrS+PmlYpjcEY62+VplY20j+EN27coG+vfOUrV/aw
ymfdohEugxCW4OA73/mO9H3pl29VQX3ATo7pAVcOOS/Lc7kh1UjvjJX89Kc/LarR89U51QB1/UMI
yeicahwCjStOkwQ9R7tK1w6/AyFDQtEBE2DDJw1atjHEbs9kZcA2MNAzBoKH3BRgTpG4m3dAhz4t
3zI3PA6q0XxcBgAXi4HDxBxF2Yl2GpLBxc2ZwpFd7OQbHT8uBpYPuXXSN8QTdLSKpo1ItvrkWCfd
GWAMDBwaA4chHIfG8gB+YOBkGDiMqHIyvI/uDAwcGgODcBx6+AbwAwNtMDAIRxu8j1YHBg6NgUE4
Dj18A/iBgWIYwP6QHqf2tIQDky1OYlyJqVKLoT9QUQo8lMHfH29dgc1A7g2VWz9+/WqdXy/G/RQM
zhlSsiZ4tJUIIQZ760j9pLaLA82wciTC3LJzY8Tth3NwtTju/2w993DLIcpnncGv0KMUeBR/TFmd
lDqv5uEozhmoReWd18mDEGbw2ZVbYAXUWROJECrqAghURwCy5im4lIHGqVLBsQCMwDdA2zwyAGBY
ROvEMa069okwbS8GFhTLi6uHHHQp8DCf3BO9oiPbUZFYg3eeOHK8mFmu7tQEj14kQuiiOrHvBYul
DLRHyyqTttnO6pCxfKMSsZFaLrG6HorlnsHfG+Z18Gjn3Bs2q99bbxFqa7tl+iQr0osUCIVqUKf9
k9/KXBuNLgZ/8DgOPukk0k9WsK4T6jiUTdqO2OimSIrpdeLlCnj4BIGzpls9LbrpV7ifxRjCOfN+
GllyHWayvkqBUDArb44EAQWgympodeHEgVY8cAJxoolEHQOoR0x8c0LCsXrge/gQzRkTnaPArM/e
3OpZhMqV2wOiIjDALkFzhUBu7GxkJ2AzvnBt4jLQFimNcSewpYNxQsJhR++FBdkmGp7xTYdH5gAA
Zj5VXp8A6bIY3E8xphOGbpQW7qvt5ykQasRdhgjyUY3ZTBlobCiQCQZXXAYUBI6jGg7T6cJiyRMS
jt7O4CfCw84Djw0fK/3C4siVLcACc+2C3E8DeTLdpUUzRRo31eSpFAgVBcLdwJV5syyuQrUlDrRt
Zu7GVgfCkq0UUVz1VolnFaupIZtFRQgemQz1iXQHtjIrR9OUYszMsdybFVMvvX5lKdKKTI8IhC4a
hWrROJljayYSSxlo6AuXDMbAWdnuHhmLrDE9oVUF1KDZtmhozalGBB4BqbGc3Q2KLLnESozTYYt2
F5sISnPCAQAhCF00UkyrF7C9jiTiYUux0MRzIaQMbJpB2MP8VJezCMc4Vl+SfRt1DQxcCAZOqOO4
kJEb3RwYaIiBQTgaIn80PTBwVAwMwnHUkRtwDww0xMAgHA2RP5oeGDgqBgbhOOrIDbgHBhpiYBCO
hsgfTQ8MHBUDg3AcdeQG3AMDDTEwCEdD5I+mBwaOioFBOI46cgPugYGGGBiEoyHyR9MDA0fFwCAc
Rx25AffAQEMMnJNwcJhaYSO8qyyiqTwjKnS47VL1lO3dhdemKXREJNSB/JyEQ+PtHVHX4b+Nlzsq
iv6wscLx+cDAETFwZsLBwvausiMEJSKwQtk6R20DA4fAwJkJx+wAECEWroFfMaLKjkMCJCUicoO4
uXl99J5fpbrSt66IQdQpN5eSNa3miEyrNEuh/EBE3BJIXiqmKQyqOQK2QQI8Fm7TTQJEfy3Vk9rl
lyinXiomazoENl+pX1x8bgHEXLS4DJqLeTdRlocidwjsE8swNosQFxJAst6FuhDCKqOjQXS7482i
WUwCAF+5IdSoATzr29nmvHnothIZlNA0UxI2jaCX4SnU2cXxXaBfW8KWdPutpBJPVFHcet4rar6i
WhFSReFeLGAU8T55r1DUbkQsgjV5wU7UhFfYy6VEGUt0pFiYqt+9NEJuKiYlWBEMCgvGPdyTBX1J
B9vrJvXAJVkCFyFKmQf0l3IyKM+AQFL00ynYfAVIQrJ9KAxbxDA3NoyLCgW2Ue4b9/0UexosGxRL
zqCQhUKIQaIugLFIF7yMTRaAy02IZVGgpjPcMO9h0k3FIOzFYfbmodtQaFDcOekhylIu6D2Vq0Lv
EwMyZXzjq/ucEcBm1RmazTbbhBdFcDMc2aRXFFl7z+LRo7cS9K1XWKNldMqtx11UbqPTVEx8rhhz
VkyZkLLAplo6yIe0a0G9XPCMwqpa651uLEUIj9NsY26d/GtojBAOFxXApt5Rfrb708GivAsGj0KI
CwlLQis21AWRHsOqshNoEF0wvKhiKh/BpOIPq5h7H4E5FPsrNCihaeZB5UI+/URApozv5RKO2Z5P
ly7zjNUFuhWe1+iLS1CsqlnCMa0zVE+IcHhtqZg4Ee8ySNLBdmHW5waG95f7CDa0QYVidmpzY3tn
nbj8SIRwuN20trKwN4sQRe5k2XPjJjea7UIIqx4YU6R524aHSZfLYLmKPxWqZ2GenQn6JDQoIURF
BjEyhRbHN044Lk7H4aFSagtF0DcGdRbdrV564ycwKoDNdBRvguSPxD7tPguV1QLhQMBWeqEKKJrO
Zg0ckLASgARQTUsS6sJ0S9gOOUQWeoHigLmElsFN0TAL8/YWE2sIdXZxfBfqj9OVg/47u114W4Q9
2o4qlm9W+lBqH283CBX2RJVZUchFLPXMZo2Vycbjq7Wjuu8jYLOigHxRVJnyU3AQ7tY9uz268osL
g1vYi8a8QlRxsedJGRIzXSmJjgj53IS64HHv1CBVy0ZRhRpAtXgNKVl0zcKsEZxlaSMcxzpRxZ1a
4ERDkDK+8bV/Zh3HbM+9AWOjMO2ju1BDiiiRJHHmVlVEa+U1NztdRNpNE2nqOlVrudeVUlydSgFb
i1Z0x1XpiatXPSEu11W+Sg05zW+qPdayrlsZ6ue9FqRymhiNtm66sLndnypH3dWlf71M9JIR3EEU
lkJdCA3WVB1ukLsTKYRJygiSaY7bKczrCEdkmmluKClPXDmqoU8Z30E4/gUD3tKFBGhya7mKw9Rk
ZRjcv1QLk8MWg1uVLRIvTUYi4Qh9LtW9lhaw2eqNgG1ZwtwZrJD8qocbV+vpLg+jIxQwZtvbMw2b
wGBJm9wyVCIU8asyRjiATZ/wl6sFsPdx7FGPdJmqwVX36qWwJLIe6YKLIpcJctMvyMgyXTwhTKqk
a12yb2dh9iaG21BEZxGaJ9ZZESkXcnca29CnjG+ccIz0CJpv49odA3gZsCSmCeJC73cHaDSwAQOX
rhzdgLrx6cDA5WJgEI7LHfvR84GB1RgYhGM16saHeRhATjF9jftl6H1e7aN0XQwMHUddfI/WBgZO
gYH/B/2+gF+Tv5kXAAAAAElFTkSuQmCC

------_=_NextPart_001_01CAE882.19F55469--

From richard.kelsey@ember.com  Fri Apr 30 10:18:46 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334AC3A69A2 for ; Fri, 30 Apr 2010 10:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.281
X-Spam-Level: 
X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-1.719,  BAYES_60=1, J_BACKHAIR_11=1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl76H-Bolnsd for ; Fri, 30 Apr 2010 10:18:44 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8C1E33A68E7 for ; Fri, 30 Apr 2010 10:18:43 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 30 Apr 2010 13:21:44 -0400
Date: Fri, 30 Apr 2010 13:13:25 -0400
Message-Id: <8739yc279m.fsf@kelsey-ws.hq.ember.com>
To: roll@ietf.org
From: Richard Kelsey 
X-OriginalArrivalTime: 30 Apr 2010 17:21:44.0160 (UTC) FILETIME=[9AF82E00:01CAE889]
Subject: [Roll] RPL ticket #32: Asymmetric Links
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 17:18:46 -0000

Note 1: This ticket is not concerned with asymmetric links in
general, but specifically with how path metrics are constructed
from asymmetric link metrics.

Note 2: The ticket is against the RPL draft, but this is really
an issue for the routing metrics draft.


The problem:

An asymmetric link metric can be used to create a number of
different path metrics, depending on how the upward and
downward link metrics are incorporated into the path metric.
The resulting path metric might reflect:
  - the metric for messages travelling upward
  - the metric for messages travelling downwards
  - average of the upward and downward metrics
  - best of the upward and downward metrics
  - worst of the upward and downward metrics
and so on.

Rather than try to encode all of the possible combining
functions, we can allow the inclusion of both the upward
and downward path metrics.

A useful example here is latency in a network where nodes
wake up to receive messages on a fixed schedule.  If nodes A
and B wake up to receive once a minute, with A waking up 5
seconds before B, then the A->B link has a latency of 5
seconds while B->A takes 55 seconds.  If A chooses B as a
parent when building a DODAG that uses latency as a metric,
what value should it use for the latency of the A<->B link?


Proposal:

Add a flag to Routing Metric/Constraint to indicate whether
the path metric represents the upward (flag = 0) or downward
(flag = 1) metric.  The flag would only be meaningful for
path metrics that are aggregations of potentially asymmetric
link metrics, such as latency or link quality,

A single DAG Metric Container would be allowed contain two
Routing Metric/Constraints of the same type, one containing
the upward path metric and the other having the downward.

                                -Richard Kelsey

From roger.alexander@ekasystems.com  Fri Apr 30 15:33:39 2010
Return-Path: 
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18EBF3A6C72 for ; Fri, 30 Apr 2010 15:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.068
X-Spam-Level: 
X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khTHQ8lePu-8 for ; Fri, 30 Apr 2010 15:33:37 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 8652C3A6A3F for ; Fri, 30 Apr 2010 15:33:37 -0700 (PDT)
Received: (qmail 75807 invoked from network); 30 Apr 2010 22:33:21 -0000
Received: from [10.85.83.37] (roger.alexander@166.137.9.55 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 30 Apr 2010 15:33:19 -0700 PDT
X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J
X-YMail-OSG: xSd14mcVM1k7XLNP4CzOG1IRJQSsd0onTTyycvGE5qhe1uHbV_KhHIYvrX2uPvBBpHXK8Lf9_RKzqMUgm3_Udku4kXYxlCeP3gN_sZ03YFhG_Ndzh4V7KoKbQP8IbvjeyhpD7_nvcWo5APINIT5lkXHUdi4gZSqtdJiw4mc2DjxvFlDW0j4_VMReb1DJS6ouNTjvPY3iPgdBNjjTUeRbK6ML_lJkX573lAtCa1ZqbK.P2pP5Et7A5d80vTWhEzPZahL0rEhaPQ1sAV6.2r4qiOm32atlpvogo_LE2tqUNnErQpZZgIGSnAG7_jfi7gZRvIY1l4UGT1nbGu_PzeoLhA6WCCQzbETMC2pvwEYx3ureAKc6ba2tWQQRCzzskumhcTiXUlf4ONs_4338J3DHkX4-
X-Yahoo-Newman-Property: ymail-3
References: <4BD8E89C.9020809@eecs.berkeley.edu> <02dc01cae7c3$0023b6e0$006b24a0$%alexander@ekasystems.com> <4BD9CF1E.20708@eecs.berkeley.edu> <-6403192417562817879@unknownmsgid> 
Message-Id: <8FA6794A-9DF8-479A-8D5E-375D0A159D47@ekasystems.com>
From: Roger Alexander 
To: "M. B. Anand" 
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-1-154334428
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7E18)
Mime-Version: 1.0 (iPhone Mail 7E18)
Date: Fri, 30 Apr 2010 18:33:13 -0400
Cc: "roll@ietf.org" 
Subject: Re: [Roll] Fwd: Re: DAO fan out
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 30 Apr 2010 22:33:39 -0000

--Apple-Mail-1-154334428
Content-Type: text/plain;
	charset=utf-8;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi Anand,

Thanks.

Roger

On Apr 30, 2010, at 12:36 AM, "M. B. Anand"  =20
wrote:

> Roger,
> 1.       While =E2=80=98disjointness=E2=80=99 as you have defined it =
does capture =20
> some measure of the independence of paths, it may not be adequately =20=

> reflecting the increased path availability that results from multipl=20=

> e DAO Parents. That is, it is possible
>
>
> There are both overall path concerns and local concerns here. The =20
> availability of a lot of alternatives at a given node along the path =20=

> says nothing about the overall path since there may be no edge-=20
> disjoint paths and everything may go through a single edge, so there =20=

> are no independent paths at all. On the other hand, you might argue =20=

> that you do want to capture the high availability of edges at a =20
> given node .
>
> If you wish to get a measure of the overall situation over the whole =20=

> network, you might perhaps consider the formal notion of edge =20
> connectivity - defined as the minimal number of edges that separates =20=

> the graph, and evaluate it for the whole graph with multiple parent =20=

> situations and see if it makes an overall difference. Would depend =20
> completely on the topology.
>
> You could also do the same exercise on a per node basis, with a =20
> subgraph consisting of all edges and included nodes in the LBR - x =20
> paths, where x is each node, and evaluate the minimal number of =20
> edges that separates x from LBR.
>
> For example, in the first step you give in the example below, for =20
> LBR - A paths, that number would 1. In the second step, it would be =20=

> 2. In the third step it would still be 2 (LBR - C and LBR - F still =20=

> separates A from LBR. Also, a useful graph theorem is that the =20
> minimal number of edges that separates a vertex s from t is equal to =20=

> the maximal number of edge-disjoint s-t paths and clearly there are =20=

> still only two edge-disjoint paths). In the fourth step, it is still =20=

> 2 - same as above.
>
> This would be the situation for the overall A - LBR path.
>
> If you wish to capture something about the fact that A has a lot of =20=

> next hop choices by step 4 in your example, regardless of the A - =20
> LBR path, then you could repeat the above exercise for each A - z =20
> path where z is each node in the A - LBR paths, and arrive at a =20
> range of values. For example, 1 edge separates A from F in step 2, =20
> but 2 edges separate it from F in step 3, although the addition of A =20=

> - H - F didn't do anything to improve the A - LBR path. Thus, if you =20=

> added several A - Hi - F, with i going from 1 to 50, then 51 edges =20
> will separate A from F, thus capturing the high availability between =20=

> A and F, but again contributing nothing to the A - LBR path.
>
> Regards,
> Anand.
>
>
> A simple example to try to clarify these thoughts. Consider a =20
> downward path between an LBR root node and a node A given by A-B-C-=20
> LBR. Disjointness is of course 1 (3/3). Add a second completely =20
> independent path given by A-E-F-LBR. Here the disjointness of the =20
> two paths is again 1 (6/6, all links remain disjoint). However the =20
> path availability to node A has increased (all links equally =20
> available, it has doubled). If a third path is added via a third DAO =20=

> Parent given by A-H-F-LBR. The disjointed measure has fallen to =20
> (7/9) even though the availability of the connection from A to the =20
> LBR has increased. If a fourth DAO parent is added to offer a path =20
> given by A-J-B-C-LBR, the disjointed measure falls further to (7/13) =20=

> even as the path availability from the LBR root to node A has =20
> improved due to the additional diversity along the path from B-A. =20
> What this seems to be implying is that even as disjointness is =20
> capturing some measure of reduced path independence, it may not be =20
> adequately capturing the improved path availability potential. Let =20
> me know if I have accurately characterized the measure.
>
>
>
>
> Regards,
> Anand.
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-1-154334428
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Hi =
Anand,

    Thanks.

    Roger
    =

    On Apr 30, 2010, at 12:36 AM, "M. B. Anand" <privateanand@gmail.com> =
wrote:

    Roger,
    

    1.      
While =E2=80=98disjointness=E2=80=99 as you have defined it does
capture some measure of the independence of paths, it may not be =
adequately
reflecting the increased path availability that results from multiple =
DAO
Parents. That is, it is possible =


    There are both overall path =
concerns and local concerns here. The availability of a lot of =
alternatives at a given node along the path says nothing about the =
overall path since there may be no edge-disjoint paths and everything =
may go through a single edge, so there are no independent paths at all. =
On the other hand, you might argue that you do want to capture the high =
availability of edges at a given node .
    

    If you wish to get a measure of the overall situation over the whole =
network, you might perhaps consider the formal notion of edge =
connectivity - defined as the minimal number of edges that separates the =
graph, and evaluate it for the whole graph with multiple parent =
situations and see if it makes an overall difference. Would depend =
completely on the topology. 
    

    You could also do the same exercise on a per node basis, with a =
subgraph consisting of all edges and included nodes in the LBR - x =
paths, where x is each node, and evaluate the minimal number of edges =
that separates x from LBR.
    

    For example, in the first step you give in the example below, for =
LBR - A paths, that number would 1. In the second step, it would be 2. =
In the third step it would still be 2 (LBR - C and LBR - F still =
separates A from LBR. Also, a useful graph theorem is that the minimal =
number of edges that separates a vertex s from t is equal to the maximal =
number of edge-disjoint s-t paths and clearly there are still only two =
edge-disjoint paths). In the fourth step, it is still 2 - same as above. =

    

    This would be the situation for the overall A - LBR path.

    If =
you wish to capture something about the fact that A has a lot of next =
hop choices by step 4 in your example, regardless of the A - LBR path, =
then you could repeat the above exercise for each A - z path where z is =
each node in the A - LBR paths, and arrive at a range of values. For =
example, 1 edge separates A from F in step 2, but 2 edges separate it =
from F in step 3, although the addition of A - H - F didn't do anything =
to improve the A - LBR path. Thus, if you added several A - Hi - F, with =
i going from 1 to 50, then 51 edges will separate A from F, thus =
capturing the high availability between A and F, but again contributing =
nothing to the A - LBR path.
    

    Regards,
    Anand.
    

     
    


    A simple example to try to clarify these thoughts. Consider a
downward path between an LBR root node and a node A given by A-B-C-LBR.
Disjointness is of course 1 (3/3). Add a second completely independent =
path given
by A-E-F-LBR. Here the disjointness of the two paths is again 1 (6/6, =
all links
remain disjoint). However the path availability to node A has increased =
(all
links equally available, it has doubled). If a third path is added via a =
third
DAO Parent given by A-H-F-LBR. The disjointed measure has fallen to =
(7/9) even
though the availability of the connection from A to the LBR has =
increased. If a
fourth DAO parent is added to offer a path given by A-J-B-C-LBR, the =
disjointed
measure falls further to (7/13) even as the path availability from the =
LBR root
to node A has improved due to the additional diversity along the path =
from B-A.
What this seems to be implying is that even as disjointness is capturing =
some
measure of reduced path independence, it may not be adequately capturing =
the improved
path availability potential. Let me know if I have accurately =
characterized the
measure.
    


     

    Regards,Anand.
    

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

--Apple-Mail-1-154334428--